Internet DRAFT - draft-rodrigueznatal-lisp-sdn
draft-rodrigueznatal-lisp-sdn
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]
