Internet DRAFT - draft-ao-sfc-transport
draft-ao-sfc-transport
SFC WG T. Ao
Internet-Draft ZTE Corporation
Intended status: Informational W. Wei
Expires: April 23, 2019 Y. Zheng
ZTE Corp.
October 20, 2018
SFC transport considertation
draft-ao-sfc-transport-00
Abstract
A Network Service Header(NSH) is imposed encapsulates a packet or a
frame for Service Function Chaining. The resulting packet, in turn,
is encapsulate according to transport layer. The NSH contains a
Service Path Identifier (SPI) and a Service Index (SI). The SPI is,
as per its name, an identifier. The SPI alone cannot be used to
forward packets along a service path. Rather, the SPI provides a
level of indirection between the service path / topology and the
network transport encapsulation. For different transport
encapsulations, this document provides the format information with
transport and NSH, and gives operational constraints that transport
technologies, used by NSH need to meet.
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 23, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ao, et al. Expires April 23, 2019 [Page 1]
Internet-Draft SFC transport consideration October 2018
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
2. Conventions used in this document . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Ethernet as transport . . . . . . . . . . . . . . . . . . . . 4
3.1. Format in encapsulation . . . . . . . . . . . . . . . . . 4
3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 5
4. VXLAN-GPE as transport . . . . . . . . . . . . . . . . . . . 6
4.1. Format in encapsulation . . . . . . . . . . . . . . . . . 6
4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6
5. GRE as transport . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Format in encapsulation . . . . . . . . . . . . . . . . . 7
5.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 7
6. GENEVE as transport . . . . . . . . . . . . . . . . . . . . . 8
6.1. Format in encapsulation . . . . . . . . . . . . . . . . . 8
6.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informational References . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
For SFC using NSH, NSH is imposed on original packets/frames. NSH
hearder format is defined in [RFC8300] as Figure 1. NSH is transport
encapsulation agnostic, and SFC packet can't be forwarded or
transmitted along without the transport layer support. So how does
the different transport technologies bear SFC service traffic is what
is discussed in this document.
Ao, et al. Expires April 23, 2019 [Page 2]
Internet-Draft SFC transport consideration October 2018
+------------------------------+
| Transport Encapsulation |
+------------------------------+
| Network Service Header (NSH) |
+------------------------------+
| Original Packet / Frame |
+------------------------------+
Figure 1
Figure 1: Network Service Header Encapsulation
The NSH is composed of a 4-byte Base Header, a 4-byte Service Path
Header, and optional Context Headers, as shown in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Context Header(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
Figure 2: Network Service Header
In the Base Header part, a Next Protocol field is provided to
indicate the protocol type of the payload. The value definition is:
o 0x1: IPv4
o 0x2: IPv6
o 0x3: Ethernet
o 0x4: NSH
o 0x5: MPLS
o 0xFE: Experiment 1
o 0xFF: Experiment 2
This document describes SFC packet over different transport networks,
and defines the format for NSH with these different transport
Ao, et al. Expires April 23, 2019 [Page 3]
Internet-Draft SFC transport consideration October 2018
protocol. For some situations, some operational constraints also
described.
2. Conventions used in this document
2.1. Terminology
SFC(Service Function Chain): An ordered set of some abstract SFs.
SFF: Service Function Forwarder
SF: Service Function
NVE: Network Virtualization Edge
VXLAN-GPE: VXLAN Generic Protocol Extension
GENEVE: Generic Network Virtualization Encapsulation
GRE: Generic Routing Encapsulation
2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Ethernet as transport
3.1. Format in encapsulation
In an Ethernet network, Ethernet is as transport for SFC traffic.
The format for Ethernet to tranport SFC packet should be as Figure 3.
Ao, et al. Expires April 23, 2019 [Page 4]
Internet-Draft SFC transport consideration October 2018
+-----------------------------+--------------------------------+---------------------------+
| L2 Header, EtherType=0x894F | NSH Header, Next Protocol=0x01 | Original IPv4 Packet |
+-----------------------------+--------------------------------+---------------------------+
Ethernet+ NSH IPv4 packet
+-----------------------------+--------------------------------+---------------------------+
| L2 Header, EtherType=0x894F | NSH Header, Next Protocol=0x03 | Original L2 frame |
+-----------------------------+--------------------------------+---------------------------+
Ethernet+ NSH L2 frame
Figure 3 NSH in Ethernet
Figure 3: NSH in Ethernet
3.2. Operation
1.The Classifier classifies the original packets according to its
policies and attach the NSH header. If the network transport is
Ethernet, before the Classifier forwards the packet, it adds a L2
Header as the outer header. In the outer L2 header, the source MAC
address is the MAC address of the Classifier, and the destination MAC
address is the MAC address of the first SFF.
For the VLAN ID in the L2 header, there should be a policy for impose
a VLAN ID. If the original packet is IP Packet, the VLAN ID relies
on the Service Function Path assigned to the packet which virtual
network it belongs.
2.The SFF receives SFC packet from a network interface, checks the
SPI and SI in the NSH-to-SF Mapping table, per [RFC8300], to get the
locator of SF attached to it, that is MAC address if the transport is
Ethernet. SFF modifies the L2 Header to be the destination MAC
addess is the SF MAC address, and the source MAC address is the MAC
address of the SFF, and then forwards the SFC packet to the SF
attached to this SFF. After the processing, the SF will decrement SI
in the NSH by a value of 1, and will swap the source MAC address with
the destination MAC address of the outer L2 Header, and then the SFC
packet is forwarded back to the SFF. Once the SFF receives the SFC
packet from SF interface, it will check the SFI and SI in the NSH-to-
SF Mapping table again to get the locator of next SFF, that is MAC
address of the next SFF if the transport is Ethernet. SFF should
modify the L2 Header again to be the the destination MAC address is
the next SFF address, and the source MAC address is the MAC address
of the SFF.
3.When the last SFF receive the SFC packet from the SF attaching to
it, it will check the SPI and SI in the NSH-to-SF Mapping table,
finding it's the end of the Service Function Path, so it should strip
Ao, et al. Expires April 23, 2019 [Page 5]
Internet-Draft SFC transport consideration October 2018
the outer L2 Header and NSH Header before it send out the original
packet .
4. VXLAN-GPE as transport
4.1. Format in encapsulation
In an overlay network, VXLAN-GPE is as transport for SFC traffic.
The format for VXLAN-GPE to transport SFC packet should be as
Figure 4. Here assuming the overlay networks are built on Ethernet.
+----------+------------------------+---------------------+--------------+---------------------+
|L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)|NSH, NP=0x1 |original IPv4 packet |
+----------+------------------------+---------------------+--------------+---------------------+
VXLAN-GPE+ NSH IPv4 packet
+----------+------------------------+---------------------+--------------+---------------------+
|L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)|NSH,NP=0x3 |original L2 frame |
+----------+------------------------+---------------------+--------------+---------------------+
VXLAN-GPE+ NSH L2 frame
Figure 4 NSH in VXLAN-GPE
Figure 4: NSH in Vxlan-GPE
4.2. Operation
1.The Classifier classifies the original packets according to the
classify its policies and attaches the NSH header. If the network
transport is VXLAN-GPE, before the Classifier forward the packet, it
should add a VXLAN-GPE header first, and then UDP header and IP
header. UDP destination port should be 4790 which means the traffic
should send to NVE, which has been specified in
[I-D.ietf-nvo3-vxlan-gpe]. The destination IP address should be the
IP address of the NVE that the first SFF located. For the VNID in
the VXLAN-GPE header, there should be a policy for impose a VNID. If
the original frame has VLAN ID, there would be a mapping between VLAN
ID and VNID.
2.The SFF receives SFC packet from network interface, remove the
outer header and checks the SPI and SI in the NSH-to-SF Mapping table
in [RFC8300] to get the locator of SF attaching to it. If the
transport between the SFF and the SF attaching to the SFF is
Ethernet, the locator of SF in the NSH-to-SF Mapping table should be
MAC address. At this time, the SFC packet format from SFF to SF is
as the Figure 3 shows. So the destination MAC address of the outer
L2 header should be SF MAC address, and the source MAC address of the
Ao, et al. Expires April 23, 2019 [Page 6]
Internet-Draft SFC transport consideration October 2018
outer L2 header should be MAC address of the SFF. After the process,
the SF will decrement SI in the NSH by a value of 1, and exchange the
source MAC address the and destination MAC address of the outer L2
Header, and then the SFC packet is forwarded back to the SFF. Once
the SFF receive the SFC packet from SF interface, it will check the
SFI and SI in the NSH-to-SF Mapping table again to get the locator of
next SFF, that is MAC address of the next SFF if the transport is
Ethernet. SFF should modify the L2 Header again to be the
destination MAC address is the next SFF address, and the source MAC
address is the MAC address of the SFF.
3.When the last SFF receive the SFC packet from the SF attaching to
it, it will check the SPI and SI in the NSH-to-SF Mapping table,
finding it's the end of the Service Function Path, so it should strip
the outer L2 Header and NSH Header before it send out the original
packet .
5. GRE as transport
5.1. Format in encapsulation
In an overlay network, GRE is as tranport for SFC traffic. The
format for GRE to tranport SFC packet should be as Figure 5. Here
assuming the overlay networks are built on Ethernet.
+----------+------------------------+-------------------+--------------+----------------+
|L2 header | IP header, Proto=47 |GRE PT=NSH |NSH, NP=0x1 |original packet |
+----------+------------------------+-------------------+--------------+----------------+
GRE+ NSH IPv4 packet
+----------+------------------------+-------------------+---------------+---------------+
|L2 header | IP header, Proto=47 |GRE PT=NSH |NSH,NP=0x3 |original frame |
+----------+------------------------+-------------------+---------------+---------------+
GRE+ NSH L2 frame
Figure 5
Figure 5: NSH in GRE
5.2. Operation
To support the encapsulation, a new value for Protocol Type in GRE is
required.
Similar with VXLAN-GPE as transport. Will add later.
Ao, et al. Expires April 23, 2019 [Page 7]
Internet-Draft SFC transport consideration October 2018
6. GENEVE as transport
6.1. Format in encapsulation
In an overlay network, GENEVE is as STANDARD transport technology.
GENEVE also can be used as transport for SFC traffic. The format for
GENEVE to tranport SFC packet should be as Figure 6. Here assuming
the overlay networks are built on Ethernet.
+----------+------------------------+-----------------------+--------------+----------------+
|L2 header | IP + UDP dst port=6081 |GENEVE PT=NSH |NSH, NP=0x1 |original packet |
+----------+------------------------+-----------------------+--------------+----------------+
GRE+ NSH IPv4 packet
+----------+------------------------+----------------------+---------------+----------------+
|L2 header | IP + UDP dst port=6081 |GENEVE PT=NSH |NSH,NP=0x3 |original frame |
+----------+------------------------+----------------------+---------------+----------------+
GRE+ NSH L2 frame
Figure 6
Figure 6: NSH in GENEVE
6.2. Operation
To support the encapsulation, a new value for Protocol Type in GEVENE
is required.
Similar with operation in VXLAN-GPE transport. Details will be added
later.
7. Security Considerations
TBD.
8. IANA Considerations
TBD.
9. Acknowledgements
TBD.
10. References
Ao, et al. Expires April 23, 2019 [Page 8]
Internet-Draft SFC transport consideration October 2018
10.1. Normative References
[I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-08 (work in progress), October 2018.
[I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work
in progress), April 2018.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701,
DOI 10.17487/RFC1701, October 1994,
<https://www.rfc-editor.org/info/rfc1701>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
10.2. Informational References
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses
Ao, et al. Expires April 23, 2019 [Page 9]
Internet-Draft SFC transport consideration October 2018
Ting Ao
ZTE Corporation
No.889, BiBo Road
Shanghai 201203
China
Phone: +86 21 68897642
Email: ao.ting@zte.com.cn
Wei Wei
ZTE Corp.
No.50, Ruanjian Avenue
Nanjing
China
Email: wei.wei@zte.com.cn
Yan Zheng
ZTE Corp.
No.50, Ruanjian Avenue
Nanjing
China
Email: zheng.yan@zte.com.cn
Ao, et al. Expires April 23, 2019 [Page 10]
