idnits 2.17.1 draft-rodrigueznatal-lisp-sdn-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 7, 2014) is 3728 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP' is mentioned on line 148, but not defined == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-04 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-04 ** 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 (~~), 5 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: August 11, 2014 S. Barkai 6 ConteXtream, Inc. 7 V. Ermagan 8 D. Lewis 9 F. Maino 10 Cisco Systems 11 D. Farinacci 12 lispers.net 13 February 7, 2014 15 Software Defined Networking extensions for the Locator/ID Separation 16 Protocol 17 draft-rodrigueznatal-lisp-sdn-00 19 Abstract 21 This document describes extensions for the Locator/ID Separation 22 Protocol (LISP) to make it more suitable to be used on Software 23 Defined Networking (SDN) scenarios. 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 http://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 August 11, 2014. 42 Copyright Notice 44 Copyright (c) 2014 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 (http://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 . . . . . . . . . . . . . . . . . . 3 61 2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Protocol operation . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. LISP tunnel routers . . . . . . . . . . . . . . . . . . . 4 65 4.2. Mapping System . . . . . . . . . . . . . . . . . . . . . 5 66 5. Extended-EID types . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. 5-tuple . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Extended-EID lookups . . . . . . . . . . . . . . . . . . . . 5 69 6.1. 5-tuple lookup . . . . . . . . . . . . . . . . . . . . . 5 70 7. Mapping updates . . . . . . . . . . . . . . . . . . . . . . . 6 71 7.1. Proactive update pushing . . . . . . . . . . . . . . . . 6 72 7.2. Mapping subscription . . . . . . . . . . . . . . . . . . 6 73 8. Provisioning and Discovery . . . . . . . . . . . . . . . . . 6 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 12. Normative References . . . . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 The Locator/ID Separation Protocol LISP [RFC6830] splits current IP 83 addresses in two different namespaces, Endpoint Identifiers (EIDs) 84 and Routing Locators (RLOCs). LISP uses a map-and-encap approach 85 that relies in two entities, the Mapping System and the Ingress/ 86 Egress Tunnel Routers (xTRs). The Mapping System is a distributed 87 database that stores and disseminates EID-RLOC bindings. The xTRs 88 are deployed at LISP sites edge points and perform encapsulation and 89 decapsulation of LISP data packets. 91 With this architecture in place, LISP is inherently decoupling 92 control-plane from data-plane. LISP moves all control onto the 93 Mapping System, while keeps data at the xTR level. This decoupling 94 entitles network operators to build a Software Defined Network on top 95 of LISP. 97 However, vanilla LISP offers a limited feature set on terms of SDN 98 requirements. To position LISP as the foundations for a SDN 99 solution, advanced interaction between LISP elements and some 100 extensions to the stock protocol can be defined. This document 101 describes SDN extensions for LISP. 103 On the present iteration of this draft, the LISP protocol operating 104 in a SDN deployment manages network traffic in terms of flows 105 identified by a 5-tuple identifier. 5-tuples are encoded in a 106 specific type of LISP Canonical Address Format (LCAF). Flows are 107 routed over the network using Explicit Locator Paths (ELPs). The 108 Mapping-System stores 5-tuple - ELP bindings. Network functions 109 (i.e. firewalls, etc) can be deployed at Re-encapsulating Tunnel 110 Routers (RTRs) spread over the network. These RTRs can be included 111 as part of a ELP. 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. Definition of terms 121 o n-tuple: The term n-tuple is used in this document to describe the 122 set of n elements present in a data packet (e.g. IP address, port, 123 protocol) that can be used to identify unequivocally a packet or a 124 set of packets. 126 o 5-tuple: The term 5-tuple is used in this document to describe the 127 set comprised by 5 elements, being these the source IP address, 128 the destination IP address, the level 4 protocol number, the level 129 4 protocol source port and the level 4 protocol destination port 130 of a data packet. 132 o Extended-EID: This document uses the term Extended-EID to refer to 133 any n-tuple (including a 5-tuple) used in a EID role. 135 o Flow: The term flow is used in this document to refer to the 136 sequence of packets identified by the same n-tuple. 138 The rest of the terms are defined in their respective documents. See 139 the LISP specification [RFC6830] for most of the definitions, 140 [I-D.ietf-lisp-lcaf] for LCAF and [I-D.farinacci-lisp-te] for RTR and 141 ELP. 143 3. Overview 145 This document describes extensions to LISP protocol definition and 146 operation to optimize it to work on SDN scenarios. 148 Protocol operation follows the specification defined on [LISP] except 149 for the following. Besides of IP to IP mappings, Mapping System 150 stores also Extended-EID to ELP mappings. Being Extended-EID a 151 n-tuple identifying a flow. LISP routers perform look-ups based on 152 these Extended-EIDs, instead of on destination IPs. Apart from using 153 n- tuples instead of IPs, retrieving information from the Mapping 154 System follows LISP standard mechanisms (i.e. Map-Request, Map- 155 Reply). 157 Traditionally ETRs register EID-prefixes that include their own RLOC 158 addresses as well as other RLOCs for ETRs at the same site. Here a 159 third-party will also register Extended-EID-to-ELP bindings. 161 4. Protocol operation 163 4.1. LISP tunnel routers 165 LISP routers (xTRs, RTRs) behave as specified on [RFC6830] and 166 [RFC6833], except for the following. LISP routers perform mapping 167 lookups based on Extended-EID (n-tuple) not on IP address EID and 168 they obtain an ELP instead of an IP address RLOC. Which specific 169 n-tuple lookup to use and how to configure the router to use it, is 170 to be covered on future iterations of this document. 172 Any LISP router must keep an internal map-cache indexed by Extended- 173 EIDs. When a LISP router receives a packet to encapsulate, it 174 extracts the fields required by the n-tuple lookup in use and stores 175 them in an Extended-EID structure. In the case of a 5-tuple lookup, 176 it will extract the source address, destination address, level 4 177 protocol, source port (if any) and destination port (if any) from the 178 packet. The LISP router uses the Extended-EID to perform a look-up 179 into the map-cache. The map- cache can contain entries with an 180 Extended-EID more coarse in some fields. The lookup process must 181 follow the procedure described in section Section 6. If there is an 182 entry on the map-cache that matches the Extended-EID, the LISP router 183 retrieves the mapping information (i.e. the ELP) and uses the first 184 hop (if it is an ITR) or the next hop (if it is a RTR) of the ELP to 185 encapsulate and forward the packet. 187 If the map-cache of the xTR contains no entry for the Exteneded-EID, 188 the xTR sends a Map-Request to the Mapping System. This Map-Request 189 carries the Extended-EID (encoded in the specific LCAF for that 190 Extended-EID type) in the EID-prefix field of the Map-Request. The 191 Mapping System must reply with a Map- Reply carrying on the locator 192 field an ELP. This Map-Reply can carry on the EID-prefix field an 193 Extended-EID more coarse in some fields, but covering the original 194 Extended-EID. The LISP router must store this Extended-EID entry 195 (even if more coarse) in its map-cache. 197 4.2. Mapping System 199 Mapping System (comprising Map Servers and Map Resolvers) behaves as 200 specified on [RFC6830] and [RFC6833], except for the following. It 201 also stores mappings indexed by Extended-EID. These mappings contain 202 n-tuple to ELP mappings. 204 Map Resolvers must be capable of processing Map-Requests with an 205 Extended-EID on the EID-prefix field. The Extended-EID carried on 206 the Map-Request contains fully qualified most specific values on all 207 its fields. Map Servers can store more coarse Extended-EID entries. 208 Map Resolvers must be capable of finding the Map-Server containing 209 the longest match Extended-EID entry, according to the lookup rules 210 described in section Section 6. Once found, the Map Resolver 211 forwards the Map-Request to the Map Server. The Map Server replies 212 itself to Map- Requests. It must not forward Map-Requests comprising 213 Extended-EIDs to any ITRs. 215 LISP elements must perform the mapping update mechanisms defined in 216 [RFC6830] (e.g, SMR) using as EID the Extended-EID. 218 5. Extended-EID types 220 Possible Extended-EID types and the LCAFs to support them. 222 5.1. 5-tuple 224 The 5-tuple LCAF is the combination of LCAF types 4 and 12. 226 6. Extended-EID lookups 228 This section describes the lookup process to be followed when using 229 Extended-EID instead of vanilla IP address EID. At this point, this 230 document only covers 5-tuple kind of Extended-EID lookups. It is 231 expected to include lookup mechanism for n-tuple lookups with more 232 complex protocol combinations. 234 6.1. 5-tuple lookup 236 TBD more specific / exact match lookup process. TBD address, port, 237 protocol preference. 239 7. Mapping updates 241 Advanced mapping update mechanisms to support SDN scenarios. 243 7.1. Proactive update pushing 245 MS can send proactive SMRs carrying Map-Reply information to some 246 LISP devices whenever there is a mapping update. 248 7.2. Mapping subscription 250 LISP devices can be subscribed or subscribe themselves to specific 251 mappings to get updates whenever these change. 253 8. Provisioning and Discovery 255 9. Acknowledgements 257 10. IANA Considerations 259 This memo includes no request to IANA. 261 11. Security Considerations 263 Security Considerations TBD 265 12. Normative References 267 [I-D.farinacci-lisp-te] 268 Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic 269 Engineering Use-Cases", draft-farinacci-lisp-te-04 (work 270 in progress), January 2014. 272 [I-D.ietf-lisp-lcaf] 273 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 274 Address Format (LCAF)", draft-ietf-lisp-lcaf-04 (work in 275 progress), January 2014. 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 281 Locator/ID Separation Protocol (LISP)", RFC 6830, January 282 2013. 284 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 285 Protocol (LISP) Map-Server Interface", RFC 6833, January 286 2013. 288 Authors' Addresses 290 Alberto Rodriguez-Natal 291 Technical University of Catalonia 292 Barcelona 293 Spain 295 Email: arnatal@ac.upc.edu 297 Albert Cabellos-Aparicio 298 Technical University of Catalonia 299 Barcelona 300 Spain 302 Email: acabello@ac.upc.edu 304 Sharon Barkai 305 ConteXtream, Inc. 306 Mountain View, CA 307 USA 309 Email: sbarkai@gmail.com 311 Vina Ermagan 312 Cisco Systems 313 170 Tasman Drive 314 San Jose, CA 315 USA 317 Email: vermagan@cisco.com 319 Darrel Lewis 320 Cisco Systems 321 170 Tasman Drive 322 San Jose, CA 323 USA 325 Email: darlewis@cisco.com 326 Fabio Maino 327 Cisco Systems 328 170 Tasman Drive 329 San Jose, CA 330 USA 332 Email: fmaino@cisco.com 334 Dino Farinacci 335 lispers.net 336 San Jose, CA 337 USA 339 Email: farinacci@gmail.com