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

Versions: 00 01

Interdomain Routing Working Group                             N. Leymann
Internet-Draft                                              C. Heidemann
Intended status: Standards Track                     Deutsche Telekom AG
Expires: July 18, 2015                                      M. Wesserman
                                                       Painless Security
                                                                  L. Xue
                                                                M. Zhang
                                                                  Huawei
                                                        January 14, 2015


                  GRE Notifications for Hybrid Access
            draft-lhwxz-gre-notifications-hybrid-access-01

Abstract

   This document specifies a set of GRE (Generic Routing Encapsulation)
   extensions which enable operators to construct residential networks
   that are able to access the provider service through more than one
   hybrid access networks simultaneously in order to satisfy the higher
   bandwidth requirements.

Requirements Language

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

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on December 11, 2014.







Leymann, et al.          Expires July 18, 2015                  [Page 1]


Internet-Draft                 GRE-Notif.               January 14, 2015


Copyright Notice

   Copyright (c) 2015 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  GRE Solution Overview . . . . . . . . . . . . . . . . . . . .   4
   4.  IP Address Assignment . . . . . . . . . . . . . . . . . . . .   7
     4.1.  IPv4 Address Assignment . . . . . . . . . . . . . . . . .   7
     4.2.  IPv6 Address Assignment . . . . . . . . . . . . . . . . .   7
   5.  GRE Solution Function . . . . . . . . . . . . . . . . . . . .   9
     5.1.  GRE Tunnels Setup and Management  . . . . . . . . . . . .   9
     5.2.  Packet-Based Traffic Overflow . . . . . . . . . . . . . .  12
     5.3.  Backward Compatibility  . . . . . . . . . . . . . . . . .  13
     5.4.  Bypassing Traffic Statistic . . . . . . . . . . . . . . .  14
     5.5.  LTE and DSL Path Difference Consideration . . . . . . . .  15
   6.  GRE Control Message Definition  . . . . . . . . . . . . . . .  15
     6.1.  GRE Setup Request Message . . . . . . . . . . . . . . . .  17
     6.2.  GRE Setup Accept Message  . . . . . . . . . . . . . . . .  17
     6.3.  GRE Setup Deny Message  . . . . . . . . . . . . . . . . .  18
     6.4.  GRE Hello Message . . . . . . . . . . . . . . . . . . . .  18
     6.5.  GRE Tear Down Message . . . . . . . . . . . . . . . . . .  18
     6.6.  GRE Notify Message  . . . . . . . . . . . . . . . . . . .  19
   7.  GRE Control Message Attribute Definitions . . . . . . . . . .  20
     7.1.  Client Identification Name (CIN)  . . . . . . . . . . . .  21
     7.2.  Session ID  . . . . . . . . . . . . . . . . . . . . . . .  21
     7.3.  Timestamp . . . . . . . . . . . . . . . . . . . . . . . .  22
     7.4.  Bypass Traffic Rate . . . . . . . . . . . . . . . . . . .  22
     7.5.  Filter List Package . . . . . . . . . . . . . . . . . . .  23
     7.6.  RTT Difference Threshold  . . . . . . . . . . . . . . . .  24
     7.7.  Bypass Bandwidth Check Interval . . . . . . . . . . . . .  25
     7.8.  Switching to DSL Tunnel . . . . . . . . . . . . . . . . .  26
     7.9.  Overflowing to LTE Tunnel . . . . . . . . . . . . . . . .  26
     7.10. Hello Interval  . . . . . . . . . . . . . . . . . . . . .  26
     7.11. Hello Retry Times . . . . . . . . . . . . . . . . . . . .  27



Leymann, et al.          Expires July 18, 2015                  [Page 2]


Internet-Draft                 GRE-Notif.               January 14, 2015


     7.12. Idle Timeout  . . . . . . . . . . . . . . . . . . . . . .  27
     7.13. Error Code  . . . . . . . . . . . . . . . . . . . . . . .  28
     7.14. DSL Link Failure  . . . . . . . . . . . . . . . . . . . .  28
     7.15. LTE Link Failure  . . . . . . . . . . . . . . . . . . . .  28
     7.16. IPv6 Prefix Assigned to Terminal Host . . . . . . . . . .  29
     7.17. Subscribed DSL Upstream BW  . . . . . . . . . . . . . . .  30
     7.18. Subscribed DSL Downstream BW  . . . . . . . . . . . . . .  30
     7.19. Delay Difference Threshold Violation  . . . . . . . . . .  31
     7.20. Delay Difference Threshold Compliance . . . . . . . . . .  31
     7.21. Filter list ACK . . . . . . . . . . . . . . . . . . . . .  32
     7.22. End AVP . . . . . . . . . . . . . . . . . . . . . . . . .  33
   8.  GRE Tunnels State Machine . . . . . . . . . . . . . . . . . .  33
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  34
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  35
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

1.  Introduction

   In order to provide higher bandwidth for residential subscribers,
   operators prefer to bond the LTE network with DSL network to transfer
   the subscriber traffics.  Especially, in some certain places (e.g.
   the old cities downtown), the DSL network is already overloading,
   even it is extremely difficult to be updated and rebuilt because of
   construction .  To satisfy this requirement, HYbrid Access(HYA)
   architecture is designed in
   [I-D.lhwxz-hybrid-access-network-architecture].  A solution is
   required to fill the gaps for operators deploying HYA.

   This document proposes a packet-based HYA solution, which achieves
   bonding the hybrid access networks via extended Generic Routing
   Encapsulation (GRE)[RFC2890] protocol.  This document presents the
   GRE protocol extensions required for HYA, specifically, those for
   signalling to setup, bond and management these GRE tunnels,
   signalling for reorder and reassemble customer traffics.

   This remainder of this document is organized as follows.  Section 2
   lists the key terms used in this document.  Section 3 outlines the
   overview of GRE solutions.  In section 4, IP address assignment in
   HYA is described.  Section 5 discusses the GRE solution functions.
   The definition of GRE control messages needed in HYA are listed in
   Section 6.  The attributions used in GRE solutions are listed in
   Section 7.  In Section 8, GRE Tunnels State MachineSection 8 is
   discussed.






Leymann, et al.          Expires July 18, 2015                  [Page 3]


Internet-Draft                 GRE-Notif.               January 14, 2015


2.  Terminology

   Customer Premise Equipment  (CPE):  A device that connects multiple
      hosts to provide connectivity to the service providers network.

   DSL GRE Tunnel:  The GRE tunnel between CPE DSL WAN and HAAP.  The
      DSL GRE tunnel termination IP addresses are IP address of CPE DSL
      WAN interface and HAAP address.

   HYbrid Access (HYA):  HYbrid Access (HYA) is the bundling of two or
      more access lines over different technologies (e.g.  DSL and LTE)
      to one Internet connection for end customers.

   Hybrid Access Aggregation Point (HAAP):  The HAAP which acts as a
      service termination and a service creation implements bonding
      mechanism and sets up a high speed Internet dual stack IP
      connection with CPE on top of two or more hybrid access
      technologies.  The packet reorder, reassemble functions in packet-
      based solutions should be supported on HAAP.

   HA Tunnel:  HA Tunnel represents LTE GRE tunnel and DSL GRE tunnel
      defined between CPE and HAAP.

   LTE GRE Tunnel:  The GRE tunnel between CPE LTE WAN and HAAP.  The
      LTE GRE tunnel termination IP addresses are IP address of CPE LTE
      WAN interface and HAAP address.

