[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Locator/ID Separation Protocol                                  M. Menth
Internet-Draft                                             A. Stockmayer
Intended status: Experimental                                 M. Schmidt
Expires: January 7, 2016                         University of Tuebingen
                                                            July 6, 2015


                           LISP Hybrid Access
                         draft-menth-lisp-ha-00

Abstract

   Hybrid access (HA) allows simultaneous usage of multiple access
   links.  Advantages are increased bandwidth and improved resilience.
   This document presents LISP Hybrid Access (LISP-HA), a mechanism to
   provide HA based on LISP technology.  The document discusses
   potential changes needed to perform dynamic load-balancing and per
   packet load-balancing, which both increase the efficiency of HA.  To
   that end, modified usage of some fields in the LISP header is
   proposed.  Discussed use cases include the bundling of multiple
   access technologies for mobile devices and residential access
   routers.  Additionally, we provide some considerations how LISP-HA
   can be deployed by providers.

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 January 7, 2016.

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



Menth, et al.            Expires January 7, 2016                [Page 1]


Internet-Draft                   LISP-HA                       July 2015


   (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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  LISP-HA-Architecture  . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Basic Operation . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Message Sequence Diagram for Basic Operation. . . . . . .   6
     3.3.  Policy-Based Path Selection . . . . . . . . . . . . . . .   8
     3.4.  Operation of an HAxTR behind a NAT  . . . . . . . . . . .   8
     3.5.  Extensions for Dynamic Load Balancing . . . . . . . . . .  10
     3.6.  Extensions for Packet-Based Load Balancing  . . . . . . .  11
     3.7.  Deployment Considerations . . . . . . . . . . . . . . . .  12
   4.  Packet Formats  . . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  Dataplane Header  . . . . . . . . . . . . . . . . . . . .  12
     4.2.  Control Message . . . . . . . . . . . . . . . . . . . . .  13
   5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     5.1.  Connecting Residential Users to the General Internet  . .  14
     5.2.  Smartphones with Mobile Node. . . . . . . . . . . . . . .  15
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   Hybrid access (HA) enables a device to simultaneously use multiple
   access links both in upstream and downstream direction.  A challenge
   of HA is to make load balancing of the traffic onto multiple paths
   transparent to endpoints.  HA may be supported on various layers.
   Multilink PPP (ML-PPP) [RFC1990] offers support for fragmented
   protocol data units (PDU) on the same local network.  Therefore, it
   cannot combine network layer paths so that it is unable to bundle
   paths provided by different Internet service providers.  A network
   architecture for HA is presented in
   [I-D.lhwxz-hybrid-access-network-architecture].  It focuses on
   bundling DSL and LTE for residential access by means of dedicated
   customer premises equipment (CPE) which does not support mobile
   devices in general.  Multipath TCP (MP-TCP) leverages multiple paths



Menth, et al.            Expires January 7, 2016                [Page 2]


Internet-Draft                   LISP-HA                       July 2015


   on the transport layer [RFC6824].  It requires both source and
   destination endpoint to support MP-TCP.  MP-TCP proxies are currently
   discussed for inter-operation with non-MP-TCP nodes
   [I-D.hampel-mptcp-proxies-anchors].  HA can be also supported by MP-
   TCP, but that approach is limited to TCP traffic.  Furthermore,
   supporting policies such as cheapest link first seems challenging
   with this approach.

   LISP by itself has basic capabilities to support HA with static load
   balancing that is not agnostic to current link loads and
   characteristics.  That means, a multihomed LISP xTR may perform
   inbound traffic engineering.  This is achieved by setting appropriate
   weights for multiple RLOCs in register messages so that it receives
   traffic over more than a single interface.  Outbound traffic may be
   sent over multiple interfaces according to local policies.

   This document proposes LISP-HA as a novel solution for HA with
   improved load balancing capabilities for better resource efficiency.

2.  Terminology

   Hybrid Access (HA):  Using two or more access lines to improve
      bandwidth and resilience; both technologies are used at the same
      time.

   Mobile Node (MN):  A LISP node that includes its own xTR and can
      connect to more than a single network at a time
      [I-D.meyer-lisp-mn].

   Mapping System (MS):  The LISP Mapping System as defined in RFC 6830
      [RFC6830].

   LISP Tunnel Router (xTR):  A combination of ITR and ETR [RFC6830].

   LISP Proxy Tunnel Router (PxTR):  iUsed to communicate with the
      legacy Internet [RFC6830].

   LISP Reencapsulating Tunnel Router (RTR):  LISP router to forward
      LISP-TE packets [I-D.farinacci-lisp-te].

   LISP NAT Traversal Router (NTR):  A LISP router that allows to
      communicate with LISP nodes behind a NAT
      [I-D.ermagan-lisp-nat-traversal].

   LISP Canonical Address Format (LCAF):  Extension to the AFI type
      system to associate the AFI, e.g.  with policies
      [I-D.farinacci-lisp-lcaf].




Menth, et al.            Expires January 7, 2016                [Page 3]


Internet-Draft                   LISP-HA                       July 2015


   Explicit Locator Path (ELP):  A mapping storing a sequence of RLOCs,
      indicating RTRs that receive and forward LISP packets to the next
      RLOC in that list; defined by LISP-TE [I-D.farinacci-lisp-te].

   Hybrid Acces xTR (HAxTR):  An xTR with multiple RLOCs that supports
      LISP-HA.

   Hybrid Access RTR (HARTR):  An RTR that supports LISP-HA.

   Hybrid Access Load Balancing (HALB):  Function in HAxTR and HARTR
      that distributes traffic over multiple paths.

   Hybrid Access Reorder and Feedback (HARF):  Function in HAxTR and
      HRTR that reorders traffic sent by a corresponding HALB over
      multiple paths and provides feedback about the link condition to
      the HALBs.

3.  LISP-HA-Architecture

   This section describes the basic operation of LISP-HA as well as
   policy-based path selection, its operation with LISP nodes behind
   NATs, extensions for dynamic load balancing, and extensions for
   packet-based load balancing.  Finally, we consider how it could be
   useful for providers to operate their own HARTR.

3.1.  Basic Operation

   LISP-HA allows to load-balance traffic over multiple paths between a
   HAxTR and HARTR.  This is transparent to nodes not on the path
   between HAxTR and HARTR.  Load-balancing works in both directions,
   therefore, both the HAxTR and the HARTR implement a HA Load Balancing
   function (HALB) and a HA Recombination function (HARF).

   We present how LISP-HA makes EIDs globally reachable over multiple
   paths between HARTR and HAxTR.  To that end, we consider the setting
   illustrated in Figure 1.















Menth, et al.            Expires January 7, 2016                [Page 4]


Internet-Draft                   LISP-HA                       July 2015


              Mapping System
          +----------------------------------------+
          |  EID |              Entry              |
          -------+---------------------------------+
          | EID0 | ELP: RLOC-HARTR -> RLOC-HAxTR-0 |
          | EID0 | ELP: RLOC-HARTR -> RLOC-HAxTR-1 |
          -----------------------------------------+


                          +------+
                    +-----| Wifi |----+
                    |     +------+    |
                    |                 |
                    |                 |
   +------+   +-----------+     +-----------+           +------+
   | EID0 |---|   HAxTR   |     |   HAR     |--- ... ---| EID1 |
   +------+   | HALB/HARF |     | HALB/HARF |           +------+
              +-----------+     +-----------+
                    |                 |
                    |                 |
                    |     +-----+     |
                    +-----| LTE |-----+
                          +-----+



   Figure 1: LISP-HA load-balances traffic between HAxTR and HARTR over
                       multiple network layer paths.

   A HAxTR is configured with the address of a HARTR and registers its
   EID prefixes at the MS.  To that end, it uses explicit locator paths
   (ELPs), containing the RLOC of the HARTR in the penultimate positoin
   of the ELP and one of its own RLOCs in the last position of the ELP.
   The HAxTR must send one register message for each of its RLOCs and
   over the interface that corresponds to that RLOC so that the MS can
   detect whether the HAxTR is behind a NAT.

   The HALB functions of the HAxTR and the HARTR distribute the traffic
   over multiple network layer paths between them.  Flow-based or
   packet-based load-balancing may be supported.

   Figure 2 shows a communication scenario between two LISP nodes.  The
   HAxTR is connected to the Internet / LISP net over multiple access
   technologies and LISP-HA is applied between HAxTR and HARTR.  The
   endpoints EID0 and EID1 exchange messages over the HAxTR, the HARTR,
   and the xTR.  The figure shows the destination EIDs and RLOCs of
   these messages.  The HAxTR/xTR add RLOCs to the messages through
   encapsulation, the HARTR exchanges the RLOCs, and the xTR/HAxTR



Menth, et al.            Expires January 7, 2016                [Page 5]


Internet-Draft                   LISP-HA                       July 2015


   remove RLOCs from the messages through decapsulation.  The HAxTR and
   xTR add RLOCs to the messages through encapsulation and the HARTR
   exchanges the RLOCs.  In upstream direction, the HAxTR adds the RLOC
   of the HARTR and selects the path by choosing the appropriate
   interface.  The HARTR exchanges its own RLOC by the RLOC of the xTR.
   In downstream direction, the xTR adds the RLOC of the HARTR as
   specified in the ELP.  The HARTR exchanges this RLOC with the
   appropriate RLOC of the HAxTR.  Thereby the desired path is selected.


   Upstream example:

   EID0  --->  HAxTR  --->   HARTR   --->   xTR  --->   EID1

         EID1         EID1           EID1        EID1
                   RLOC-HARTR       RLOC-xTR

   Downstream example:

   EID0  <---  HAxTR  <---   HARTR   <---   xTR  <---   EID1

         EID0         EID0           EID0        EID0
                  RLOC-HAxTR-i    RLOC-HARTR


     Figure 2: Destination EIDs and RLOCs of a LISP packet between two
                         communicating endpoints.

3.2.  Message Sequence Diagram for Basic Operation.

   Figure 3 and Figure 4 illustrate the basic operation of LISP-HA by a
   diagram showing all control and data messages exchanged to send data
   in upstream and downstream direction.  In both cases we assume that
   the HAxTR and the xTR have registered their EIDsi EID0 and EID1 at
   the MS, but the required mappings are not available in caches.

   When the endhost with EID0 starts sending data to EID1, it forwards
   them to its HAxTR.  The HAxTR requests the mapping for RLOC of EID1
   from the MS to verify that EID1 is globally reachble before sending
   it to the HAxTR.  The HAxTR encapsulates the packet with the
   configured address of the HARTR as destination RLOC, using the access
   line selected by its HALB.  Upon receipt of the packet, the HARTR
   also requests the mapping for EID1, exchnages the destination RLOC in
   the packet with the RLOC of the xTR provided in the map-reply and
   sends the packet to the xTR.  Upon receipt, the xTR decapsulates the
   LISP packet and forwards it to the endhost with EID1.





Menth, et al.            Expires January 7, 2016                [Page 6]


Internet-Draft                   LISP-HA                       July 2015


   EID0        HAxTR        MS        HARTR        xTR        EID1
         data
     ----------->
                request for EID1
                  ---------->
                reply containing RLOC-xTR
                  <----------
           LISP data with dst:EID1 / RLOC-HARTR
                  --------------------->
                            request for EID1
                             <----------
                      reply containing RLOC-xTR
                             ---------->
                         LISP data dst:EID1/RLOC-xTR
                                        ----------->
                                                        data
                                                    ---------->



      Figure 3: Message sequence diagram for upstream communication.

   When endhost with EID1 starts sending data to EID0, it forwards them
   to its xTR.  The HAxTR requests the mapping for EID0 from the MS,
   receives the ELP for EID0, encapsulates the packet with RLOC-HARTR,
   and sends it to the HARTR.  Upon receipt of the packet, the HARTR
   requests the mapping for EID0 from the MS.  The HALB function of the
   HARTR selects the path to the HAxTR, the HARTR exchanges the
   destination RLOC in the LISP packet with RLOC-HAxTR and sends the
   packet over the determined path.  Upon receipt, the HAxTR
   decapsulates the LISP packet and forwards it to the endhost with
   EID0.



















Menth, et al.            Expires January 7, 2016                [Page 7]


Internet-Draft                   LISP-HA                       July 2015


   EID0        HAxTR        MS        HARTR        xTR        EID1
                                                        data
                                                    <----------
                                 request for EID0
                              <-----------------
              reply containing ELP:RLOC-HAxTR-i -> HARTR
                             ----------------->
                                   LISP data with dst:EID0/RLOC-HARTR
                                        <-----------
                               request for EID0
                             <----------
                            reply containing ELP:RLOC-HAxTR-i -> HARTR
                             ---------->
                LISP data with dst:EID0/RLOC-HAxTR-i
                  <---------------------
        data
    <------------


     Figure 4: Message sequence diagram for downstream communication.

3.3.  Policy-Based Path Selection

   For specific kinds of traffic, e.g., for realtime communication, the
   usage of specific paths may be desired.  LISP-HA supports such
   requirements through LISP LCAF extensions both on upstream and
   downstream.  To that end, the HAxTR is configured with LCAF
   extensions, e.g., indicating that traffic for realtime communication
   must be forwarded over a specific path.  The HAxTR uses this LCAF as
   local policy to encapsulate the traffic.  In addition, Tthe HAxTR
   registers the same LCAF at the MS.  As a consequence, xTRs
   encapsulate traffic towards the HAxTR using the specific RLOC in the
   LCAF.

3.4.  Operation of an HAxTR behind a NAT

   A HAxTR may be located behind a NAT.  We consider this case as this
   scenario is common for HAxTRs connected via LTE.













Menth, et al.            Expires January 7, 2016                [Page 8]


Internet-Draft                   LISP-HA                       July 2015


              Mapping System
          +------+---------------------------------+
          | EID  |              Entry              |
          +------+---------------------------------+
          | EID0 | ELP: RLOC-HARTR -> RLOC-HAxTR-0 |
          | EID0 | ELP: RLOC-HARTR -> RLOC-NTR     |
          +------+---------------------------------+


                          +------+
                    +-----| Wifi |-----------+
                    |     +------+           |
                    |                        |
                    |                        |
   +------+   +-----------+            +-----------+           +------+
   | EID0 |---|   HAxTR   |            |   HARTR   |--- ... ---| EID1 |
   +------+   | HALB/HARF |            | HALB/HARF |           +------+
              +-----------+            +-----------+
                    |                        |
                    |                        |
                    |     +-----------+   +-----+
                    +-----| LTE | NAT |---| NTR |
                          +-----------+   +-----+



     Figure 5: LISP-HA load-balances traffic between HAxTR and HARTRT
                while part of the traffic traverses a NAT.

   We show how LISP-HA leverages existing LISP NAT traversal
   [I-D.ermagan-lisp-nat-traversal] so that it does not require
   additional mechanisms to cope with NATs.

   Figure 5 shows a HAxTR that is connected to the Internet / LISP net
   via LTE and through a NAT.  The HAxTR registers its RLOC at the MS,
   the MS detects that the RLOC in the LISP register message differs
   from the RLOC in the outer header encapsulating it.  As a
   consequence, the MS does not register the mapping and informs the
   HAxTR proposing a list of potential NAT Traversal Routers (NTRs).
   Then, the HAxTR selects one of the NTRs and registers again at the MS
   via this NTR.  The NTR exchanges the RLOC in the mapping by its own
   RLOC (RLOC-NTR).  As a result, traffic for the HAxTR is directed to
   the NTR which forwards it to the HAxTR.  This mechanism works for
   LISP-HA only if the HAxTR registers its ELPs over the corresponding
   interfaces; otherwise the MS cannot securely detect that the HAxTR is
   behind a NAT.





Menth, et al.            Expires January 7, 2016                [Page 9]


Internet-Draft                   LISP-HA                       July 2015


   The usage of general NTRs leads to triangle routing and adds
   significant delay which may be prohibitive.  However, an NTR may be
   combined with the HARTR and configured with the HAxTR so that
   triangle routing and added path delay are avoided.

   To cope with carrier grade NATs, messages need to be exchanged
   frequently enough over the NTR to avoid that NAT table entries are
   removed.  This, however, is to be fixed for the NTR draft
   [I-D.ermagan-lisp-nat-traversal].  Moreover, HAxTR and HARTR exchange
   feedback messages for dynamic load balancing frequently enough so
   that NAT table entries will not be removed.

3.5.  Extensions for Dynamic Load Balancing

   One goal of HA is to increase a HAxTR's overall access bandwidth by
   combining the bandwidth of all available paths.  However, static load
   balancing leads to statistical variations [Menth06p] so that some
   paths are already overloaded while others are underutilized.  Dynamic
   load balancing takes the current load on the links into account and
   can achieve better resource utilization without overloading paths.

   We propose dynamic load balancing for LISP-HA with the purpose to
   increase resource efficiency, thereby providing higher bandwidth to
   the user.  A challenge is that path properties like available
   bandwidth and delay are possibly unknown and vary over time,
   especially if the path is shared and includes wireless links.  Also
   flow rates vary over time and the rate of elastic flows depends on
   path characteristics.  Nevertheless, incipient congestion can be
   inferred from increasing path-specifc packet loss and delay.  So the
   idea is to obtain feedback about path-specific packet loss and delay
   and leverage this information for improved load balancing.  To that
   end, the HARF functions continuously monitor the quality of all paths
   perceived by transmitted traffic so that the HALB can leverage path-
   specific information about packet loss and delay for load balancing
   decisions.  In the following we briefly explain how a pair of
   corresponding HALB and HARF functions on a one-directional path can
   obtain information about packet loss and delay.

   To estimate packet loss, the HALB function equips the overall packet
   stream with sequence numbers before load-balancing them over multiple
   interfaces.  These sequence numbers are also used for packet
   reordering if needed.

   The HALB function counts the number of packets sent per path up to
   some checkpoint sequence number.  The corresponding HARF function
   counts the number of packets received per path up to the same
   checkpoint sequence numbers and reports them to the corresponding
   HALB.  The difference between the number of sent and received packets



Menth, et al.            Expires January 7, 2016               [Page 10]


Internet-Draft                   LISP-HA                       July 2015


   between checkpoint sequence numbers gives an estimate about packet
   loss per path.

   Measuring packet delay between HALB and HARF is rather difficult as
   their clocks may not be synchronized and have a drift.  Therefore,
   only relative delays are measured over time.

   The HALB equips packets with timestamps before sending them to an
   interface and the HARF computes the difference to its current time
   upon receipt, yielding a biased packet delay due to potentially
   missing clock synchronization.  Assuming that all biased packet
   delays have the same bias, the evolution of the biased packet delay
   reflects the evolution of the real packet delay.  The HARF reports to
   the HALB the path-specific numbers of recently received packets and
   delay information.  Delay metrics may be minimum, maximum, average
   delay as well as a standard deviation.  However, the metrics are not
   clear, yet, because the load-balancing algorithm is still under
   research.  The same holds for the frequency of checkpoint sequence
   numbers and the frequency of feedback reports from the HARF to the
   HALB.

3.6.  Extensions for Packet-Based Load Balancing

   Per-flow load balancing forwards packets of a flow over the same
   path.  Therefore, packets will arrive in order unless they are
   reordered for other reasons on the path.  Thus, per-flow load
   balancing avoids additional packet reordering by LISP-HA.  However,
   it is more difficult to efficiently use the bandwidth of existing
   paths with per-flow load-balancing than with per-packet load
   balancing.  Moreover, as flow-based load balancing forwards packets
   of a single flow only over a single path, very large flows cannot
   profit from several paths.

   Packet-based load balancing may cause reordered packets in particular
   if paths have different delay.  As packet reordering has negative
   impact on some transport protocols and applications, it should either
   be avoided or packets should be reordered.  We propose that the HARF
   function performs packet reordering if needed so that the HALB
   function can load-balance per packet if desired.  However, packet
   reordering causes some additional delay leading to a tradeoff between
   reordered packets and increased delay.

   A HALB may be configured to load-balance certain flows per flow and
   other flows per packet, depending on the needs of specific transport
   protocols or applications.  In addition, the HARC may reorder packets
   from per-packet load balanced flows into order.  To that end, such
   packets need to be marked with a "Reorder" flag so that other packets
   do not suffer from reordering delay.



Menth, et al.            Expires January 7, 2016               [Page 11]


Internet-Draft                   LISP-HA                       July 2015


   The HARF leverages the sequence numbers of all packets for packet
   reordering.  It holds back packets which require reordering before
   forwarding so long that it is unlikely that packets from the same
   flow with lower sequence numbers will be received.  Details are
   subject to future work.

3.7.  Deployment Considerations

   HARTRs are infrastructure that need to be operated and cause costs in
   the first place.  However, the operation of a HARTR allows to perform
   traffic engineering by appropriate load balancing.  E.g., an LTE
   network operator prefers to offload its resources and can achieve
   that with the HARTR if other paths have sufficient capacity.  Thus,
   ISPs may have interest to set up HARTRs to have strategic control
   over traffic forwarding in the network.

   Apart from that, offering a HARTR as a service by a third party for a
   small fee may also be an option.  Thereby, customers could book cheap
   contracts for LTE and residential access and combine these
   technologies via the third party HARTR.

4.  Packet Formats

   A modified LISP dataplane header is presented to convey information
   from HALB to HARF and a new LISP control message is proposed to
   report feedback information from HARF to HALB.

4.1.  Dataplane Header

   LISP-HA reuses some fields of the dataplane header of encapsulated
   LISP data packets to convey information for dynamic load balancing
   from the HALB to the HARF.  The original dataplane header is
   illustrated in Figure 6.  The usage of the fields is defined in
   [RFC6830].


    x x x x 1 0 0 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Instance ID                   |     LSBs      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 6: Original dataplane header.

   The Nonce was proposed for security purpose, but has no application
   in the LISP-HA context.  An Instance ID is used to uniquely identify



Menth, et al.            Expires January 7, 2016               [Page 12]


Internet-Draft                   LISP-HA                       July 2015


   the source in a virtual address space, which is neither applicable in
   the LISP-HA context.  Three header flags are unused.  Therefore we
   propose to reuse the Nonce and the Instance ID fields of the original
   dataplane header definition to convey sequence numbers and timestamps
   from the HALB to the HARF together with an indication whether a
   packet needs to be forwarded in-order.  The modified LISP header is
   illustrated in Figure 7.  The modified header fields are explained in
   the following.


    0 x 0 x 0 x 0 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|flg|              Sequence number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Timestamp                    |     LSBs      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 7: Modified LISP Dataplane Header.

   R: Reorder flag to indicate whether a packet needs to be forwarded
      in-order.  It is 1 if the packet has to be reordered, and it is 0
      if the packet can be forwarded immediately.

   Sequence number:  Sequence number for packets sent from HALB to HARF,
      used for packet loss detection and reordering.

   Timestamp:  The lower 24 bits of the timestamp of the sender.

   All other fields:  All fields not explicitly described here have the
      same meaning as in [RFC6830].

   In upstream direction the HAxTR sends packet with the modified header
   to the HARTR.  The HARTR modifies the modified header in upstream
   direction to be compliant to [RFC6830].  In downstream direction the
   HARTR receives LISP packets with a header format com,pliant to
   [RFC6830] and modifies the header as proposed in this section.  The
   HAxTR removes this header.  NTRs may be located between HAxTR and
   HARTR, but they do not need to process the modified header fields.
   Therefore, only HAxTR and HARTR need to implement, understand, and
   process the modified header format.

4.2.  Control Message

   We propose the unused Type number 5 for LISP-HA Feedback Messages to
   report feedback about packet loss and delay from the HARF to the
   HALB.  These messages contain information about the number of
   received packets between sequence number checkpoint and information



Menth, et al.            Expires January 7, 2016               [Page 13]


Internet-Draft                   LISP-HA                       July 2015


   about packet delay as described in Section 3.5.  The exact values and
   format is are subject to further research.

5.  Use Cases

   In the following, we describe two typical use cases of LISP-HA.  The
   first use case explains how LISP-HA can be used for residential users
   to benefit from HA to connect to the Internet.  In the second use
   case, we present how a mobile node, e.g. a smartphone, can use LISP-
   HA.

5.1.  Connecting Residential Users to the General Internet

   For customers with cable internet high bandwidth can not be
   guaranteed as cable internet is based on a shared medium.  Especially
   in the evening hours when many customers need bandwidth at the same
   time, the rate can drop significantly.  For those customers it would
   be a great benefit if they could bundle their, sometimes slow, cable
   access with LTE to improve their bandwidth.  Figure 8 illustrates a
   potential solution using LISP-HA.

   The HAxTR may be implemented in the home router, it has a public EID
   which it registers at the MS.  The customer typically uses a private
   address space in his home LAN which is connected through the NAT of
   the home router.  The HAxTR is connected to the Internet through a
   DSL and an LTE interface and there is a provider NAT on the LTE path.
   An NTR is used to make the HAxTR reachable vial LTE from the
   Internet.  As LISP nodes cannot communicate directly with the
   Internet, the HAxTR is configured with an appropriate PxTR, to send
   traffic to non-LISP IP addresses.  To minimize path stretch and
   delay, both NTR and PxTR may be integrated in the same box as the
   HARTR.



















Menth, et al.            Expires January 7, 2016               [Page 14]


Internet-Draft                   LISP-HA                       July 2015


        +------+---------------------------------+
        | EID  |              Entry              |
        +------+---------------------------------+
        | EID0 | ELP: RLOC-HARTR -> RLOC-HAxTR-0 |
        | EID1 | ELP: RLOC-HARTR -> RLOC-NTR     |
        +------+---------------------------------+


                     +----------+
                     |  cable   |
                 +---| internet |-------+
                 |   +----------+       |
                 |                      |
                 |                      |
 ---      +-------------+               |                       --------
    \     | Home Router |               |                      /
     \    +-------------+         +-----------+   +------+    /
  LAN |---|    (NAT)    |         |   HARTR   |---| PxTR |---| Internet
     /    +------------ +         | HALB/HARF |   +------+    \
    /     |    HAxTR    |         +-----------+                \
 ---      |  HALB/HARF  |               |                       --------
          +-------------+               |
                 |                      |
                 |                      |
                 |   +-----------+   +-----+
                 +---| LTE | NAT |---| NTR |
                     +-----------+   +-----+


      Figure 8: LISP-HA used for residential access to the Internet.

   This solution may be attractive to users who are not even aware of
   LISP.  Their traffic is just load-balanced over DSL and LTE between
   the home router and the HARTR and decapsulated by the PxTR.  In case
   of a public address space in the customer's LAN the HAxTR can
   register the entire subnet of the LAN as EID prefix at the MS.  The
   PxTR has to announce the EIDs registered by the HAxTR to the Internet
   so that traffic for the HAxTR is sent to PxTR.

5.2.  Smartphones with Mobile Node.

   Today's smartphones include multiple radio interfaces that allow to
   connect to multiple access technologies like LTE and Wifi at he same
   time.  The default policy that is implemented in smartphones is to
   offload traffic from the cellular network to Wifi access.  However,
   it would be desireable to use both technologies to increase the
   available bandwidth for normal internet traffic like downloads and to
   select the Wifi connection for realtime applications like VoIP.  In



Menth, et al.            Expires January 7, 2016               [Page 15]


Internet-Draft                   LISP-HA                       July 2015


   Figure 9, we present a potential setup how a MN can use LISP-HA to
   realize the scenario.


             Mapping System
         +------+--------------------------------+
         | EID  |              Entry             |
         +------+--------------------------------+
         | EID0 | ELP: RLOC-HARTR -> RLOC-NTR-0  |
         | EID0 | ELP: RLOC-HARTR -> RLOC-NTR-1  |
         | EID0 | LCAF: VoIP use RLOC-NTR-0      |
         +------+--------------------------------+


           +------+-----+   +-----+   +-----+
        +--| Wifi | NAT |---| DSL |---| NTR |
        |  +------+-----+   +-----+   +-----+
        |                                |
  +-----------+                          |                      --------
  |    MN     |                          |                     /
  +-----------+                   +-----------+   +------+    /
  |   HAxTR   |                   |   HARTR   |---| PxTR |---| Internet
  | HALB/HARF |                   | HALB/HARF |   +------+    \
  +-----------+                   +-----------+                \
        |                                |                      --------
        |                                |
        |  +-----------+   +-----+       |
        +--| LTE | NAT |---| NTR |-------+
           +-----------+   +-----+


         Figure 9: LISP-HA used for Smartphones with Mobile Node.

   To realize HA on a MN, the MN has to implement its own HAxTR
   consisting of HALB and HARF.  Typically, the MN has access to the
   Internet most of the time using cellular networks like LTE or HSDPA.
   So the MN registers its EID through the cellular network at the MS.
   A provider NAT in the LTE network is handled like described in
   Section 3.4.  Wifi access becomes available if the MN is in reach of
   a public Wifi hotspot, in the home LAN of the user or other known
   Wifi networks.  Once Wifi access is available, the MN registers its
   EID over Wifi, too.  Additionally, the MN can register an LCAF for
   VoIP traffic to use Wifi.  If Wifi is available no more because the
   MN left the Wifi cell, the MN should de-register the Wifi mappings at
   the MS.






Menth, et al.            Expires January 7, 2016               [Page 16]


Internet-Draft                   LISP-HA                       July 2015


6.  Security Considerations

   HA by itself does not raise any security concerns.  However, LISP-HA
   is based on LISP so that the same security considerations apply as
   described in [RFC6830].  There is no authentication of endhosts at
   the xTR and no authentication between xTRs which allows every node to
   send any amount of traffic to any xTR which makes it vulnerable to
   DOS attacks.  This also counts for the HARTR and the HAxTR.  LISP
   traffic is not encrypted, so if it is required to encrypt the
   communication, this has to be realized by the endhosts.

7.  Acknowledgements

   The authors would like to thank Gerd Pflueger and Wilhelm
   Boeddinghaus for their helpful input and discussions.

8.  References

8.1.  Normative References

   [RFC1990]  Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
              Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
              August 1996.

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

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, January 2013.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830, January
              2013.

8.2.  Informative References

   [I-D.ermagan-lisp-nat-traversal]
              Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
              F., and C. White, "NAT traversal for LISP", draft-ermagan-
              lisp-nat-traversal-07 (work in progress), February 2015.

   [I-D.farinacci-lisp-lcaf]
              Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", draft-farinacci-lisp-lcaf-10 (work
              in progress), July 2012.





Menth, et al.            Expires January 7, 2016               [Page 17]


Internet-Draft                   LISP-HA                       July 2015


   [I-D.farinacci-lisp-te]
              Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic
              Engineering Use-Cases", draft-farinacci-lisp-te-08 (work
              in progress), March 2015.

   [I-D.hampel-mptcp-proxies-anchors]
              Hampel, G. and T. Klein, "MPTCP Proxies and Anchors",
              draft-hampel-mptcp-proxies-anchors-00 (work in progress),
              February 2012.

   [I-D.lhwxz-hybrid-access-network-architecture]
              Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M.
              Zhang, "Hybrid Access Network Architecture", draft-lhwxz-
              hybrid-access-network-architecture-02 (work in progress),
              January 2015.

   [I-D.meyer-lisp-mn]
              Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
              Mobile Node", draft-meyer-lisp-mn-12 (work in progress),
              January 2015.

   [Menth06p]
              Milbrandt, J., Humm, K., and M. Menth, "Adaptive Bandwidth
              Allocation: Impact of Routing and Load Balancing on Tunnel
              Capacity Requirements", in Proceedings of 2nd Conference
              on Next Generation Internet Design and Engineering,
              Valencia, Spain , April 2006.

Authors' Addresses

   Michael Menth
   University of Tuebingen
   room B302, Institute of Computer Science
   Sand 13
   Tuebingen  72076
   Germany

   Phone: +49 7071 29-70505
   Email: menth@uni-tuebingen.de












Menth, et al.            Expires January 7, 2016               [Page 18]


Internet-Draft                   LISP-HA                       July 2015


   Andreas Stockmayer
   University of Tuebingen
   room B305, Institute of Computer Science
   Sand 13
   Tuebingen  72076
   Germany

   Phone: +49 7071 29-70511
   Email: andreas.stockmayer@uni-tuebingen.de


   Mark Schmidt
   University of Tuebingen
   room B305, Institute of Computer Science
   Sand 13
   Tuebingen  72076
   Germany

   Phone: +49 7071 29-70510
   Email: mark-thomas.schmidt@uni-tuebingen.de































Menth, et al.            Expires January 7, 2016               [Page 19]


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