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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . 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, . 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]