3.  GRE Solution Overview

   The GRE solution is proposed as a candidate solution for HYA based on
   per-packet traffic distribution mechanism.  Only a dedicated GRE
   tunnel is setup over either hybrid access network between CPE and
   Hybrid Access Aggregation Point (HAAP), DSL GRE tunnel and LTE GRE
   tunnelFigure 1.  Bonding these GRE tunnels is preformed on CPE and
   HAAP.  In addition, the types of packet distribution rules over
   hybrid accesses are deployed on both CPE and HAAP according to kinds
   of criteria (e.g., DSL load, failures, service list, etc).

   To achieve these performances, the possible communications between
   CPE and HAAP are needed to achieve GRE tunnel setup, bonding and
   management, while to deploy and control the consistent traffic
   distribution for efficiency use of network resources.  In addition,
   packet reorder, reassemble and fragmentation issues should be settled
   based on this
   communication[I-D.lhwxz-hybrid-access-network-architecture].






Leymann, et al.          Expires July 18, 2015                  [Page 4]


Internet-Draft                 GRE-Notif.               January 14, 2015


         |==============================================
         | <............ LTE path   .................> |
    <--->| <............ DSL path   .................> |<--->
         |==============================================         ----
      +--+---+                                     +---+---+   /      \
      |      |                                     |       |  |Internet|
      | CPE  |                                     | HAAP  +--+        |
      +-+--+-+                                     +---+---+   \      /
        D  E              LTE Network                  H         ----
        |  |      *......................... *         |           |
        |  |      < +------+       +------+  >         |           |
        |  +--------+      +-------+      +------------+           |
        |         < |eNodeB|       | EPC  |  >         |           |
        |         < +------+       +------+  >         |           |
        |         *..........................*         |           |
        |         *......................... *         |           |
        |         ( +------+       +------+  )         |           |
        +-----------+      +-------+      +------------+-----------+
                  ( |  AN  |       | SN   |  )
                  ( +------+       +------+  )
                  *..........................*
                          DSL Network
   Legend:
   AN      Access Node
   SN      Service Node
   EPC     Evolved Packet Core

               Figure 1: Hybrid Access Network Architecture

   Once LTE and DSL GRE tunnels establishment and bonding procedure are
   completed, customer traffics can be distributed into LTE and/or DSL
   GRE tunnel based on traffic distribution rules on CPE and HAAP.  The
   traffic encapsulation is shown in Figure 2.

                 +--------+      +--------------+       +--------+
                 |  CPE   |      |  LTE Network |       | HAAP   |
                 | +-+****************************************** |
                 | | |  +-|      |              |       | | |    |
                 | | |  |E+....lte gre tunnel.......    | | |    |
                 | | |  +-+      +--------------+  ........ |    |
                 | |C|    |                        +.-.-.-.H|    |
                 | | |  +-+      +--------------+  |    | | |    |
                 | | |  |D+.-.-dsl gre tunnel.-.-.-.    | | |    |
                 | | |  +-+      |              |       | | |    |
                 | +-+****************************************** |
                 |        |      |  DSL Network |       |        |
                 +--------+      +--------------+       +--------+




Leymann, et al.          Expires July 18, 2015                  [Page 5]


Internet-Draft                 GRE-Notif.               January 14, 2015


    ------------> Upstream Traffic

              +---------+ +----------+        +----------+ +---------+
              | Payload | | Payload  |        | Payload  | | Payload |
              +---------+ +----------+        +----------+ +---------+
              |Src:CPE C| |Src:CPE C |        |Src:CPE C | |Src:CPE C|
              +---------+ +----------+        +----------+ +---------+
              |Dst:Inter| |Dst:Inter |        |Dst:Inter | |Dst:Inter|
              +---------+ +----------+ ---->  +==========+ +---------+
                          |GRE Header|        |GRE Header|
                          +==========+        +==========+
                          |Src:E/D   |        |Src:E/D   |
                          +==========+        +==========+
                          |Dst:H     |        |Dst:H     |
                          +==========+        +==========+


   <------------- Downstream Traffic
              +---------+ +----------+        +----------+ +---------+
              | Payload | | Payload  |        | Payload  | | Payload |
              +---------+ +----------+        +----------+ +---------+
              |Src:Inter| | Src:Inter|        | Src:Inter| |Src:Inter|
              +---------+ +----------+        +----------+ +---------+
              |Dst:CPE C| | Dst:Inter| <----- | Dst:Inter| |Dst:CPE C|
              +---------+ +==========+        +==========+ +---------+
                          |GRE Header|        |GRE Header|
                          +==========+        +==========+
                          |Src: H    |        |Src: H    |
                          +==========+        +==========+
                          |Dst:E/D   |        |Dst:E/D   |
                          +==========+        +==========+


                      Figure 2: GRE Solution Overview

   As shown in Figure 2 , particularly, the traffic going to upstream is
   encapsulated by GRE on CPE and decapsulated on HAAP.  On the other
   side, HAAP encapsulates the downstream traffic by GRE which will be
   decapsulated on CPE.  In order to clarify the details, the traffic
   forward actions is described following taking the upstream traffic as
   an example.  A Internet service is initiated at CPE, whose source
   address is Src:CPE C, which is the public address of CPE assigned by
   HAAP, the destination address is dst: Inter, the specific Internet
   server address (e.g. google, youtube,etc).  Receiving the upstream
   traffic, CPE encapsulates the packets of the upstream traffic by GRE
   tunnel, either LTE GRE tunnel header (Src: E and Dst: H) or DSL GRE
   tunnel header (Src:D and Dst:H) in order to balance the traffic
   between LTE and DSL network when DSL network is almost fully



Leymann, et al.          Expires July 18, 2015                  [Page 6]


Internet-Draft                 GRE-Notif.               January 14, 2015


   occupied.  When the GRE packets the HAAP, they will be decapsulated
   and then be forwarded as general IP packets.

4.  IP Address Assignment

4.1.  IPv4 Address Assignment

   The IPv4 address assignment in Figure 2 are shown as follows:

   o  E: CPE LTE WAN Interface IPv4 address (LTE GRE tunnel termination
      on CPE side )

   In LTE network, during Packet Data Protocol (PDP)
   establishment[TS23.401], the PDN Gateway in LTE network will allocate
   IPv4 address to CPE LTE WAN interface , referred as E .  This IPv4
   address is used as LTE GRE tunnel termination's IPv4 address on CPE
   side.

   o  D: CPE DSL WAN Interface IPv4 address (DSL GRE tunnel termination
      on CPE side)

   In DSL network, during PPPoE exchanges [RFC2561], it is the DSL
   gateway (e.g.  Broadband Network Gateway (BNG)) responsibility to
   allocate the IPv4 address to CPE DSL WAN interface.  This IPv4
   address is referred as D, which is used as DSL GRE tunnel
   termination's IPv4 address on CPE side.

   o  C: CPE Public IPv4 address for route advertisement__

   This address is assigned by HAAP acting as DHCPv4 server.  CPE
   advertises this IPv4 address during Interior Gateway Protocol (IGP)
   exchanges for following service transmit.  This is the IPv4 address
   used for the Internet communication.

   o  H: HAAP IPv4 address (LTE/DSL GRE tunnel termination on HAAP side)

   This address can be pre-configured statically on HAAP.

4.2.  IPv6 Address Assignment

   The IPv6 addresses in Figure 2 are shown as follows:

   o  E: CPE LTE WAN Interface IPv6 prefix (LTE GRE tunnel termination
      on CPE side)

   In LTE network the CPE LTE WAN interface gets assigned a specific
   IPv6 prefix (e.g. /64 prefix) by establishing PDP context with PGW,
   referred as D in Figure 2.



