idnits 2.17.1 draft-rodrigueznatal-lisp-multi-tuple-eids-03.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 238 has weird spacing: '...src-add pr ...' -- The document date (April 4, 2017) is 2569 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP-DHT' is mentioned on line 305, but not defined ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 4 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, 2017 Technical University of Catalonia 6 S. Barkai 7 Hewlett Packard Enterprise 8 V. Ermagan 9 D. Lewis 10 F. Maino 11 Cisco Systems 12 D. Farinacci 13 lispers.net 14 April 4, 2017 16 LISP support for Multi-Tuple EIDs 17 draft-rodrigueznatal-lisp-multi-tuple-eids-03 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 http://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 October 6, 2017. 41 Copyright Notice 43 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . 7 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 [I-D.ietf-lisp-ddt] 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 [RFC6830] for most of the definitions, 126 [RFC8060] for LCAF and [I-D.farinacci-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 [RFC6830] except for the following. Besides of IP mappings, a 133 Mapping System can store Extended-EID mappings. Being Extended-EID a 134 n-tuple identifying a flow. LISP routers perform look-ups based on 135 these Extended-EIDs, instead of on destination IPs. Apart from using 136 n-tuples instead of IPs, retrieving information from the Mapping 137 System follows LISP standard mechanisms (i.e. Map-Request, Map- 138 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 146 [RFC6830] and [RFC6833], with the particularity that MT-TRs perform 147 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 [RFC6830] 161 If the map-cache of the MT-TR contains no entry for the Extended-EID, 162 the MT-TR sends a Map-Request to a MT-MR. The MT-TR MUST be 163 provisioned with the RLOC of at least one MT-MR. The Map-Request 164 sent carries the Extended-EID (encoded in the specific LCAF for that 165 Extended-EID type) in the EID-prefix field of the Map-Request. This 166 Map-Request will eventually trigger a Map-Reply to be sent back the 167 requester MT-TR, see section Section 4.2. This Map-Reply carries an 168 Extended-EID on the EID-prefix field. The MT-TR stores, as defined 169 in [RFC6830], the mapping for the Extended-EID. 171 4.2. Mapping System 173 Mapping System elements (comprising Map Servers and Map Resolvers) 174 behave as specified on [RFC6830] and [RFC6833] when implementing 175 enhanced Multi-Tuple Extended-EIDs operation, with the particularity 176 that MT-MRs resolve Map-Requests based on Extended-EIDs and MT-MSs 177 store mappings indexed by Extended-EIDs. 179 MT-MRs must be capable of processing Map-Requests with an Extended- 180 EID on the EID-prefix field, of finding the appropriate MT-MS for the 181 Extended-EID and of forwarding the Map-Request to it. This is done 182 according to the lookup rules described in section Section 6 and 183 using the mapping database described in section Section 7 which 184 differs depending on the specific Extended-EID. 186 LISP elements must perform the mapping update mechanisms defined in 187 [RFC6830] (e.g, SMR) using as EID the Extended-EID. 189 5. Extended-EIDs Encoding 191 This section describes the Extended-EID types defined so far and the 192 LCAFs to support them. 194 5.1. 5-Tuple 196 The 5-tuple LCAF is a combination of Application Data Type 4 and 197 Source/Dest Type 12 LCAFs. Experimental deployment may indicate that 198 a specific 5-tuple type LCAF is necessary. 200 6. Extended-EID Lookups 202 This section describes the lookup process to be followed when using 203 Extended-EID. At this point, this document only covers 5-tuple kind 204 of Extended-EID lookups (with options for coarse or exact lookup). 205 It is expected to include lookup mechanism for n-tuple lookups with 206 more complex protocol combinations. 208 6.1. 5-Tuple (Coarse) 210 When using a coarse lookup for 5-tuple, the encoding described in 211 Section 5.1 is used to carry the Extended-EID. Note that a coarse 212 lookup also covers exact lookups. The lookup is (logically) done at 213 steps, one per each element of the tuple. The lookup MUST follow 214 this strict order: 216 (1) Destination address 218 (2) Source address 220 (3) Protocol number 222 (4) Destination port 224 (5) Source port 226 This means that for a given 5-tuple, the lookup process will first 227 select from the available 5-tuples present in the system, the ones 228 that match the destination address. Among them, those that also 229 match the source address. This is iterated for the rest of the 230 elements in the tuple. If a 5-tuple matches several entries, then 231 the one with the longest prefix match or shortest port-range has 232 priority. To clarify the process an example is provided below. 234 Suppose that a MT-MS stores the mappings indexed by the tuples (A), 235 (B), (C), (D) and (E), and that it receives Map-Request messages 236 carrying the Extended-EIDs (T), (U), (V), (W), (X) and (Y). 238 dst-add src-add pr dst-prt src-prt 240 (A) [1.1.1.0/24, 2.2.0.0/16, 17, 1000-3000, 1000-3000] 241 (B) [1.1.0.0/16, 2.2.2.0/24, 17, 1000-3000, 1000-3000] 242 (C) [3.3.3.0/24, 4.4.4.0/24, 6, 4000-4500, 7000-8000] 243 (D) [3.3.3.0/24, 4.4.4.0/24, 6, 4000-6000, 7000-8000] 244 (E) [5.5.5.0/24, 6.6.6.0/24, 17, 0-65535, 0-65535] 246 (T) [ 1.1.1.8, 2.2.2.9, 17, 2000, 2000 ] 247 (U) [ 1.1.8.8, 2.2.9.9, 17, 2000, 2000 ] 248 (V) [ 1.1.8.8, 2.2.2.9, 17, 2000, 2000 ] 249 (W) [ 3.3.3.3, 4.4.4.4, 6, 4300, 7500 ] 250 (X) [ 3.3.3.3, 4.4.4.4, 6, 5000, 7500 ] 251 (Y) [ 5.5.5.5, 6.6.6.6, 17, 6000, 6000 ] 253 5-tuple example for coarse lookup 255 (1) When (T) is Map-Requested, the lookup could match both (A) and 256 (B), however destination address has preference over source 257 address and therefore (A) is returned. 259 (2) When (U) is Map-Requested, the lookup will return that no entry 260 exists for the 5-tuple. 262 (3) When (V) is Map-Requested, the lookup will return (B). 264 (4) When (W) is Map-Requested, the lookup will return (C) and not 265 (D), although both could match the tuple, since the destination 266 port range is shorter in (C). 268 (5) When (X) is Map-Requested, the lookup will return (D). 270 (6) When (Y) is Map-Requested, the lookup will return (E). A port 271 range of 0-65535 means any port. 273 6.2. 5-Tuple (Exact) 275 In scenarios where 5-tuple coarse lookup is not required, the lookup 276 can be optimized to only account for exact matchs. When using a 277 exact lookup for 5-tuple, the encoding described in Section 6.1 is 278 used to carry the Extended-EID. The exact match lookup is performed 279 by serializing the elements of the 5-tuple as a single vector of 280 bits. The order to serialize the elements is the same that is 281 described in Section 5.1 This (unique) vector of bits is then used as 282 the key to perform a exact match lookup over the available entries. 284 7. Mapping Databases for Extended-EIDs 286 The mapping database, i.e. the system to interconnect (MT-)MRs and 287 (MT-)MSs should be optimal for each one of the different Extended- 288 EIDs types. This section covers recommended mapping databases for 289 each of the Extended-EIDs described in this document. 291 7.1. 5-Tuple (Coarse) 293 The mapping database to be used for a coarse lookup of 5-tuples can 294 leverage on the LISP-DDT mapping database [I-D.ietf-lisp-ddt] since 295 it supports multi-tuple lookups. Note that a LISP-DDT based database 296 can support also a exact lookup. 298 7.2. 5-Tuple (Exact) 300 Although a LISP-DDT based mapping database supports both coarse and 301 exact lookups, the particularities of the latter benefit of using a 302 mapping database optimized for flat namespaces rather than one 303 optimized for hierarchical data. In that sense, the exact match 304 mechanism should be supported by a DHT-like mapping database, such 305 [I-D.cheng-lisp-shdht] or [LISP-DHT]. 307 8. A Note on Instance-ID 309 Instance-ID is a special case to be considered. If it is in use, its 310 lookup is resolved before the lookup for the Extended-EID begins 311 (regardless of the Extended-EID type). In terms of implementation 312 this means that if the Instance-ID is present, it will have always 313 more priority that any other field within the multi-tuple EID. In 314 other words, Instance-ID is the high-order parts of the destination 315 and source addresses and a longest match lookup should be applied to 316 it before looking up the address itself. 318 9. Acknowledgments 320 10. IANA Considerations 322 This memo includes no request to IANA. 324 11. Security Considerations 326 Security Considerations TBD 328 12. Normative References 330 [I-D.cheng-lisp-shdht] 331 Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping 332 Overlay", draft-cheng-lisp-shdht-04 (work in progress), 333 July 2013. 335 [I-D.farinacci-lisp-te] 336 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 337 Engineering Use-Cases", draft-farinacci-lisp-te-12 (work 338 in progress), February 2017. 340 [I-D.ietf-lisp-ddt] 341 Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 342 Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- 343 ddt-09 (work in progress), January 2017. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 351 Locator/ID Separation Protocol (LISP)", RFC 6830, 352 DOI 10.17487/RFC6830, January 2013, 353 . 355 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 356 Protocol (LISP) Map-Server Interface", RFC 6833, 357 DOI 10.17487/RFC6833, January 2013, 358 . 360 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 361 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 362 February 2017, . 364 Authors' Addresses 366 Alberto Rodriguez-Natal 367 Cisco Systems 368 170 Tasman Drive 369 San Jose, CA 370 USA 372 Email: albrodr2@cisco.com 373 Albert Cabellos-Aparicio 374 Technical University of Catalonia 375 Barcelona 376 Spain 378 Email: acabello@ac.upc.edu 380 Sharon Barkai 381 Hewlett Packard Enterprise 382 3000 Hanover Street 383 Palo Alto, CA 384 USA 386 Email: sharon.barkai@hpe.com 388 Vina Ermagan 389 Cisco Systems 390 170 Tasman Drive 391 San Jose, CA 392 USA 394 Email: vermagan@cisco.com 396 Darrel Lewis 397 Cisco Systems 398 170 Tasman Drive 399 San Jose, CA 400 USA 402 Email: darlewis@cisco.com 404 Fabio Maino 405 Cisco Systems 406 170 Tasman Drive 407 San Jose, CA 408 USA 410 Email: fmaino@cisco.com 411 Dino Farinacci 412 lispers.net 413 San Jose, CA 414 USA 416 Email: farinacci@gmail.com