idnits 2.17.1 draft-haindl-ground-lisp-atn-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 : ---------------------------------------------------------------------------- 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 (September 22, 2017) is 2407 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 (-31) exists of draft-ietf-lisp-rfc6833bis-05 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-13 == Outdated reference: A later version (-02) exists of draft-rodrigueznatal-lisp-pubsub-00 Summary: 1 error (**), 0 flaws (~~), 6 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: March 26, 2018 R. Rahman 6 M. Portoles 7 V. Moreno 8 F. Maino 9 Cisco Systems 10 September 22, 2017 12 Ground-Based LISP for the Aeronautical Telecommunications Network 13 draft-haindl-ground-lisp-atn-00 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 March 26, 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 . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 12 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 the 157 ATN/IPS internetworking region (that is in the LISP RLOC space) and 158 provides connectivity between endsystems (that are in the LISP EID 159 space) hosted in the aircrafts and in the AOC/ATS regions. The A/ 160 G-Rs and the G/G-Rs assume the role of LISP xTRs supported by a LISP 161 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. 211 Aircrafts will attach to a specific radio region, via the radio 212 interfaces of the A-Rs. How the radio attachment works is specific 213 to each particular radio infrastructure, and out of the scope of this 214 document, see [GBL]. 216 Typically at the end of the attachment phase, the access router (AC- 217 R) corresponding to the A-R, will announce the reachability of the 218 EID prefixes corresponding to the attached aircraft (the announcement 219 is specific to each particular radio infrastructure, and is out of 220 the scope of this document). A/G-Rs in that particular radio region 221 are responsible to detect those announcements, and, since they act as 222 xTRs, register to the LISP mapping systems the corresponding IPv6 EID 223 prefixes on behalf of the A-R. 225 The EID prefixes registered by the A/G-Rs are then reachable by any 226 of the AOC/ATS Endsystems that are part of the ground based LISP 227 overlay. 229 The LISP infrastructure is used to support seamless aircraft mobility 230 from one radio network to another, as well as multi-homing attachment 231 of an aircraft to multiple radio networks with use of LISP weight and 232 priorities to load balance traffic directed toward the aircraft. 234 The rest of this document provides further details on how ground- 235 based LISP is used to address the requirements of the ATN/IPS use 236 cases. The main design goals are: 238 o minimize added complexity on the aircraft 240 * airborne routers can assume that any ground system is reachable 241 via any A/G router. Static routing policies can be used on 242 board 244 * no need for routing/mobility protocols on board. Routing/ 245 mobility is managed on the ground ATN/IPS network 247 * on-board outgoing link selection can be done with simple static 248 policy 250 o seamless support for aircraft mobility and multi-homing with 251 minimal traffic overhead on the A/G datalink 253 o minimize complexity of ground deployment 255 * ground-based LISP can be easily deployed over existing ATN/IPS 256 ground infrastructure 258 * it is based on COTS solutions 259 * can ease IPv4 to IPv6 transition issues 261 4. Basic Protocol Operation 263 Figure 1 provides the reference topology for a description of the 264 basic operation. A more detailed description of the basic protocol 265 operation is described in [GBL]. 267 4.1. Endsystem Registration 269 The following are the steps via which airborne endsystem prefixes are 270 registered with the LISP mapping system: 272 1. Each Airborne Endsystem (A-E) is assigned an IPv6 address that is 273 the endsystem EID. Each EID includes a Network-ID prefix that 274 comprises (1) an ICAO ID which uniquely identifies the aircraft, 275 and possibly (2) an aircraft network identifier. Airborne 276 devices are grouped in one (and possibly several) IPv6 EID 277 prefixes. As an example an IPv6 EID prefix could be used for all 278 ATC applications located in a safety critical domain of the 279 aircraft network, another IPv6 EID prefix could be used for AOC 280 applications located in a less safety critical domain. 282 2. After the Airborne Router (A-R) on an aircraft attaches to one 283 radio region, the corresponding Access Router (AC-R) learns the 284 IPv6 EID prefixes belonging to the aircraft. The AC-R also 285 announces reachability of these prefixes in the radio region 286 (subnetwork) e.g. by using an IGP protocol like OSPF. The 287 attachment to a radio includes a preference parameter and a 288 quality parameter, these parameters are used e.g. to calculate 289 the IGP reachability advertisement metric. 291 3. The Air/Ground Router (A/G-R) in the subnetwork receives the 292 radio region announcements which contain reachablity information 293 for the IPv6 EID prefixes corresponding to the Airborne 294 Endsystems. Since each A/G-R is also an xTR, the A/G-R registers 295 the IPv6 EID prefixes with the LISP MS/MR on behalf of the A-R. 296 The included quality parameter (e.g. IGP metric) is converted to 297 a LISP priority, so that a lower quality metric results in a 298 lower LISP priority value. 300 Ground based endsystems are part of ground subnetworks where the 301 Ground/Ground Router (G/G-R) is an xTR. Each G/G-R therefore 302 registers the prefixes corresponding to the AOC endsystems and ATS 303 endsystems with the LISP mapping system, as specified in [RFC6830]. 305 4.2. Ground to Airborne Traffic Flow 307 Here is an example of how traffic flows from the ground to the 308 airborne endsystems, when ATS endsystem 1 (ATS-E1) has traffic 309 destined to airborne endsystem 1 (A-E1): 311 1. The default route in the ATS region takes the traffic to xTR3 312 which is also a Ground/Ground Router (G/G-R). 314 2. xTR3 sends a Map-Request message for the address of A-E1 to the 315 LISP mapping system. xTR2 sends a Map-Reply to xTR3 with RLOC set 316 to its address which is reachable from xTR3 via the 317 internetworking region. 319 3. xTR3 encapsulates the traffic to xTR2 using the RLOC information 320 in the Map-Reply message. 322 4. xTR2 decapsulates the traffic coming from xTR3. The destination 323 address of the inner packet belongs to A-E1 which has been 324 advertised by the AC-R in the same region. The traffic is 325 therefore forwarded to AC-R2. 327 5. AC-R2 sends the traffic to the Airborne Router of the aircraft 328 and the A-R sends it to the endsystem. 330 4.3. Airborne to Ground Traffic Flow 332 Here is an example of how traffic flows from the airborne endsystems 333 to the ground when airborne endsystem 2 (A-E2) has traffic destined 334 to ATS endsystem 2 (ATS-E2): 336 1. The default route in the aircraft points to the Airborne Router 337 (A-R). The latter forwards the traffic over the radio link to 338 AC-R2. 340 2. The default route on AC-R2 points to xTR2 (also an A/G-R), so the 341 traffic is sent from AC-R2 to xTR2. 343 3. xTR2 sends a Map-Request message for the address of ATS-E2 to the 344 LISP mapping system. xTR3 sends a Map-Reply to xTR2 with RLOC set 345 to its address which is reachable from xTR2 via the 346 internetworking region. 348 4. xTR2 encapsulates the traffic to xTR3 using the RLOC information 349 in the Map-Reply message. 351 5. xTR3 decapsulates the traffic coming from xTR2, and forwards it 352 to ATS-E2. 354 4.4. Default forwarding path 356 When an xTR is waiting for a Map-Reply for an EID, the xTR does not 357 know how to forward the packets destined to that EID. This means 358 that the first packets for ground-to-air traffic would get dropped 359 until the Map-Reply is received and a map-cache entry is created. 360 However if a device acting as RTR, see 361 [I-D.ermagan-lisp-nat-traversal], has mappings for all EIDs, the xTR 362 could use the RTR as default path for packets which have to be 363 encapsulated. How the RTR gets all the mappings is outside the scope 364 of this document but one example is the use of LISP pub-sub as 365 specified in [I-D.rodrigueznatal-lisp-pubsub]. Note that the RTR 366 does not have to be a new device, the device which has the MS/MR role 367 can also act as RTR. 369 4.5. Traffic symmetry 371 There is a requirement for air-to-ground traffic and ground-to-air 372 traffic to follow the same path. As described in Section 4.3, the 373 path for air-to-ground traffic is controlled by the A-R: the A-R 374 decides which radio link to use. The path for ground-to-air traffic 375 is governed by the quality metrics in the radio advertisement from 376 the A-R, this is described in Section 4.2. This means that the 377 responsibility for enforcing traffic symmetry lies on the A-R. 379 5. Multi-Homing and Mobility 381 Multi-homing support builds on the procedures described in 382 Section 4:. 384 1. The Airborne Router (A-R) on an aircraft attaches to multiple 385 radio regions. As an example, and referring to Figure 1, the A-R 386 attaches to the LDACS and SATCOM regions, via AC-R2 and AC-R1 387 respectively. 389 2. Through the preference parameter sent to each region, the A-R has 390 control over which path (i.e. radio region) ground to air traffic 391 flows. For example, A-R would indicate preference of the LDACS 392 region by choosing a better preference value for the LDACS region 393 compared to the preference value sent to the SATCOM region. 395 3. Both xTR1 and xTR2 register the IPv6 EID prefixes with the LISP 396 mapping system using merge semantic, as specified in section 4.6 397 of [I-D.ietf-lisp-rfc6833bis]. Since the priority used in the 398 LISP registrations is derived from the preference and quality 399 parameters, xTR2 would use a lower priority value than xTR1. In 400 this way the LISP mapping system will favour xTR2 (A/G-R for the 401 LDACS region) over xTR1 (A/G-R for the SATCOM region), as 402 specified by the preference and quality parameters. 404 4. Upon registration the LISP MS/MR will send Map-Notify messages to 405 both xTR1 and xTR2, to inform that they have reachability to the 406 aircraft's IPv6 EID prefixes. 408 5. Upstream and downstream traffic flows on the same path, i.e. both 409 use the LDACS region. 411 With mobility, the aircraft could want to switch traffic from one 412 radio link to another. For example while transiting from an area 413 covered by LDACS to an area covered by SATCOM, the aircraft could 414 desire to switch all traffic from LDACS to SATCOM. For air-to-ground 415 traffic, the A-R has complete control over which radio link to use, 416 and will simply select the SATCOM outgoing interface. For ground-to- 417 air traffic: 419 1. The A-R sends a radio advertisement to AC-R1 indicating a better 420 preference for the SATCOM link. 422 2. This leads to AC-R1 lowering its quality parameter (e.g. IGP 423 metric) for the IPv6 EID prefixes. 425 3. Upon receiving the better preference value, xTR1 registers the 426 IPv6 EID prefixes with the MS/MR, using a lower priority value 427 than what xTR2 had used. Both xTR1 and xTR2 receives Map-Notify 428 messages signaling to xTR2 that xTR1 is now the preferred path 429 toward the aircraft. 431 4. xTR3 has a map-cache which still points to xTR2, therefore xTR3 432 still sends traffic via xTR2. xTR2 sends Solicit-Map-Request 433 (SMR) to xTR3 who queries the LISP mapping system again. This 434 results in updating the map-cache on xTR3 which now points to 435 XTR1 so ground-to-air traffic now flows on the SATCOM radio link. 437 6. Convergence 439 When traffic is flowing on a radio link and that link goes down, the 440 network has to converge rapidly on the other link available for that 441 aircraft. 443 For air-to-ground traffic, once the A-R detects the failure it can 444 switch immediatly to the other radio link. 446 For ground-to-air traffic, when a radio link fails, the corresponding 447 AC-R sends a reachability update that the IPv6 EID prefixes are not 448 reachable anymore. This leads to the A/G-R (also an xTR) in that 449 region to unregister the IPv6 EID prefixes with the MS/MR. This 450 indicates that the xTR in question has no reachability to the EID 451 prefixes. The notification of the failure should reach all relevant 452 xTRs as soon as possible. For example, if the LDACS radio link 453 fails, xTR3 and xTR4 need to learn about the failure so that they 454 stop sending traffic via xTR2 and use xTR1 instead. 456 In the sub-sections below, we the use of RLOC-probing, Solicit-Map- 457 Request, and LISP pub-sub as alternative mechanisms for link failure 458 notification. 460 6.1. Use of RLOC-probing 462 RLOC-probing is described in section 6.3.2 of [RFC6830]. 464 At regular intervals xTR3 sends Map-Request to xTR2 for the 465 aircraft's EID prefixes. When xTR3 detects via RLOC-probing that it 466 can not use xTR2 anymore, it sends a Map-Request for the aircraft's 467 EID prefixes. The corresponding Map-Reply indicates that xTR1 should 468 now be used. The map-cache on xTR3 is updated and air-to-ground 469 traffic now goes through xTR1 to use the SATCOM radio link to the 470 aircraft. 472 The disadvantage of RLOC-probing is that fast detection becomes more 473 difficult when the number of EID prefixes is large. 475 6.2. Use of Solicit-Map-Request 477 Solicit-Map-Request is used as described in Section 5: 479 1. xTR3 is still sending traffic to xTR2 since its map-cache has not 480 been updated yet. 482 2. Upon detecting that the link is down, and receiving data plane 483 traffic from the ground network, xTR2 sends an SMR to xTR3 that 484 sends a Map-Request to update its map-cache. The corresponding 485 Map-Reply indicates that xTR1 should now be used. 487 The disadvantage of this approach is that the traffic is delayed 488 pending control-plane resolution. This method also depends on data 489 traffic being continuous, in many cases data traffic may be sporadic, 490 leading to very slow convergence. 492 6.3. Use of LISP pub-sub 494 As specified in [I-D.rodrigueznatal-lisp-pubsub], ITRs can subscribe 495 to changes in the LISP mapping system. So if all ITRs subscribe to 496 the EID prefixes for which they have traffic, the ITRs will be 497 notified when there is mapping change. 499 In the example where the LDACS radio link fails, when xTR2 500 unregisters the EID prefixes with the MS/MR, xTR3 would be notified 501 via LISP pub-sub (assuming xTR3 has a map-cache entry for these EID 502 prefixes). 504 This mechanism provides the fastest convergence at the cost of more 505 state in the LISP mapping system. 507 7. Security Considerations 509 For LISP control-plane message security, please refer to 510 [I-D.ietf-lisp-sec]. 512 8. IANA Considerations 514 No IANA considerations. 516 9. Acknowledgements 518 10. References 520 10.1. Normative References 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, 524 DOI 10.17487/RFC2119, March 1997, 525 . 527 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 528 Locator/ID Separation Protocol (LISP)", RFC 6830, 529 DOI 10.17487/RFC6830, January 2013, 530 . 532 10.2. Informative References 534 [GBL] Frequentis, "Ground Based LISP for Multilink Operation, 535 https://www.icao.int/safety/acp/ACPWGF/CP WG-I 19/WP06 536 Ground_Based_LISP 2016-01-14.pdf", January 2016. 538 [I-D.ermagan-lisp-nat-traversal] 539 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 540 F., and C. White, "NAT traversal for LISP", draft-ermagan- 541 lisp-nat-traversal-13 (work in progress), September 2017. 543 [I-D.ietf-lisp-rfc6833bis] 544 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 545 "Locator/ID Separation Protocol (LISP) Control-Plane", 546 draft-ietf-lisp-rfc6833bis-05 (work in progress), May 547 2017. 549 [I-D.ietf-lisp-sec] 550 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 551 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-13 552 (work in progress), September 2017. 554 [I-D.rodrigueznatal-lisp-pubsub] 555 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 556 Cabellos-Aparicio, A., Barkai, S., and D. Farinacci, 557 "Publish-Subscribe mechanism for LISP", draft- 558 rodrigueznatal-lisp-pubsub-00 (work in progress), August 559 2017. 561 Authors' Addresses 563 Bernhard Haindl 564 Frequentis 566 Email: bernhard.haindl@frequentis.com 568 Manfred Lindner 569 Frequentis 571 Email: manfred.lindner@frequentis.com 573 Reshad Rahman 574 Cisco Systems 576 Email: rrahman@cisco.com 578 Marc Portoles Comeras 579 Cisco Systems 581 Email: mportole@cisco.com 583 Victor Moreno 584 Cisco Systems 586 Email: vmoreno@cisco.com 587 Fabio Maino 588 Cisco Systems 590 Email: fmaino@cisco.com