idnits 2.17.1 draft-rodrigueznatal-lisp-multi-tuple-eids-06.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 239 has weird spacing: '...src-add pr ...' -- The document date (October 1, 2018) is 2033 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP-DHT' is mentioned on line 306, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-15 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-te-02 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: April 4, 2019 Technical University of Catalonia 6 S. Barkai 7 Fermi Serverless 8 V. Ermagan 9 D. Lewis 10 F. Maino 11 Cisco Systems 12 D. Farinacci 13 lispers.net 14 October 1, 2018 16 LISP support for Multi-Tuple EIDs 17 draft-rodrigueznatal-lisp-multi-tuple-eids-06 19 Abstract 21 This document describes extensions for LISP to support EIDs based on 22 tuples of multiple elements. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 4, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 60 2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Protocol Operation with Extended-EIDs . . . . . . . . . . . . 4 63 4.1. LISP Tunnel Routers . . . . . . . . . . . . . . . . . . . 4 64 4.2. Mapping System . . . . . . . . . . . . . . . . . . . . . 4 65 5. Extended-EIDs Encoding . . . . . . . . . . . . . . . . . . . 5 66 5.1. 5-Tuple . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Extended-EID Lookups . . . . . . . . . . . . . . . . . . . . 5 68 6.1. 5-Tuple (Coarse) . . . . . . . . . . . . . . . . . . . . 5 69 6.2. 5-Tuple (Exact) . . . . . . . . . . . . . . . . . . . . . 6 70 7. Mapping Databases for Extended-EIDs . . . . . . . . . . . . . 7 71 7.1. 5-Tuple (Coarse) . . . . . . . . . . . . . . . . . . . . 7 72 7.2. 5-Tuple (Exact) . . . . . . . . . . . . . . . . . . . . . 7 73 8. A Note on Instance-ID . . . . . . . . . . . . . . . . . . . . 7 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 12. Normative References . . . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 This document describes how LISP handles lookups based on Extended- 83 EIDs, i.e. tuples of n elements. Particularly it describes how the 84 Tunnel Routers and the Mapping System operate when Extended-EIDs are 85 in place, the different types of Extended-EIDs defined so far, how 86 the lookup is performed for each Extended-EID type and which mapping 87 databases are recommended to use depending on the kind of Extended- 88 EIDs used. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. Definition of terms 98 o n-tuple: The term n-tuple is used in this document to describe the 99 set of n elements present in a data packet (e.g. IP address, 100 port, protocol) that can be used to identify unequivocally a 101 packet or a set of packets. 103 o 5-tuple: The term 5-tuple is used in this document to describe the 104 set comprised by 5 elements, being these the source IP address, 105 the destination IP address, the level 4 protocol number, the level 106 4 protocol source port and the level 4 protocol destination port 107 of a data packet. 109 o Extended-EID: This document uses the term Extended-EID to refer to 110 any n-tuple (including a 5-tuple) used in a EID role. See as well 111 [RFC8111] 113 o Flow: The term flow is used in this document to refer to the 114 sequence of packets identified by the same n-tuple. 116 o MT-[xTR, RTR, MS, MR]: A LISP [xTR, RTR, MS, MR] that supports the 117 enhanced operation for Multi-Tuple Extended-EIDs described in this 118 document. 120 o MT-TR: A LISP tunnel router (e.g. xTR, RTR) that supports the 121 enhanced operation for Multi-Tuple Extended-EIDs described in this 122 document, e.g. MT-xTR, MT-RTR. 124 The rest of the terms are defined in their respective documents. See 125 the LISP specification [I-D.ietf-lisp-rfc6833bis] for most of the 126 definitions, [RFC8060] for LCAF and [I-D.ietf-lisp-te] for RTR. 128 3. Overview 130 This document describes extensions for LISP to support Multi-Tuple 131 Extended-EIDs. Protocol operation follows the specification defined 132 on [I-D.ietf-lisp-rfc6833bis] except for the following. Besides of 133 IP mappings, a Mapping System can store Extended-EID mappings. Being 134 Extended-EID a n-tuple identifying a flow. LISP routers perform 135 look-ups based on these Extended-EIDs, instead of on destination IPs. 136 Apart from using n-tuples instead of IPs, retrieving information from 137 the Mapping System follows LISP standard mechanisms (i.e. Map- 138 Request, Map-Reply). 140 4. Protocol Operation with Extended-EIDs 142 4.1. LISP Tunnel Routers 144 LISP tunnel routers with enhanced operation for Multi-Tuple Extended- 145 EIDs, or MT-TRs (MT-xTRs and MT-RTRs), behave as specified on and 146 [I-D.ietf-lisp-rfc6833bis], with the particularity that MT-TRs 147 perform mapping lookups based on Extended-EIDs (n-tuples). 149 Any MT-TR must keep an internal map-cache indexed by Extended-EIDs. 150 When a MT-TR receives a packet to encapsulate, it extracts the fields 151 required by the n-tuple lookup in use and stores them in an Extended- 152 EID structure. In the case of a 5-tuple lookup, it will extract the 153 source address, destination address, level 4 protocol, source port 154 (if any) and destination port (if any) from the packet. The MT-TR 155 uses the Extended-EID to perform a look-up into the map-cache. The 156 lookup process must follow the procedure described in section 157 Section 6. If there is an entry on the map-cache that matches the 158 Extended-EID, the MT-TR retrieves the mapping information, selects a 159 destination RLOC and encapsulates the packet, as defined in 160 [I-D.ietf-lisp-rfc6833bis] 162 If the map-cache of the MT-TR contains no entry for the Extended-EID, 163 the MT-TR sends a Map-Request to a MT-MR. The MT-TR MUST be 164 provisioned with the RLOC of at least one MT-MR. The Map-Request 165 sent carries the Extended-EID (encoded in the specific LCAF for that 166 Extended-EID type) in the EID-prefix field of the Map-Request. This 167 Map-Request will eventually trigger a Map-Reply to be sent back the 168 requester MT-TR, see section Section 4.2. This Map-Reply carries an 169 Extended-EID on the EID-prefix field. The MT-TR stores, as defined 170 in [I-D.ietf-lisp-rfc6833bis], the mapping for the Extended-EID. 172 4.2. Mapping System 174 Mapping System elements (comprising Map Servers and Map Resolvers) 175 behave as specified on [I-D.ietf-lisp-rfc6833bis] when implementing 176 enhanced Multi-Tuple Extended-EIDs operation, with the particularity 177 that MT-MRs resolve Map-Requests based on Extended-EIDs and MT-MSs 178 store mappings indexed by Extended-EIDs. 180 MT-MRs must be capable of processing Map-Requests with an Extended- 181 EID on the EID-prefix field, of finding the appropriate MT-MS for the 182 Extended-EID and of forwarding the Map-Request to it. This is done 183 according to the lookup rules described in section Section 6 and 184 using the mapping database described in section Section 7 which 185 differs depending on the specific Extended-EID. 187 LISP elements must perform the mapping update mechanisms defined in 188 [I-D.ietf-lisp-rfc6833bis] (e.g, SMR) using as EID the Extended-EID. 190 5. Extended-EIDs Encoding 192 This section describes the Extended-EID types defined so far and the 193 LCAFs to support them. 195 5.1. 5-Tuple 197 The 5-tuple LCAF is a combination of Application Data Type 4 and 198 Source/Dest Type 12 LCAFs. Experimental deployment may indicate that 199 a specific 5-tuple type LCAF is necessary. 201 6. Extended-EID Lookups 203 This section describes the lookup process to be followed when using 204 Extended-EID. At this point, this document only covers 5-tuple kind 205 of Extended-EID lookups (with options for coarse or exact lookup). 206 It is expected to include lookup mechanism for n-tuple lookups with 207 more complex protocol combinations. 209 6.1. 5-Tuple (Coarse) 211 When using a coarse lookup for 5-tuple, the encoding described in 212 Section 5.1 is used to carry the Extended-EID. Note that a coarse 213 lookup also covers exact lookups. The lookup is (logically) done at 214 steps, one per each element of the tuple. The lookup MUST follow 215 this strict order: 217 (1) Destination address 219 (2) Source address 221 (3) Protocol number 223 (4) Destination port 225 (5) Source port 227 This means that for a given 5-tuple, the lookup process will first 228 select from the available 5-tuples present in the system, the ones 229 that match the destination address. Among them, those that also 230 match the source address. This is iterated for the rest of the 231 elements in the tuple. If a 5-tuple matches several entries, then 232 the one with the longest prefix match or shortest port-range has 233 priority. To clarify the process an example is provided below. 235 Suppose that a MT-MS stores the mappings indexed by the tuples (A), 236 (B), (C), (D) and (E), and that it receives Map-Request messages 237 carrying the Extended-EIDs (T), (U), (V), (W), (X) and (Y). 239 dst-add src-add pr dst-prt src-prt 241 (A) [1.1.1.0/24, 2.2.0.0/16, 17, 1000-3000, 1000-3000] 242 (B) [1.1.0.0/16, 2.2.2.0/24, 17, 1000-3000, 1000-3000] 243 (C) [3.3.3.0/24, 4.4.4.0/24, 6, 4000-4500, 7000-8000] 244 (D) [3.3.3.0/24, 4.4.4.0/24, 6, 4000-6000, 7000-8000] 245 (E) [5.5.5.0/24, 6.6.6.0/24, 17, 0-65535, 0-65535] 247 (T) [ 1.1.1.8, 2.2.2.9, 17, 2000, 2000 ] 248 (U) [ 1.1.8.8, 2.2.9.9, 17, 2000, 2000 ] 249 (V) [ 1.1.8.8, 2.2.2.9, 17, 2000, 2000 ] 250 (W) [ 3.3.3.3, 4.4.4.4, 6, 4300, 7500 ] 251 (X) [ 3.3.3.3, 4.4.4.4, 6, 5000, 7500 ] 252 (Y) [ 5.5.5.5, 6.6.6.6, 17, 6000, 6000 ] 254 5-tuple example for coarse lookup 256 (1) When (T) is Map-Requested, the lookup could match both (A) and 257 (B), however destination address has preference over source 258 address and therefore (A) is returned. 260 (2) When (U) is Map-Requested, the lookup will return that no entry 261 exists for the 5-tuple. 263 (3) When (V) is Map-Requested, the lookup will return (B). 265 (4) When (W) is Map-Requested, the lookup will return (C) and not 266 (D), although both could match the tuple, since the destination 267 port range is shorter in (C). 269 (5) When (X) is Map-Requested, the lookup will return (D). 271 (6) When (Y) is Map-Requested, the lookup will return (E). A port 272 range of 0-65535 means any port. 274 6.2. 5-Tuple (Exact) 276 In scenarios where 5-tuple coarse lookup is not required, the lookup 277 can be optimized to only account for exact matchs. When using a 278 exact lookup for 5-tuple, the encoding described in Section 6.1 is 279 used to carry the Extended-EID. The exact match lookup is performed 280 by serializing the elements of the 5-tuple as a single vector of 281 bits. The order to serialize the elements is the same that is 282 described in Section 5.1 This (unique) vector of bits is then used as 283 the key to perform a exact match lookup over the available entries. 285 7. Mapping Databases for Extended-EIDs 287 The mapping database, i.e. the system to interconnect (MT-)MRs and 288 (MT-)MSs should be optimal for each one of the different Extended- 289 EIDs types. This section covers recommended mapping databases for 290 each of the Extended-EIDs described in this document. 292 7.1. 5-Tuple (Coarse) 294 The mapping database to be used for a coarse lookup of 5-tuples can 295 leverage on the LISP-DDT mapping database [RFC8111] since it supports 296 multi-tuple lookups. Note that a LISP-DDT based database can support 297 also a exact lookup. 299 7.2. 5-Tuple (Exact) 301 Although a LISP-DDT based mapping database supports both coarse and 302 exact lookups, the particularities of the latter benefit of using a 303 mapping database optimized for flat namespaces rather than one 304 optimized for hierarchical data. In that sense, the exact match 305 mechanism should be supported by a DHT-like mapping database, such 306 [I-D.cheng-lisp-shdht] or [LISP-DHT]. 308 8. A Note on Instance-ID 310 Instance-ID is a special case to be considered. If it is in use, its 311 lookup is resolved before the lookup for the Extended-EID begins 312 (regardless of the Extended-EID type). In terms of implementation 313 this means that if the Instance-ID is present, it will have always 314 more priority that any other field within the multi-tuple EID. In 315 other words, Instance-ID is the high-order parts of the destination 316 and source addresses and a longest match lookup should be applied to 317 it before looking up the address itself. 319 9. Acknowledgments 321 10. IANA Considerations 323 This memo includes no request to IANA. 325 11. Security Considerations 327 Security Considerations TBD 329 12. Normative References 331 [I-D.cheng-lisp-shdht] 332 Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping 333 Overlay", draft-cheng-lisp-shdht-04 (work in progress), 334 July 2013. 336 [I-D.ietf-lisp-rfc6833bis] 337 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 338 "Locator/ID Separation Protocol (LISP) Control-Plane", 339 draft-ietf-lisp-rfc6833bis-15 (work in progress), 340 September 2018. 342 [I-D.ietf-lisp-te] 343 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 344 Engineering Use-Cases", draft-ietf-lisp-te-02 (work in 345 progress), April 2018. 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, 349 DOI 10.17487/RFC2119, March 1997, 350 . 352 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 353 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 354 February 2017, . 356 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 357 Smirnov, "Locator/ID Separation Protocol Delegated 358 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 359 May 2017, . 361 Authors' Addresses 363 Alberto Rodriguez-Natal 364 Cisco Systems 365 170 Tasman Drive 366 San Jose, CA 367 USA 369 Email: natal@cisco.com 370 Albert Cabellos-Aparicio 371 Technical University of Catalonia 372 Barcelona 373 Spain 375 Email: acabello@ac.upc.edu 377 Sharon Barkai 378 Fermi Serverless 379 CA 380 USA 382 Email: sharon@fermicloud.io 384 Vina Ermagan 385 Cisco Systems 386 170 Tasman Drive 387 San Jose, CA 388 USA 390 Email: vermagan@cisco.com 392 Darrel Lewis 393 Cisco Systems 394 170 Tasman Drive 395 San Jose, CA 396 USA 398 Email: darlewis@cisco.com 400 Fabio Maino 401 Cisco Systems 402 170 Tasman Drive 403 San Jose, CA 404 USA 406 Email: fmaino@cisco.com 407 Dino Farinacci 408 lispers.net 409 San Jose, CA 410 USA 412 Email: farinacci@gmail.com