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]