[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

LISP Working Group                                            V. Ermagan
Internet-Draft                                                  P. Quinn
Intended status: Experimental                                   D. Lewis
Expires: April 6, 2017                                          F. Maino
                                                                F. Coras
                                                       Cisco Systems Inc
                                                         October 3, 2016


                LISP Control Plane integration with NSH
                       draft-ermagan-lisp-nsh-02

Abstract

   This document defines extensions to the LISP control plane protocol
   to enable support for Network Service Header(NSH) based Service
   Function Chaining (SFC).

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 6, 2017.

Copyright Notice

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




Ermagan, et al.           Expires April 6, 2017                 [Page 1]


Internet-Draft                  LISP-NSH                    October 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  LISP Model of Service Function Chaining . . . . . . . . . . .   2
   3.  Service Path Encoding . . . . . . . . . . . . . . . . . . . .   3
     3.1.  SPI LCAF  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  LISP ITR Processing . . . . . . . . . . . . . . . . . . . . .   4
   5.  LISP Map-Server Processing  . . . . . . . . . . . . . . . . .   4
     5.1.  Packet Flow Example . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The Locator/ID Separation Protocol (LISP) [LISP]defines a data plane
   encapsulation format that carries IPv4 and IPv6 packets using a LISP
   header - the LISP encapsulation - and an outer UDP/IP transport.

   The combination of the LISP encapsulation and the LISP control plane
   creates a dynamic network overlay.

   LISP-GPE [LISP-GPE] and VXLAN-GPE [VXLAN-GPE] define an extension to
   the LISP and VXLAN encapsulations with multi-protocol support,
   enabling encapsulation of any inner payload, including IP, Ethernet,
   and NSH [NSH].

   This document defines the necessary extensions to the LISP control
   plane to support dynamic NSH-based service function chaining ( map-
   and-encap based on SPI and SI) , using LISP-GPE/VXLAN-GPE as the
   overlay transport protocol.

2.  LISP Model of Service Function Chaining

   The NSH header [NSH] identifies the service path that a packet
   belongs to, and the next hop in the path for that packet via the
   Service Path Identifier (SPI) and Service Index (SI) fields in the
   Service Path header, as depicted in the figure below.








Ermagan, et al.           Expires April 6, 2017                 [Page 2]


Internet-Draft                  LISP-NSH                    October 2016


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Service Path ID              | Service Index |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   To provide a dynamic overlay for NSH packets using LISP, the
   assumptions are that a LISP xTR is co-located with, or connected to,
   every Service Function Forwarder (SFF) [SFC] in a service path
   visible to LISP, and that the xTR can send/receive the NSH packets
   encapsulated in LISP-GPE/VXLAN-GPE headers.  The ITRs in this
   scenario need to resolve the combination of SPI and SI from the NSH
   header ( which together identify the next hop in the Service Path) to
   the associated Network locations (RLOCs) for the next hop.  These
   RLOCs in SFC terminology are the locators for the Service Function
   Forwarder (SFF) that is hosting the next hop Service Function in the
   associated Service Path.  Once this mapping is resolved, the packet
   is encapsulated to the destination RLOC (SFF).  The ETR at the next
   hop SFF receives and decapsulates this packet.  The NSH packet is
   then passed to the SFF.

   As a result, the LISP mapping service and the xTRs need to be
   extended to support a new identity type ( i.e. SPI+SI) as well as
   encapsulation of NSH packets.

   To this end, a new LCAF [LCAF] is defined to represent the SPI and SI
   information as a new EID.  We refer to this new LCAF as the SPI LCAF.
   With this new LCAF, the LISP control protocol is extended to store
   and retrieve SPI and SI information and their mappings to the routing
   locators of the next hop in the associated service path.

3.  Service Path Encoding

   This section defines the new SPI LCAF required to encode NSH fields
   and the associated path information in the LISP mapping system.

3.1.  SPI LCAF

   A new LCAF is defined to encode SPI and SI information as a new LISP
   address type.  The SPI LCAF fields are defined below.  See [LCAF] for
   a description of all LCAF fields.










Ermagan, et al.           Expires April 6, 2017                 [Page 3]


Internet-Draft                  LISP-NSH                    October 2016


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           AFI = 16387         |    Rsvd1      |     Flags     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Type = 17    |     Rsvd2   |               4               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Service Path ID                  | Service index |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Field definitions:

   Service Path ID: The SPI from the NSH header that identifies the
   service path this packet belongs to.

   Service index: The SI from the NSH header that identifies the next
   hop within the path for this packet.

4.  LISP ITR Processing

   LISP ITRs determine the destination routing locator to encapsulate
   the packet to by looking up the Service Path ID and Service Index
   from the NSH header in the mapping system.  When querying the mapping
   system, the ITRs will generate a Map-Request using the SPI LCAF as an
   EID record.

   The Map-Reply to such a Map-Request will have the SPI LCAF as the EID
   record, and the routing locator information of only the next hop for
   this SPI and SI combination, in the locator records.  The ITRs store
   this mapping in its local map-cache for future use.

5.  LISP Map-Server Processing

   A LISP Map-Server stores mapping entries such that it can resolve the
   SPI and SI to the RLOC(s) of the associated next hop (SFF locators).
   In the common deployment scenario, it is expected that the proxy-
   reply bit is set for SPI and SI mapping entries, resulting in the
   Map-Server proxy-replying to Map-Requests.  When such a Map-Server
   receives a Map-Request for an SPI and SI, the Map-Server returns in a
   Map-Reply the routing locators associated with the next hop,
   including their weights and priorities.  This is done by using the
   SPI LCAF as the EID record in the Map-Reply message.








Ermagan, et al.           Expires April 6, 2017                 [Page 4]


Internet-Draft                  LISP-NSH                    October 2016


5.1.  Packet Flow Example

   This section provides an example packet flow assuming that the NSH
   Classifier function (co-located in this example with a LISP ITR),
   classifies incoming traffic and imposes an NSH header (with the
   appropriate SPI and SI values).  Furthermore, a LISP xTR is co-
   located with every SFF participating in the service path in this
   example.

   1.  Upon receiving a packet with the NSH header, the LISP ITR creates
   a Map-Request (if needed) with the SPI and SI from the NSH header and
   forwards this request to the mapping system.  This request is
   eventually delivered to the Map-Server.

   2.  The Map-Server creates a LISP Map-Reply encoding the next hop
   RLOC for the requested SPI and SI, and sends this reply back to the
   requesting ITR.  The ITR then caches this mapping.

   3.  The ITR now encapsulates packets matching this SPI and SI, in a
   LISP-GPE header using the RLOC(s) returned in the mapping record, and
   setting the Next Protocol of the header to indicate a NSH payload.

   4.  When the LISP packet arrives at the destination ETR, the ETR
   decapsulates the packet and forwards to the co-located SFF.

   5.  When SFF needs to forward the serviced packet to the next hop in
   the Service Path, the packet with the updated NSH header (new SI
   value) is returned to co-located ITR, in which case, ITR continues as
   in step 1.

   6.  At the last hop SFF, the SFF removes the NSH header and returns
   the packet in its original form to the co-located ITR.  In this case
   the ITR performs normal LISP ITR processing as defined in .

6.  Acknowledgments

   NA in this version.

7.  IANA Considerations

   This draft includes no request to IANA.

8.  Security Considerations

   No additional security considerations are foreseen at this time.






Ermagan, et al.           Expires April 6, 2017                 [Page 5]


Internet-Draft                  LISP-NSH                    October 2016


9.  Normative References

   [LCAF]     Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", draft-ietf-lisp-lcaf-12 (work in
              progress), March 2016.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",  RFC 6830,
              January 2013.

   [LISP-GPE]
              Lewis, D., Agrawal, P., Kreeger, L., Maino, F., Quinn, P.,
              Smith, M., and N. Yadav, "LISP Generic Protocol
              Extension", draft-lewis-lisp-gpe-02 (work in progress).

   [NSH]      Quinn, P. and U. Elzur, "Network Service Header", draft-
              ietf-sfc-nsh-10 (work in progress), 2016.

   [SFC]      Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture",  RFC 7665, 2016.

   [VXLAN-GPE]
              Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
              Smith, M., Agrawal, P., Yong, L., Xu, X., Elzur, U., Garg,
              P., and D. Melman, "Generic Protocol Extension for VXLAN",
              draft-ietf-nvo3-vxlan-gpe-02 (work in progress).

Authors' Addresses

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

   Email: vermagan@cisco.com


   Paul Quinn
   Cisco Systems Inc
   55 Cambridge Parkway
   CAMBRIDGE, MA  02141
   USA

   Email: paulq@cisco.com






Ermagan, et al.           Expires April 6, 2017                 [Page 6]


Internet-Draft                  LISP-NSH                    October 2016


   Darrel Lewis
   Cisco Systems Inc
   170 W Tasman Dr
   San Jose, CA  95134
   USA

   Email: darlewis@cisco.com


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

   Email: fmaino@cisco.com


   Florin Coras
   Cisco Systems Inc

   Email: fcoras@cisco.com





























Ermagan, et al.           Expires April 6, 2017                 [Page 7]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/