<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-heileyli-gre-notifications-00"
     ipr="trust200902">
  <front>
    <title abbrev="Abbreviated-Title">GRE Notifications</title>

    <author fullname="Nicolai Leymann" initials="N.L." role="editor"
            surname="Leymann">
      <organization>Deutsche Telekom AG</organization>

      <address>
        <postal>
          <street>Winterfeldtstrasse 21-27</street>

          <city>Berlin</city>

          <code>10781</code>

          <country>Germany</country>
        </postal>

        <phone>+49-170-2275345</phone>

        <email>n.leymann@telekom.de</email>
      </address>
    </author>

    <author fullname="Cornelius Heidemann" initials="C.H." surname="Heidemann">
      <organization>Deutsche Telekom AG</organization>

      <address>
        <postal>
          <street>Heinrich-Hertz-Strasse 3-7</street>

          <city>Darmstadt</city>

          <code>64295</code>

          <country>Germany</country>
        </postal>

        <phone>+4961515812721</phone>

        <email>heidemannc@telekom.de</email>
      </address>
    </author>

    <author fullname="Xue Li" initials="X.L." surname="Li">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>NO.156 Beiqing Rd. Z-park,
          Shi-Chuang-Ke-Ji-Shi-Fan-Yuan</street>

          <city>Beijing, HaiDian District 100095</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>xueli@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date month="October" year="2013"/>

    <area>Routing Area</area>

    <workgroup>Interdomain Routing Working Group</workgroup>

    <keyword>GRE Notifications</keyword>

    <keyword>Draft</keyword>

    <abstract>
      <t>GRE (Generic Routing Encapsulation) specifies a protocol for the
      encapsulation of an arbitrary protocol over another arbitrary network
      layer protocol.</t>

      <t>This document describes extensions to manage multiple GRE tunnels
      over multiple access lines to one home network with the purpose to
      present a novel architecture using Hybrid Access (HA) networks. HA is
      designed to bundle multiple access technologies, e.g. fixed access and
      wireless access to one Internet connection. This enables higher
      bandwidth for end customers. The document describes the Hybrid Access
      network architecture and th extensions for GRE which are necessary to
      implement the HA architecture.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document specifies a new GRE extension which allows the
      operators to have home networks that consist of at least two IP access
      lines to the same location from one network gateway. GRE tunnels are
      used to combine the multiple access lines together to one Internet
      connection. The combination from e.g. a wireless access (LTE) and a
      fixed line (DSL) access enables new use cases:.</t>

      <t><list style="numbers">
          <t>Bandwidth on demand, if fixed line is full, bandwidth of mobile
          access is added on demand</t>

          <t>Seamless handover, if one access lines fails the service can
          still be provided without interruption</t>

          <t>Application dependent transport of different combined or
          non-combined access lines to one home network location</t>
        </list>This extension contains signaling information to manage those
      multiple GRE connections over the multiple access lines. The lines can
      have different weight and qualities and have to be merged to one
      authorized connection. Therefore a signaling is needed for the following
      cases:</t>

      <t><list style="numbers">
          <t>Signaling of the IP addresses of the access lines and IP
          addressed of the combination GRE tunnels</t>

          <t>Signaling of the weight of one access line, a cheaper access line
          should be used</t>

          <t>Signaling of keep alive to decide which GRE tunnels are active
          and can be used</t>

          <t>Signaling of bypass traffic amount which should be bypassed from
          the tunnels</t>

          <t>Signalling of deny and allowed messages</t>
        </list></t>
    </section>

    <section title="Use Cases">
      <t>Recently, the existing network status can bringing changes to the
      operator's network: Higher bandwidth requirement and current limited
      usage of existing networks(e.g.wireless network: LTE, etc). There is a
      strong interest to integrate the existing network resource as a single
      Internet connection for end customers. The resulting network is called a
      Hybrid Access (HA) network. The HA network can be controlled by the
      user's Customer Premise Equipment (CPE). The connectivity in HA is being
      implemented by using a tunnel mechanism on top of the physical
      infrastructure.</t>

      <t>This document described the HA architecture by illustrating DSL and
      LTE bundled. Nevertheless the solution is not limited to those
      technologies and can be easily applied to other scenarios. This document
      describes the base HA network architecture, while solution approach with
      extensions of GRE protocol <xref target="RFC2890"/> will realize HA
      network architecture.</t>

      <t>With HA many deficiencies in the current operator's network,
      following use cases are enabled.</t>

      <t><list style="hanging">
          <t hangText="1.">Bandwidth On Demand</t>
        </list>Typically end customers are only connected using a single link
      (e.g. fixed or wireless) to the network of a service provider. If the
      required bandwidth exceeds the bandwidth provided by the link usually
      the link needs to be upgraded. However, using the current network
      deployment model such an upgrade is not always economically feasible. A
      different approach is needed.</t>

      <t>In this model end customer are connected over one standard access
      line (e.g.fixed line: DSL, Cable, ...) primarily to the operator's
      service. In addition there are one or more another connections over the
      different access technologies, (e.g. wireless line: LTE). If the traffic
      exceeds the bandwidth of the primary access line the bundled connections
      can provide a higher bandwidth to the end customer.</t>

      <t><list style="hanging">
          <t hangText="2.">Seamless Handover</t>
        </list></t>

      <t>In HA network, the customer has a CPE connection through the access
      network (e.g.fixed line: DSL, Cable, ...). The CPE also provides a
      back-up WAN connection through another network (e.g. wireless line:
      LTE), when the fixed line is unavailable.</t>

      <t>The customer is using Internet service via fixed WAN connection. When
      the fixed connection gets disconnected unexpectedly, the ongoing service
      is automatically switched to the backup connection. The Internet service
      is not interrupted by this event and continues seamlessly by
      end-user.</t>
    </section>

    <section title="Conventions and Terminology">
      <t/>

      <section title="Terminology">
        <t><list style="hanging">
            <t hangText="Bonding Tunnel:">The bundling tunnel of both fixed
            access tunnel and wireless access tunnel. The bonding tunnel in HA
            is the connection on top of the physical infrastructure,
            terminated between CPE and HAAP.</t>

            <t hangText="Tunnel Transit IP:">The outer IP of a GRE
            encapsulation.</t>

            <t hangText="DSL Tunnel:">The GRE tunnel between CPE DSL WAN and
            HAAP. The tunnel transit IP is IP address of CPE DSL WAN interface
            and HAAP address. It is one subset tunnel of bonding tunnel.</t>

            <t hangText="Dynamic GRE:">The dynamic stateful GRE tunnel.</t>

            <t hangText="Customer Premise Equipment  (CPE):">A device that
            connects multiple terminals to provide connectivity to the service
            providers network.</t>

            <t hangText="Hybrid Access (HA):">Hybrid Access (HA) is the
            bundling of two or more access line over different technologies
            (e.g. DSL and LTE) to one Internet connection for end
            customers.</t>

            <t hangText="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 different
            access technologies.</t>

            <t hangText="HA IP:">The inner IP of a GRE encapsulation. This IP
            is assigned by HAAP to CPE; this is the IP for the Internet
            communication. Sometimes it is called tunnel IP in this
            document.</t>

            <t hangText="LTE Tunnel:">The GRE tunnel between CPE LTE WAN and
            HAAP. The tunnel transit IP is IP address of CPE LTE WAN interface
            and HAAP address. It is one subset tunnel of bonding tunnel.</t>
          </list></t>
      </section>
    </section>

    <section title="Hybrid Access Network Architecture">
      <t>The basic idea of Hybrid Access is the bundling of the DSL and LTE
      access technologies. <xref target="NetworkArch"/> illustrates one
      example of Hybrid Access network.</t>

      <t><figure anchor="NetworkArch"
          title="Hybrid Access Network Architecture">
          <artwork><![CDATA[
         |==============================================|
         | <........e.g. LTE Tunnel ..................> |
    <--->| <........e.g. DSL Tunnel ..................> |<--->
         |==============================================|           -----
      +--+---+        Bonding Tunnel               +----+----+    /       \
      |      |                                     |         |   | Internet|
      | CPE  |                                     |  HAAP   +---+         |
      +--++--+                                     +---+-+---+    \       /
         ||              Mobile   network              | |          -----
         ||        *......................... *        | |
         ||        < +------+       +------+  >        | |
         |+----------+      +-------+      +-----------+ |
         |         < |eNodeB|       | EPC  |  >          |
         |         < +------+       +------+  >          |
         |         *..........................*          |
         |                                               |
         |         *......................... *          |
         |         ( +------+       +------+  )          |
         +-----------+      +-------+      +-------------+
                   ( |  AN  |       | SN   |  )
                   ( +------+       +------+  )
                   *..........................*
                          Fixed Network
   Legend:
   AN      Access Node
   CPE     Customer Premise Equipment 
   SN      Service Node
   EPC     Evolved Packet Core 
   HAAP    Hybrid Access Aggregation Point]]></artwork>
        </figure></t>

      <t/>

      <t>In the fixed network, users are served fixed services by the Access
      Node (AN) and Service Node (e.g. Broadband Network Gateway (BNG)). In
      the wireless network, cellular sites are connected to the mobile core
      network using mobile backhaul network and EPC core network. The new
      approach of Hybrid should take into consideration the fact that
      operators introduces additional network bandwidth resource with limited
      usage to users.</t>

      <t>In the HA architecture, on the client site, CPE is used to implement
      the bonding mechanism for customers. On the network side, a device named
      as Hybrid Access Aggregation Point (HAAP) MUST be deployed. The HAAP
      which acts as a service termination and a service creation implements
      bonding mechanism and sets up a higher speed Internet dual stack IP
      connection with the CPE on top of both access technologies a.k.a., DSL
      and LTE. The HA connection between the end user's CPE and the HAAP could
      be done by using the tunnel mechanism on top of the physical
      infrastructure. This document describes the extensions for dynamic GRE
      which are necessary.</t>

      <t>The bonding tunnel between CPE and HAAP carries best effort traffic
      going to and coming from the public Internet. Particularly, based on the
      operator's requirement, it is possible that not all traffic from the
      home network is routed into the bonding tunnel in order to ensure that
      existing services are not influenced by using HA. Certain traffic such
      as VoIP, IPTV traffic depending on its destination or QoS markings,
      needs to be routed via the fixed line interface or via the wireless
      interface instead to be routed into the bonding tunnel between CPE and
      HAAP. The CPE should implement an mechanism which can be used to specify
      exceptions (traffic which should not be routed into the tunnel). This
      mechanisms is out of scope of this document.</t>
    </section>

    <section title="Solution Approach Overview">
      <t>The bonding tunnel behavior is accomplished by implementing dynamic
      subset tunnels setup and bonding them together during the procedure.
      This section identifies the HA solution approaches that operators can
      leverage for deploying HA technologies, which is dynamic Generic Routing
      Encapsulation (GRE).</t>

      <section title="Dynamic GRE Definition">
        <t>The dynamic GRE protocol is specified for encapsulation of the user
        traffic over multiple arbitrary network layer via bundling mechanism
        on CPE and HAAP. This section describes dynamic GRE protocol.</t>

        <t>The dynamic GRE protocol transport layer carries GRE encapsulated
        Control messages, and GRE encapsulated Data messages. GRE Data
        messages encapsulate forwarded user frames. GRE Control messages are
        management messages exchanged between a CPE and a HAAP in HA
        architecture. The format of GRE protocol Control are defined in
        section 7.</t>

        <t>The dynamic GRE protocol begins with a base access phase. CPE gets
        DSL WAN interface IP address through PPPoE from service node (e.g.,
        BNG) or DHCP and LTE WAN interface IP address through Packet Data
        Protocol (PDP)<xref target="TS23.401"/> from PGW. Additionally, CPE
        obtains HAAP address for tunnel establishment. From the base access
        phase, a CPE discoveries the HAAP with which to establish the tunnels
        for HA.</t>

        <t>Once the base access have be completed, GRE Request is initiated by
        CPE in order to begin bonding tunnels setup phase between CPE and
        HAAP. CPE setups the authorized LTE GRE tunnel before DSL GRE tunnel
        by sending GRE Request control messages via LTE WAN interface to HAAP.
        After, CPE obtains HA IP address from HAAP through DHCP over LTE GRE
        tunnel. Subsequently, authorized DSL GRE tunnel is established. During
        these exchanges, the CPE may receive some information in order to
        enable both tunnel bundled. GRE Accept/Deny identifies that GRE tunnel
        setup request is accepted/rejected.</t>

        <t>When the CPE and HAAP have completed the bonding tunnels setup
        exchange, the customers have the single service connection through
        both access technologies infrastructure. Particularly,the specific
        traffic will send through the bonding tunnels and thus encapsulated by
        GRE. As long as the primary connection (e.g., DSL) is sufficient,
        traffic goes through the DSL GRE tunnel only. If traffic exceeds the
        bandwidth, traffic overflows to the LTE GRE tunnel.</t>

        <t>The dynamic GRE also provides commands exchange between CPE and
        HAAP for HA management. These may be included in GRE Notify message
        for tunnel status/information changing between CPE and HAAP. These may
        include the bypass traffic amount which should be bypassed from the
        bonding tunnels.</t>

        <t>The dynamic GRE protocol provides for a keep-alive feature that
        preserves the communication channel between the CPE and HAAP. If the
        tunnels fail to appear alive, the CPE will try to re-establish it. For
        example, if the DSL tunnel cannot be re-established, HA traffic will
        still run through the LTE tunnel only. If the LTE tunnel cannot be
        re-established, new Internet sessions will be established over native
        DSL. The DSL tunnel will be finally torn down after a period without
        service interruption.</t>

        <t>For maintenance reasons, the GRE Tear Down message also can be used
        by CPE and HAAP to complete the HA architecture in out of service
        scenario.</t>
      </section>

      <section title="Bonding Tunnel Establishement Overview ">
        <t>This section describes the bonding tunnel establishment process
        message exchanges between CPE and HAAP. The annotated ladder diagram
        shows the CPE on the left, the HAAP on the right. The dynamic GRE
        state mechanism is defined in detail in <xref
        target="GREStateMachine"/>. Note that in the Authentication step, the
        authentication required certain messages are aggregated into a single
        step, which is denoted via an asterisk line in <xref
        target="GRETunnelEst"/></t>

        <figure anchor="GRETunnelEst" title="GRE Tunnel Establishment ">
          <artwork><![CDATA[
       ==========           ::::::::::                    ==========
           CPE                 SN/PGW                        HAAP
       ==========           ::::::::::                    ==========

       [...CPE gets DSL WAN connection through PPPoE/DHCP ....]
       [...CPE gets LTE WAN connection through PDP from PGW...]
       [........ CPE gets HAAP address via DNS   .............]

       [.......... begin bonding tunnel setup ...............
         (........ begin lte gre tunnel setup .............)

          --------   LTE GRE Setup Request   -------------->

         **** Authentication and Authorization Passed  *****

          <--------  LTE GRE Setup Accept(session ID) ------

        (......... lte gre tunnel is setup now ............)


         ---- Request HA IP Address (DHCP over LTE GRE) --->

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


        (........ begin dsl gre tunnel setup .............)

         --------   DSL GRE Setup Request (session ID) ---->

         ****  Authentication and Authorization Passed  *****

         <--------  DSL GRE Setup Accept    ----------------

        (........ dsl gre tunnel is setup now ............)

       [.......... bonding tunnel is setup now...............]


]]></artwork>
        </figure>

        <t>At the end of the illustrated GRE control messages exchange, the
        bonding tunnel between CPE and HAAP is setup completely by binding LTE
        Tunnel and DSL Tunnel with same session ID, defined in <xref
        target="S-DynamicGREProt"/>.</t>

        <t>After, the CPE and HAAP are securely exchanging GRE Control
        messages for tunnel keepalive (GRE Hello) and management (GRE
        Notify).</t>

        <t>The GRE Notify message is used to inform status/information
        changing information between CPE and HAAP. A notify acknowledgement
        (ACK) and retransmission mechanism can be used to provide certain
        level reliable transport capability. When receiving end receives a
        notify packet, it will send back a GRE notify packet without any
        attributions appended to the sending end immediately as
        acknowledgement for the notify packet. When sending end doesn't
        receive the notify ACK message in after a specific seconds, sending
        end treats it as lost of notify message and will retransmit the notify
        message.</t>

        <t>When sending end not receiving the notify ACK for a certain notify
        message for continually specific times, sending end treats it as
        sending failure and tunnel failure also, sending end will tear down
        the GRE tunnel which sent the notify message. If the CPE is the
        sending end, the CPE will tear down the tunnel over which the notify
        packet was send, and try to re-establish the tunnel. If HAAP is the
        sending end, the HAAP will tear down the corresponding GRE tunnel and
        wait for CPE to reestablish it.</t>

        <t>This illustration is provided to clarify the protocol operation,
        and does not include any possible error conditions and all the control
        packets. <xref target="GREStateMachine"/> provides a detailed
        description of the corresponding state machine.</t>
      </section>
    </section>

    <section anchor="GREStateMachine"
             title="Dynamic GRE State Machine Definition ">
      <t>The following state diagram (<xref target="Figure-GREStateMachine"/>)
      represents the life cycle of HA bonding tunnel.</t>

      <t><figure anchor="Figure-GREStateMachine" title="GRE State Machine">
          <artwork><![CDATA[
                   +------------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
]]></artwork>
        </figure>The various states are described as below:</t>

      <t><figure title="Tunnel / GRE States">
          <artwork><![CDATA[
    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
]]></artwork>
        </figure></t>
    </section>

    <section title="Dynamic Packet Format">
      <t>This section describes GRE encapsulated control messages definitions
      and attributes which can be optionally carried in the GRE control
      messages.</t>

      <section title="Dynamic GRE Control Messages ">
        <t>The GRE control messages are defined according to <xref
        target="RFC2890"/>. The proposed GRE header of the control messages
        has the following format (see <xref
        target="GREHeaderFormat"/>):<figure anchor="GREHeaderFormat"
            title="GRE Header Format">
            <artwork><![CDATA[
     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                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t>Protocol Type (2 octets)</t>

        <t>The Protocol Type field identifies the dynamic GRE protocol. The
        value is TBD.</t>

        <t>Message Type (MesType) (4 bits)</t>

        <t>The Message Type field identifies the dynamic GRE protocol control
        messages in the HA network. The value is TBD. The existing control
        message types are listed below. Additional values may be defined in
        the future.</t>

        <t><figure anchor="F-ControlMessages" title="GRE Control Messages">
            <artwork><![CDATA[
      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
]]></artwork>
          </figure></t>

        <t>Tunnel Type (T) (1 bit)</t>

        <t>It indicates this control message for the type of the subset tunnel
        in HA. For example, if the Tunnel Type (T) bit is set to 1, then this
        control message is for the DSL tunnel shown in <xref
        target="F-ControlMessages"/>. Otherwise it indicates that this is for
        the LTE tunnel shown in <xref target="F-ControlMessages"/>.</t>

        <t/>

        <t>Attribute Type (1 octet)</t>

        <t>The Attribute Type indicates the type of the appended attribution
        in the control message. The attribute value pair is defined in <xref
        target="S-DynamicGREProt"/>.</t>

        <t/>

        <t>Attribute Length (2 octets)</t>

        <t>The Attribute Length field indicates the length of the attribute by
        byte.</t>

        <t/>

        <t>Attribute Value (variable)</t>

        <t>The Attribute Value field includes the value of the attribute.</t>
      </section>

      <section anchor="S-DynamicGREProt"
               title="Dynamic GRE Protocol Messages Attributes">
        <t>This section defines the attributions that are included in dynamic
        GRE protocol control messages. Attributions are used to carry
        information needed during bonding tunnel setup and management
        procedure. Every attribution is identified by the Type, Length, Value
        field. All of the message attributions in this document use the same
        format, shown as below in <xref target="F-MessageAttributes"/>.</t>

        <t><figure anchor="F-MessageAttributes" title="GRE Message Attributes">
            <artwork><![CDATA[
    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......                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure>The 8-bits Type field identifies the type of the appended
        attribution carried in Attribute Value field in the control messages
        header. The type field values are allocated right now listed in this
        section as follows:</t>

        <t><list style="symbols">
            <t>Session ID</t>
          </list>This is 32 bits value is generated by HAAP, and unified
        within a HAAP, to identify a certain subscriber. This value is using
        to binding the DSL tunnel and LTE tunnel together for individual HA
        user. HAAP generates a session ID for a HA user's and sends this value
        to CPE via LTE GRE setup accept, then CPE carries this value in the
        DSL GRE setup request, defined in section 4.2. With this information,
        HAAP binds the DSL tunnel and LTE tunnel together, then bonding GRE
        tunnel is achieved accordingly. When LTE recovery from failure with
        DSL tunnel exists, the re-establish LTE tunnel request need carry the
        Session ID attribute.</t>

        <t>Type: 4 for Session ID</t>

        <t>Length: 4 Octets</t>

        <t>Value: 32 bits value generated by HAAP.</t>

        <t><list style="symbols">
            <t>Bypass Traffic Rate</t>
          </list>This attribute is used to notify HAAP of the downstream
        bypass traffic on CPE via DSL Notify control message from CPE. HAAP
        will calculate the available DSL bandwidth for DSL GRE tunnel based on
        this information. CPE and HAAP can decide the bypass traffic amount
        which should be bypassed from the combination tunnels. The unit of
        this value is kbps.</t>

        <t>Type: 6 for Bypass traffic rate</t>

        <t>Length: 4 Octets</t>

        <t>Value: Downstream bypass traffic on CPE.</t>

        <t><list style="symbols">
            <t>Hello Interval</t>
          </list>This is the configuration which is assigned to the CPE by the
        HAAP. Configure the Hello signaling checking period on CPE from HAAP.
        The unit of this value is second. This attribution is carried in GRE
        Setup Accept control message for LTE tunnel.</t>

        <t>Type: 14 for Hello Interval</t>

        <t>Length: 4 Octets</t>

        <t>Value: Hello Interval</t>
      </section>
    </section>

    <section title="Overflow Bonding Operations">
      <t>In HA network, the user traffic can be transferred to wireless access
      (Overflow tunnel) when the fixed line (Primary tunnel) bandwidth is not
      any more sufficient.</t>

      <t>There are two types of overflow bonding mechanisms, packet-based
      balancing and stream-based balancing. Balancing per stream can require
      the DSL bandwidth threshold configuration. The steam only runs over the
      DSL or LTE link. Balancing of per packet will use DSL bandwidth as soon
      as DSL bandwidth is not full. It is possible that the same stream can
      run the different DSL and LTE link at the same time. In HA network,
      packet-based balancing is proposed for efficiency.</t>

      <t>The packet-based overflow balancing is based on the Single Rate Three
      Color Marker (srTCM) and Two Rate Three Color Marker (trTCM) which is
      defined in<xref target="RFC2697"/> and <xref target="RFC2698"/>.The
      packet is marked if the packet is overflowed or not. The CIR (Committed
      Information Rate) is equal to the DSL bandwidth minus several layers'
      overhead. The CBS (Committed Burst Size) provides the burst capability
      which can help TCP achieve the committed bandwidth. This mechanism is
      used on both HAAP for downstream overflow bonding and CPE for upstream
      overflow bonding.</t>

      <t>Then the colored based policy routing is executed for packet-based
      balancing, user's packet will be routed into the corresponding tunnel
      based on color. For example,Yellow color packet will be routed to LTE
      GRE tunnel; green color packet will be routed into DSL GRE tunnel. At
      this stage, the GRE IP header will be added.</t>

      <t>Additionally, during the packet-based balancing, reorder mechanism
      are need for both HA downstream and upstream. On the downstream, the
      packets encapsulated in GRE will come from DSL GRE tunnel and/or LTE GRE
      tunnel. The packets will be sent to a buffer for reordering. If the GRE
      sequence number is not continuous, the packets will be buffered until
      the missing sequence packet has arrived or the buffering time has
      expired. After reordering, the GRE header will be removed and the packet
      will be sent to the ordinary CPE processing. Upstream direction
      reordering is performed on HAAP using the same mechanism as
      downstream.</t>

      <t>In order to ensure that existing services are not influenced by using
      HA, it is possible that certain traffic does not be routed through the
      tunnel, but directly over the corresponding interfaces. This is
      necessary in case the tunnel and the HAAP are not supporting QoS (e.g.
      for IPTV or VoIP services) and Multicast (for IPTV). Some customers
      delay-sensitive traffic (like Internet gaming) need to be sent through
      the fixed line interface to ensure quality of experience depending on
      customer requirements.</t>

      <t>This bypass behavior is accomplished by implementing a routing table
      which routes traffic which needs to bypass the tunnel through its
      relevant interfaces. For example, IPTV related traffic might be routed
      over the fixed line interface to ensure the use of QoS.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA is requested to allocate one code TBD for the dynamic GRE
      protocol.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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.</t>

      <t>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.</t>

      <t>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.</t>

      <t>For data traffic security, it is also proposed to use IP address
      validation to protect against IP Spoofing attacks.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Many thanks to Dennis Kusidlo.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.2697'?>

      <?rfc include='reference.RFC.2698'?>

      <?rfc include='reference.RFC.2890'?>

      <reference anchor="TS23.401">
        <front>
          <title>3GPP TS23.401, General Packet Radio Service (GPRS)
          enhancements for Evolved Universal Terrestrial Radio Access Network
          (E-UTRAN) access</title>

          <author>
            <organization/>
          </author>

          <date month="September" year="2013"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
