LISP Working Group A. Rodriguez-Natal Internet-Draft A. Cabellos-Aparicio Intended status: Experimental Technical University of Catalonia Expires: August 11, 2014 S. Barkai ConteXtream, Inc. V. Ermagan D. Lewis F. Maino Cisco Systems D. Farinacci lispers.net February 7, 2014 Software Defined Networking extensions for the Locator/ID Separation Protocol draft-rodrigueznatal-lisp-sdn-00 Abstract This document describes extensions for the Locator/ID Separation Protocol (LISP) to make it more suitable to be used on Software Defined Networking (SDN) scenarios. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 11, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Rodriguez-Natal, et al. Expires August 11, 2014 [Page 1] Internet-Draft LISP-SDN February 2014 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol operation . . . . . . . . . . . . . . . . . . . . . 4 4.1. LISP tunnel routers . . . . . . . . . . . . . . . . . . . 4 4.2. Mapping System . . . . . . . . . . . . . . . . . . . . . 5 5. Extended-EID types . . . . . . . . . . . . . . . . . . . . . 5 5.1. 5-tuple . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Extended-EID lookups . . . . . . . . . . . . . . . . . . . . 5 6.1. 5-tuple lookup . . . . . . . . . . . . . . . . . . . . . 5 7. Mapping updates . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Proactive update pushing . . . . . . . . . . . . . . . . 6 7.2. Mapping subscription . . . . . . . . . . . . . . . . . . 6 8. Provisioning and Discovery . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 11. Security Considerations . . . . . . . . . . . . . . . . . . . 6 12. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Locator/ID Separation Protocol LISP [RFC6830] splits current IP addresses in two different namespaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map-and-encap approach that relies in two entities, the Mapping System and the Ingress/ Egress Tunnel Routers (xTRs). The Mapping System is a distributed database that stores and disseminates EID-RLOC bindings. The xTRs are deployed at LISP sites edge points and perform encapsulation and decapsulation of LISP data packets. With this architecture in place, LISP is inherently decoupling control-plane from data-plane. LISP moves all control onto the Mapping System, while keeps data at the xTR level. This decoupling entitles network operators to build a Software Defined Network on top of LISP. Rodriguez-Natal, et al. Expires August 11, 2014 [Page 2] Internet-Draft LISP-SDN February 2014 However, vanilla LISP offers a limited feature set on terms of SDN requirements. To position LISP as the foundations for a SDN solution, advanced interaction between LISP elements and some extensions to the stock protocol can be defined. This document describes SDN extensions for LISP. On the present iteration of this draft, the LISP protocol operating in a SDN deployment manages network traffic in terms of flows identified by a 5-tuple identifier. 5-tuples are encoded in a specific type of LISP Canonical Address Format (LCAF). Flows are routed over the network using Explicit Locator Paths (ELPs). The Mapping-System stores 5-tuple - ELP bindings. Network functions (i.e. firewalls, etc) can be deployed at Re-encapsulating Tunnel Routers (RTRs) spread over the network. These RTRs can be included as part of a ELP. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Definition of terms o n-tuple: The term n-tuple is used in this document to describe the set of n elements present in a data packet (e.g. IP address, port, protocol) that can be used to identify unequivocally a packet or a set of packets. o 5-tuple: The term 5-tuple is used in this document to describe the set comprised by 5 elements, being these the source IP address, the destination IP address, the level 4 protocol number, the level 4 protocol source port and the level 4 protocol destination port of a data packet. o Extended-EID: This document uses the term Extended-EID to refer to any n-tuple (including a 5-tuple) used in a EID role. o Flow: The term flow is used in this document to refer to the sequence of packets identified by the same n-tuple. The rest of the terms are defined in their respective documents. See the LISP specification [RFC6830] for most of the definitions, [I-D.ietf-lisp-lcaf] for LCAF and [I-D.farinacci-lisp-te] for RTR and ELP. Rodriguez-Natal, et al. Expires August 11, 2014 [Page 3] Internet-Draft LISP-SDN February 2014 3. Overview This document describes extensions to LISP protocol definition and operation to optimize it to work on SDN scenarios. Protocol operation follows the specification defined on [LISP] except for the following. Besides of IP to IP mappings, Mapping System stores also Extended-EID to ELP mappings. Being Extended-EID a n-tuple identifying a flow. LISP routers perform look-ups based on these Extended-EIDs, instead of on destination IPs. Apart from using n- tuples instead of IPs, retrieving information from the Mapping System follows LISP standard mechanisms (i.e. Map-Request, Map- Reply). Traditionally ETRs register EID-prefixes that include their own RLOC addresses as well as other RLOCs for ETRs at the same site. Here a third-party will also register Extended-EID-to-ELP bindings. 4. Protocol operation 4.1. LISP tunnel routers LISP routers (xTRs, RTRs) behave as specified on [RFC6830] and [RFC6833], except for the following. LISP routers perform mapping lookups based on Extended-EID (n-tuple) not on IP address EID and they obtain an ELP instead of an IP address RLOC. Which specific n-tuple lookup to use and how to configure the router to use it, is to be covered on future iterations of this document. Any LISP router must keep an internal map-cache indexed by Extended- EIDs. When a LISP router receives a packet to encapsulate, it extracts the fields required by the n-tuple lookup in use and stores them in an Extended-EID structure. In the case of a 5-tuple lookup, it will extract the source address, destination address, level 4 protocol, source port (if any) and destination port (if any) from the packet. The LISP router uses the Extended-EID to perform a look-up into the map-cache. The map- cache can contain entries with an Extended-EID more coarse in some fields. The lookup process must follow the procedure described in section Section 6. If there is an entry on the map-cache that matches the Extended-EID, the LISP router retrieves the mapping information (i.e. the ELP) and uses the first hop (if it is an ITR) or the next hop (if it is a RTR) of the ELP to encapsulate and forward the packet. If the map-cache of the xTR contains no entry for the Exteneded-EID, the xTR sends a Map-Request to the Mapping System. This Map-Request carries the Extended-EID (encoded in the specific LCAF for that Extended-EID type) in the EID-prefix field of the Map-Request. The Rodriguez-Natal, et al. Expires August 11, 2014 [Page 4] Internet-Draft LISP-SDN February 2014 Mapping System must reply with a Map- Reply carrying on the locator field an ELP. This Map-Reply can carry on the EID-prefix field an Extended-EID more coarse in some fields, but covering the original Extended-EID. The LISP router must store this Extended-EID entry (even if more coarse) in its map-cache. 4.2. Mapping System Mapping System (comprising Map Servers and Map Resolvers) behaves as specified on [RFC6830] and [RFC6833], except for the following. It also stores mappings indexed by Extended-EID. These mappings contain n-tuple to ELP mappings. Map Resolvers must be capable of processing Map-Requests with an Extended-EID on the EID-prefix field. The Extended-EID carried on the Map-Request contains fully qualified most specific values on all its fields. Map Servers can store more coarse Extended-EID entries. Map Resolvers must be capable of finding the Map-Server containing the longest match Extended-EID entry, according to the lookup rules described in section Section 6. Once found, the Map Resolver forwards the Map-Request to the Map Server. The Map Server replies itself to Map- Requests. It must not forward Map-Requests comprising Extended-EIDs to any ITRs. LISP elements must perform the mapping update mechanisms defined in [RFC6830] (e.g, SMR) using as EID the Extended-EID. 5. Extended-EID types Possible Extended-EID types and the LCAFs to support them. 5.1. 5-tuple The 5-tuple LCAF is the combination of LCAF types 4 and 12. 6. Extended-EID lookups This section describes the lookup process to be followed when using Extended-EID instead of vanilla IP address EID. At this point, this document only covers 5-tuple kind of Extended-EID lookups. It is expected to include lookup mechanism for n-tuple lookups with more complex protocol combinations. 6.1. 5-tuple lookup TBD more specific / exact match lookup process. TBD address, port, protocol preference. Rodriguez-Natal, et al. Expires August 11, 2014 [Page 5] Internet-Draft LISP-SDN February 2014 7. Mapping updates Advanced mapping update mechanisms to support SDN scenarios. 7.1. Proactive update pushing MS can send proactive SMRs carrying Map-Reply information to some LISP devices whenever there is a mapping update. 7.2. Mapping subscription LISP devices can be subscribed or subscribe themselves to specific mappings to get updates whenever these change. 8. Provisioning and Discovery 9. Acknowledgements 10. IANA Considerations This memo includes no request to IANA. 11. Security Considerations Security Considerations TBD 12. Normative References [I-D.farinacci-lisp-te] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic Engineering Use-Cases", draft-farinacci-lisp-te-04 (work in progress), January 2014. [I-D.ietf-lisp-lcaf] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", draft-ietf-lisp-lcaf-04 (work in progress), January 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013. Rodriguez-Natal, et al. Expires August 11, 2014 [Page 6] Internet-Draft LISP-SDN February 2014 Authors' Addresses Alberto Rodriguez-Natal Technical University of Catalonia Barcelona Spain Email: arnatal@ac.upc.edu Albert Cabellos-Aparicio Technical University of Catalonia Barcelona Spain Email: acabello@ac.upc.edu Sharon Barkai ConteXtream, Inc. Mountain View, CA USA Email: sbarkai@gmail.com Vina Ermagan Cisco Systems 170 Tasman Drive San Jose, CA USA Email: vermagan@cisco.com Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA Email: darlewis@cisco.com Rodriguez-Natal, et al. Expires August 11, 2014 [Page 7] Internet-Draft LISP-SDN February 2014 Fabio Maino Cisco Systems 170 Tasman Drive San Jose, CA USA Email: fmaino@cisco.com Dino Farinacci lispers.net San Jose, CA USA Email: farinacci@gmail.com Rodriguez-Natal, et al. Expires August 11, 2014 [Page 8]