Internet DRAFT - draft-fourie-nvo3-nsh-geneve-encap
draft-fourie-nvo3-nsh-geneve-encap
Network Working Group L. Fourie
Internet-Draft H. Zhang
Intended Status: Proposed Standard F. Sunavala
Expires: February 19, 2017 Huawei
J. McDowall
Palo Alto Networks
August 18, 2016
NSH Encapsulation in Geneve
draft-fourie-nvo3-nsh-geneve-encap-00
Abstract
This document describes how the Network Server Header (NSH) used for
service chaining is encapsulated in Geneve tunnel TLV metadata.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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
Fourie, et al Expires February 19, 2017 [Page 1]
Internet-Draft NSH Encapsulation in Geneve August 18, 2016
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. NSH Encapsulation in Geneve. . . . . . . . . . . . . . . . . . 4
5.1 Geneve Encapsulation Headers . . . . . . . . . . . . . . . . 4
5.2 Geneve NSH Service Path TLV . . . . . . . . . . . . . . . . 5
5.3 Geneve NSH MD Type-1 Context TLV . . . . . . . . . . . . . . 5
5.4 Geneve NSH MD Type-2 Context TLV . . . . . . . . . . . . . . 6
5.5 Example Geneve Header . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . . 7
8.2 Informative References . . . . . . . . . . . . . . . . . . 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Fourie, et al Expires February 19, 2017 [Page 2]
Internet-Draft NSH Encapsulation in Geneve August 18, 2016
1. Introduction
Network Service Header (NSH) [SFC-NSH] is a protocol used to create of
Service Function Chains (SFC) [RFC7665]. As such, NSH provides Service
Function Path identification and the transport of metadata between
Service Functions.
NSH is independent of the underlying transport mechanism and may be
encapsulated in a number of different transports. The presence of NSH in
the outer transport is indicated by a protocol type or other indicator
in the outer encapsulation.
An example of NSH encapsulation in GRE from the NSH specification [SFC-
NSH] is shown here.
+----------+--------------------+--------------------+
|L2 header | L3 header, proto=47|GRE header,PT=0x894F|
+----------+--------------------+--------------------+
-------------+----------------+
NSH, NP=0x1 |Original packet |
-------------+----------------+
Figure 1: NSH in GRE Encapsulation
Geneve [GENEVE] is an IP-based transport tunnel protocol between
hypervisors and other devices used in network virtualization
environments such as the modern data center. One of the primary
characteristics of Geneve is its ability to carry a large amount of
metadata within the packet header in a flexible manner through the use
of Type-Length-Value (TLV) elements.
One example of a system using Geneve is Open Virtual Networking (OVN)
[OVN]. OVN is an open source network virtualization project which uses
Geneve TLVs to carry information between hypervisors to compose a
network. Current uses of the data include logical ingress and egress
ports but this will likely continue to evolve in the future.
There is currently no mechanism defined to transport NSH over Geneve.
This document describes a scheme to encapsulate NSH in Geneve TLV
metadata.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology
Fourie, et al Expires February 19, 2017 [Page 3]
Internet-Draft NSH Encapsulation in Geneve August 18, 2016
The terminology used in this document is from [RFC7665], [GENEVE] and
[OVN] and is summarized here for convenience:
Metadata: Provides contextual information about data packets.
Service Function (SF): A network function that provides a value-added
service to packet flows. Service functions include: firewall, DPI
(Deep Packet Inspection), NAT, HTTP Header Enrichment function,
TCP optimizer, load-balancer, etc.
Service Function (SF) Chain: An ordered list of Service Function
instances.
SFC-enabled domain: Denotes a network (or a region thereof) that
implements SFC.
TLV: Type-Length-Value data structure. This is a variable length
structure used to transport optional Geneve metadata.
VNI: Virtual Network Identifier.
5. NSH Encapsulation in Geneve.
The NSH can be be transported in a number of Geneve TLVs. The following
Geneve TLVs must be used to transport the NSH:
1. NSH Service Path (NSH-SP) TLV
2. NSH MD Type-1 Context (NSH-MD1) TLV
3. NSH MD Type-2 Context (NSH-MD2) TLV
The fixed length NSH MD Type-1 Context field is mapped to the Geneve MD
Type-1 TLV. Each NSH MD Type-2 TLV present in the NSH is mapped to a
separate Geneve MD Type-2 TLV. There is no need to transport the NSH
Base header as its information is already present in the Geneve header.
5.1 Geneve Encapsulation Headers
The Geneve encapsulation headers are shown below. The Geneve header is
followed by various NSH TLVs described in the following sections.
+----------+----------+----------------------+--------------+
|L2 header |L3 header |UDP header dport=6081 |Geneve header |
+----------+----------+----------------------+--------------+
---------+----------------+----------------+
NSH TLVs |Inner L2 header |Original packet |
---------+----------------+----------------+
Fourie, et al Expires February 19, 2017 [Page 4]
Internet-Draft NSH Encapsulation in Geneve August 18, 2016
Figure 2: NSH in Geneve Encapsulation
5.2 Geneve NSH Service Path TLV
The Geneve NSH Service Path TLV is shown below. The Geneve NSH-SP TLV
Class is defined in the section on IANA Considerations.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Geneve NSH-SP TLV Class | Type=0 |R|R|R| Len=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Geneve NSH Service Path TLV
The Service Path ID and the Service Index are mapped directly from the
NSH Service Path header.
5.3 Geneve NSH MD Type-1 Context TLV
The fixed length Geneve NSH MD-Type-1 Context TLV is shown below. The
Geneve NSH-MD1 TLV Class is defined in the section on IANA
Considerations.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Geneve NSH-MD1 TLV Class | Type |R|R|R| Len=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Geneve NSH MD Type-1 Context TLV
The Type field is used to identify the different content allocations for
various usage scenarios described in [CTX-DC], [CTX-BB] and [CTX-NS].
These are listed below.
Fourie, et al Expires February 19, 2017 [Page 5]
Internet-Draft NSH Encapsulation in Geneve August 18, 2016
+----------------+--------------------------------------+
| Type | Description |
+----------------+--------------------------------------+
| 0 | NSH MD Type-1 TLV - Data Center |
| 1 | NSH MD Type-1 TLV - Broadband |
| 2 | NSH MD Type-1 TLV - Network Security |
+----------------+--------------------------------------+
Other NSH Context header allocations may be introduced in the future and
new Type values will be assigned for them.
5.4 Geneve NSH MD Type-2 Context TLV
The variable length Geneve NSH MD Type-2 Context TLV is shown below. The
contents of this Geneve NSH MD Type-2 TLV is a NSH MD Type-2 TLV [SFC-
NSH], including the NSH TLV Class, Type, and Len fields followed by its
variable length contents. The Geneve NSH-MD2 TLV Class is defined in the
section on IANA Considerations.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Geneve NSH MD-2 TLV Class | Type=0 |R|R|R| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSH TLV Class |C| Type |R|R|R| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Variable Length TLV Contents ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Geneve NSH MD Type-2 Context TLV
5.5 Example Geneve Header
An example of the Geneve header with the NSH Service Path TLV and the
NSH MD Type-2 Context TLV is shown below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Opt Len |O|C| Rsvd. | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Geneve NSH-SP TLV Class | Type=0 |R|R|R| Len=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Geneve NSH-MD2 TLV Class | Type=0 |R|R|R| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSH TLV Class |C| Type |R|R|R| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Variable Length TLV Contents ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fourie, et al Expires February 19, 2017 [Page 6]
Internet-Draft NSH Encapsulation in Geneve August 18, 2016
Figure 6: Geneve Header with NSH-SP TLV and NSH-MD2 TLV
6. Security Considerations
Existing security protocols IPSec [RFC6071] may be used to encrypt the
content of a packet that includes the NSH. Existing security protocols
that provide authenticity and authorization can be used.
If possible, the NSH should be used in a controlled network with trusted
devices, for example, a data center or a Gi-LAN network, thus reducing
the risk of unauthorized header manipulation.
7. IANA Considerations
IANA is requested to assign additional Geneve Option Class values to
identify NSH TLVs as listed below.
Initially, the Experimental Geneve Option Class values 0xfffd-0xffff
will be used to identify NSH TLVs until the IANA assignment is granted.
+----------------+--------------------------------------+
| Option Class | Description |
+----------------+--------------------------------------+
| 0xfffd | NSH Service Path TLV |
| 0xfffe | NSH MD Type-1 Context TLV |
| 0xffff | NSH MD Type-2 Context TLV |
+----------------+--------------------------------------+
8. References
8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
February 2011.
[RFC7665] Halpern, J. and Pignataro, C., Service Function Chaining
(SFC) Architecture.
8.2 Informative References
Fourie, et al Expires February 19, 2017 [Page 7]
Internet-Draft NSH Encapsulation in Geneve August 18, 2016
[GENEVE] Gross, J. and Ganga, I., Geneve: Generic Network
Virtualization Encapsulation
<https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve-
01/>.
[OVN] Open Virtual Network Architecture
<http://openvswitch.org/support/dist-docs-2.5/ovn-
architecture.7.html>.
[SFC-NSH] Quinn, P. and Elzur, U., Network Service Header
<https://datatracker.ietf.org/doc/draft-ietf-sfc-
architecture/>.
[NSH-TLV] Quinn, P. et al, Network Service Header TLVs
<https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh-
tlv/>.
[CTX-DC] Guichard, J. et al, Network Service Header (NSH) Context
Header Allocation (Data Center)
<https://datatracker.ietf.org/doc/draft-guichard-sfc-nsh-
dc-allocation/>.
[CTX-BB] Meng, W. and Wang, C., NSH Context Header - Broadband
<https://datatracker.ietf.org/doc/draft-meng-sfc-nsh-
broadband-allocation/>.
[CTX-NS] Wang, E. and Leung, K. Network Service Header (NSH)
Context Header Allocation (Network Security)
<https://datatracker.ietf.org/doc/draft-wang-sfc-nsh-ns-
allocation/>.
10. Acknowledgments
The authors would like to thank Jesse Gross and Russell Bryant for their
review, comments and contributions.
Authors' Addresses
Louis Fourie
Huawei US R&D
EMail: louis.fourie@huawei.com
Hong (Cathy) Zhang
Huawei US R&D
EMail: cathy.h.zhang@huawei.com
Fourie, et al Expires February 19, 2017 [Page 8]
Internet-Draft NSH Encapsulation in Geneve August 18, 2016
Farhad Sunvala
Huawei US R&D
EMail: farhad.sunavala@huawei.com
John McDowall
Palo Alto Networks
Email: jmcdowall@paloaltonetworks.com
Fourie, et al Expires February 19, 2017 [Page 9]
