Internet DRAFT - draft-cabellos-sfc-map-assisted-proxy

draft-cabellos-sfc-map-assisted-proxy







Network Working Group                                        A. Cabellos
Internet-Draft                                         UPC-BarcelonaTech
Intended status: Experimental                                  S. Barkai
Expires: April 21, 2016                                       B. Perlman
                                              Hewlett Packard Enterprise
                                                              V. Ermagan
                                                                F. Maino
                                                       Cisco Systems Inc
                                                      A. Rodriguez-Natal
                                                       UPC-BarcelonaTech
                                                        October 19, 2015


                   Map-Assisted SFC Proxy using LISP
              draft-cabellos-sfc-map-assisted-proxy-00.txt

Abstract

   This document specifies a map-assisted SFC proxy.  The SFC proxy uses
   the LISP Mapping System to store the NSH header indexed by 5-tuple,
   before decapsulating and forwarding the packet to the legacy
   function.  After the function has processed the packet, the SFC proxy
   retrieves the NSH header from the Mapping System to SFC encapsulate
   it.

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].

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 April 21, 2016.

Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

   1.  Introduction
   2.  Overview
     2.1.  Flow example
     2.2.  Benefits of Map-Assisted SFC Proxies
   3.  Encoding of 5-tuple and NSH in LISP messages
     3.1.  Encoding of 5-tuple Index
     3.2.  Encoding of NSH Header
   4.  SFC Proxy Processing
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Authors' Addresses

1.  Introduction

   The Locator/ID Separation Protocol (LISP) [RFC6830] is an overlay
   protocol that creates two namespaces: EIDs (End-point IDentifiers)
   and RLOCs (Routing LOCators).  The LISP Mapping System stores the
   mappings between both namespaces, LISP provides a standard way for
   its data-plane elements, called xTRs, to store and retrieve mappings
   from the Mapping System to make forwarding decisions: Map-Request,
   Map-Request and Map-Reply.  Finally, LISP also offers a flexible
   syntax for both EIDs and RLOCs by means of LCAFs [I-D.ietf-lisp-lcaf]
   to define what is an EID and what is an RLOC.

   With such architecture in place, the LISP control-plane represents a
   programmable protocol.  The Mapping System is a logically centralized
   database that stores network state, which is retrieved by data-plane
   nodes in a standard way to make decisions.  Any external control
   plane can program the LISP Mapping System while any data-plane node
   can be map-assisted.

   This document specifies a map-assisted SFC proxy
   [I-D.ietf-sfc-architecture].  An SFC acts on behalf the SFC unaware
   functions on the SFC domain.  Basically the SFC Proxy removes the SFC
   encapsulation, forwards the packet to the SFC unaware function,
   receives back the packets and reapplies an SFC encapsulation.
   Specifically this document specifies how to map-assist the
   encapsulation operation by means of the LISP control-plane.

   In short, the SFC Proxy before decapsulating the packet stores (Map-
   Registers) the NSH header (including Context Headers)
   [I-D.ietf-sfc-nsh] in the LISP Mapping System indexed by the 5-tuple
   of the packet {5-tuple->NSH}. After the SFC unaware function has
   processed the packet, the proxy retrieves (Map-Requests based on the
   5-tuple of the packet) the NSH+Context headers to SFC encapsulate the
   packet.

   This has two main benefits; first the SFC proxy is stateless and
   connectionless.  Second, in some cases the legacy function may change
   the headers of the original packet, the SFC control plane can change
   the stored mapping {5-tuple->NSH} in the Mapping System accordingly
   and allow for fast reclassification by the proxy.

2.  Overview

