LISP Control Plane integration with NSH

The Locator/ID Separation Protocol (LISP) defines a control plane for driving dynamic network overlays, and can be used with various encapsulations such as VXLAN, LISP, LISP-GPE , VXLAN-GPE, NV-GRE. LISP-GPE/VXLAN-GPE defines a way for the LISP/VXLAN to support multi-protocol encapsulations; i.e. enabling encapsulation of any inner payload, including IP, Ethernet, and NSH . This document defines the necessary extensions to the LISP control plane to support driving a dynamic NSH-based service function chain ( map-and-encap based on SPI and SI). These extensions enable a LISP xTR or a service node to use the LISP control plane for dynamically looking up the next hop's locator in the service path.

The NSH header 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.

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

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

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 for a description of all LCAF fields.

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.

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.

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.

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 .

In a heterogeneous environment where different hops in a single service path have different data plane encapsulation capabilities, the supported encapsulation formats can be specified together with the locator mappings using the multiple data plane LCAF type 16. In such cases, xTR receiving a Map Reply with an RLOC encoded in LCAF type 16 can choose a matching encapsulation format among next hop's supported encapsulations.

NA in this version.

This draft includes no request to IANA.

No additional security considerations are foreseen at this time.