Leymann, et al.          Expires July 18, 2015                  [Page 7]


Internet-Draft                 GRE-Notif.               January 14, 2015


   o  D: CPE DSL WAN Interface IPv6 prefix (DSL GRE tunnel termination
      on CPE side)

   For IPv6 communication, the CPE DSL WAN interface is assigned a
   specific IPv6 prefix (e.g. /64 prefix) by BNG during PPPoE procedure.

   o  C: CPE IPv6 prefix

   This IPv6 prefix is assigned by HAAP.  This address is stored both on
   CPE and HAAP.  In this case, HAAP will act as DHCPv6 service.

   o  H: HAAP IPv6 prefix (LTE/DSL GRE tunnel termination on HAAP side)

   This address can be pre-configured statically on HAAP.

   There may be two routing for terminal host traffic via the same CPE
   DSL WAN interface, one route is for bypass traffic without arriving
   HAAP in Section 5.3, the other route is for HYA traffic with arriving
   HAAP.  So there must be two IPv6 address advertisement for one host
   in Internet.  To achieve this purpose, the IPv6 prefix translation is
   deployed.

   There are two scenarios:

   1 DSL GRE Tunnel UP and LTE GRE Tunnel UP

   Terminal Host will get a IPv6 prefix D-LAN from D prefix via SLAAC
   [RFC4862].  This prefix is used for DSL bypass traffic route
   advertisement.

   IPv6 translation happens on HAAP.  On HAAP, the terminal host IPv6
   prefix D-LAN will be mapped to C, which is CPE IPv6 prefix assigned
   by HAAP.  The C is used for HYA traffic route advertisement.

   2 DSL GRE Tunnel Down and LTE GRE Tunnel UP

   Terminal Host will get a IPv6 prefix C-LAN from C prefix via SLAAC
   [RFC4862].  This prefix is used for DSL bypass traffic route
   advertisement.

   IPv6 translation happens on HAAP.  On HAAP, the terminal host IPv6
   prefix C-LAN will be mapped to C, which is CPE IPv6 prefix assigned
   by HAAP.  The C is used for HYA traffic route advertisement.








Leymann, et al.          Expires July 18, 2015                  [Page 8]


Internet-Draft                 GRE-Notif.               January 14, 2015


5.  GRE Solution Function

5.1.  GRE Tunnels Setup and Management

   In this document, the LTE and DSL GRE tunnels described in Figure 2
   are established by GRE control messages exchanges between CPE and
   HAAP.  The general procedures for the tunnels establishment are
   illustrated in the following diagram Figure 3.

   The annotated ladder diagram shows CPE on the left, HAAP on the
   right.  LTE and DSL network support customer traffic transmission as
   shown in the middle.







































Leymann, et al.          Expires July 18, 2015                  [Page 9]


Internet-Draft                 GRE-Notif.               January 14, 2015


        ==========           ::::::::::                       ==========
            CPE                LTE/DSL                           HAAP
        ==========           ::::::::::                       ==========

        [....CPE obtains LTE WAN IF addreess during PDP from PGW....]
        [...CPE obtains DSL WAN IF address during PPPoE from BNG...]
        [.......... CPE obtains HAAP address H via DNS   ..........]

        [.......... begin tunnel establishment and bond............]

          (........ begin lte gre tunnel establishment.............)

              ----   GRE Setup Request Message over LTE ------->
               ** Authentication and Authorization Passed  **
              <- (1) GRE Setup Accept Message over LTE---------
                            (carrying session ID)
              ** Authentication and Authorization Failed  **
              <-(2) GRE Setup Deny Message over LTE -----------
              if (1)
          (........ lte gre tunnel establishment finishs ...........)
              if (2)
          (------------------------  end  --------------------------)

          ---- Request CPE IP Address(C) (DHCP over LTE GRE) ------>
          <--IP Address (C) Assigned to CPE(DHCP over LTE GRE)------

         (........... begin dsl gre tunnel establishment ...........)

              ----- GRE Setup Request Message over DSL ----->
             (same session ID acquired during LTE establishment )
              **  Authentication and Authorization Passed  **
              <----(3) GRE Setup Accept Message over DSL ----
              ** Authentication and Authorization Failed   **
              <----(4) GRE Setup Deny Message over DSL ------
             If (3)
          (........ dsl gre tunnel establishment finishes..............)
          (.......finish tunnel establishment and bond ...............)
             if (4)
          (-----------------------  end  -----------------------------)

               Figure 3: GRE Tunnel Establishment Procedure

   The procedure of tunnel establishment is achieved by GRE control
   message exchanging.  Meanwhile, the LTE and DSL GRE tunnels are
   bonded via the same "session ID" exchanged during the tunnel
   establishment procedure.

   The details procedures are shown as follows:



Leymann, et al.          Expires July 18, 2015                 [Page 10]


Internet-Draft                 GRE-Notif.               January 14, 2015


   1.   CPE already gets DSL WAN interface IP address through PPPoE from
        BRAS and LTE WAN interface IP address through PDP from PGW.

   2.   CPE request DNS resolution for HAAP domain name via DSL WAN or
        LTE WAN interface, DNS server will return a corresponding HAAP
        IP address which can be pre-configured by operators.

   3.   Then CPE tries to setup the tunnels and bundling them.  CPE will
        setup LTE GRE tunnel before DSL GRE tunnel.  CPE sends GRE
        Tunnel Setup Request message to HAAP via LTE WAN interface.

   4.   The HAAP receives the message and then iniates the
        Authentication and Authorization procedure in order to check
        whether CPE is trusted for PGW.  It is similar like UE
        authentication in [TS23.401].

   5.   After authentication and authorization succeed, HAAP then
        replies GRE Tunnel Setup Accept message to CPE via LTE.
        Specially, Session ID generated randomly by HAAP will be carried
        in this message, which is used for bonding LTE GRE tunnel and
        DSL GRE tunnel for one subscriber later.If authentication and
        authorization failed, HAAP must send the GRE Setup Deny message
        to CPE over LTE, the tunnel establishment procedure must be tore
        down.

   6.   After LTE GRE tunnel setup is success, CPE begins to obtain C
        address defined in Section 4 from HAAP through DHCP over LTE GRE
        tunnel.  At the same time, CPE begins to setup DSL GRE tunnel.

   7.   CPE sends GRE Setup Request message with HAAP address as the
        destination IP of GRE via DSL WAN interface, carrying the same
        session ID received from HAAP in Step 5.

   8.   The HAAP receives the message and then initiates the
        Authentication and Authorization procedure in order to check
        whether CPE is trusted for BRAS and validate the HYA service
        rights for CPE.

   9.   After authentication and authorization succeed, HAAP sends GRE
        Setup Accept message to CPE via DSL.  CPE then bundle the two
        GRE tunnels based on same Session ID.

   10.  CPE sends GRE Notify message via DSL WAN immediately after the
        DSL GRE tunnel setup successfully in order to inform the DSL
        bypass bandwidth to HAAP.  More details is shown in Section 6.






Leymann, et al.          Expires July 18, 2015                 [Page 11]


