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

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 https://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 4, 2019.

Copyright Notice

Copyright (c) 2018 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 (https://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. LISP Model of Service Function Chaining
• 3. Service Path Encoding
• 3.1. SPI LCAF
• 4. LISP ITR Processing
• 5. LISP Map-Server Processing
• 6. Packet Flow Example
• 7. Multiple Data Planes
• 8. Acknowledgments
• 9. IANA Considerations
• 10. Security Considerations
• 11. Normative References
• Authors' Addresses

1. Introduction

The Locator/ID Separation Protocol (LISP) [LISP] defines a control plane for driving dynamic network overlays, and can be used with various encapsulations such as VXLAN, LISP, LISP-GPE [LISP-GPE], VXLAN-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 [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 [LISP] or a service node [SFC] to use the LISP control plane for dynamically looking up the next hop's locator in the service path.

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.

    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.

    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 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

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

7. Multiple Data Planes

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

8. Acknowledgments

NA in this version.

9. IANA Considerations

This draft includes no request to IANA.

10. Security Considerations

No additional security considerations are foreseen at this time.

11. Normative References

Authors' Addresses