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