2.1.  Flow example

   This section shows a flow example of map-assisted SFC Proxy
   processing:

                        +------------+     +------------+
                        |LISP Mapping|     |SFC Control |
                        |   System   |     |   Plane    |
                        |            |     |            |
                        +------------+     +------------+
                              ^
                              |
                        Map-Register
                       {5-tuple->NSH}
                              |
                              |              +----------+
     +----------+        +----+-----+        |   SFC    |
     |   SFF    |------->|SFC Proxy |------->| Unaware  |
     +----------+        +----------+        | Function |
                                             +----------+
              Figure 1.- SFC Proxy Decapsulation


   1.  An SFC proxy receives an SFC encapsulated packet as defined in
       the SFC architecture [I-D.ietf-sfc-architecture].

   2.  The SFC proxy Map-Registers the SFC encapsulation in the LISP
       Mapping System (figure 1), this includes the entire NSH header:
       Base Header, Service Header and Context Headers.  The NSH header
       is indexed by the 5-tuple of the payload.  Both the 5-tuple and
       the NSH header are encoded using two different LISP LCAFs,
       further details can be found in Section 3.

   3.  The SFC proxy forwards the packet to the SFC unaware function as
       specified in the SFC architecture [I-D.ietf-sfc-architecture].

   4.  The SFC unaware function processes the packet and sends it back
       to the SFC proxy.

   5.  Upon reception of the processed packet, the SFC proxy must SFC
       encapsulate the packet.  For this it retrieves the NSH header
       from the LISP Mapping System using a Map-Request indexed by the
       5-tuple of the received packet (figure 2).  Once the packet is
       SFC encapsulated, the SFC proxy forwards it as defined in the SFC
       architecture [I-D.ietf-sfc-architecture].



                        +------------+  Reclassificaton +------------+
                        |LISP Mapping|{New 5-tuple->NSH}|SFC Control |
                        |   System   | <----------------|   Plane    |
                        |            |                  |            |
                        +---------+--+                  +------------+
                          ^       |
                          |  Map-Reply
                          |    {NSH}
                     Map-Request  |
                     {5-tuple?}   |
                          |       v          +----------+
     +----------+        ++---------+        |   SFC    |
     |   SFF    |<-------|SFC Proxy |<-------| Unaware  |
     +----------+        +----------+        | Function |
                                             +----------+
              Figure 2.- SFC Proxy Encapsulation


2.2.  Benefits of Map-Assisted SFC Proxies

   The Map-Assisted encapsulation described in step 5 of the previous
   section brings the following benefits to the SFC architecture:

   o  The map-assisted SFC proxy is connectionless and stateless, as
      such it does not need to store state to forward packets from/to
      SFC unaware functions.  Since the required state is stored in the
      Mapping System, any other SFC proxy can receive the processed
      packets and SFC encapsulate them.

   o  In some scenarios the legacy functions may change the packet
      header and hence, the SFC proxy must re-classify it.  With map-
      assisted SFC proxies, the SFC control-plane can change the stored
      state on the Mapping System to accordingly and allow map-assisted
      stateless reclassification by the SFC-Proxy.  This is illustrated
      in the figure 2 by the "Reclassification" arrow.  How the SFC
      control plane updates information on the LISP Mapping system is
      out of the scope of this document.  In any case, please note that
      the SFC proxy still operates as described in this document and
      remains unaware of the reclassification.

3.  Encoding of 5-tuple and NSH in LISP messages

   This section describes the LCAFs used to encode both the 5-tuple and
   NSH header (Base, Service Path and Context Headers).  The 5-tuple
   index is encoded in a LISP record as an EID while the NSH header as
   an RLOC.

3.1.  Encoding of 5-tuple Index

   The Multiple-tuple EID [I-D.rodrigueznatal-lisp-multi-tuple-eid] is
   used to encode the 5-tuple EID that indexes the NSH header,
   specifically using the "Exact Match" mode and EID mask-ken set to 0.

