idnits 2.17.1 draft-rodrigueznatal-lisp-multi-tuple-eids-07.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 : ---------------------------------------------------------------------------- == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 240 has weird spacing: '...src-add pr ...' -- The document date (April 4, 2019) is 1820 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP-DHT' is mentioned on line 307, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-24 == Outdated reference: A later version (-14) exists of draft-ietf-lisp-te-03 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group A. Rodriguez-Natal 3 Internet-Draft Cisco Systems 4 Intended status: Experimental A. Cabellos-Aparicio 5 Expires: October 6, 2019 Technical University of Catalonia 6 S. Barkai 7 Nexar Inc. 8 V. Ermagan 9 Google 10 D. Lewis 11 F. Maino 12 Cisco Systems 13 D. Farinacci 14 lispers.net 15 April 4, 2019 17 LISP support for Multi-Tuple EIDs 18 draft-rodrigueznatal-lisp-multi-tuple-eids-07 20 Abstract 22 This document describes extensions for LISP to support EIDs based on 23 tuples of multiple elements. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 6, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 61 2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Protocol Operation with Extended-EIDs . . . . . . . . . . . . 4 64 4.1. LISP Tunnel Routers . . . . . . . . . . . . . . . . . . . 4 65 4.2. Mapping System . . . . . . . . . . . . . . . . . . . . . 4 66 5. Extended-EIDs Encoding . . . . . . . . . . . . . . . . . . . 5 67 5.1. 5-Tuple . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Extended-EID Lookups . . . . . . . . . . . . . . . . . . . . 5 69 6.1. 5-Tuple (Coarse) . . . . . . . . . . . . . . . . . . . . 5 70 6.2. 5-Tuple (Exact) . . . . . . . . . . . . . . . . . . . . . 6 71 7. Mapping Databases for Extended-EIDs . . . . . . . . . . . . . 7 72 7.1. 5-Tuple (Coarse) . . . . . . . . . . . . . . . . . . . . 7 73 7.2. 5-Tuple (Exact) . . . . . . . . . . . . . . . . . . . . . 7 74 8. A Note on Instance-ID . . . . . . . . . . . . . . . . . . . . 7 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 12. Normative References . . . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 This document describes how LISP handles lookups based on Extended- 84 EIDs, i.e. tuples of n elements. Particularly it describes how the 85 Tunnel Routers and the Mapping System operate when Extended-EIDs are 86 in place, the different types of Extended-EIDs defined so far, how 87 the lookup is performed for each Extended-EID type and which mapping 88 databases are recommended to use depending on the kind of Extended- 89 EIDs used. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Definition of terms 99 o n-tuple: The term n-tuple is used in this document to describe the 100 set of n elements present in a data packet (e.g. IP address, 101 port, protocol) that can be used to identify unequivocally a 102 packet or a set of packets. 104 o 5-tuple: The term 5-tuple is used in this document to describe the 105 set comprised by 5 elements, being these the source IP address, 106 the destination IP address, the level 4 protocol number, the level 107 4 protocol source port and the level 4 protocol destination port 108 of a data packet. 110 o Extended-EID: This document uses the term Extended-EID to refer to 111 any n-tuple (including a 5-tuple) used in a EID role. See as well 112 [RFC8111] 114 o Flow: The term flow is used in this document to refer to the 115 sequence of packets identified by the same n-tuple. 117 o MT-[xTR, RTR, MS, MR]: A LISP [xTR, RTR, MS, MR] that supports the 118 enhanced operation for Multi-Tuple Extended-EIDs described in this 119 document. 121 o MT-TR: A LISP tunnel router (e.g. xTR, RTR) that supports the 122 enhanced operation for Multi-Tuple Extended-EIDs described in this 123 document, e.g. MT-xTR, MT-RTR. 125 The rest of the terms are defined in their respective documents. See 126 the LISP specification [I-D.ietf-lisp-rfc6833bis] for most of the 127 definitions, [RFC8060] for LCAF and [I-D.ietf-lisp-te] for RTR. 129 3. Overview 131 This document describes extensions for LISP to support Multi-Tuple 132 Extended-EIDs. Protocol operation follows the specification defined 133 on [I-D.ietf-lisp-rfc6833bis] except for the following. Besides of 134 IP mappings, a Mapping System can store Extended-EID mappings. Being 135 Extended-EID a n-tuple identifying a flow. LISP routers perform 136 look-ups based on these Extended-EIDs, instead of on destination IPs. 137 Apart from using n-tuples instead of IPs, retrieving information from 138 the Mapping System follows LISP standard mechanisms (i.e. Map- 139 Request, Map-Reply). 141 4. Protocol Operation with Extended-EIDs 143 4.1. LISP Tunnel Routers 145 LISP tunnel routers with enhanced operation for Multi-Tuple Extended- 146 EIDs, or MT-TRs (MT-xTRs and MT-RTRs), behave as specified on and 147 [I-D.ietf-lisp-rfc6833bis], with the particularity that MT-TRs 148 perform mapping lookups based on Extended-EIDs (n-tuples). 150 Any MT-TR must keep an internal map-cache indexed by Extended-EIDs. 151 When a MT-TR receives a packet to encapsulate, it extracts the fields 152 required by the n-tuple lookup in use and stores them in an Extended- 153 EID structure. In the case of a 5-tuple lookup, it will extract the 154 source address, destination address, level 4 protocol, source port 155 (if any) and destination port (if any) from the packet. The MT-TR 156 uses the Extended-EID to perform a look-up into the map-cache. The 157 lookup process must follow the procedure described in section 158 Section 6. If there is an entry on the map-cache that matches the 159 Extended-EID, the MT-TR retrieves the mapping information, selects a 160 destination RLOC and encapsulates the packet, as defined in 161 [I-D.ietf-lisp-rfc6833bis] 163 If the map-cache of the MT-TR contains no entry for the Extended-EID, 164 the MT-TR sends a Map-Request to a MT-MR. The MT-TR MUST be 165 provisioned with the RLOC of at least one MT-MR. The Map-Request 166 sent carries the Extended-EID (encoded in the specific LCAF for that 167 Extended-EID type) in the EID-prefix field of the Map-Request. This 168 Map-Request will eventually trigger a Map-Reply to be sent back the 169 requester MT-TR, see section Section 4.2. This Map-Reply carries an 170 Extended-EID on the EID-prefix field. The MT-TR stores, as defined 171 in [I-D.ietf-lisp-rfc6833bis], the mapping for the Extended-EID. 173 4.2. Mapping System 175 Mapping System elements (comprising Map Servers and Map Resolvers) 176 behave as specified on [I-D.ietf-lisp-rfc6833bis] when implementing 177 enhanced Multi-Tuple Extended-EIDs operation, with the particularity 178 that MT-MRs resolve Map-Requests based on Extended-EIDs and MT-MSs 179 store mappings indexed by Extended-EIDs. 181 MT-MRs must be capable of processing Map-Requests with an Extended- 182 EID on the EID-prefix field, of finding the appropriate MT-MS for the 183 Extended-EID and of forwarding the Map-Request to it. This is done 184 according to the lookup rules described in section Section 6 and 185 using the mapping database described in section Section 7 which 186 differs depending on the specific Extended-EID. 188 LISP elements must perform the mapping update mechanisms defined in 189 [I-D.ietf-lisp-rfc6833bis] (e.g, SMR) using as EID the Extended-EID. 191 5. Extended-EIDs Encoding 193 This section describes the Extended-EID types defined so far and the 194 LCAFs to support them. 196 5.1. 5-Tuple 198 The 5-tuple LCAF is a combination of Application Data Type 4 and 199 Source/Dest Type 12 LCAFs. Experimental deployment may indicate that 200 a specific 5-tuple type LCAF is necessary. 202 6. Extended-EID Lookups 204 This section describes the lookup process to be followed when using 205 Extended-EID. At this point, this document only covers 5-tuple kind 206 of Extended-EID lookups (with options for coarse or exact lookup). 207 It is expected to include lookup mechanism for n-tuple lookups with 208 more complex protocol combinations. 210 6.1. 5-Tuple (Coarse) 212 When using a coarse lookup for 5-tuple, the encoding described in 213 Section 5.1 is used to carry the Extended-EID. Note that a coarse 214 lookup also covers exact lookups. The lookup is (logically) done at 215 steps, one per each element of the tuple. The lookup MUST follow 216 this strict order: 218 (1) Destination address 220 (2) Source address 222 (3) Protocol number 224 (4) Destination port 226 (5) Source port 228 This means that for a given 5-tuple, the lookup process will first 229 select from the available 5-tuples present in the system, the ones 230 that match the destination address. Among them, those that also 231 match the source address. This is iterated for the rest of the 232 elements in the tuple. If a 5-tuple matches several entries, then 233 the one with the longest prefix match or shortest port-range has 234 priority. To clarify the process an example is provided below. 236 Suppose that a MT-MS stores the mappings indexed by the tuples (A), 237 (B), (C), (D) and (E), and that it receives Map-Request messages 238 carrying the Extended-EIDs (T), (U), (V), (W), (X) and (Y). 240 dst-add src-add pr dst-prt src-prt 242 (A) [1.1.1.0/24, 2.2.0.0/16, 17, 1000-3000, 1000-3000] 243 (B) [1.1.0.0/16, 2.2.2.0/24, 17, 1000-3000, 1000-3000] 244 (C) [3.3.3.0/24, 4.4.4.0/24, 6, 4000-4500, 7000-8000] 245 (D) [3.3.3.0/24, 4.4.4.0/24, 6, 4000-6000, 7000-8000] 246 (E) [5.5.5.0/24, 6.6.6.0/24, 17, 0-65535, 0-65535] 248 (T) [ 1.1.1.8, 2.2.2.9, 17, 2000, 2000 ] 249 (U) [ 1.1.8.8, 2.2.9.9, 17, 2000, 2000 ] 250 (V) [ 1.1.8.8, 2.2.2.9, 17, 2000, 2000 ] 251 (W) [ 3.3.3.3, 4.4.4.4, 6, 4300, 7500 ] 252 (X) [ 3.3.3.3, 4.4.4.4, 6, 5000, 7500 ] 253 (Y) [ 5.5.5.5, 6.6.6.6, 17, 6000, 6000 ] 255 5-tuple example for coarse lookup 257 (1) When (T) is Map-Requested, the lookup could match both (A) and 258 (B), however destination address has preference over source 259 address and therefore (A) is returned. 261 (2) When (U) is Map-Requested, the lookup will return that no entry 262 exists for the 5-tuple. 264 (3) When (V) is Map-Requested, the lookup will return (B). 266 (4) When (W) is Map-Requested, the lookup will return (C) and not 267 (D), although both could match the tuple, since the destination 268 port range is shorter in (C). 270 (5) When (X) is Map-Requested, the lookup will return (D). 272 (6) When (Y) is Map-Requested, the lookup will return (E). A port 273 range of 0-65535 means any port. 275 6.2. 5-Tuple (Exact) 277 In scenarios where 5-tuple coarse lookup is not required, the lookup 278 can be optimized to only account for exact matchs. When using a 279 exact lookup for 5-tuple, the encoding described in Section 6.1 is 280 used to carry the Extended-EID. The exact match lookup is performed 281 by serializing the elements of the 5-tuple as a single vector of 282 bits. The order to serialize the elements is the same that is 283 described in Section 5.1 This (unique) vector of bits is then used as 284 the key to perform a exact match lookup over the available entries. 286 7. Mapping Databases for Extended-EIDs 288 The mapping database, i.e. the system to interconnect (MT-)MRs and 289 (MT-)MSs should be optimal for each one of the different Extended- 290 EIDs types. This section covers recommended mapping databases for 291 each of the Extended-EIDs described in this document. 293 7.1. 5-Tuple (Coarse) 295 The mapping database to be used for a coarse lookup of 5-tuples can 296 leverage on the LISP-DDT mapping database [RFC8111] since it supports 297 multi-tuple lookups. Note that a LISP-DDT based database can support 298 also a exact lookup. 300 7.2. 5-Tuple (Exact) 302 Although a LISP-DDT based mapping database supports both coarse and 303 exact lookups, the particularities of the latter benefit of using a 304 mapping database optimized for flat namespaces rather than one 305 optimized for hierarchical data. In that sense, the exact match 306 mechanism should be supported by a DHT-like mapping database, such 307 [I-D.cheng-lisp-shdht] or [LISP-DHT]. 309 8. A Note on Instance-ID 311 Instance-ID is a special case to be considered. If it is in use, its 312 lookup is resolved before the lookup for the Extended-EID begins 313 (regardless of the Extended-EID type). In terms of implementation 314 this means that if the Instance-ID is present, it will have always 315 more priority that any other field within the multi-tuple EID. In 316 other words, Instance-ID is the high-order parts of the destination 317 and source addresses and a longest match lookup should be applied to 318 it before looking up the address itself. 320 9. Acknowledgments 322 10. IANA Considerations 324 This memo includes no request to IANA. 326 11. Security Considerations 328 Security Considerations TBD 330 12. Normative References 332 [I-D.cheng-lisp-shdht] 333 Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping 334 Overlay", draft-cheng-lisp-shdht-04 (work in progress), 335 July 2013. 337 [I-D.ietf-lisp-rfc6833bis] 338 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 339 "Locator/ID Separation Protocol (LISP) Control-Plane", 340 draft-ietf-lisp-rfc6833bis-24 (work in progress), February 341 2019. 343 [I-D.ietf-lisp-te] 344 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 345 Engineering Use-Cases", draft-ietf-lisp-te-03 (work in 346 progress), October 2018. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, 350 DOI 10.17487/RFC2119, March 1997, 351 . 353 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 354 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 355 February 2017, . 357 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 358 Smirnov, "Locator/ID Separation Protocol Delegated 359 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 360 May 2017, . 362 Authors' Addresses 364 Alberto Rodriguez-Natal 365 Cisco Systems 366 170 Tasman Drive 367 San Jose, CA 368 USA 370 Email: natal@cisco.com 371 Albert Cabellos-Aparicio 372 Technical University of Catalonia 373 Barcelona 374 Spain 376 Email: acabello@ac.upc.edu 378 Sharon Barkai 379 Nexar Inc. 380 CA 381 USA 383 Email: sharon.barkai@getnexar.com 385 Vina Ermagan 386 Google 387 USA 389 Email: ermagan@gmail.com 391 Darrel Lewis 392 Cisco Systems 393 170 Tasman Drive 394 San Jose, CA 395 USA 397 Email: darlewis@cisco.com 399 Fabio Maino 400 Cisco Systems 401 170 Tasman Drive 402 San Jose, CA 403 USA 405 Email: fmaino@cisco.com 407 Dino Farinacci 408 lispers.net 409 San Jose, CA 410 USA 412 Email: farinacci@gmail.com