Internet-Draft                 GRE-Notif.               January 14, 2015


   For management and control motivations, GRE tunnel management process
   message exchanges between CPE and HAAP are needed, shown in the
   following figureFigure 4.

        ==========           ::::::::::                       ==========
            CPE                LTE/DSL                           HAAP
        ==========           ::::::::::                       ==========

          (..... lte/dsl tunnel failure detection and keepalive...)
              ---------  GRE Hello Message over LTE -------->
             <---------  GRE Hello Message over LTE ---------
             ----------  GRE Hello Message over DSL -------->
             <---------  GRE Hello Message over DSL ---------

          (..........lte/dsl tunnel information inform.............)
             ----------  GRE Notify Message over LTE--------> <---------
              GRE Notify Message over LTE -------- ----------  GRE
             Notify Message over DSL--------> <---------  GRE Notify
             Message over DSL --------

          ( ......... lte/dsl tunnel teardown ....................)
             <---------  GRE Tear Down Message over LTE --------
             <---------  GRE Tear Down Message over DSL --------

                 Figure 4: GRE Tunnel Management Procedure

   GRE Hello messages exchange between CPE and HAAP for LTE/DSL tunnel
   failure detection and keep-alive.  GRE Notify message is used to
   inform status/information (e.g., dsl network status, service list for
   HYA, etc) between CPE and HAAP.  A notify acknowledgement (ACK) via
   GRE Notify message and retransmission mechanism can be used to
   provide certain level reliable transport capability.  For maintenance
   reasons, GRE Tear Down message can be used by HAAP to terminate the
   bond LTE GRE tunnel and DSL GRE tunnel for some reasons because of
   network failures.  The detailed control messages are proposed in
   Section 6.1.

5.2.  Packet-Based Traffic Overflow

   In this document, traffic distribution between the established and
   bond LTE and DSL GRE tunnel is packet-based overflow.The packet-based
   traffic overflow machinism includes two requirements, cheapest path
   used first (e.g., DSL GRE tunnel Figure 2 )and traffics overflowed
   when cheapest path is almost fully occupied.  To satisfy these
   requirements,Two Rate Three Color Marker (trTCM) [RFC2698]can be
   used.





Leymann, et al.          Expires July 18, 2015                 [Page 12]


Internet-Draft                 GRE-Notif.               January 14, 2015


   Two token buckets based on DSL and LTE resource are used to meter if
   the packets is overflowed or not.  The details rate configuration is
   based on the operators' requirement, which is out of the scope.
   Clearly,the packet can be marked with yellow if the packet is
   overflowed, otherwise the packet is marked with green based on
   [RFC2698].  Then the colored based policy routing is executed on CPE
   and HAAP.  The packet will be routed into the corresponding tunnel
   based on the marked color.  For example, yellow color packet will be
   routed to LTE GRE tunnel; green color packet will be routed into DSL
   GRE tunnel.The GRE IP headed is used to encapsulate the traffic on
   CPE and HAAP as shown in . (Figure 2).

   On the received side, the packets encapsulated in GRE will come from
   DSL GRE tunnel and/or LTE GRE tunnel.  Due to different transporting
   delivery caused by LTE and DSL paths, the packets in the same flow
   may reach out of the order.  Consequentially the packets will be sent
   to a buffer for reordering based on the sequence information in GRE
   header, details in Section 6.  After reordering, the GRE header will
   be removed and the packet will be sent to the ordinary IP packet
   processing.

5.3.  Backward Compatibility

   The solution should satisfy the backward compatibility requirements.
   While deploying HYA architecture, the existing services must not be
   influenced.  For example, IPTV traffic must be remained into the DSL
   path only for performance reasons, instead of LTE tunnel.  In
   addition some control messages (e.g. for TR069/ACS, DNS etc.) might
   not be reachable through the HAAP as well due to control and
   management entities deployment scenario in the network.  These kinds
   of services can be defined and managed by operators during HYA
   deployment.

   In this document, the mechanism must be defined for deploying and
   maintaining the list of these kinds of traffic.  The negotiation
   between HG and HAAPFigure 5 is described for this purpose.

   During network arrangement, operators may configure this service
   list.  HAAP provision the information to CPE via LTE/DSL GRE tunnel.
   And the list must be updateable during the established tunnel.  At
   each time when CPE try to establish the tunnel, the list is pushed by
   HAAP.  CPE will flash the the list if it have a previous one.  If the
   list is taken some errors during list flashing, CPE should keep the
   previous one and reply the error code to HAAP via GRE Notify
   message.The errors include download unsuccessfully, incorrect format,
   wrong syntax etc defined in Section 6.





Leymann, et al.          Expires July 18, 2015                 [Page 13]


Internet-Draft                 GRE-Notif.               January 14, 2015


        ==========           ::::::::::                       ==========
            CPE                LTE/DSL                           HAAP
        ==========           ::::::::::                       ==========
             <---------  GRE Notify Message (Filter list TLV) ---------
             ----------  GRE Notify Message (ACK or Errors) ---------->

               Figure 5: GRE Tunnel Service List Management

   As shown Figure 5, only one GRE tunnel (LTE/GRE) will be used for one
   time transmission of GRE Notify message carrying the service list,
   and each notification will be replied by a notification ACK.If
   several times of transmission failure for notification, the tunnel
   for sending notification will be switched to the other one.

   HG will validate the received filter list packet, if no error found,
   CPE will reply GRE Notify message as ACK to HAAP.  So HAAP directly
   stops to send the following filter list packet, that means this time
   of filter list notification is completed successfully.  If any error
   found, CPE will reply GRE Notify message as errors feedback, HAAP
   will try to send it again or stop it.  The details are described in
   Section 6.

   In case of large size of the service list, multiple GRE Notify
   messages to CPE are needed to carry multiple fragments of the list.
   Each of these GRE Notify message needs a notification ACK.

5.4.  Bypassing Traffic Statistic

   Bypassing Traffic means that the traffic MUST bypass the HYA GRE
   tunnel but directly over DSL WAN interface as mentioned filter list
   in Section 5.3, and this happens on the CPE.  The traffic bypass
   behavior is accomplished by implementing a routing table on CPE.
   Distinctly, part of DSL bandwidth is already occupied by these types
   of bypass traffic with higher priority.  As a result, only the DSL
   bandwidth left can be used for HYA DSL GRE tunnel.

   The solution must consider how to meter the bypassing traffic
   statistic on DSL bandwidth and adjust the free resource left in DSL
   for HYA.  The DSL bandwidth for HYA must be adjusted dynamically when
   bypass traffics are presenting.  CPE can check the bypass traffic
   rate periodically, and notify the parameters to the HAAP.  HAAP can
   adjust the token buckets for packet overflow action later on defined
   in Section 5.2.








Leymann, et al.          Expires July 18, 2015                 [Page 14]


Internet-Draft                 GRE-Notif.               January 14, 2015


5.5.  LTE and DSL Path Difference Consideration

   In HYA, LTE and DSL tunnel may have different characters, such as
   rates, delay and MTU which cause the throughput and traffic
   fragmentation issues.  These differences should be considered during
   the GRE solution design.

   The rate, Round Trip Time (RTT) /delay of a DSL link is relatively
   fixed, but the RTT/delay character of an LTE link vary over time.
   When the DSL and LTE link are combined in HYA, the CPE has a larger
   combined bandwidth (DSL_BW + LTE_BW), but the RTT/delay of the bonded
   tunnels may become bigger for customer traffics.  The maximum RTT/
   delay of customer HYA traffic is equal to bigger one of the LTE and
   DSL links.  Usually, the buffering size for packet reorder is related
   to the RTT/delay difference between both LTE and DSL link.  If the
   RTT/delay difference is too big, the buffer size will be too huge to
   be achieved on CPE/HAAP.  In this case, the bandwidth efficiency of
   the HYA will disappeared comparing the bigger RTT/delay and huge
   buffer requirement.

   The MTU difference may impact the packet fragmentation and reorder.
   The minimum MTU on DSL path is PPPoE MTU, which is 1492.  The minimum
   MTU on LTE path is UGW MTU, which is 1436.  In HYA, the maxium tunnel
   MTU is LTE MTU minus GRE overhead.  Static calculation for GRE tunnel
   MTU sized based on DSL path MTU and LTE path MTU is configured.  MSS
   adjustment for TCP on CPE based on the calculation in order to avoid
   IP fragmentation on both GRE outer IP layer and inner IP layer.

