Software Defined Networking extensions for the Locator/ID Separation Protocol

The Locator/ID Separation Protocol LISP 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.

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. 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. Extended-EID: This document uses the term Extended-EID to refer to any n-tuple (including a 5-tuple) used in a EID role. 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 for most of the definitions, for LCAF and for RTR and ELP.

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 and , 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 . 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 and , 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 . 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 (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