Internet DRAFT - draft-menth-lisp-ha
draft-menth-lisp-ha
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]
