idnits 2.17.1 draft-farinacci-lisp-satellite-network-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 date (April 1, 2022) is 727 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC1700' is defined on line 329, but no explicit reference was found in the text == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-25 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) == Outdated reference: A later version (-18) exists of draft-farinacci-lisp-mobile-network-14 == Outdated reference: A later version (-11) exists of draft-farinacci-lisp-telemetry-07 == Outdated reference: A later version (-09) exists of draft-haindl-lisp-gb-atn-07 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-eid-anonymity-12 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-09 == Outdated reference: A later version (-14) exists of draft-ietf-lisp-te-10 == Outdated reference: A later version (-06) exists of draft-lhan-problems-requirements-satellite-net-02 == Outdated reference: A later version (-03) exists of draft-lhan-satellite-instructive-routing-00 == Outdated reference: A later version (-04) exists of draft-lhan-satellite-semantic-addressing-01 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental V. Moreno 5 Expires: October 3, 2022 P. Pillay-Esnault 6 Independent 7 April 1, 2022 9 LISP for Satellite Networks 10 draft-farinacci-lisp-satellite-network-00 12 Abstract 14 This specification describes how the LISP architecture and protocols 15 can be used over satellite network systems. The LISP overlay runs on 16 earth using the satellite network system in space as the underlay. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 3, 2022. 35 Copyright Notice 37 Copyright (c) 2022 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4. Mapping System . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. EID Mobility . . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Satellite RLOCs and Underlay Routing . . . . . . . . . . . . 7 58 7. Underlay Performance . . . . . . . . . . . . . . . . . . . . 8 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 10.2. Informative References . . . . . . . . . . . . . . . . . 9 64 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 65 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10 66 B.1. Changes to draft-farinacci-lisp-satellite-network-00 . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 This specification describes how a LISP overlay structure can run on 72 top of a satellite network underlay. The approach is similar to how 73 [I-D.haindl-lisp-gb-atn] is used in Aeronautical Telecommunications 74 Networks and [I-D.farinacci-lisp-mobile-network] is used in cellular 75 networks. 77 This satellite deployment use-case requires no changes to the LISP 78 architecture or standard protocol specifications. In addition, any 79 LISP implementations that run on a device with an existing satellite 80 interface does not need to be upgraded. 82 Even though an overlay should not concern itself with the operation 83 of an underlay, the requirements from 84 [I-D.lhan-problems-requirements-satellite-net] are considered but 85 outside the scope of this document. 87 The LISP overlay requirements are: 89 1. There will be no EID state in the satellite network underlay. 91 2. The satellite underlay is completely unaware of the overlay 92 running over it. 94 3. The overlay requires the underlay network to deliver packets to 95 RLOC addresses. 97 4. The underlay network can transport IPv4 or IPv6 packets and can 98 be dual-stack. 100 5. When path optimization in the underlay is available, an RLOC- 101 record can be a source route of satellite hops. 103 The diagram below illustrates a 4 satellite system where each have 104 Inter-Satellite-Links (ISLs) for connectivity between them and edge 105 satellites with RF links to Ground Stations. The EID connectivity to 106 the xTRs is achieved via typical IP network connectivity where EIDs 107 can be directly connected, one or more switch hops away, one or more 108 router hops away, or any combination. 110 in space (underlay) 111 +--------------------------------------------------------------+ 112 | | 113 | sat ISL sat ISL sat ISL sat | 114 | ))*(( ------- ))*(( ------- ))*(( ------- ))*(( | 115 | | | | 116 | | | | 117 | |up/down RF-link up/down RF-link| | 118 | | | | 119 | | | | 120 +------|-----------------------------------------------|-------+ 121 | | 122 | | 123 | on earth (overlay) | 124 +------|-----------------------------------------------|-------+ 125 | | | | 126 | GS-xTR [mapping system] GS-xTR | 127 | / \ / \ | 128 | / \ / \ | 129 | / \ / \ | 130 | / \ / \ | 131 | EIDs ... EIDs EIDs ... EIDs | 132 | | 133 +--------------------------------------------------------------+ 135 Overlay on Earth, Underlay in Space 137 The LISP mapping system runs on the earth-resident Internet and 138 requires reachability by xTRs before LISP encapsulation can occur 139 over the satellite network underlay. 141 EIDs are known only to the overlay xTR nodes. EIDs are not routable 142 or require state in the satellite network. This provides great value 143 for scaling and EID mobility. 145 2. Definition of Terms 147 Inter-Satellite-Links (ISLs): are phased-array laser wireless links 148 that transmit within or across orbits in space to other 149 satellites. They are different than satellite downlinks which are 150 RF links to Ground-Stations. 152 xTR: is a LISP data-plane device. xTR is the general term for ITR, 153 ETR, or RTR. The formal and authoritative definition is in 154 [I-D.ietf-lisp-rfc6830bis]. When a LISP xTR runs on a ground 155 station device, it is called a GS-xTR. 157 Ground-Station (GS): is a device on the ground that has wireless 158 links to a satellite node in space 159 [I-D.lhan-problems-requirements-satellite-net]. When a Ground- 160 Station is an LISP xTR, it encapsulates and decapsulates packets 161 sent and received on satellite links according to the forwarding 162 procedures in [I-D.ietf-lisp-rfc6830bis] and 163 [I-D.ietf-lisp-rfc6833bis]. A GS can also be part of the 164 satellite network system but isn't deployed as a GS-xTR. In this 165 scenario, the GS is part of the underlay and assumes the satellite 166 network system, with its attached ground stations, deliver RLOC 167 addressed packets. When a satellite is in relay mode (not using 168 ISLs), a LISP RTR can be used to support traffic engineering where 169 a GS-ITR encapsulates through a single satellite hop to a GS-RTR 170 which decapsulates and re-encapsulates through another single 171 satellite hop to a GS-ETR. See [I-D.ietf-lisp-te] for details, 172 and how LISP-TE can also be used with multiple satellite hops. 174 source-GS-xTR: is the LISP ITR which does a mapping system lookup to 175 obtain and cache the destination-RLOC for the destination-EID. It 176 then encapsulates the packet and sends it on the uplink whatever 177 satellite that is in coverage range. 179 destination-GS-xTR: is the LISP ETR which receives a LISP 180 encapsulated packet on the downlink from the satellite that is in 181 coverage range over it. The outer header is stripped and packet 182 is delivered to local EID on the ground. 184 EID: defined as an Endpoint-ID in [I-D.ietf-lisp-rfc6830bis]. An 185 EID is assigned to devices that reside behind GS-xTRs and are 186 registered to the LISP mapping system with a satellite network 187 address which is used as an RLOC. 189 RLOC: defined as a Routing Locator in [I-D.ietf-lisp-rfc6830bis]. 190 Within the scope of this specification, the RLOC is the satellite 191 network address of a GS-xTR where the satellite network knows how 192 to forward packets to this RLOC address. 194 3. Overview 196 Here is how a packet flow sequence occurs from a source-EID to a 197 destination-EID when the underlay is a satellite network: 199 1. source-EID originates an IP packet to a destination-EID. The 200 addresses in the packet are EIDs. 202 2. The packet travels to the GS-xTR (source-GS-xTR) via traditional 203 IP routing. 205 3. The source-GS-xTR does a map-cache lookup for destination-EID to 206 obtain the RLOC for the destination-GS-xTR. 208 4. If map-cache lookup fails, a mapping system lookup is performed 209 for destination-EID. 211 5. The source-GS-xTR LISP encapsulates the packet and sends it on 212 the uplink to the satellite. The RLOC addresses in the outer 213 header are source-GS-xTR and destination-GS-xTR. 215 6. The satellite network delivers the packet to Ground-Station 216 addressed as destination-GS-xTR. 218 7. The destination-GS-xTR decapsulates the LISP packet by stripping 219 the outer header and delivering the packet to the destination-EID 220 on the ground. 222 4. Mapping System 224 The LISP mapping system holds EID-to-RLOC-set mappings. They are 225 kept up to date by GS-xTRs and all the mechanisms from 226 [I-D.ietf-lisp-rfc6833bis] are available for use. The mappings can 227 contain RLOCs that are not GS-xTRs thereby allowing load-splitting 228 between both satellite and terrestrial paths. The RLOC-set can also 229 contain multicast RLOCs that can be reachable via satellite or 230 terrestrial paths. 232 All of IPv4, IPv6, and MAC EIDs can be registered to the mapping 233 system to create multi-address-family L3 overlays as well as L2 234 overlays on the satellite underlay. That is, GS-xTR RLOCs can be 235 used with these EID address types. 237 Since the satellite network is not required to carry all routes that 238 are earth-based, the LISP critical infrastructure will not be 239 reachable by satellite nodes. Therefore, the mapping system must be 240 earth-based so xTRs which are not GS-xTRs can register and lookup 241 mappings. Note the satellite network is only required to carry 242 routes for GS-xTR addresses. 244 When satellite connectivity changes from a GS-xTR within its coverage 245 range, the RLOC of the GS-xTR does not change. Therefore, there is 246 no need to update the mapping system when this happens. This 247 provides more scale to the total system since the LISP overlay is 248 providing a level of indirection. 250 5. EID Mobility 252 EID-mobility [I-D.ietf-lisp-eid-mobility] is supported so devices can 253 roam to other xTRs and are found by mapping system updates for remote 254 xTRs encapsulating to the EID. GS-xTRs learn EIDs on the ground 255 dynamically via the mechanisms in [I-D.ietf-lisp-eid-mobility]. 257 6. Satellite RLOCs and Underlay Routing 259 The address format of a GS-xTR RLOC depends on the design of the 260 satellite network system. The LISP RLOC formatting is flexible to 261 accommodate new address types such as GPS coordinate based addressing 262 or other forms of satellite addressing 263 [I-D.lhan-satellite-semantic-addressing]. The only requirement is 264 that they are routable by the satellite network system. 266 If the satellite network supports IP forwarding and IP addresses are 267 assigned to the RF-links on the GS-xTRs, then the satellite network 268 just needs to make these "attachment point addresses" routable in the 269 satellite network routing system. And if the satellite network 270 desires to scale the route state in its routing system, it can use 271 prefix aggregation, a local design matter to the satellite network 272 routing system. When this is the case, the RLOC is a standard AFI 273 encoded IPv4 or IPv6 address. 275 If the satellite network underlay supports a source-routing 276 mechanism, as suggested in [I-D.lhan-satellite-instructive-routing], 277 the same approach can be used as a LISP overlay on a terrestrial 278 underlay running Segment Routing [RFC8754]. The source-route is 279 encoded in an RLOC-record stored in the mapping system that is 280 formatted as a list of satellite hop addresses. 282 7. Underlay Performance 284 The RLOC probing procedures in [I-D.ietf-lisp-rfc6833bis] can provide 285 underlay telemetry measurement [I-D.farinacci-lisp-telemetry] so the 286 overlay can tell how well the satellite network is performing. And 287 if the underlay under performs or telemetry metrics change, the GS- 288 xTR can select another RLOC, possibly to a terrestrial RLOC. 290 8. Security Considerations 292 There are no specific security considerations at this time for this 293 use-case. However, existing LISP security functionality documented 294 in [I-D.ietf-lisp-rfc6833bis], [I-D.ietf-lisp-sec], 295 [I-D.ietf-lisp-eid-anonymity], and [I-D.farinacci-lisp-ecdsa-auth] 296 can be used when the LISP overlay runs over a satellite network 297 underlay. 299 Data-plane encryption can be used to make the satellite underlay more 300 secure. See LISP Data-Plane Confidentiality [RFC8061] for more 301 details. This solution can work when packets take multiple satellite 302 hops and/or Ground-Station hops. 304 9. IANA Considerations 306 There are no requests for IANA at this time. 308 10. References 310 10.1. Normative References 312 [I-D.ietf-lisp-rfc6830bis] 313 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 314 Cabellos, "The Locator/ID Separation Protocol (LISP)", 315 draft-ietf-lisp-rfc6830bis-36 (work in progress), November 316 2020. 318 [I-D.ietf-lisp-rfc6833bis] 319 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 320 "Locator/ID Separation Protocol (LISP) Control-Plane", 321 draft-ietf-lisp-rfc6833bis-30 (work in progress), November 322 2020. 324 [I-D.ietf-lisp-sec] 325 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 326 "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-25 (work 327 in progress), December 2021. 329 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 330 DOI 10.17487/RFC1700, October 1994, 331 . 333 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 334 (LISP) Data-Plane Confidentiality", RFC 8061, 335 DOI 10.17487/RFC8061, February 2017, 336 . 338 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 339 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 340 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 341 . 343 10.2. Informative References 345 [I-D.farinacci-lisp-ecdsa-auth] 346 Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA 347 Authentication and Authorization", draft-farinacci-lisp- 348 ecdsa-auth-03 (work in progress), September 2018. 350 [I-D.farinacci-lisp-mobile-network] 351 Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP 352 for the Mobile Network", draft-farinacci-lisp-mobile- 353 network-14 (work in progress), March 2022. 355 [I-D.farinacci-lisp-telemetry] 356 Farinacci, D., Ouissal, S., and E. Nordmark, "LISP Data- 357 Plane Telemetry", draft-farinacci-lisp-telemetry-07 (work 358 in progress), November 2021. 360 [I-D.haindl-lisp-gb-atn] 361 Haindl, B., Lindner, M., Moreno, V., Comeras, M. P., 362 Maino, F., and B. Venkatachalapathy, "Ground-Based LISP 363 for the Aeronautical Telecommunications Network", draft- 364 haindl-lisp-gb-atn-07 (work in progress), March 2022. 366 [I-D.ietf-lisp-eid-anonymity] 367 Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP 368 EID Anonymity", draft-ietf-lisp-eid-anonymity-12 (work in 369 progress), March 2022. 371 [I-D.ietf-lisp-eid-mobility] 372 Comeras, M. P., Ashtaputre, V., Maino, F., Moreno, V., and 373 D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified 374 Control Plane", draft-ietf-lisp-eid-mobility-09 (work in 375 progress), January 2022. 377 [I-D.ietf-lisp-te] 378 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 379 Engineering Use-Cases", draft-ietf-lisp-te-10 (work in 380 progress), March 2022. 382 [I-D.lhan-problems-requirements-satellite-net] 383 Han, L., Li, R., Retana, A., Chen, M., Su, L., and N. 384 Wang, "Problems and Requirements of Satellite 385 Constellation for Internet", draft-lhan-problems- 386 requirements-satellite-net-02 (work in progress), February 387 2022. 389 [I-D.lhan-satellite-instructive-routing] 390 Han, L., Retana, A., and R. Li, "Semantic Address Based 391 Instructive Routing for Satellite Network", draft-lhan- 392 satellite-instructive-routing-00 (work in progress), March 393 2022. 395 [I-D.lhan-satellite-semantic-addressing] 396 Han, L., Li, R., Retana, A., Chen, M., and N. Wang, 397 "Satellite Semantic Addressing for Satellite 398 Constellation", draft-lhan-satellite-semantic- 399 addressing-01 (work in progress), March 2022. 401 Appendix A. Acknowledgments 403 The authors would like to thank the LISP working group for their 404 review of this specification. A special thank you goes to Lin Han 405 for email discussions on this topic. 407 Appendix B. Document Change Log 409 B.1. Changes to draft-farinacci-lisp-satellite-network-00 411 o Initial posting April 2022. 413 Authors' Addresses 415 Dino Farinacci 416 lispers.net 417 San Jose, CA 418 USA 420 Email: farinacci@gmail.com 422 Victor Moreno 423 Independent 424 Mountain View, CA 425 USA 427 Email: victor@magooit.com 429 Padma Pillay-Esnault 430 Independent 431 Santa Clara, CA 432 USA 434 Email: padma.ietf@gmail.com