idnits 2.17.1 draft-menth-lisp-ha-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3215 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 720, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-07 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-08 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-12 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Locator/ID Separation Protocol M. Menth 3 Internet-Draft A. Stockmayer 4 Intended status: Experimental M. Schmidt 5 Expires: January 7, 2016 University of Tuebingen 6 July 6, 2015 8 LISP Hybrid Access 9 draft-menth-lisp-ha-00 11 Abstract 13 Hybrid access (HA) allows simultaneous usage of multiple access 14 links. Advantages are increased bandwidth and improved resilience. 15 This document presents LISP Hybrid Access (LISP-HA), a mechanism to 16 provide HA based on LISP technology. The document discusses 17 potential changes needed to perform dynamic load-balancing and per 18 packet load-balancing, which both increase the efficiency of HA. To 19 that end, modified usage of some fields in the LISP header is 20 proposed. Discussed use cases include the bundling of multiple 21 access technologies for mobile devices and residential access 22 routers. Additionally, we provide some considerations how LISP-HA 23 can be deployed by providers. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 7, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. LISP-HA-Architecture . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Message Sequence Diagram for Basic Operation. . . . . . . 6 64 3.3. Policy-Based Path Selection . . . . . . . . . . . . . . . 8 65 3.4. Operation of an HAxTR behind a NAT . . . . . . . . . . . 8 66 3.5. Extensions for Dynamic Load Balancing . . . . . . . . . . 10 67 3.6. Extensions for Packet-Based Load Balancing . . . . . . . 11 68 3.7. Deployment Considerations . . . . . . . . . . . . . . . . 12 69 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.1. Dataplane Header . . . . . . . . . . . . . . . . . . . . 12 71 4.2. Control Message . . . . . . . . . . . . . . . . . . . . . 13 72 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.1. Connecting Residential Users to the General Internet . . 14 74 5.2. Smartphones with Mobile Node. . . . . . . . . . . . . . . 15 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 79 8.2. Informative References . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 Hybrid access (HA) enables a device to simultaneously use multiple 85 access links both in upstream and downstream direction. A challenge 86 of HA is to make load balancing of the traffic onto multiple paths 87 transparent to endpoints. HA may be supported on various layers. 88 Multilink PPP (ML-PPP) [RFC1990] offers support for fragmented 89 protocol data units (PDU) on the same local network. Therefore, it 90 cannot combine network layer paths so that it is unable to bundle 91 paths provided by different Internet service providers. A network 92 architecture for HA is presented in 93 [I-D.lhwxz-hybrid-access-network-architecture]. It focuses on 94 bundling DSL and LTE for residential access by means of dedicated 95 customer premises equipment (CPE) which does not support mobile 96 devices in general. Multipath TCP (MP-TCP) leverages multiple paths 97 on the transport layer [RFC6824]. It requires both source and 98 destination endpoint to support MP-TCP. MP-TCP proxies are currently 99 discussed for inter-operation with non-MP-TCP nodes 100 [I-D.hampel-mptcp-proxies-anchors]. HA can be also supported by MP- 101 TCP, but that approach is limited to TCP traffic. Furthermore, 102 supporting policies such as cheapest link first seems challenging 103 with this approach. 105 LISP by itself has basic capabilities to support HA with static load 106 balancing that is not agnostic to current link loads and 107 characteristics. That means, a multihomed LISP xTR may perform 108 inbound traffic engineering. This is achieved by setting appropriate 109 weights for multiple RLOCs in register messages so that it receives 110 traffic over more than a single interface. Outbound traffic may be 111 sent over multiple interfaces according to local policies. 113 This document proposes LISP-HA as a novel solution for HA with 114 improved load balancing capabilities for better resource efficiency. 116 2. Terminology 118 Hybrid Access (HA): Using two or more access lines to improve 119 bandwidth and resilience; both technologies are used at the same 120 time. 122 Mobile Node (MN): A LISP node that includes its own xTR and can 123 connect to more than a single network at a time 124 [I-D.meyer-lisp-mn]. 126 Mapping System (MS): The LISP Mapping System as defined in RFC 6830 127 [RFC6830]. 129 LISP Tunnel Router (xTR): A combination of ITR and ETR [RFC6830]. 131 LISP Proxy Tunnel Router (PxTR): iUsed to communicate with the 132 legacy Internet [RFC6830]. 134 LISP Reencapsulating Tunnel Router (RTR): LISP router to forward 135 LISP-TE packets [I-D.farinacci-lisp-te]. 137 LISP NAT Traversal Router (NTR): A LISP router that allows to 138 communicate with LISP nodes behind a NAT 139 [I-D.ermagan-lisp-nat-traversal]. 141 LISP Canonical Address Format (LCAF): Extension to the AFI type 142 system to associate the AFI, e.g. with policies 143 [I-D.farinacci-lisp-lcaf]. 145 Explicit Locator Path (ELP): A mapping storing a sequence of RLOCs, 146 indicating RTRs that receive and forward LISP packets to the next 147 RLOC in that list; defined by LISP-TE [I-D.farinacci-lisp-te]. 149 Hybrid Acces xTR (HAxTR): An xTR with multiple RLOCs that supports 150 LISP-HA. 152 Hybrid Access RTR (HARTR): An RTR that supports LISP-HA. 154 Hybrid Access Load Balancing (HALB): Function in HAxTR and HARTR 155 that distributes traffic over multiple paths. 157 Hybrid Access Reorder and Feedback (HARF): Function in HAxTR and 158 HRTR that reorders traffic sent by a corresponding HALB over 159 multiple paths and provides feedback about the link condition to 160 the HALBs. 162 3. LISP-HA-Architecture 164 This section describes the basic operation of LISP-HA as well as 165 policy-based path selection, its operation with LISP nodes behind 166 NATs, extensions for dynamic load balancing, and extensions for 167 packet-based load balancing. Finally, we consider how it could be 168 useful for providers to operate their own HARTR. 170 3.1. Basic Operation 172 LISP-HA allows to load-balance traffic over multiple paths between a 173 HAxTR and HARTR. This is transparent to nodes not on the path 174 between HAxTR and HARTR. Load-balancing works in both directions, 175 therefore, both the HAxTR and the HARTR implement a HA Load Balancing 176 function (HALB) and a HA Recombination function (HARF). 178 We present how LISP-HA makes EIDs globally reachable over multiple 179 paths between HARTR and HAxTR. To that end, we consider the setting 180 illustrated in Figure 1. 182 Mapping System 183 +----------------------------------------+ 184 | EID | Entry | 185 -------+---------------------------------+ 186 | EID0 | ELP: RLOC-HARTR -> RLOC-HAxTR-0 | 187 | EID0 | ELP: RLOC-HARTR -> RLOC-HAxTR-1 | 188 -----------------------------------------+ 190 +------+ 191 +-----| Wifi |----+ 192 | +------+ | 193 | | 194 | | 195 +------+ +-----------+ +-----------+ +------+ 196 | EID0 |---| HAxTR | | HAR |--- ... ---| EID1 | 197 +------+ | HALB/HARF | | HALB/HARF | +------+ 198 +-----------+ +-----------+ 199 | | 200 | | 201 | +-----+ | 202 +-----| LTE |-----+ 203 +-----+ 205 Figure 1: LISP-HA load-balances traffic between HAxTR and HARTR over 206 multiple network layer paths. 208 A HAxTR is configured with the address of a HARTR and registers its 209 EID prefixes at the MS. To that end, it uses explicit locator paths 210 (ELPs), containing the RLOC of the HARTR in the penultimate positoin 211 of the ELP and one of its own RLOCs in the last position of the ELP. 212 The HAxTR must send one register message for each of its RLOCs and 213 over the interface that corresponds to that RLOC so that the MS can 214 detect whether the HAxTR is behind a NAT. 216 The HALB functions of the HAxTR and the HARTR distribute the traffic 217 over multiple network layer paths between them. Flow-based or 218 packet-based load-balancing may be supported. 220 Figure 2 shows a communication scenario between two LISP nodes. The 221 HAxTR is connected to the Internet / LISP net over multiple access 222 technologies and LISP-HA is applied between HAxTR and HARTR. The 223 endpoints EID0 and EID1 exchange messages over the HAxTR, the HARTR, 224 and the xTR. The figure shows the destination EIDs and RLOCs of 225 these messages. The HAxTR/xTR add RLOCs to the messages through 226 encapsulation, the HARTR exchanges the RLOCs, and the xTR/HAxTR 227 remove RLOCs from the messages through decapsulation. The HAxTR and 228 xTR add RLOCs to the messages through encapsulation and the HARTR 229 exchanges the RLOCs. In upstream direction, the HAxTR adds the RLOC 230 of the HARTR and selects the path by choosing the appropriate 231 interface. The HARTR exchanges its own RLOC by the RLOC of the xTR. 232 In downstream direction, the xTR adds the RLOC of the HARTR as 233 specified in the ELP. The HARTR exchanges this RLOC with the 234 appropriate RLOC of the HAxTR. Thereby the desired path is selected. 236 Upstream example: 238 EID0 ---> HAxTR ---> HARTR ---> xTR ---> EID1 240 EID1 EID1 EID1 EID1 241 RLOC-HARTR RLOC-xTR 243 Downstream example: 245 EID0 <--- HAxTR <--- HARTR <--- xTR <--- EID1 247 EID0 EID0 EID0 EID0 248 RLOC-HAxTR-i RLOC-HARTR 250 Figure 2: Destination EIDs and RLOCs of a LISP packet between two 251 communicating endpoints. 253 3.2. Message Sequence Diagram for Basic Operation. 255 Figure 3 and Figure 4 illustrate the basic operation of LISP-HA by a 256 diagram showing all control and data messages exchanged to send data 257 in upstream and downstream direction. In both cases we assume that 258 the HAxTR and the xTR have registered their EIDsi EID0 and EID1 at 259 the MS, but the required mappings are not available in caches. 261 When the endhost with EID0 starts sending data to EID1, it forwards 262 them to its HAxTR. The HAxTR requests the mapping for RLOC of EID1 263 from the MS to verify that EID1 is globally reachble before sending 264 it to the HAxTR. The HAxTR encapsulates the packet with the 265 configured address of the HARTR as destination RLOC, using the access 266 line selected by its HALB. Upon receipt of the packet, the HARTR 267 also requests the mapping for EID1, exchnages the destination RLOC in 268 the packet with the RLOC of the xTR provided in the map-reply and 269 sends the packet to the xTR. Upon receipt, the xTR decapsulates the 270 LISP packet and forwards it to the endhost with EID1. 272 EID0 HAxTR MS HARTR xTR EID1 273 data 274 -----------> 275 request for EID1 276 ----------> 277 reply containing RLOC-xTR 278 <---------- 279 LISP data with dst:EID1 / RLOC-HARTR 280 ---------------------> 281 request for EID1 282 <---------- 283 reply containing RLOC-xTR 284 ----------> 285 LISP data dst:EID1/RLOC-xTR 286 -----------> 287 data 288 ----------> 290 Figure 3: Message sequence diagram for upstream communication. 292 When endhost with EID1 starts sending data to EID0, it forwards them 293 to its xTR. The HAxTR requests the mapping for EID0 from the MS, 294 receives the ELP for EID0, encapsulates the packet with RLOC-HARTR, 295 and sends it to the HARTR. Upon receipt of the packet, the HARTR 296 requests the mapping for EID0 from the MS. The HALB function of the 297 HARTR selects the path to the HAxTR, the HARTR exchanges the 298 destination RLOC in the LISP packet with RLOC-HAxTR and sends the 299 packet over the determined path. Upon receipt, the HAxTR 300 decapsulates the LISP packet and forwards it to the endhost with 301 EID0. 303 EID0 HAxTR MS HARTR xTR EID1 304 data 305 <---------- 306 request for EID0 307 <----------------- 308 reply containing ELP:RLOC-HAxTR-i -> HARTR 309 -----------------> 310 LISP data with dst:EID0/RLOC-HARTR 311 <----------- 312 request for EID0 313 <---------- 314 reply containing ELP:RLOC-HAxTR-i -> HARTR 315 ----------> 316 LISP data with dst:EID0/RLOC-HAxTR-i 317 <--------------------- 318 data 319 <------------ 321 Figure 4: Message sequence diagram for downstream communication. 323 3.3. Policy-Based Path Selection 325 For specific kinds of traffic, e.g., for realtime communication, the 326 usage of specific paths may be desired. LISP-HA supports such 327 requirements through LISP LCAF extensions both on upstream and 328 downstream. To that end, the HAxTR is configured with LCAF 329 extensions, e.g., indicating that traffic for realtime communication 330 must be forwarded over a specific path. The HAxTR uses this LCAF as 331 local policy to encapsulate the traffic. In addition, Tthe HAxTR 332 registers the same LCAF at the MS. As a consequence, xTRs 333 encapsulate traffic towards the HAxTR using the specific RLOC in the 334 LCAF. 336 3.4. Operation of an HAxTR behind a NAT 338 A HAxTR may be located behind a NAT. We consider this case as this 339 scenario is common for HAxTRs connected via LTE. 341 Mapping System 342 +------+---------------------------------+ 343 | EID | Entry | 344 +------+---------------------------------+ 345 | EID0 | ELP: RLOC-HARTR -> RLOC-HAxTR-0 | 346 | EID0 | ELP: RLOC-HARTR -> RLOC-NTR | 347 +------+---------------------------------+ 349 +------+ 350 +-----| Wifi |-----------+ 351 | +------+ | 352 | | 353 | | 354 +------+ +-----------+ +-----------+ +------+ 355 | EID0 |---| HAxTR | | HARTR |--- ... ---| EID1 | 356 +------+ | HALB/HARF | | HALB/HARF | +------+ 357 +-----------+ +-----------+ 358 | | 359 | | 360 | +-----------+ +-----+ 361 +-----| LTE | NAT |---| NTR | 362 +-----------+ +-----+ 364 Figure 5: LISP-HA load-balances traffic between HAxTR and HARTRT 365 while part of the traffic traverses a NAT. 367 We show how LISP-HA leverages existing LISP NAT traversal 368 [I-D.ermagan-lisp-nat-traversal] so that it does not require 369 additional mechanisms to cope with NATs. 371 Figure 5 shows a HAxTR that is connected to the Internet / LISP net 372 via LTE and through a NAT. The HAxTR registers its RLOC at the MS, 373 the MS detects that the RLOC in the LISP register message differs 374 from the RLOC in the outer header encapsulating it. As a 375 consequence, the MS does not register the mapping and informs the 376 HAxTR proposing a list of potential NAT Traversal Routers (NTRs). 377 Then, the HAxTR selects one of the NTRs and registers again at the MS 378 via this NTR. The NTR exchanges the RLOC in the mapping by its own 379 RLOC (RLOC-NTR). As a result, traffic for the HAxTR is directed to 380 the NTR which forwards it to the HAxTR. This mechanism works for 381 LISP-HA only if the HAxTR registers its ELPs over the corresponding 382 interfaces; otherwise the MS cannot securely detect that the HAxTR is 383 behind a NAT. 385 The usage of general NTRs leads to triangle routing and adds 386 significant delay which may be prohibitive. However, an NTR may be 387 combined with the HARTR and configured with the HAxTR so that 388 triangle routing and added path delay are avoided. 390 To cope with carrier grade NATs, messages need to be exchanged 391 frequently enough over the NTR to avoid that NAT table entries are 392 removed. This, however, is to be fixed for the NTR draft 393 [I-D.ermagan-lisp-nat-traversal]. Moreover, HAxTR and HARTR exchange 394 feedback messages for dynamic load balancing frequently enough so 395 that NAT table entries will not be removed. 397 3.5. Extensions for Dynamic Load Balancing 399 One goal of HA is to increase a HAxTR's overall access bandwidth by 400 combining the bandwidth of all available paths. However, static load 401 balancing leads to statistical variations [Menth06p] so that some 402 paths are already overloaded while others are underutilized. Dynamic 403 load balancing takes the current load on the links into account and 404 can achieve better resource utilization without overloading paths. 406 We propose dynamic load balancing for LISP-HA with the purpose to 407 increase resource efficiency, thereby providing higher bandwidth to 408 the user. A challenge is that path properties like available 409 bandwidth and delay are possibly unknown and vary over time, 410 especially if the path is shared and includes wireless links. Also 411 flow rates vary over time and the rate of elastic flows depends on 412 path characteristics. Nevertheless, incipient congestion can be 413 inferred from increasing path-specifc packet loss and delay. So the 414 idea is to obtain feedback about path-specific packet loss and delay 415 and leverage this information for improved load balancing. To that 416 end, the HARF functions continuously monitor the quality of all paths 417 perceived by transmitted traffic so that the HALB can leverage path- 418 specific information about packet loss and delay for load balancing 419 decisions. In the following we briefly explain how a pair of 420 corresponding HALB and HARF functions on a one-directional path can 421 obtain information about packet loss and delay. 423 To estimate packet loss, the HALB function equips the overall packet 424 stream with sequence numbers before load-balancing them over multiple 425 interfaces. These sequence numbers are also used for packet 426 reordering if needed. 428 The HALB function counts the number of packets sent per path up to 429 some checkpoint sequence number. The corresponding HARF function 430 counts the number of packets received per path up to the same 431 checkpoint sequence numbers and reports them to the corresponding 432 HALB. The difference between the number of sent and received packets 433 between checkpoint sequence numbers gives an estimate about packet 434 loss per path. 436 Measuring packet delay between HALB and HARF is rather difficult as 437 their clocks may not be synchronized and have a drift. Therefore, 438 only relative delays are measured over time. 440 The HALB equips packets with timestamps before sending them to an 441 interface and the HARF computes the difference to its current time 442 upon receipt, yielding a biased packet delay due to potentially 443 missing clock synchronization. Assuming that all biased packet 444 delays have the same bias, the evolution of the biased packet delay 445 reflects the evolution of the real packet delay. The HARF reports to 446 the HALB the path-specific numbers of recently received packets and 447 delay information. Delay metrics may be minimum, maximum, average 448 delay as well as a standard deviation. However, the metrics are not 449 clear, yet, because the load-balancing algorithm is still under 450 research. The same holds for the frequency of checkpoint sequence 451 numbers and the frequency of feedback reports from the HARF to the 452 HALB. 454 3.6. Extensions for Packet-Based Load Balancing 456 Per-flow load balancing forwards packets of a flow over the same 457 path. Therefore, packets will arrive in order unless they are 458 reordered for other reasons on the path. Thus, per-flow load 459 balancing avoids additional packet reordering by LISP-HA. However, 460 it is more difficult to efficiently use the bandwidth of existing 461 paths with per-flow load-balancing than with per-packet load 462 balancing. Moreover, as flow-based load balancing forwards packets 463 of a single flow only over a single path, very large flows cannot 464 profit from several paths. 466 Packet-based load balancing may cause reordered packets in particular 467 if paths have different delay. As packet reordering has negative 468 impact on some transport protocols and applications, it should either 469 be avoided or packets should be reordered. We propose that the HARF 470 function performs packet reordering if needed so that the HALB 471 function can load-balance per packet if desired. However, packet 472 reordering causes some additional delay leading to a tradeoff between 473 reordered packets and increased delay. 475 A HALB may be configured to load-balance certain flows per flow and 476 other flows per packet, depending on the needs of specific transport 477 protocols or applications. In addition, the HARC may reorder packets 478 from per-packet load balanced flows into order. To that end, such 479 packets need to be marked with a "Reorder" flag so that other packets 480 do not suffer from reordering delay. 482 The HARF leverages the sequence numbers of all packets for packet 483 reordering. It holds back packets which require reordering before 484 forwarding so long that it is unlikely that packets from the same 485 flow with lower sequence numbers will be received. Details are 486 subject to future work. 488 3.7. Deployment Considerations 490 HARTRs are infrastructure that need to be operated and cause costs in 491 the first place. However, the operation of a HARTR allows to perform 492 traffic engineering by appropriate load balancing. E.g., an LTE 493 network operator prefers to offload its resources and can achieve 494 that with the HARTR if other paths have sufficient capacity. Thus, 495 ISPs may have interest to set up HARTRs to have strategic control 496 over traffic forwarding in the network. 498 Apart from that, offering a HARTR as a service by a third party for a 499 small fee may also be an option. Thereby, customers could book cheap 500 contracts for LTE and residential access and combine these 501 technologies via the third party HARTR. 503 4. Packet Formats 505 A modified LISP dataplane header is presented to convey information 506 from HALB to HARF and a new LISP control message is proposed to 507 report feedback information from HARF to HALB. 509 4.1. Dataplane Header 511 LISP-HA reuses some fields of the dataplane header of encapsulated 512 LISP data packets to convey information for dynamic load balancing 513 from the HALB to the HARF. The original dataplane header is 514 illustrated in Figure 6. The usage of the fields is defined in 515 [RFC6830]. 517 x x x x 1 0 0 0 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 |N|L|E|V|I|flags| Nonce/Map-Version | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Instance ID | LSBs | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 6: Original dataplane header. 526 The Nonce was proposed for security purpose, but has no application 527 in the LISP-HA context. An Instance ID is used to uniquely identify 528 the source in a virtual address space, which is neither applicable in 529 the LISP-HA context. Three header flags are unused. Therefore we 530 propose to reuse the Nonce and the Instance ID fields of the original 531 dataplane header definition to convey sequence numbers and timestamps 532 from the HALB to the HARF together with an indication whether a 533 packet needs to be forwarded in-order. The modified LISP header is 534 illustrated in Figure 7. The modified header fields are explained in 535 the following. 537 0 x 0 x 0 x 0 0 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 |N|L|E|V|I|R|flg| Sequence number | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Timestamp | LSBs | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 7: Modified LISP Dataplane Header. 546 R: Reorder flag to indicate whether a packet needs to be forwarded 547 in-order. It is 1 if the packet has to be reordered, and it is 0 548 if the packet can be forwarded immediately. 550 Sequence number: Sequence number for packets sent from HALB to HARF, 551 used for packet loss detection and reordering. 553 Timestamp: The lower 24 bits of the timestamp of the sender. 555 All other fields: All fields not explicitly described here have the 556 same meaning as in [RFC6830]. 558 In upstream direction the HAxTR sends packet with the modified header 559 to the HARTR. The HARTR modifies the modified header in upstream 560 direction to be compliant to [RFC6830]. In downstream direction the 561 HARTR receives LISP packets with a header format com,pliant to 562 [RFC6830] and modifies the header as proposed in this section. The 563 HAxTR removes this header. NTRs may be located between HAxTR and 564 HARTR, but they do not need to process the modified header fields. 565 Therefore, only HAxTR and HARTR need to implement, understand, and 566 process the modified header format. 568 4.2. Control Message 570 We propose the unused Type number 5 for LISP-HA Feedback Messages to 571 report feedback about packet loss and delay from the HARF to the 572 HALB. These messages contain information about the number of 573 received packets between sequence number checkpoint and information 574 about packet delay as described in Section 3.5. The exact values and 575 format is are subject to further research. 577 5. Use Cases 579 In the following, we describe two typical use cases of LISP-HA. The 580 first use case explains how LISP-HA can be used for residential users 581 to benefit from HA to connect to the Internet. In the second use 582 case, we present how a mobile node, e.g. a smartphone, can use LISP- 583 HA. 585 5.1. Connecting Residential Users to the General Internet 587 For customers with cable internet high bandwidth can not be 588 guaranteed as cable internet is based on a shared medium. Especially 589 in the evening hours when many customers need bandwidth at the same 590 time, the rate can drop significantly. For those customers it would 591 be a great benefit if they could bundle their, sometimes slow, cable 592 access with LTE to improve their bandwidth. Figure 8 illustrates a 593 potential solution using LISP-HA. 595 The HAxTR may be implemented in the home router, it has a public EID 596 which it registers at the MS. The customer typically uses a private 597 address space in his home LAN which is connected through the NAT of 598 the home router. The HAxTR is connected to the Internet through a 599 DSL and an LTE interface and there is a provider NAT on the LTE path. 600 An NTR is used to make the HAxTR reachable vial LTE from the 601 Internet. As LISP nodes cannot communicate directly with the 602 Internet, the HAxTR is configured with an appropriate PxTR, to send 603 traffic to non-LISP IP addresses. To minimize path stretch and 604 delay, both NTR and PxTR may be integrated in the same box as the 605 HARTR. 607 +------+---------------------------------+ 608 | EID | Entry | 609 +------+---------------------------------+ 610 | EID0 | ELP: RLOC-HARTR -> RLOC-HAxTR-0 | 611 | EID1 | ELP: RLOC-HARTR -> RLOC-NTR | 612 +------+---------------------------------+ 614 +----------+ 615 | cable | 616 +---| internet |-------+ 617 | +----------+ | 618 | | 619 | | 620 --- +-------------+ | -------- 621 \ | Home Router | | / 622 \ +-------------+ +-----------+ +------+ / 623 LAN |---| (NAT) | | HARTR |---| PxTR |---| Internet 624 / +------------ + | HALB/HARF | +------+ \ 625 / | HAxTR | +-----------+ \ 626 --- | HALB/HARF | | -------- 627 +-------------+ | 628 | | 629 | | 630 | +-----------+ +-----+ 631 +---| LTE | NAT |---| NTR | 632 +-----------+ +-----+ 634 Figure 8: LISP-HA used for residential access to the Internet. 636 This solution may be attractive to users who are not even aware of 637 LISP. Their traffic is just load-balanced over DSL and LTE between 638 the home router and the HARTR and decapsulated by the PxTR. In case 639 of a public address space in the customer's LAN the HAxTR can 640 register the entire subnet of the LAN as EID prefix at the MS. The 641 PxTR has to announce the EIDs registered by the HAxTR to the Internet 642 so that traffic for the HAxTR is sent to PxTR. 644 5.2. Smartphones with Mobile Node. 646 Today's smartphones include multiple radio interfaces that allow to 647 connect to multiple access technologies like LTE and Wifi at he same 648 time. The default policy that is implemented in smartphones is to 649 offload traffic from the cellular network to Wifi access. However, 650 it would be desireable to use both technologies to increase the 651 available bandwidth for normal internet traffic like downloads and to 652 select the Wifi connection for realtime applications like VoIP. In 653 Figure 9, we present a potential setup how a MN can use LISP-HA to 654 realize the scenario. 656 Mapping System 657 +------+--------------------------------+ 658 | EID | Entry | 659 +------+--------------------------------+ 660 | EID0 | ELP: RLOC-HARTR -> RLOC-NTR-0 | 661 | EID0 | ELP: RLOC-HARTR -> RLOC-NTR-1 | 662 | EID0 | LCAF: VoIP use RLOC-NTR-0 | 663 +------+--------------------------------+ 665 +------+-----+ +-----+ +-----+ 666 +--| Wifi | NAT |---| DSL |---| NTR | 667 | +------+-----+ +-----+ +-----+ 668 | | 669 +-----------+ | -------- 670 | MN | | / 671 +-----------+ +-----------+ +------+ / 672 | HAxTR | | HARTR |---| PxTR |---| Internet 673 | HALB/HARF | | HALB/HARF | +------+ \ 674 +-----------+ +-----------+ \ 675 | | -------- 676 | | 677 | +-----------+ +-----+ | 678 +--| LTE | NAT |---| NTR |-------+ 679 +-----------+ +-----+ 681 Figure 9: LISP-HA used for Smartphones with Mobile Node. 683 To realize HA on a MN, the MN has to implement its own HAxTR 684 consisting of HALB and HARF. Typically, the MN has access to the 685 Internet most of the time using cellular networks like LTE or HSDPA. 686 So the MN registers its EID through the cellular network at the MS. 687 A provider NAT in the LTE network is handled like described in 688 Section 3.4. Wifi access becomes available if the MN is in reach of 689 a public Wifi hotspot, in the home LAN of the user or other known 690 Wifi networks. Once Wifi access is available, the MN registers its 691 EID over Wifi, too. Additionally, the MN can register an LCAF for 692 VoIP traffic to use Wifi. If Wifi is available no more because the 693 MN left the Wifi cell, the MN should de-register the Wifi mappings at 694 the MS. 696 6. Security Considerations 698 HA by itself does not raise any security concerns. However, LISP-HA 699 is based on LISP so that the same security considerations apply as 700 described in [RFC6830]. There is no authentication of endhosts at 701 the xTR and no authentication between xTRs which allows every node to 702 send any amount of traffic to any xTR which makes it vulnerable to 703 DOS attacks. This also counts for the HARTR and the HAxTR. LISP 704 traffic is not encrypted, so if it is required to encrypt the 705 communication, this has to be realized by the endhosts. 707 7. Acknowledgements 709 The authors would like to thank Gerd Pflueger and Wilhelm 710 Boeddinghaus for their helpful input and discussions. 712 8. References 714 8.1. Normative References 716 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 717 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, 718 August 1996. 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, March 1997. 723 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 724 "TCP Extensions for Multipath Operation with Multiple 725 Addresses", RFC 6824, January 2013. 727 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 728 Locator/ID Separation Protocol (LISP)", RFC 6830, January 729 2013. 731 8.2. Informative References 733 [I-D.ermagan-lisp-nat-traversal] 734 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 735 F., and C. White, "NAT traversal for LISP", draft-ermagan- 736 lisp-nat-traversal-07 (work in progress), February 2015. 738 [I-D.farinacci-lisp-lcaf] 739 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 740 Address Format (LCAF)", draft-farinacci-lisp-lcaf-10 (work 741 in progress), July 2012. 743 [I-D.farinacci-lisp-te] 744 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 745 Engineering Use-Cases", draft-farinacci-lisp-te-08 (work 746 in progress), March 2015. 748 [I-D.hampel-mptcp-proxies-anchors] 749 Hampel, G. and T. Klein, "MPTCP Proxies and Anchors", 750 draft-hampel-mptcp-proxies-anchors-00 (work in progress), 751 February 2012. 753 [I-D.lhwxz-hybrid-access-network-architecture] 754 Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. 755 Zhang, "Hybrid Access Network Architecture", draft-lhwxz- 756 hybrid-access-network-architecture-02 (work in progress), 757 January 2015. 759 [I-D.meyer-lisp-mn] 760 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 761 Mobile Node", draft-meyer-lisp-mn-12 (work in progress), 762 January 2015. 764 [Menth06p] 765 Milbrandt, J., Humm, K., and M. Menth, "Adaptive Bandwidth 766 Allocation: Impact of Routing and Load Balancing on Tunnel 767 Capacity Requirements", in Proceedings of 2nd Conference 768 on Next Generation Internet Design and Engineering, 769 Valencia, Spain , April 2006. 771 Authors' Addresses 773 Michael Menth 774 University of Tuebingen 775 room B302, Institute of Computer Science 776 Sand 13 777 Tuebingen 72076 778 Germany 780 Phone: +49 7071 29-70505 781 Email: menth@uni-tuebingen.de 782 Andreas Stockmayer 783 University of Tuebingen 784 room B305, Institute of Computer Science 785 Sand 13 786 Tuebingen 72076 787 Germany 789 Phone: +49 7071 29-70511 790 Email: andreas.stockmayer@uni-tuebingen.de 792 Mark Schmidt 793 University of Tuebingen 794 room B305, Institute of Computer Science 795 Sand 13 796 Tuebingen 72076 797 Germany 799 Phone: +49 7071 29-70510 800 Email: mark-thomas.schmidt@uni-tuebingen.de