Service Function Chaining S. Kumar, Ed. Internet-Draft L. Kreeger, Ed. Intended status: Standards Track Cisco Systems, Inc. Expires: May 19, 2016 S. Majee F5 Networks W. Haeffner Vodafone R. Manur Broadcom D. Melman Marvell November 16, 2015 UDP Transport For Network Service Header draft-kumar-sfc-nsh-udp-transport-01 Abstract This draft describes the transport encapsulation to carry Network Service Header (NSH) over UDP protocol. This enables applications and services using NSH to communicate over a simple layer-3 network without topological constraints. It brings down the barrier to implement overlay transports by not requiring additional overhead as is typical of overlay mechanisms designed on top of UDP. As a first benefit, this method eases the deployment of Service Function Chaining (SFC) by allowing SFC components to utilize the basic UDP/IP stack available in virtually all network elements and end systems to setup the overlays and realize SFCs. 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 http://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 May 19, 2016. Kumar, et al. Expires May 19, 2016 [Page 1] Internet-Draft NSH UDP Transport November 2015 Copyright Notice Copyright (c) 2015 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 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. NSH UDP Overlay Transport . . . . . . . . . . . . . . . . . . 4 3.1. Stacking And Layering . . . . . . . . . . . . . . . . . . 4 3.2. NSH UDP Overlay Packet Format . . . . . . . . . . . . . . 4 3.3. Overlay Transport End-points . . . . . . . . . . . . . . 5 3.4. UDP Source Port Considerations . . . . . . . . . . . . . 6 3.5. Checksum Considerations . . . . . . . . . . . . . . . . . 6 3.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 7 3.7. Fragmentation Considerations . . . . . . . . . . . . . . 7 3.8. UDP-Lite Considerations . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction NSH is an encapsulation designed to carry SFC specific information and metadata. It is very flexible in providing fixed and variable length encapsulation options while allowing for a high degree of extensibility. NSH in addition allows for carrying a variety of packets as payload, there by being just a shim header between the inner payload and the outer transport. NSH focuses on the application aspect of the encapsulation while leaving the transport mechanisms out of scope. This design choice Kumar, et al. Expires May 19, 2016 [Page 2] Internet-Draft NSH UDP Transport November 2015 allows NSH to be carried on any overlay transport as required by the application and the use cases. The transport independence aspect of NSH makes it necessary for existing transport protocols or new ones to carry NSH encapsulated packet as a payload. Given that IP networks are ubiquitous with virtually every device, element, node connected to the IP network possessing the ability to support UDP datagram transport over IP layer, it is one of the most basic of the transports to carry NSH. UDP as a transport provides many benefits which has made it the de- facto choice for overlay networks such as VxLAN [RFC7348]. By nature it is a datagram service and trades reliability for simplicity and reduced overhead. It allows for sufficient entropy, for the network to exploit, in load balancing packets across paths in the network. Likewise, end hosts exploit it to distribute packets between the NICs and processor cores, within, for optimum performance. To this end, network elements and end hosts, both hardware and software, implement specific mechanisms to optimize UDP packet processing. UDP datagram service and efficient implementations of it in existing networks is thus a forgone conclusion. These benefits among others, coupled with extensibility aspect of NSH - to implement security, header verification, etc., makes UDP a very simple, widely available and foundational choice for transporting NSH encapsulated packets. This draft describes the creation of on-demand point-to-point lightweight NSH overlays using UDP as the overlay transport mechanism. 1.1. Requirements Language 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]. 2. Definition Of Terms This document uses some terms defined in SFC architecture [I-D.ietf-sfc-architecture] and NSH [I-D.ietf-sfc-nsh] drafts as mere examples for ease of understanding. Kumar, et al. Expires May 19, 2016 [Page 3] Internet-Draft NSH UDP Transport November 2015 3. NSH UDP Overlay Transport 3.1. Stacking And Layering A NSH encapsulated packet when carried over an UDP overlay transport looks as depicted in Figure 1. The original payload, L2 frame, L3 packet, NSH OAM message, etc., is first encapsulated in NSH shim header. The NSH encapsulated packet then becomes the payload for the UDP packet carried over an IPv4 or IPv6 network. The UDP header serves as the L4 overlay transport for NSH and its payload. Although depicted as a layer3 IP over an L2 network, nothing is assumed about how the L3 network is designed and deployed. It is entirely possible for IPinIP or MPLS or other underpinnings. +---------------------------------------------------------------+ | L2 (Ethernet) Header | | | +---------------------------------------------------------------+ | L3 (IPv4|IPv6) Header | | | +---------------------------------------------------------------+ | L4 UDP Header | | | +---------------------------------------------------------------+ | Network Service Header (NSH) | | | +---------------------------------------------------------------+ | NSH Payload | | (Original L2/L3 frame/packet or other as signaled by NSH) | | | +---------------------------------------------------------------+ Figure 1: NSH UDP Stack 3.2. NSH UDP Overlay Packet Format Figure 2 shows the format of the NSH encapsulation transported over UDP. Kumar, et al. Expires May 19, 2016 [Page 4] Internet-Draft NSH UDP Transport November 2015 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | Source Port = XXXXX | Dest Port = 6633 | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | Hdr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | UDP ~ Network Service Header (NSH) ~ | | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a | | y | | l ~ NSH Payload ~ o | (Original L2/L3 frame/packet or other as signaled by NSH) | a | | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Figure 2: NSH UDP Overlay Encapsulation Format Source Port : The UDP port number computed to provide entropy. See Section 3.4 for details. Dest Port : UDP port number assigned to NSH: 6633. Length : Length of the UDP payload. This includes both the UDP header and payload. Checksum : Standard UDP checksum or zero. NSH : The NSH encapsulation. NSH Payload : The original frame or packet being carried or OAM message, etc. 3.3. Overlay Transport End-points The UDP overlay transport extends between the two end-points involved in carrying the NSH overlay traffic. The control plane provisioning the NSH overlay MUST specify the location of the overlay destination when using UDP transport overlay, such as the IPv4 or IPv6 address of the end-point. Kumar, et al. Expires May 19, 2016 [Page 5] Internet-Draft NSH UDP Transport November 2015 In the case of SFC, this UDP overlay transport extends between two SFC components: Classifier and SFF or SFFs or SFF and SF or SFF and SFC-proxy. The destination of the UDP overlay transport is thus the IP address used by these components to receive the NSH overlay traffic. When UDP overlay transport is required to carry NSH encapsulated traffic, SFC control plane MUST provision the UDP overlay transport destination and the use of UDP overlay transport. 3.4. UDP Source Port Considerations The source port used in the UDP overlay transport SHOULD be computed to provide entropy for load balancing along the transmission path, including network elements such as routers and switches as well as end points such as servers. This behavior may in turn be controlled by local-policy at the encapsulating entity. The source UDP port number SHOULD stay constant and not change for the flow represented within the NSH payload. This is typically done by computing the source UDP port number as a hash over the invariant part of the NSH payload. This could be IP and UDP or IP and TCP part of the NSH payload when the next-protocol field in NSH base header is set to IPv4, for instance. This avoids inducing packet reordering due to the use of NSH UDP overlay transport. The recommended selection of source port as per [RFC6335], is the dynamic range: 49152-65535. A number in this range SHOULD be selected to reflect the NSH payload. 3.5. Checksum Considerations The checksum in the UDP header MAY be set to zero for performance or other implementation specific reasons by the entity encapsulating the NSH packet (classifier, SFF, SF-proxy or SF). The receiving entity thus MUST accept a UDP encapsulated NSH packet with zero UDP checksum. Implementations MAY choose to use non-zero checksum values. When a checksum other than zero is set by the encapsulating entity, it MUST be computed over the IP, UDP headers and the data as defined in the UDP specification [RFC0768]. The receiving entity thus MUST accept a UDP encapsulated NSH packet with non-zero UDP checksum. Receiving entities, of NSH UDP overlay packets with non-zero checksum, are RECOMMENDED to verify the checksum before accepting the packet. Kumar, et al. Expires May 19, 2016 [Page 6] Internet-Draft NSH UDP Transport November 2015 3.6. MTU Considerations Operators of networks deploying UDP overlay transport for NSH are RECOMMENDED to configure the MTU of the network to accommodate NSH and UDP transport encapsulation overhead. This prevents fragmentation of UDP overlay transport encapsulated NSH packets and the overhead of processing such fragments both in the network and the end-points. 3.7. Fragmentation Considerations Entities performing the UDP transport encapsulation MUST use the same source port number on all the fragments of the same packet when encapsulating pre-fragmented IP packets. 3.8. UDP-Lite Considerations Exercising the option of setting the NSH UDP encapsulation checksum to zero, does not protect the NSH header from errors introduced into the header during transmission. NSH provides extensibility for applications or future NSH extensions to build such bit error protection. Implementations that require protection against bit errors MAY use UDP-lite [RFC3828] with checksum coverage covering the NSH header. UDP-lite shares the UDP name space but uses the IP protocol identifier to distinguish itself from UDP. 4. IANA Considerations IANA is requested to de-assign the well-known UDP port number 6633 and re-assign it for the purpose defined in this draft. 5. Security Considerations Encapsulating NSH in UDP does not alter the security risk of NSH encapsulation and payload. Security of the payload encapsulated by NSH is as defined in [I-D.ietf-sfc-nsh] 6. References 6.1. Normative References [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-01 (work in progress), July 2015. Kumar, et al. Expires May 19, 2016 [Page 7] Internet-Draft NSH UDP Transport November 2015 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, . 6.2. Informative References [I-D.ietf-sfc-architecture] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", draft-ietf-sfc-architecture-11 (work in progress), July 2015. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . Authors' Addresses Surendra Kumar (editor) Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US Email: smkumar@cisco.com Kumar, et al. Expires May 19, 2016 [Page 8] Internet-Draft NSH UDP Transport November 2015 Larry Kreeger (editor) Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US Email: kreeger@cisco.com Sumandra Majee F5 Networks 90 Rio Robles San Jose, CA 95134 US Email: S.Majee@F5.com Walter Haeffner Vodafone Ferdinand-Braun-Platz 1 Duesseldorf 40549 DE Email: walter.haeffner@vodafone.com Rajeev Manur Broadcom Email: rmanur@broadcom.com David Melman Marvell Email: davidme@marvell.com Kumar, et al. Expires May 19, 2016 [Page 9]