6.  GRE Control Message Definition

   In this section, GRE encapsulation control messages are defined for
   negotiation between CPE and HAAP for the LTE and DSL tunnel
   establishment, bond, management, etc, which are not standardized yet.
   The GRE control messages format are according to [RFC2890].  The GRE
   header as described inFigure 6 indicates a control protocol with the
   Protocol Type section set to 0x0101 in this document.















Leymann, et al.          Expires July 18, 2015                 [Page 15]


Internet-Draft                 GRE-Notif.               January 14, 2015


        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               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Key                                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |MsgType|T| Res |Attribute Type |  Attribute Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Attribute Value                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 6: GRE Header Format

   Protocol Type (2 octets)

   The Protocol Type field identifies the GRE protocol for HYA network.
   The value 0x0101 is proposed.

   Message Type (MesType) (4 bits)

   The Message Type field identifies GRE protocol control messages for
   HYA network.  Right now, there are 6 valid types of GRE control
   message mentioned , shown as belowFigure 7:

         Control Message Family        Type
        =========================   ============

          GRE Setup Request             1
          GRE Setup Accept              2
          GRE Setup Deny                3
          GRE Hello                     4
          GRE Tear Down                 5
          GRE Notify                    6
          Reserved                      0,7-15

                      Figure 7: GRE Control Messages

   Tunnel Type (T) (1 bit)

   If the Tunnel Type bit is set to 1, then it indicates that this
   control message is used for the DSL GRE tunnel.  Otherwise it
   indicates that this control message is used for the LTE GRE tunnel.

   Attribute Type (1 octet)

   Attribute Type indicates the type of the appended attributes included
   in the GRE header.  The types of attributes are defined in Section 7.



Leymann, et al.          Expires July 18, 2015                 [Page 16]


Internet-Draft                 GRE-Notif.               January 14, 2015


   Attribute Length (2 octets)

   Attribute Length field indicates the length of the attribute by byte.

   Attribute Value (variable)

   Attribute Value field includes the value of the attribute.

6.1.  GRE Setup Request Message

   GRE Setup Request message is sent by CPE to HAAP via LTE and DSL WAN
   in order to set up LTE and DSL GRE tunnel.

   The following attributions MUST be included in the GRE Setup Request
   Message.

   o  Client Identification Name (CIN) Figure 10.  Only the GRE Tunnel
      Setup Requst Message through LTE WAN must contain the CIN.

   o  Session ID Figure 11.  CPE must encapsulate the Session ID
      attribute in GRE Setup Request message via DSL WAN.  This Session
      ID is genernated by HAAP during LTE tunnel establishment Figure 3.
      The value in Session ID attribute must be same via both DSL and
      LTE WAN.  In addition, when LTE GRE tunnel recovery from failure
      while DSL GRE tunnel exists, the re-established LTE tunnel request
      needs to carry the Session ID Attribute.

   o  End AVP, see Section 7.

6.2.  GRE Setup Accept Message

   HAAP sends GRE Setup Accept Message to CPE if HAAP accepts associated
   GRE Setup Request from CPE.  The routing path of a pair of GRE Setup
   Request message and GRE Setup Accept message must be the same, either
   LTE or DSL.

   The following attributions MUST be included in the GRE Setup Accept
   Message via LTE WAN.

   o  Session IDFigure 11, HAAP generates a session ID for a CPE and
      sends the Session ID attribute to CPE LTE WAN via GRE Setup Accept
      Message.

   o  RTT Difference Threshold AttributeFigure 16, see Section 7.6.

   o  Bypass Bandwidth Check IntervalFigure 17, see Section 7.7.

   o  Hello IntervalFigure 18, see Section 7.10.



Leymann, et al.          Expires July 18, 2015                 [Page 17]


Internet-Draft                 GRE-Notif.               January 14, 2015


   o  Hello Retry TimesFigure 19, see Section 7.11.

   o  Idle TimeoutFigure 20, see Section 7.12.

   o  Delay Difference Threshold Violation, see Section 7.19

   o  Delay Difference Threshold Compliance, see Section 7.20

   o  End AVP, see Section 7.22

   The following attributions MUST be included in the GRE Setup Accept
   Message via DSL WAN.

   o  Subscribed DSL Upstream BWFigure 23, see Section 7.17.

   o  Subscribed DSL Downstream BWFigure 24, see Section 7.18.

   o  End AVP, see Section 7.22

6.3.  GRE Setup Deny Message

   HAAP will send GRE Setup Deny Message to CPE through LTE and/or DSL
   path if HAAP denies the GRE Setup Request for LTE and/or DSL GRE
   tunnel from CPE.

   The following attributions MUST be included in the GRE Setup Deny
   Message.

   o  Error CodeFigure 21, see Section 7.13.

   o  End AVP, see Section 7.22.

6.4.  GRE Hello Message

   The GRE Hello Message is used for CPE and HAAP on both LTE GRE tunnel
   and DSL GRE tunnel for failure detection and keepalive of the tunnel.

   The following attributes MUST be included in the GRE Hello Message.

   o  TimestampFigure 12, see Section 7.3.

   o  End AVP, see Section 7.22.

6.5.  GRE Tear Down Message

   GRE Tear down message is used to maintain the state and can only be
   send from HAAP to CPE to terminate the established LTE and/or DSL
   tunnels.



Leymann, et al.          Expires July 18, 2015                 [Page 18]


Internet-Draft                 GRE-Notif.               January 14, 2015


   The following attributes MUST be included in the GRE Tear Down
   Message.

   o  Error CodeFigure 21, see Section 7.13.

   o  End AVP, see Section 7.22.

6.6.  GRE Notify Message

   GRE notify message is used to inform status/information changing and
   the filter list information between CPE and HAAP.

   The following attributes MUST be included in the GRE Notify Message
   via both LTE and DSL WAN.

   o  End AVP, see Section 7.22.

   The following attributes MAY be included in the GRE Notify Message
   via LTE WAN .

   o  Filter list packageFigure 14, see Section 7.5.

   o  DSL link failure, see Section 7.14.

   o  IPv6 prefix assigned to terminal hostFigure 22, see Section 7.16.

   o  Filter list ACKFigure 14, see Section 7.21.

   The following attributes MAY be included in the GER Notify Message
   via DSL WAN.

   o  Bypass traffic rateFigure 13, see Section 7.4.

   o  Filter list packageFigure 14, see Section 7.5.

   o  Switching to DSL tunnel, see Section 7.8.

   o  Overflowing to LTE tunnel, see Section 7.9.

   o  LTE link failure, see Section 7.15.

   o  IPv6 prefix assigned to terminal hostFigure 22, see Section 7.16.

   o  Filter list ACKFigure 14, see Section 7.21.







Leymann, et al.          Expires July 18, 2015                 [Page 19]


Internet-Draft                 GRE-Notif.               January 14, 2015


