Internet DRAFT - draft-ermagan-lisp-nsh
draft-ermagan-lisp-nsh
LISP Working Group V. Ermagan
Internet-Draft P. Quinn
Intended status: Experimental D. Lewis
Expires: April 4, 2019 F. Maino
F. Coras
Cisco Systems Inc
October 1, 2018
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
Ermagan, et al. Expires April 4, 2019 [Page 1]
Internet-Draft LISP-NSH October 2018
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
6. Packet Flow Example . . . . . . . . . . . . . . . . . . . . . 4
7. Multiple Data Planes . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
10. Security Considerations . . . . . . . . . . . . . . . . . . . 5
11. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ermagan, et al. Expires April 4, 2019 [Page 2]
Internet-Draft LISP-NSH October 2018
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field definitions:
Ermagan, et al. Expires April 4, 2019 [Page 3]
Internet-Draft LISP-NSH October 2018
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.
Ermagan, et al. Expires April 4, 2019 [Page 4]
Internet-Draft LISP-NSH October 2018
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
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC8060.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013.
Ermagan, et al. Expires April 4, 2019 [Page 5]
Internet-Draft LISP-NSH October 2018
[LISP-GPE]
Maino, F., Lemon, J., Agrawal, P., Lewis, D., and M.
Smith, "LISP Generic Protocol Extension", draft-ietf-lisp-
gpe-06 (work in progress).
[NSH] Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header", RFC 8300.
[SFC] Halpern, J. and C. Pignataro, "Service Function Chaining
(SFC) Architecture", RFC 7665.
[VXLAN-GPE]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (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
Darrel Lewis
Cisco Systems Inc
170 W Tasman Dr
San Jose, CA 95134
USA
Email: darlewis@cisco.com
Ermagan, et al. Expires April 4, 2019 [Page 6]
Internet-Draft LISP-NSH October 2018
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 4, 2019 [Page 7]
