idnits 2.17.1 draft-rodrigueznatal-lisp-multi-tuple-eids-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 : ---------------------------------------------------------------------------- == There are 9 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 245 has weird spacing: '...src-add pr ...' -- The document date (July 5, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP-DHT' is mentioned on line 292, but not defined == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-08 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-03 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-10 ** 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 (~~), 7 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 A. Cabellos-Aparicio 4 Intended status: Experimental Technical University of Catalonia 5 Expires: January 6, 2016 S. Barkai 6 ConteXtream, Inc. 7 V. Ermagan 8 D. Lewis 9 F. Maino 10 Cisco Systems 11 D. Farinacci 12 lispers.net 13 July 5, 2015 15 LISP support for Multi-Tuple EIDs 16 draft-rodrigueznatal-lisp-multi-tuple-eids-00 18 Abstract 20 This document describes extensions for LISP to support EIDs based on 21 tuples of multiple elements. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 6, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 59 2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Protocol Operation with Extended-EIDs . . . . . . . . . . . . 4 62 4.1. LISP Tunnel Routers . . . . . . . . . . . . . . . . . . . 4 63 4.2. Mapping System . . . . . . . . . . . . . . . . . . . . . 4 64 5. Extended-EIDs Encoding . . . . . . . . . . . . . . . . . . . 5 65 5.1. 5-Tuple . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6. Extended-EID Lookups . . . . . . . . . . . . . . . . . . . . 5 67 6.1. 5-Tuple (Coarse) . . . . . . . . . . . . . . . . . . . . 5 68 6.2. 5-Tuple (Exact) . . . . . . . . . . . . . . . . . . . . . 6 69 7. Mapping Databases for Extended-EIDs . . . . . . . . . . . . . 6 70 7.1. 5-Tuple (Coarse) . . . . . . . . . . . . . . . . . . . . 7 71 7.2. 5-Tuple (Exact) . . . . . . . . . . . . . . . . . . . . . 7 72 8. A Note on Instance-ID . . . . . . . . . . . . . . . . . . . . 7 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 This document describes how LISP handles lookups based on Extended- 82 EIDs, i.e. tuples of n elements. Particularly it describes how the 83 Tunnel Routers and the Mapping System operate when Extended-EIDs are 84 in place, the different types of Extended-EIDs defined so far, how 85 the lookup is performed for each Extended-EID type and which mapping 86 databases are recommended to use depending on the kind of Extended- 87 EIDs used. 89 1.1. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 2. Definition of terms 97 o n-tuple: The term n-tuple is used in this document to describe the 98 set of n elements present in a data packet (e.g. IP address, 99 port, protocol) that can be used to identify unequivocally a 100 packet or a set of packets. 102 o 5-tuple: The term 5-tuple is used in this document to describe the 103 set comprised by 5 elements, being these the source IP address, 104 the destination IP address, the level 4 protocol number, the level 105 4 protocol source port and the level 4 protocol destination port 106 of a data packet. 108 o Extended-EID: This document uses the term Extended-EID to refer to 109 any n-tuple (including a 5-tuple) used in a EID role. See as well 110 [I-D.ietf-lisp-ddt] 112 o Flow: The term flow is used in this document to refer to the 113 sequence of packets identified by the same n-tuple. 115 o MT-[xTR, RTR, MS, MR]: A LISP [xTR, RTR, MS, MR] that supports the 116 enhanced operation for Multi-Tuple Extended-EIDs described in this 117 document. 119 o MT-TR: A LISP tunnel router (e.g. xTR, RTR) that supports the 120 enhanced operation for Multi-Tuple Extended-EIDs described in this 121 document, e.g. MT-xTR, MT-RTR. 123 The rest of the terms are defined in their respective documents. See 124 the LISP specification [RFC6830] for most of the definitions, 125 [I-D.ietf-lisp-lcaf] for LCAF and [I-D.farinacci-lisp-te] for RTR. 127 3. Overview 129 This document describes extensions for LISP to support Multi-Tuple 130 Extended-EIDs. Protocol operation follows the specification defined 131 on [RFC6830] except for the following. Besides of IP mappings, a 132 Mapping System can store Extended-EID mappings. Being Extended-EID a 133 n-tuple identifying a flow. LISP routers perform look-ups based on 134 these Extended-EIDs, instead of on destination IPs. Apart from using 135 n-tuples instead of IPs, retrieving information from the Mapping 136 System follows LISP standard mechanisms (i.e. Map-Request, Map- 137 Reply). 139 4. Protocol Operation with Extended-EIDs 141 4.1. LISP Tunnel Routers 143 LISP tunnel routers with enhanced operation for Multi-Tuple Extended- 144 EIDs, or MT-TRs (MT-xTRs and MT-RTRs), behave as specified on 145 [RFC6830] and [RFC6833], with the particularity that MT-TRs perform 146 mapping lookups based on Extended-EIDs (n-tuples). 148 Any MT-TR must keep an internal map-cache indexed by Extended-EIDs. 149 When a MT-TR receives a packet to encapsulate, it extracts the fields 150 required by the n-tuple lookup in use and stores them in an Extended- 151 EID structure. In the case of a 5-tuple lookup, it will extract the 152 source address, destination address, level 4 protocol, source port 153 (if any) and destination port (if any) from the packet. The MT-TR 154 uses the Extended-EID to perform a look-up into the map-cache. The 155 lookup process must follow the procedure described in section 156 Section 6. If there is an entry on the map-cache that matches the 157 Extended-EID, the MT-TR retrieves the mapping information, selects a 158 destination RLOC and encapsulates the packet as defined in [RFC6830] 160 If the map-cache of the MT-TR contains no entry for the Extended-EID, 161 the MT-TR sends a Map-Request to a MT-MR. The MT-TR MUST be 162 provisioned with the RLOC of at least one MT-MR. The Map-Request 163 sent carries the Extended-EID (encoded in the specific LCAF for that 164 Extended-EID type) in the EID-prefix field of the Map-Request. This 165 Map-Request will eventually trigger a Map-Reply to be sent back the 166 requester MT-TR, see section Section 4.2. This Map-Reply carries an 167 Extended-EID on the EID-prefix field. The MT-TR stores, as defined 168 in [RFC6830], the mapping for the Extended-EID. 170 4.2. Mapping System 172 Mapping System elements (comprising Map Servers and Map Resolvers) 173 behave as specified on [RFC6830] and [RFC6833] when implementing 174 enhanced Multi-Tuple Extended-EIDs operation, with the particularity 175 that MT-MRs resolve Map-Requests based on Extended-EIDs and MT-MSs 176 store mappings indexed by Extended-EIDs. 178 MT-MRs must be capable of processing Map-Requests with an Extended- 179 EID on the EID-prefix field, of finding the appropriate MT-MS for the 180 Extended-EID and of forwarding the Map-Request to it. This is done 181 according to the lookup rules described in section Section 6 and 182 using the mapping database described in section Section 7 which 183 differs depending on the specific Extended-EID. 185 LISP elements must perform the mapping update mechanisms defined in 186 [RFC6830] (e.g, SMR) using as EID the Extended-EID. 188 5. Extended-EIDs Encoding 190 This section describes the Extended-EID types defined so far and the 191 LCAFs to support them. 193 5.1. 5-Tuple 195 The 5-tuple LCAF is a combination of Application Data Type 4 and 196 Source/Dest Type 12 LCAFs. Experimental deployment may indicate that 197 a specific 5-tuple type LCAF is necessary. 199 6. Extended-EID Lookups 201 This section describes the lookup process to be followed when using 202 Extended-EID. At this point, this document only covers 5-tuple kind 203 of Extended-EID lookups (with options for coarse or exact lookup). 204 It is expected to include lookup mechanism for n-tuple lookups with 205 more complex protocol combinations. 207 6.1. 5-Tuple (Coarse) 209 When using a coarse lookup for 5-tuple, the encoding described in 210 Section 5.1 is used to carry the Extended-EID. Note that a coarse 211 lookup also covers exact lookups. The lookup is (logically) done at 212 steps, one per each element of the tuple. The lookup MUST follow 213 this strict order: 215 (1) Destination address 217 (2) Source address 219 (3) Protocol number 221 (4) Destination port 223 (5) Source port 225 This means that for a given 5-tuple, the lookup process will first 226 select from the available 5-tuples present in the system, the ones 227 that match the destination address. Among them, those that also 228 match the source address. This is iterated for the rest of the 229 elements in the tuple. If a 5-tuple matches several entries, then 230 the one with the longest prefix match or shortest port-range has 231 priority. To clarify the process an example is provided below. 233 Suppose that a MT-MS stores the mappings indexed by the tuples (A), 234 (B), (C) and (D). A Map-Request carrying the Extended-EID (T) is 235 received by the MT-MS. The Extended-EID (T) can match both (A) and 236 (B) entries, however destination address has preference over source 237 address and therefore entry (A) is the one selected. If the Map- 238 Request carries (U) instead of (T), the lookup will return that no 239 entry exists for the 5-tuple, however if it carries (V), the lookup 240 will return the (B) entry. On the other hand, a lookup for (W) will 241 return (C) and not (D), although both match the tuple, since the 242 destination port range is shorter in (C). In the case of (X) the 243 lookup will return (D). 245 dst-add src-add pr dst-prt src-prt 247 (A) [1.1.1.0/24, 2.2.0.0/16, 17, 1000-3000, 1000-3000] 248 (B) [1.1.0.0/16, 2.2.2.0/24, 17, 1000-3000, 1000-3000] 249 (C) [3.3.3.0/24, 4.4.4.0/24, 17, 4000-4500, 7000-8000] 250 (D) [3.3.3.0/24, 4.4.4.0/24, 17, 4000-6000, 7000-8000] 252 (T) [ 1.1.1.8, 2.2.2.9, 17, 2000, 2000 ] 253 (U) [ 1.1.8.8, 2.2.9.9, 17, 2000, 2000 ] 254 (V) [ 1.1.8.8, 2.2.2.9, 17, 2000, 2000 ] 255 (W) [ 3.3.3.3, 4.4.4.4, 6, 4300, 7500 ] 256 (X) [ 3.3.3.3, 4.4.4.4, 6, 5000, 7500 ] 258 5-tuple example for coarse lookup 260 6.2. 5-Tuple (Exact) 262 In scenarios where 5-tuple coarse lookup is not required, the lookup 263 can be optimized to only account for exact matchs. When using a 264 exact lookup for 5-tuple, the encoding described in Section 6.1 is 265 used to carry the Extended-EID. The exact match lookup is performed 266 by serializing the elements of the 5-tuple as a single vector of 267 bits. The order to serialize the elements is the same that is 268 described in Section 5.1 This (unique) vector of bits is then used as 269 the key to perform a exact match lookup over the available entries. 271 7. Mapping Databases for Extended-EIDs 273 The mapping database, i.e. the system to interconnect (MT-)MRs and 274 (MT-)MSs should be optimal for each one of the different Extended- 275 EIDs types. This section covers recommended mapping databases for 276 each of the Extended-EIDs described in this document. 278 7.1. 5-Tuple (Coarse) 280 The mapping database to be used for a coarse lookup of 5-tuples can 281 leverage on the LISP-DDT mapping database [I-D.ietf-lisp-ddt] since 282 it supports multi-tuple lookups. Note that a LISP-DDT based database 283 can support also a exact lookup. 285 7.2. 5-Tuple (Exact) 287 Although a LISP-DDT based mapping database supports both coarse and 288 exact lookups, the particularities of the latter benefit of using a 289 mapping database optimized for flat namespaces rather than one 290 optimized for hierarchical data. In that sense, the exact match 291 mechanism should be supported by a DHT-like mapping database, such 292 [I-D.cheng-lisp-shdht] or [LISP-DHT]. 294 8. A Note on Instance-ID 296 Instance-ID is a special case to be considered. If it is in use, its 297 lookup is resolved before the lookup for the Extended-EID begins 298 (regardless of the Extended-EID type). In terms of implementation 299 this means that if the Instance-ID is present, it will have always 300 more priority that any other field within the multi-tuple EID. In 301 other words, Instance-ID is the high-order parts of the destination 302 and source addresses and a longest match lookup should be applied to 303 it before looking up the address itself. 305 9. Acknowledgments 307 10. IANA Considerations 309 This memo includes no request to IANA. 311 11. Security Considerations 313 Security Considerations TBD 315 12. Normative References 317 [I-D.cheng-lisp-shdht] 318 Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping 319 Overlay", draft-cheng-lisp-shdht-04 (work in progress), 320 July 2013. 322 [I-D.farinacci-lisp-te] 323 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 324 Engineering Use-Cases", draft-farinacci-lisp-te-08 (work 325 in progress), March 2015. 327 [I-D.ietf-lisp-ddt] 328 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 329 Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in 330 progress), April 2015. 332 [I-D.ietf-lisp-lcaf] 333 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 334 Address Format (LCAF)", draft-ietf-lisp-lcaf-10 (work in 335 progress), June 2015. 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 341 Locator/ID Separation Protocol (LISP)", RFC 6830, January 342 2013. 344 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 345 Protocol (LISP) Map-Server Interface", RFC 6833, January 346 2013. 348 Authors' Addresses 350 Alberto Rodriguez-Natal 351 Technical University of Catalonia 352 Barcelona 353 Spain 355 Email: arnatal@ac.upc.edu 357 Albert Cabellos-Aparicio 358 Technical University of Catalonia 359 Barcelona 360 Spain 362 Email: acabello@ac.upc.edu 364 Sharon Barkai 365 ConteXtream, Inc. 366 Mountain View, CA 367 USA 369 Email: sbarkai@gmail.com 370 Vina Ermagan 371 Cisco Systems 372 170 Tasman Drive 373 San Jose, CA 374 USA 376 Email: vermagan@cisco.com 378 Darrel Lewis 379 Cisco Systems 380 170 Tasman Drive 381 San Jose, CA 382 USA 384 Email: darlewis@cisco.com 386 Fabio Maino 387 Cisco Systems 388 170 Tasman Drive 389 San Jose, CA 390 USA 392 Email: fmaino@cisco.com 394 Dino Farinacci 395 lispers.net 396 San Jose, CA 397 USA 399 Email: farinacci@gmail.com