7.  GRE Control Message Attribute Definitions

   All the attributions are identified by the Type, Length, Value field,
   shown as below Figure 8.The 8-bits Type field identifies the type of
   the attribution.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Attribute Type |   Attribute Length            |Attribute Value|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Attribute Value......                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 8: GRE Control Message Attribute Definitions

   The following GRE control message attributes for HYA are defined in
   this documentFigure 9 .

         Control Message Family                  Type
        =========================             ============

          CIN                                    3
          Session ID                             4
          Timestamp                              5
          Bypass Traffic Rate                    6
          Filter List Package                    8
          RTT Difference Threshold               9
          Bypass Bandwidth Check Interval        10
          Switching to DSL Tunnel                11
          Overflowing to LTE Tunnel              12
          Hello Interval                         14
          Hello Retry Times                      15
          Idle Timeout                           16
          Error Code                             17
          DSL Link Failure                       18
          LTE Link Failure                       19
          IPv6 Prefix Assigned to Terminal Host  21
          Subscribed DSL Upstream BW             22
          Subscribed  DSL Downstream BW          23
          Delay Difference Threshold Violation   24
          Delay Difference Threshold Compliance  25
          Filter list ACK                        30
          End AVP                                255
          Reserved

                 Figure 9: GRE Control Message Attributes




Leymann, et al.          Expires July 18, 2015                 [Page 20]


Internet-Draft                 GRE-Notif.               January 14, 2015


7.1.  Client Identification Name (CIN)

   CIN is used to identified the RG in operator network.  CIN is sent to
   HAAP by CPE for authentication and authorization purpose.  It is
   similar like UE authentication in [TS23.401].Any CPE must transmit a
   CIN during the tunnel request procedure for authentication.  CIN must
   be unique for each CPE in operator's network.

   The attribute contains the following value Figure 10:

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

                         Figure 10: CIN Attribute

   Type:3 for CIN Attribute

   Length: 40 Bytes

   CIN: String defined by operators

7.2.  Session ID

   Session ID attribute is used to bind the DSL tunnel and LTE tunnel
   together for individual CPE.  Session ID 32bit value is generated by
   HAAP, and unique within a HAAP.  It is used to identify a certain
   subscriber CPE.

   HAAP sends this attribute to requesting CPE LTE WAN via GRE Setup
   Accept message, then CPE encapsulates this attribute in GRE Setup
   Request through DSL WAN.  With this information, CPE and HAAP can
   bind these two tunnels together.  When LTE recovery from failure with
   DSL tunnel exists, the re-established LTE tunnel request needs to
   carry the Session ID.

   The attribute contains the following value Figure 11:

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

                      Figure 11: Session ID Attribute




Leymann, et al.          Expires July 18, 2015                 [Page 21]


Internet-Draft                 GRE-Notif.               January 14, 2015


   Type:4 for Session ID Attribute

   Length: 4 Bytes

   Session ID: String value generated by HAAP to identify a certain CPE.

7.3.  Timestamp

   The Timestamp attribute is used for Round-Trip Time (RTT) RTT
   calculation.

   The attribute contains the following value Figure 12.

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

                      Figure 12: Timestamp Attribute

   Type:5 for Timestamp Attribute

   Length: 8 Bytes

   Session ID: The higher order 4 bytes is seconds, the low-order 4
   bytes is millisecond

7.4.  Bypass Traffic Rate

   The Bypass Traffic Rate attribute is used by HG to notify HAAP of the
   bypass traffic rate on CPE, such as IPTV, DNS, etc, see Section 5.4
   for details.  HAAP will calculate the available DSL bandwidth for HYA
   DSL GRE tunnel based on this information.

   The attribute contains the following valuesFigure 13.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Bypass Traffic Rate                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 13: Bypass Traffic Rate Attribute

   Type:6 for BypassTraffic Rate Attribute



Leymann, et al.          Expires July 18, 2015                 [Page 22]


Internet-Draft                 GRE-Notif.               January 14, 2015


   Length: 4 Bytes

   Bypass Traffic Rate: A 4-bytes length integer to identify the
   resource already occupied in DSL by kinds of bypass traffic referred
   as Section 5.4 .The CPE will check the bypass traffic rate
   periodically, if the bypass traffic rate difference is greater than
   specified percentage of the DSL bandwidth, and then notify the bypass
   traffic rate to the HAAP.  HAAP can adjust the token buckets for
   packet overflow action later on Section 5.4.

7.5.  Filter List Package

   The Filter List Package is the collection of the services list which
   MUST not be routed through HYA, but directly over the specific
   interface mentioned in Section 5.3.  The filter service list is
   configured on CPE by HAAP.  This attribute is the collection of
   filter list TLVs, each TLV carries one kinds of filter service list.

   The attribute contains the following valuesFigure 14:

       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                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      packt_sum                |         packt_id              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         type                  |          length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         enable                |     description length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        description value                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      *                        value (0-256 bits)                     *
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 14: Filter List Package Attribute

   Type: 8 for Filter List Package Attribute

   Length: <= 969 Bytes

   Commit_count: It is used to identify the Filter list version.  If the
   Filter list recieved from HAAP changed, the commit_count will be
   updated.  CPE will refresh the previous filter list.






Leymann, et al.          Expires July 18, 2015                 [Page 23]


Internet-Draft                 GRE-Notif.               January 14, 2015


   Packet_sum: If the filter list packet is larger than the MTU and
   should be divided into multiple fragments, the Packet_sum indicate
   the fragments numbers of the filter list packet.

   Packet_ID: The index of the multiple fragments.

   Type: Several filter list type can be defined, which is described as
   followingFigure 15.

   Length: The length of the specific type of filter list.

   Enable: Indicate this type of filter list is enabled.  Only can be
   1(Enabled) or 0 (Unenabled), other values are reserved.

   Description Length: The length of this type of filter list
   description, the unit is byte.

   Description Value:The value of this type of the filter list

   Value: Value of the specific type of filter list.

            Filter List                Type
        =========================   ============
        Fully Qualified Domain Name     1
        DSCP                            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
        Destination IP Range&Port       14
        Reserved

                        Figure 15: Filter List Type

7.6.  RTT Difference Threshold

   The difference RTT/delay between DSL and LTE should impact the HYA
   network efficiency, mentioned in Section 5.5.  So the acceptable RTT
   difference threshold in HYA must be defined.  This value is signed to
   CPE by HAAP.  When the RTT difference exceeds the configured RTT




Leymann, et al.          Expires July 18, 2015                 [Page 24]


Internet-Draft                 GRE-Notif.               January 14, 2015


   difference threshold, CPE may changing the traffic distribution into
   DSL only rather than LTE GRE tunnel.

   The attribute contains the following valuesFigure 16

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  RTT Difference Threshold                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 16: RTT Difference Threshold

   Type: 9 for RTT Difference Threshold Attribute

   Length: 4 Bytes

   RTT Difference Threshold: The unit of this integer value is ms
   (milliseconds).  This value is configurable, the value range can be
   from 0~1200ms, changing step is 1ms.

7.7.  Bypass Bandwidth Check Interval

   The Bypass Bandwidth Check Interval is assigned to CPE by HAAP. Based
   on requirement in Section 5.4, CPE will check the bypass bandwidth on
   DSL path after this interval.

   The attribute contains the following valueFigure 17:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Bypass Bandwidth Check Interval                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 17: Bypass Bandwidth Check Interval Attribute

   Type: 10 for Bypass Bandwidth Check Interval Attribute

   Length: 4 Bytes

   Bypass Bandwidth Check Interval: Integer as seconds.  This value is
   configurable, the range is from 10-300s, changing step is 1s.








Leymann, et al.          Expires July 18, 2015                 [Page 25]


Internet-Draft                 GRE-Notif.               January 14, 2015