3.2.  Encoding of NSH Header

   The NSH header (Base Header, Service Path Header and Context Headers)
   [I-D.ietf-sfc-nsh] is encoded using the JSON Data Model Type LCAF as
   defined in [I-D.ietf-lisp-lcaf].  The header is encoded in binary
   format using BSON [BSON] as a single binary field (subtype "Generic
   binary subtype"):

   document ::= int32 binary "\x00"

   A LISP record only transports a single NSH header and all the "Loc"
   fields are ignored except "Loc-AFI" and "Locator".

4.  SFC Proxy Processing

   This section specifies the behavior of a map-assisted SFC Proxy, the
   proxy acts as specified in [I-D.ietf-sfc-architecture] with the
   following exceptions.

   Inbound: For traffic received from the SFF and before removing the
   SFC encapsulation, the proxy Map-Registers the NSH header (Base,
   Service and Context) using the 5-tuple and JSON LCAFs defined in
   Section 3, the 5-tuple is applied to the original payload.  After
   this the SFC Proxy acts as specified in [I-D.ietf-sfc-architecture].

   Outbound: For returning traffic from the legacy SF, the SFC Proxy
   Map-Requests using a 5-tuple lookup LCAF and receives back the entire
   NSH header encoded using the JSON LCAF.  The proxy applies the NSH
   encapsulation, decrements the Service Index and forwards the traffic
   as specified in [I-D.ietf-sfc-architecture].

   In addition to this please note the following:

   o  In some scenarios the SFC Control Plane may have changed the
      {5-tuple->NSH} mapping to account for changes made by the legacy
      SF to the payload.

   o  The LISP Mapping System can identify the registering and
      requesting SFC Proxy using the RLOC of the Map-Register and Map-
      Request message respectively.  This is useful when the inbound and
      outbound SFC Proxies are different.

   o  This document assumes that the payload is IP (IPv4 or IPv6) and a
      transport header (TCP or UDP).  Further revisions of this document
      will consider other payloads.

5.  Security Considerations

   The map-assisted SFC Proxy does not introduce additional security
   considerations beyond the ones described in
   [I-D.ietf-sfc-architecture] and [I-D.ietf-lisp-threats].

6.  IANA Considerations

   This memo includes no request to IANA.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,
              <http://www.rfc-editor.org/info/rfc6830>.

7.2.  Informative References

   [BSON]     MongoDB, , ""BSON - Binary JSON Specification
              "http://bsonspec.org/"", June 2015.

   [I-D.ietf-lisp-lcaf]
              Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", draft-ietf-lisp-lcaf-11 (work in
              progress), September 2015.

   [I-D.ietf-lisp-threats]
              Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
              Analysis", draft-ietf-lisp-threats-13 (work in progress),
              August 2015.

   [I-D.ietf-sfc-architecture]
              Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", draft-ietf-sfc-architecture-11 (work
              in progress), July 2015.

   [I-D.ietf-sfc-nsh]
              Quinn, P. and U. Elzur, "Network Service Header", draft-
              ietf-sfc-nsh-01 (work in progress), July 2015.

   [I-D.rodrigueznatal-lisp-multi-tuple-eid]
              Rodriguez-Natal, A., Cabellos-Aparicio, A., Barkai, S.,
              Ermagan, V., Maino, F., Lewis, D., and D. Farinacci,
              ""LISP support for Multi-Tuple EIDs" draft-rodrigueznatal-
              lisp-multi-tuple-eids-00 (work in progress)", June 2015.

Authors' Addresses

   Albert Cabellos
   UPC-BarcelonaTech
   c/ Jordi Girona 1-3
   Barcelona, Catalonia  08034
   Spain

   Email: acabello@ac.upc.edu


   Sharon Barkai
   Hewlett Packard Enterprise
   3000 Hanover Street
   Palo Alto, CA
   USA

   Email: sharon.barkai@hpe.com


   Barak Perlman
   Hewlett Packard Enterprise
   3000 Hanover Street
   Palo Alto, CA
   USA

   Email: barak.perlman@hpe.com


   Vina Ermagan
   Cisco Systems Inc
   170 W Tasman Drive
   San Jose, CA  95134
   USA

   Email: vermagan@cisco.com


   Fabio Maino
   Cisco Systems Inc
   170 W Tasman Drive
   San Jose, CA  95134
   USA

   Email: fmaino@cisco.com


   Alberto Rodriguez-Natal
   UPC-BarcelonaTech
   c/ Jordi Girona 1-3
   Barcelona, Catalonia  08034
   Spain

   Email: arnatal@ac.upc.edu