idnits 2.17.1 draft-haindl-ground-lisp-atn-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 27, 2017) is 2345 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-13 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-00 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-06 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-14 == Outdated reference: A later version (-02) exists of draft-rodrigueznatal-lisp-pubsub-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group B. Haindl 3 Internet-Draft M. Lindner 4 Intended status: Informational Frequentis 5 Expires: April 30, 2018 R. Rahman 6 M. Portoles 7 V. Moreno 8 F. Maino 9 Cisco Systems 10 October 27, 2017 12 Ground-Based LISP for the Aeronautical Telecommunications Network 13 draft-haindl-ground-lisp-atn-01 15 Abstract 17 This document describes the use of the LISP architecture and 18 protocols to address the requirements of the worldwide Aeronautical 19 Telecommunications Network with Internet Protocol Services, as 20 articulated by the International Civil Aviation Organization. 22 The ground-based LISP overlay provides mobility and multi-homing 23 services to the IPv6 networks hosted on commercial aircrafts, to 24 support Air Traffic Management communications with Air Traffic 25 Controllers and Air Operation Controllers. The proposed architecture 26 doesn't require support for LISP protocol in the airborne routers, 27 and can be easily deployed over existing ground infrastructures. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 30, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 70 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Basic Protocol Operation . . . . . . . . . . . . . . . . . . 7 72 4.1. Endsystem Registration . . . . . . . . . . . . . . . . . 7 73 4.2. Ground to Airborne Traffic Flow . . . . . . . . . . . . . 8 74 4.3. Airborne to Ground Traffic Flow . . . . . . . . . . . . . 8 75 4.4. Default forwarding path . . . . . . . . . . . . . . . . . 9 76 4.5. Traffic symmetry . . . . . . . . . . . . . . . . . . . . 9 77 5. Multi-Homing and Mobility . . . . . . . . . . . . . . . . . . 9 78 6. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.1. Use of RLOC-probing . . . . . . . . . . . . . . . . . . . 11 80 6.2. Use of Solicit-Map-Request . . . . . . . . . . . . . . . 11 81 6.3. Use of LISP pub-sub . . . . . . . . . . . . . . . . . . . 12 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 10.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 This document describes the use of the LISP [RFC6830] architecture 93 and protocols to address the requirements of the worldwide 94 Aeronautical Telecommunications Network with Internet Protocol 95 Services (ATN/IPS), as articulated by the International Civil 96 Aviation Organization (ICAO). 98 ICAO is proposing to replace the existing aeronautical communication 99 services with an IPv6 based infrastructure that supports Air Traffic 100 Management (ATM) between commercial aircrafts, Air Traffic 101 Controllers (ATC) and Air Operation Controllers (AOC). 103 This document describes how a LISP overlay can be used to offer 104 mobility and multi-homing services to the IPv6 networks hosted on 105 commercial aircrafts without requiring LISP support in the airborne 106 routers. Use of the LISP protocol is limited to the ground-based 107 routers, hence the name "ground-based LISP". The material for this 108 document is derived from [GBL]. 110 2. Definition of Terms 112 AOC: Airline Operational Control 114 ATN/IPS: Aeronautical Telecommunications Network with Internet 115 Protocol Services 117 AC-R: Access Ground Router 119 A/G-R: Air/Ground Router 121 G/G-R: Ground/Ground Router 123 A-R: Airborne Router 125 A-E: Airborne Endsystem 127 ATS-E: ATS Endsystem 129 For definitions of other terms, notably Map-Register, Map-Request, 130 Map-Reply, Routing Locator (RLOC), Solicit-Map-Request (SMR), Ingress 131 Tunnel Router (ITR), Egress Tunnel Router (ETR), xTR (ITR or ETR), 132 Map-Server (MS), and Map-Resolver (MR) please consult the LISP 133 specification [RFC6830]. 135 3. Design Overview 137 In the ATN/IPS architecture the airborne endsystems hosted on an 138 aircraft are part of an IPV6 network connected to the ground network 139 by one or more Airborne Routers (A-R). A-Rs have multiple radio 140 interfaces that connects them via various radios infrastructures 141 (e.g. SATCOM, LDACS, AeroMACS) to a given radio region, also known 142 as subnetwork, on the ground. Typically an A-R has a corresponding 143 ground based Access Router (AC-R) that terminates the radio protocol 144 with the A-R and provides access services to the ground based portion 145 of the radio network infrastructure. Each radio region is 146 interconnected with the ATN/IPS ground network via an Air-to-Ground 147 router (AG-R). 149 Similarly, the Air Traffic Controllers and Air Operation Controllers 150 Endsystems (ATS-E and AOC-E) are part of IPv6 networks reachable via 151 one or more Ground-to-Ground Routers (G/G-Rs). 153 The ATN/IPS ground network infrastructure is the internetworking 154 region located between the A/G routers and the G/G routers. 156 In the ground-based LISP architecture, a LISP overlay is laid over 157 the ATN/IPS internetworking region (that is in the LISP RLOC space) 158 and provides connectivity between endsystems (that are in the LISP 159 EID space) hosted in the aircrafts and in the AOC/ATS regions. The 160 A/G-Rs and the G/G-Rs assume the role of LISP xTRs supported by a 161 LISP mapping system infrastructure. 163 ,------, 164 ,---------. : A-E1 : 165 ,' `./'------' 166 ( AIRCRAFT ) 167 `. +-----+ ,'\ ,------, 168 `-| A-R |-' \: A-E2 : 169 +-----+ '------' 170 // \\ 171 // \\ 172 +---+--+ +-+--+--+ 173 .--.-.| AC-R1|'.-. .| AC-R2 |.-. 174 ( +---+--+ ) ( +-+--+--+ ) 175 ( __. ( '. 176 ..'SATCOM Region ) .' LDACS Region ) 177 ( .'-' ( .'-' 178 ' +-------+ ) ' +-------+ ) 179 '-| A/G-R |-' '-| A/G-R |-'' 180 | | | | 181 | xTR1 | | xTR2 | 182 +-------+ +-------+ 183 \ / 184 \ .--..--. .--. ../ 185 \ ( ' '.--. 186 .-.' Internetworking '' '-------' 187 ( region )--: MS/MR : 188 ( (RLOC SPACE) '-'' '-------' 189 ._.'--'._.'.-._.'.-._) 190 / \ 191 +---+---+ +-+--+--+ 192 -.-.| G/G-R |'. .| G/G-R |. 193 ( | | ) ( | | ) 194 ( | xTR3 | ) ( | xTR4 | ) 195 ( +---+---+ ) ( +-+--+--+ ) 196 ( _._. ( '. 197 ..' ATS Region ) .' AOC Region ) 198 ( .'-' ( .'-' 199 '--'._.'. )\ '--'._.'. )\ 200 / '--' \ / '--' \ 201 '--------' '--------' '--------' '--------' 202 : ATS-E1 : : ATS-E2 : : AOC-E1 : : AOC-E2 : 203 '--------' '--------' '--------' '--------' 205 Figure 1: ATN/IPS and ground-based LISP overlay 207 Endsystems in the AOC/ATS regions are mapped in the LISP overlay by 208 the G/G-Rs, that are responsible for the registration of the AOC/ATS 209 endsystems to the LISP mapping system. Each G/G-R is basically an 210 xTR which has direct connections only to the terrestrial regions, 211 i.e. no direct connection to the radio regions. 213 Aircrafts will attach to a specific radio region, via the radio 214 interfaces of the A-Rs. How the radio attachment works is specific 215 to each particular radio infrastructure, and out of the scope of this 216 document, see [GBL]. 218 Typically at the end of the attachment phase, the access router (AC- 219 R) corresponding to the A-R, will announce the reachability of the 220 EID prefixes corresponding to the attached aircraft (the announcement 221 is specific to each particular radio infrastructure, and is out of 222 the scope of this document). A/G-Rs in that particular radio region 223 are responsible to detect those announcements, and, since they act as 224 xTRs, register to the LISP mapping systems the corresponding IPv6 EID 225 prefixes on behalf of the A-R, but with the RLOC of the A/G-R. 227 The EID prefixes registered by the A/G-Rs are then reachable by any 228 of the AOC/ATS Endsystems that are part of the ground based LISP 229 overlay. 231 The LISP infrastructure is used to support seamless aircraft mobility 232 from one radio network to another, as well as multi-homing attachment 233 of an aircraft to multiple radio networks with use of LISP weight and 234 priorities to load balance traffic directed toward the aircraft. 236 The rest of this document provides further details on how ground- 237 based LISP is used to address the requirements of the ATN/IPS use 238 cases. The main design goals are: 240 o minimize added complexity on the aircraft 242 * airborne routers can assume that any ground system is reachable 243 via any A/G router. Static routing policies can be used on 244 board 246 * no need for routing/mobility protocols on board. Routing/ 247 mobility is managed on the ground ATN/IPS network 249 * on-board outgoing link selection can be done with simple static 250 policy 252 o seamless support for aircraft mobility and multi-homing with 253 minimal traffic overhead on the A/G datalink 255 o minimize complexity of ground deployment 256 * ground-based LISP can be easily deployed over existing ATN/IPS 257 ground infrastructure 259 * it is based on COTS solutions 261 * can ease IPv4 to IPv6 transition issues 263 4. Basic Protocol Operation 265 Figure 1 provides the reference topology for a description of the 266 basic operation. A more detailed description of the basic protocol 267 operation is described in [GBL]. 269 4.1. Endsystem Registration 271 The following are the steps via which airborne endsystem prefixes are 272 registered with the LISP mapping system: 274 1. Each Airborne Endsystem (A-E) is assigned an IPv6 address that is 275 the endsystem EID. Each EID includes a Network-ID prefix that 276 comprises (1) an ICAO ID which uniquely identifies the aircraft, 277 and possibly (2) an aircraft network identifier. Airborne 278 devices are grouped in one (and possibly several) IPv6 EID 279 prefixes. As an example an IPv6 EID prefix could be used for all 280 ATC applications located in a safety critical domain of the 281 aircraft network, another IPv6 EID prefix could be used for AOC 282 applications located in a less safety critical domain. 284 2. After the Airborne Router (A-R) on an aircraft attaches to one 285 radio region, the corresponding Access Router (AC-R) learns the 286 IPv6 EID prefixes belonging to the aircraft. The AC-R also 287 announces reachability of these prefixes in the radio region 288 (subnetwork) e.g. by using an IGP protocol like OSPF. The 289 attachment to a radio includes a preference parameter and a 290 quality parameter, these parameters are used e.g. to calculate 291 the IGP reachability advertisement metric. 293 3. The Air/Ground Router (A/G-R) in the subnetwork receives the 294 radio region announcements which contain reachablity information 295 for the IPv6 EID prefixes corresponding to the Airborne 296 Endsystems. Since each A/G-R is also an xTR, the A/G-R registers 297 the IPv6 EID prefixes with the LISP MS/MR on behalf of the A-R, 298 but with the RLOC of the A/G-R. The included quality parameter 299 (e.g. IGP metric) is converted to a LISP priority, so that a 300 lower quality metric results in a lower LISP priority value. 302 Ground based endsystems are part of ground subnetworks where the 303 Ground/Ground Router (G/G-R) is an xTR. Each G/G-R therefore 304 registers the prefixes corresponding to the AOC endsystems and ATS 305 endsystems with the LISP mapping system, as specified in [RFC6830]. 307 4.2. Ground to Airborne Traffic Flow 309 Here is an example of how traffic flows from the ground to the 310 airborne endsystems, when ATS endsystem 1 (ATS-E1) has traffic 311 destined to airborne endsystem 1 (A-E1): 313 1. The default route in the ATS region takes the traffic to xTR3 314 which is also a Ground/Ground Router (G/G-R). 316 2. xTR3 sends a Map-Request message for the address of A-E1 to the 317 LISP mapping system. xTR2 sends a Map-Reply to xTR3 with RLOC set 318 to its address which is reachable from xTR3 via the 319 internetworking region. 321 3. xTR3 encapsulates the traffic to xTR2 using the RLOC information 322 in the Map-Reply message. 324 4. xTR2 decapsulates the traffic coming from xTR3. The destination 325 address of the inner packet belongs to A-E1 which has been 326 advertised by the AC-R in the same region. The traffic is 327 therefore forwarded to AC-R2. 329 5. AC-R2 sends the traffic to the Airborne Router of the aircraft 330 and the A-R sends it to the endsystem. 332 4.3. Airborne to Ground Traffic Flow 334 Here is an example of how traffic flows from the airborne endsystems 335 to the ground when airborne endsystem 2 (A-E2) has traffic destined 336 to ATS endsystem 2 (ATS-E2): 338 1. The default route in the aircraft points to the Airborne Router 339 (A-R). The latter forwards the traffic over the radio link to 340 AC-R2. 342 2. The default route on AC-R2 points to xTR2 (also an A/G-R), so the 343 traffic is sent from AC-R2 to xTR2. 345 3. xTR2 sends a Map-Request message for the address of ATS-E2 to the 346 LISP mapping system. xTR3 sends a Map-Reply to xTR2 with RLOC set 347 to its address which is reachable from xTR2 via the 348 internetworking region. 350 4. xTR2 encapsulates the traffic to xTR3 using the RLOC information 351 in the Map-Reply message. 353 5. xTR3 decapsulates the traffic coming from xTR2, and forwards it 354 to ATS-E2. 356 4.4. Default forwarding path 358 When an xTR is waiting for a Map-Reply for an EID, the xTR does not 359 know how to forward the packets destined to that EID. This means 360 that the first packets for ground-to-air traffic would get dropped 361 until the Map-Reply is received and a map-cache entry is created. 362 However if a device acting as RTR, see 363 [I-D.ermagan-lisp-nat-traversal], has mappings for all EIDs, the xTR 364 could use the RTR as default path for packets which have to be 365 encapsulated. How the RTR gets all the mappings is outside the scope 366 of this document but one example is the use of LISP pub-sub as 367 specified in [I-D.rodrigueznatal-lisp-pubsub]. Note that the RTR 368 does not have to be a new device, the device which has the MS/MR role 369 can also act as RTR. It is only the RTR which needs to subscribe to 370 all the aircraft EIDs, the XTRs (i.e. the A/G-Rs and G/G-Rs) do not 371 need to subscribe. 373 4.5. Traffic symmetry 375 The requirements for traffic symmetry are still TBD. 377 5. Multi-Homing and Mobility 379 Multi-homing support builds on the procedures described in Section 4: 381 1. The Airborne Router (A-R) on an aircraft attaches to multiple 382 radio regions. As an example, and referring to Figure 1, the A-R 383 attaches to the LDACS and SATCOM regions, via AC-R2 and AC-R1 384 respectively. 386 2. Through the preference parameter sent to each region, the A-R has 387 control over which path (i.e. radio region) ground to air traffic 388 flows. For example, A-R would indicate preference of the LDACS 389 region by choosing a better preference value for the LDACS region 390 compared to the preference value sent to the SATCOM region. 392 3. Both xTR1 and xTR2 register the IPv6 EID prefixes with the LISP 393 mapping system using merge semantic, as specified in section 4.6 394 of [I-D.ietf-lisp-rfc6833bis]. Since the priority used in the 395 LISP registrations is derived from the preference and quality 396 parameters, xTR2 would use a lower priority value than xTR1. In 397 this way the LISP mapping system will favour xTR2 (A/G-R for the 398 LDACS region) over xTR1 (A/G-R for the SATCOM region), as 399 specified by the preference and quality parameters. 401 4. Upon registration the LISP MS/MR will send Map-Notify messages to 402 both xTR1 and xTR2, to inform that they have reachability to the 403 aircraft's IPv6 EID prefixes. Both xTRs are notified because 404 they have both set the merge-request and want-map-notify bits in 405 their respective Map-Register message. 407 5. Upstream and downstream traffic flows on the same path, i.e. both 408 use the LDACS region. 410 With mobility, the aircraft could want to switch traffic from one 411 radio link to another. For example while transiting from an area 412 covered by LDACS to an area covered by SATCOM, the aircraft could 413 desire to switch all traffic from LDACS to SATCOM. For air-to-ground 414 traffic, the A-R has complete control over which radio link to use, 415 and will simply select the SATCOM outgoing interface. For ground-to- 416 air traffic: 418 1. The A-R sends a radio advertisement to AC-R1 indicating a better 419 preference for the SATCOM link. 421 2. This leads to AC-R1 lowering its quality parameter (e.g. IGP 422 metric) for the IPv6 EID prefixes. 424 3. Upon receiving the better preference value, xTR1 registers the 425 IPv6 EID prefixes with the MS/MR, using a lower priority value 426 than what xTR2 had used. Both xTR1 and xTR2 receives Map-Notify 427 messages signaling to xTR2 that xTR1 is now the preferred path 428 toward the aircraft. 430 4. xTR3 has a map-cache which still points to xTR2, therefore xTR3 431 still sends traffic via xTR2. xTR2 sends Solicit-Map-Request 432 (SMR) to xTR3 who queries the LISP mapping system again. This 433 results in updating the map-cache on xTR3 which now points to 434 XTR1 so ground-to-air traffic now flows on the SATCOM radio link. 436 The procedure for mobility is derived from 437 [I-D.ietf-lisp-eid-mobility]. 439 6. Convergence 441 When traffic is flowing on a radio link and that link goes down, the 442 network has to converge rapidly on the other link available for that 443 aircraft. 445 For air-to-ground traffic, once the A-R detects the failure it can 446 switch immediatly to the other radio link. 448 For ground-to-air traffic, when a radio link fails, the corresponding 449 AC-R sends a reachability update that the IPv6 EID prefixes are not 450 reachable anymore. This leads to the A/G-R (also an xTR) in that 451 region to unregister the IPv6 EID prefixes with the MS/MR. This 452 indicates that the xTR in question has no reachability to the EID 453 prefixes. The notification of the failure should reach all relevant 454 xTRs as soon as possible. For example, if the LDACS radio link 455 fails, xTR3 and xTR4 need to learn about the failure so that they 456 stop sending traffic via xTR2 and use xTR1 instead. 458 In the sub-sections below, we the use of RLOC-probing, Solicit-Map- 459 Request, and LISP pub-sub as alternative mechanisms for link failure 460 notification. 462 6.1. Use of RLOC-probing 464 RLOC-probing is described in section 6.3.2 of [RFC6830]. 466 At regular intervals xTR3 sends Map-Request to xTR2 for the 467 aircraft's EID prefixes. When xTR3 detects via RLOC-probing that it 468 can not use xTR2 anymore, it sends a Map-Request for the aircraft's 469 EID prefixes. The corresponding Map-Reply indicates that xTR1 should 470 now be used. The map-cache on xTR3 is updated and air-to-ground 471 traffic now goes through xTR1 to use the SATCOM radio link to the 472 aircraft. 474 The disadvantage of RLOC-probing is that fast detection becomes more 475 difficult when the number of EID prefixes is large. 477 6.2. Use of Solicit-Map-Request 479 Solicit-Map-Request is used as described in Section 5: 481 1. xTR3 is still sending traffic to xTR2 since its map-cache has not 482 been updated yet. 484 2. Upon detecting that the link is down, and receiving data plane 485 traffic from the ground network, xTR2 sends an SMR to xTR3 that 486 sends a Map-Request to update its map-cache. The corresponding 487 Map-Reply indicates that xTR1 should now be used. 489 The disadvantage of this approach is that the traffic is delayed 490 pending control-plane resolution. This method also depends on data 491 traffic being continuous, in many cases data traffic may be sporadic, 492 leading to very slow convergence. 494 6.3. Use of LISP pub-sub 496 As specified in [I-D.rodrigueznatal-lisp-pubsub], ITRs can subscribe 497 to changes in the LISP mapping system. So if all ITRs subscribe to 498 the EID prefixes for which they have traffic, the ITRs will be 499 notified when there is mapping change. 501 In the example where the LDACS radio link fails, when xTR2 502 unregisters the EID prefixes with the MS/MR, xTR3 would be notified 503 via LISP pub-sub (assuming xTR3 has a map-cache entry for these EID 504 prefixes). 506 This mechanism provides the fastest convergence at the cost of more 507 state in the LISP mapping system. 509 7. Security Considerations 511 For LISP control-plane message security, please refer to 512 [I-D.ietf-lisp-sec]. This addresses the control-plane threats that 513 target EID-to-RLOC mappings, including manipulations of Map-Request 514 and Map-Reply messages, and malicious ETR EID prefix overclaiming. 516 8. IANA Considerations 518 No IANA considerations. 520 9. Acknowledgements 522 The authors would like to thank Dino Farinacci for his review of the 523 document. 525 10. References 527 10.1. Normative References 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, 531 DOI 10.17487/RFC2119, March 1997, 532 . 534 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 535 Locator/ID Separation Protocol (LISP)", RFC 6830, 536 DOI 10.17487/RFC6830, January 2013, 537 . 539 10.2. Informative References 541 [GBL] Frequentis, "Ground Based LISP for Multilink Operation, 542 https://www.icao.int/safety/acp/ACPWGF/CP WG-I 19/WP06 543 Ground_Based_LISP 2016-01-14.pdf", January 2016. 545 [I-D.ermagan-lisp-nat-traversal] 546 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 547 F., and C. White, "NAT traversal for LISP", draft-ermagan- 548 lisp-nat-traversal-13 (work in progress), September 2017. 550 [I-D.ietf-lisp-eid-mobility] 551 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 552 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 553 Unified Control Plane", draft-ietf-lisp-eid-mobility-00 554 (work in progress), May 2017. 556 [I-D.ietf-lisp-rfc6833bis] 557 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 558 "Locator/ID Separation Protocol (LISP) Control-Plane", 559 draft-ietf-lisp-rfc6833bis-06 (work in progress), October 560 2017. 562 [I-D.ietf-lisp-sec] 563 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 564 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 565 (work in progress), October 2017. 567 [I-D.rodrigueznatal-lisp-pubsub] 568 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 569 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 570 Boucadair, M., Jacquenet, C., and s. 571 stefano.secci@lip6.fr, "Publish/Subscribe Functionality 572 for LISP", draft-rodrigueznatal-lisp-pubsub-01 (work in 573 progress), October 2017. 575 Authors' Addresses 577 Bernhard Haindl 578 Frequentis 580 Email: bernhard.haindl@frequentis.com 582 Manfred Lindner 583 Frequentis 585 Email: manfred.lindner@frequentis.com 586 Reshad Rahman 587 Cisco Systems 589 Email: rrahman@cisco.com 591 Marc Portoles Comeras 592 Cisco Systems 594 Email: mportole@cisco.com 596 Victor Moreno 597 Cisco Systems 599 Email: vmoreno@cisco.com 601 Fabio Maino 602 Cisco Systems 604 Email: fmaino@cisco.com