7.8.  Switching to DSL Tunnel

   The Switching to DSL Tunnel is used by CPE to notify HAAP to switch
   the traffic to DSL only.  When the RTT difference between DSL and LTE
   tunnel exceeds the RTT difference thresholdFigure 16 3 times (default
   value), the CPE will send a Notify message with "Switching to DSL
   tunnel" attribute to HAAP.  Then the traffic will be sent through the
   DSL tunnel only no matter HAAP or CPE.

   There is no value in this attribute.

   Type: 11 for Switching to DSL Tunnel

   Length: 0

7.9.  Overflowing to LTE Tunnel

   The Overflowing to LTE Tunnel is used by CPE to notify HAAP to
   overflow the traffic to LTE tunnel.  When the RTT difference between
   DSL and LTE tunnel is lower than the RTT difference
   thresholdFigure 16 3 times (default value), the CPE will send a a
   Notify message with "Overflowing to LTE tunnel" attribute to HAAP.
   Then the traffic can overflow to the LTE tunnel.

   There is no value in this attribute.

   Type: 12 for Overflowing to LTE Tunnel

   Length: 0

7.10.  Hello Interval

   The Hello Interval is configured to CPE by HAAP.  The GRE Hello
   message between CPE and HAAP will be negotiated in each hello
   interval period.

   The attribute contains the following valueFigure 18:

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

                    Figure 18: Hello Interval Attribute

   Type: 14 for Hello Interval Attribute




Leymann, et al.          Expires July 18, 2015                 [Page 26]


Internet-Draft                 GRE-Notif.               January 14, 2015


   Length: 4 Bytes

   Hello Interval: Integer.  The unit of this value is second.  This
   value should be configurable, with range 1~100s, changing step is 1s.

7.11.  Hello Retry Times

   The Hello Retry Times is configured to CPE by HAAP.  The GRE Hello
   message between CPE and HAAP will be retried several times defined in
   this atrribute.

   The attribute contains the following valueFigure 19.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Hello Retry Times                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 19: Hello Retry Times Attribute

   Type: 15 for Hello Retry Times Attribute

   Length: 4 Bytes

   Hello Retry Times: Integer.  It is the times about the GRE Hello
   Message retry.  This value is configurable, the value range is from
   3~10, changing step is 1.

7.12.  Idle Timeout

   The Idle Timeout is configured on CPE by HAAP.  If GRE tunnels are
   already established via DSL and LTE, idle timeoutFigure 28 will
   occur.  All tunnels must be terminated if LTE/DSL tunnel isn't
   restored within a period time (e.g., idle timeout).

   The attribute contains the following valueFigure 20.

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

                     Figure 20: Idle Timeout Attribute

   Type: 16 for Idle Timeout Attribute




Leymann, et al.          Expires July 18, 2015                 [Page 27]


Internet-Draft                 GRE-Notif.               January 14, 2015


   Length: 4 Bytes

   Idle Timeout: Integer.  The unit of this value is seconds.  The value
   is configurable, with range from 0~172800s, step is 60s.

7.13.  Error Code

   The Error Code is used when the erros happens in HYA network.

   The attribute contains the following valueFigure 21.


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

                      Figure 21: Error Code Attribute

   Type: 17 for Error Code Attribute

   Length: 4 Bytes

   Idle Timeout: Integer.  Error cases have to be handled.

7.14.  DSL Link Failure

   The DSL Link Failure will be used by CPE to inform HAAP of CPE DSL
   link failure through LTE WAN.  Usually, the failure can be detected
   by HAAP via GRE Hello message.  However, it is possible that the
   local failures happen on CPE.  In this case, direct notification to
   HAAP is a efficiency way than GRE hello mechanism (Failure Detection
   time is retry times*hello interval)

   There is no value in this attribute.

   Type: 18 for DSL Link Failure

   Length: 0

7.15.  LTE Link Failure

   The LTE Link Failure will be used by CPE to inform HAAP of CPE LTE
   link failure through DSL WAN.  Usually, the failure can be detected
   by HAAP via GRE Hello message.  However, it is possible that the
   local failures happen on CPE.  In this case, direct notification to




Leymann, et al.          Expires July 18, 2015                 [Page 28]


Internet-Draft                 GRE-Notif.               January 14, 2015


   HAAP is a efficiency way than GRE hello mechanism (Failure Detection
   time is retry times*hello interval)

   There is no value in this attribute.

   Type: 19 for LTE Link Failure

   Length: 0

7.16.  IPv6 Prefix Assigned to Terminal Host

   The IPv6 Prefix assigned to terminal host on CPE will be notified to
   HAAP.  Then HAAP can setup the IPv6 prefix translation mapping
   between CPE HA IPv6 prefix and the terminal host IPv6 prefix.  When
   the downstream traffic arriving, HAAP can advertise the CPE HA IPv6
   prefix for HYA refereed to Section 4.2.

   When both DSL link and LTE link are working, CPE will assign BRAS
   IPv6 prefix to terminal host.  When DSL line failure and lead to
   PPPoE terminated, CPE will assign HAAP IPv6 prefix to terminal host.
   When DSL line recovers from failure and obtains a new IPv6 prefix
   from BRAS, CPE will assign BRAS IPv6 prefix to terminal host again.
   When HG change the IPv6 prefix assigned to terminal host, need to
   send notify to HAAP.

   The attribute contains the following valueFigure 22:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \            IPv6 Prefix Assigned to Terminal Host               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Network Mask  |
      +-+-+-+-+-+-+-+-+

        Figure 22: IPv6 Prefix Assigned to Terminal Host Attribute

   Type: 21 for IPv6 Prefix Assigned to Terminal Host Attribute

   Length: 17 Bytes

   Value: The first 16 bytes are the IPv6 prefix, the last byte
   indicates the network mask.







Leymann, et al.          Expires July 18, 2015                 [Page 29]


Internet-Draft                 GRE-Notif.               January 14, 2015


7.17.  Subscribed DSL Upstream BW

   The Subscribed DSL Upstream BW is used by HAAP to notify CPE the
   available DSL upstream Bandwidth.  The subscribed DSL Upstream BW can
   be obtained by HAAP during authentication and authorization process.
   CPE/HAAP will use this value to set the token bucket on DSL for
   traffic overflow referred to Section 5.4.

   The attribute contains the following valueFigure 23


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Subscribed DSL Upstream BW                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 23: Subscribed DSL Upstream BW

   Type: 22 for Subscribed DSL Upstream BW

   Length: 4 Bytes

   Subscribed DSL Upstream BW: The conventional DSL upstream BW is
   provided by operator for CPE.The unit of this value is kbps.

7.18.  Subscribed DSL Downstream BW

   The Subscribed DSL Downstream BW is used by HAAP to notify CPE the
   available DSL downstream Bandwidth.  The subscribed DSL Downstream BW
   can be obtained by HAAP during authentication and authorization
   process.  CPE/HAAP will use this value to set the token bucket on DSL
   for traffic overflow referred to Section 5.4.

   The attribute contains the following valueFigure 24:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Subscribed DSL Downstream BW                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 24: Subscribed DSL Downstream BW

   Type: 23 for Subscribed DSL Downstream BW

   Length: 4 Bytes




Leymann, et al.          Expires July 18, 2015                 [Page 30]


Internet-Draft                 GRE-Notif.               January 14, 2015


   Subscribed DSL Downstream BW: The conventional DSL downstream BW is
   provided by operator for CPE.  The unit of this value is kbps.

