LISP Working Group V. Ermagan Internet-Draft P. Quinn Intended status: Experimental D. Lewis Expires: October 4, 2016 F. Maino Cisco Systems Inc F. Coras Technical University of Catalonia April 2, 2016 LISP Control Plane integration with NSH draft-ermagan-lisp-nsh-01 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 October 4, 2016. 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 October 4, 2016 [Page 1] Internet-Draft LISP-NSH April 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) [RFC6830] 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 October 4, 2016 [Page 2] Internet-Draft LISP-NSH April 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 October 4, 2016 [Page 3] Internet-Draft LISP-NSH April 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 October 4, 2016 [Page 4] Internet-Draft LISP-NSH April 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 [RFC6830]. 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 October 4, 2016 [Page 5] Internet-Draft LISP-NSH April 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-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-04 (work in progress), March 2016. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [SFC] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC Service Function Chaining (SFC) Architecture, 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-01 (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 October 4, 2016 [Page 6] Internet-Draft LISP-NSH April 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 Technical University of Catalonia Barcelona Spain Email: fcoras@ac.upc.edu Ermagan, et al. Expires October 4, 2016 [Page 7]