| 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 07, 2014 |
Software Defined Networking extensions for the Locator/ID Separation Protocol
draft-rodrigueznatal-lisp-sdn-00
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.
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 (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 (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.
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.
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.
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].
[RFC6830] for most of the definitions, [I-D.ietf-lisp-lcaf] for LCAF and [I-D.farinacci-lisp-te] for RTR and ELP.
The rest of the terms are defined in their respective documents. See the LISP specification
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.
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 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.
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.
Possible Extended-EID types and the LCAFs to support them.
The 5-tuple LCAF is the combination of LCAF types 4 and 12.
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.
TBD more specific / exact match lookup process. TBD address, port, protocol preference.
Advanced mapping update mechanisms to support SDN scenarios.
MS can send proactive SMRs carrying Map-Reply information to some LISP devices whenever there is a mapping update.
LISP devices can be subscribed or subscribe themselves to specific mappings to get updates whenever these change.
This memo includes no request to IANA.
Security Considerations TBD
| [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. |
| [I-D.ietf-lisp-lcaf] | Farinacci, D., Meyer, D. and J. Snijders, "LISP Canonical Address Format (LCAF)", Internet-Draft draft-ietf-lisp-lcaf-04, January 2014. |
| [I-D.farinacci-lisp-te] | Farinacci, D., Lahiri, P. and M. Kowal, "LISP Traffic Engineering Use-Cases", Internet-Draft draft-farinacci-lisp-te-04, January 2014. |