7.19.  Delay Difference Threshold Violation

   The Delay Different Threshold Violation is used to carry the times
   when the RTT/delay difference exceeds the threshold defined in Figure
   16.  This times will impact the decision to switch the traffic to DSL
   GRE tunnel only.  When the RTT/delay difference exceeds the threshold
   above the times defined in this attribute, all the traffic will be
   switched to DSL tunnel, rather than LTE tunnel.  This is the
   configuration to CPE by HAAP.

   The attribute contains the following valueFigure 25.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Delay Difference Threshold Violation Times            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 25: Delay Difference Threshold Violation

   Type: 24 for Delay Difference Threshold Violation Attribute

   Length: 4 Bytes

   Delay Difference Threshold Violation Times: The times when the RTT/
   delay difference exceeds the threshold defined in Figure 16.  This
   value can be configured by operators.

7.20.  Delay Difference Threshold Compliance

   The Delay Different Threshold Compliance is used to carry the times
   when the RTT/delay difference stays below the threshold defined in
   Figure 16.  This times will impact the decision to switch the traffic
   to DSL GRE tunnel only.When the RTT/delay difference stays below the
   threshold above the times defined in this attribute, all the traffic
   can be transmitted over HYA, with both LTE and DSL tunnel.  This is
   the configuration to CPE by HAAP.

   The attribute contains the following valueFigure 26.









Leymann, et al.          Expires July 18, 2015                 [Page 31]


Internet-Draft                 GRE-Notif.               January 14, 2015


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Delay Difference Threshold Compliance Times            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 26: Delay Difference Threshold Compliance

   Type: 25 for Delay Difference Threshold Compliance Attribute

   Length: 4 Bytes

   Delay Difference Threshold Compliance Times: The times when the RTT/
   delay difference stays below the threshold defined in Figure 16. This
   value can be configured by operators.

7.21.  Filter list ACK

   The Filter List ACK attribute is defined for acknowledgement of
   filter list notify and filter list error notification.  This
   attribute is used as a reply for Figure 14.

   The attribute contains the following value Figure 27.

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

                   Figure 27: Filter List ACK Attribute

   Type: 30 for Filter List ACK Attribute

   Length: 5 Bytes

   Commit_count: The first 4 bytes is committed count, to differentiate
   filter list packages in case of change of the filter list package.

   Error Code: Code 0 is ACK; code 1 is NACK and indicates this is new
   dial-in subscriber, which means HAAP should teardown this user to let
   this user to redial; code 2 is NACK and indicates this is a existing
   subscriber, HAAP should sent the filter list package to this
   subscriber again.





Leymann, et al.          Expires July 18, 2015                 [Page 32]


Internet-Draft                 GRE-Notif.               January 14, 2015


7.22.  End AVP

   The End AVP is used to indicate that this is the last attribute
   contained in the GRE control messages.  There is no value in End AVP.

   Type: 255 for End AVP

   Length: 0

8.  GRE Tunnels State Machine

   The following state diagram (Figure 28) represents the life cycle of
   HYA bonding tunnel.

                     +------------TUNNEL UP--------------+
                     |                                   |
                   /-+-\                               /-V-\
        + LTE UP-->     +-DSL UP+             +------->     +-------+
        |         |  6  |       |             DSL DOWN|  7  |LTE DOWN
        |          \---/        |    TUNNEL   |        \-+-/        |
      /-+-\                   /-V-\  UP     /-+-\        |        /-V-\
     |     |                 |     +------->     <-DSL UP+       |     |
     |  1  |                 |  3  |       |  4  <-LTE UP+       |  8  |
      \^+-/                   \-^-/         \-+-/        |        \-^+/
       ||                       |             |          |          ||
       ||                       |             |          |   DSL DOWN|
       ||          /---\        |             LTE DOWN /-+-\        ||
       |+-DSL UP-->     +-LTE UP+             +------->     +-------+|
       |          |  2  |                             |  5  |        |
       |           \-^-/                               \-+-/         |
       |             |    TUNNEL DOWN IDLE TIMEOUT       |           |
       |             +-----------------------------------+           |
       +-------------------------------------------------------------+
                               TUNNEL DOWN

                       Figure 28: GRE State Machine

   The various states are described as below:













Leymann, et al.          Expires July 18, 2015                 [Page 33]


Internet-Draft                 GRE-Notif.               January 14, 2015


       State No.    DSL Tunnel      LTE Tunnel       Bonding Tunnel
       =========    ===========    ===========       ===============

          1           Down            Down             Down
          2           Up              Down             Down
          3           Up              Up               Down
          4           Up              Up               Up
          5           Up              Down             Up
          6           Down            Up               Down
          7           Down            Up               Up
          8           Down            Down             Up

                            Tunnel / GRE States

9.  IANA Considerations

   IANA is requested to allocate one code TBD for the dynamic GRE
   protocol.

10.  Security Considerations

   In the whole processing of HA, security of control messages MUST be
   guaranteed.  The CPE discovers the HAAP by resolving the HAAP address
   over DNS.  This protects the CPE against connections to foreign HAAP,
   if the DNS service and the domain name in the CPE isn't corrupted.

   The CPE should be prevented against receiving GRE notifications
   without a valid session In the whole processing of end to end HAAP
   session establishing and GRE notification signaling, the source IP
   address for session establishment from CPE MUST be strictly verified,
   including IP address authentication and identification at the HAAP
   side.  Any authentication mechanism with credential or checking the
   IP address is feasible.

   GRE notification key poisoning Every new session at the HAAP
   generates a magic number, which is encapsulated in the key field of
   the GRE header and will be carried in the signalling messages and
   data traffic for verification by comparing the Magic Number in the
   message and the Magic Number in the local session table.  Traffic
   without a valid Magic Number and outer IP address will be discarded
   on the HAAP.  Magic number is used for both control message and data
   message security.

   For data traffic security, it is also proposed to use IP address
   validation to protect against IP Spoofing attacks.






Leymann, et al.          Expires July 18, 2015                 [Page 34]


Internet-Draft                 GRE-Notif.               January 14, 2015


11.  Acknowledgements

   Many thanks to Dennis Kusidlo.

12.  Normative References

   [I-D.lhwxz-hybrid-access-network-architecture]
              Leymann, N., Heidemann, C., Wasserman, M., and D. Zhang,
              "Hybrid Access Network Architecture", draft-lhwxz-hybrid-
              access-network-architecture-00 (work in progress), June
              2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2561]  White, K. and R. Moore, "Base Definitions of Managed
              Objects for TN3270E Using SMIv2", RFC 2561, April 1999.

   [RFC2697]  Heinanen, J. and R. Guerin, "A Single Rate Three Color
              Marker", RFC 2697, September 1999.

   [RFC2698]  Heinanen, J. and R. Guerin, "A Two Rate Three Color
              Marker", RFC 2698, September 1999.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

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

Authors' Addresses

   Nicolai Leymann
   Deutsche Telekom AG
   Winterfeldtstrasse 21-27
   Berlin  10781
   Germany

   Phone: +49-170-2275345
   Email: n.leymann@telekom.de






Leymann, et al.          Expires July 18, 2015                 [Page 35]


Internet-Draft                 GRE-Notif.               January 14, 2015


   Cornelius Heidemann
   Deutsche Telekom AG
   Heinrich-Hertz-Strasse 3-7
   Darmstadt  64295
   Germany

   Phone: +4961515812721
   Email: heidemannc@telekom.de


   Margaret Wesserman
   Painless Security

   Email: mrw@painless-security.com


   Li Xue
   Huawei
   NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan
   Beijing, HaiDian District 100095
   China

   Email: xueli@huawei.com


   Mingui Zhang
   Huawei
   NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan
   Beijing, HaiDian District 100095
   China

   Email: zhangmingui@huawei.com



















Leymann, et al.          Expires July 18, 2015                 [Page 36]


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