UDP Entropy Tunnel for Softwire
Author(s): Pradosh Mohapatra, Carlos Pignataro, Clarence Filsfils, Nagendra Kumar
This document describes a method for encapsulatation of tunneled packets within UDP in order to provide per-flow entropy for load- balancing. The method is targeted for use with softwire mesh deployments that include routers which have support for...
softwire C. Pignataro Internet-Draft N. Kumar Intended status: Standards Track P. Mohapatra Expires: August 22, 2013 C. Filsfils Cisco Systems, Inc. February 18, 2013 UDP Entropy Tunnel for Softwire draft-kumar-softwire-uet-00 Abstract This document describes a method for encapsulatation of tunneled packets within UDP in order to provide per-flow entropy for load- balancing. The method is targeted for use with softwire mesh deployments that include routers which have support for load- balancing based on UDP ports and not fields in L2TPv3 or GRE. 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 August 22, 2013. Copyright Notice Copyright (c) 2013 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 Pignataro, et al. Expires August 22, 2013 [Page 1] Internet-Draft UET-Softwire February 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 3. UDP Entropy Tunnel Encapsulation . . . . . . . . . . . . . . . 3 4. Procedure to use UDP Entropy Tunnel Encapsulation . . . . . . . 4 4.1. Ingress node procedure . . . . . . . . . . . . . . . . . . 5 4.2. Egress node procedure . . . . . . . . . . . . . . . . . . . 5 5. Entropy ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Pignataro, et al. Expires August 22, 2013 [Page 2] Internet-Draft UET-Softwire February 2013 1. Introduction [RFC5565] explains how routing information in BGP and data packets in L2TPv3 or GRE are tunneled from one edge of an IPv4 network, over IPv6, to another IPv4 network or from one edge of an IPv6 network, over IPv4, to another IPv6 network. [RFC5640] describes how to encode and load-balance specific flows by utilizing the L2TPv3 Session ID or GRE Key field. While implementations and deployments exist, not as many routers support the per-hop behavior described in [RFC5640] compared to routers that support load-balancing based on UDP ports. In cases where [RFC5640] is not supported on the intervening network where tunneled packets traverse and where load-balancing is desirable, UDP may be used in order to encode additional entropy for routers to perform more granular load-balancing. In addition to entropy information for more granular load-balancing, use of the "UDP Entropy Tunnel" encapsulation defined in this document allows egress devices to identify additional information about the type of softwire packet being carried. UET encapsulation defined in this document appends Entropy ID assigned and advertised by tunnel tailend node to Protocol ID and encode the same as Destination port of UDP while using the source port field to carry Entropy value. Each edge node is expected to assign a minimum of one Entropy ID which makes the ingress node to maintain one Entropy ID per egress node. This document does not aim to deprecate or replace [RFC5640], but to provide an alternative when there is no specific support for load- balancing based on L2TPv3, GRE, or other softwire encapsulation types. 2. Requirements notation 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]. 3. UDP Entropy Tunnel Encapsulation This section defines the UDP Entropy Tunnel encapsulation format as below: Pignataro, et al. Expires August 22, 2013 [Page 3] Internet-Draft UET-Softwire February 2013 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 (entropy value) | E-ID | P-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Softwire Tunnel (Variable) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Port Resulting Entropy value (using any hashing algorithm) is populated in this field. E-ID Entropy Identifier, used to identify UDP Entropy Tunnel. P-ID Protocol Identifier, used to identify the softwire service. UDP Length As defined in [RFC0768] UDP Checksum Set to zero. 4. Procedure to use UDP Entropy Tunnel Encapsulation Below is a sample toplogy where softwire tunnel is used to deliver payload between Client network, +--------+ +--------+ +--------+ +--------+ | Client | | Ingress| _ _ _ _ _ | Egress | | Client | | Network|====| Node |()_ _ _ _ _()| Node |====| Network| +--------+ +--------+ softwire +--------+ +--------+ Pignataro, et al. Expires August 22, 2013 [Page 4] Internet-Draft UET-Softwire February 2013 4.1. Ingress node procedure Any Ingress node on sending traffic through softwire tunnel and if no Entropy ID is received from remote endpoint via BGP or other encapsulation signaling protocol, MUST NOT use UDP Entropy tunnel. Any Ingress node on sending traffic through softwire tunnel and if an Entropy ID is received from remote endpoint via BGP or other encapsulation signaling protocol, MUST encapsulate with UDP Entropy tunnel as below: o Generate Entropy value using any hashing algorithm and populate the Source port with the value. o Copy the "Entropy ID" value received from remote endpoint to E-ID field. o Populate the P-ID field with Softwire encapsulation protocol (e.g, L2TPv3, GRE-in-IP, IP-in-IP etc.) o Set the UDP checksum value as zero as described in [I-D.ietf-6man-udpchecksums] and [I-D.ietf-6man-udpzero]. The Ingress node further adds IP header to the above encapsulated UDP based UDP Entropy tunnel header and send across the core to egress node. 4.2. Egress node procedure When any node is enabled with UDP based entropy, it assigns a locally significant 8 bits Entropy ID. While any signaling protocol can be used to advertise this assigned Entropy ID to other nodes, Section 5 of this document describes one mechanism using Tunnel Encapsulation Attribute [RFC5512]. At the egress node, if the E-ID (See Section 3) of the UDP packet matches locally assigned Entropy ID, MUST use P-ID field (See Section 3) to identify the Softwire encapsulation protocol. When any node receives UDP Entropy Tunnel encapsulated packet and if P-ID field doesnt match any of the locally configured softwire service MUST drop the packet. When any node receives traffic over softwire tunnel without UDP Entropy Tunnel encapsulation MUST decapsulate the softwire encapsulation and process the packet further. Pignataro, et al. Expires August 22, 2013 [Page 5] Internet-Draft UET-Softwire February 2013 5. Entropy ID Sub-TLV Any node that is enabled with UDP based entropy, MUST inlcude Entropy ID Sub-TLV (Type = 6) in Tunnel Encapsulation Attribute [RFC5512]. This Sub-TLV is of 4 octets length and can be used with any Tunnel type proposed in [RFC5512] or any new tunnel type proposed in future. The Entropy ID carried in this Sub-TLV is a 1 octet value and is locally significant to the assigning edge node. While it is a local matter, this document recommends to assign a single Entropy ID for all Softwire transport enabled and advertise the same with all tunnel type. Considering the number of available softwire transport options, 8 bit of Entropy ID is sufficient to handle single Entropy ID for all softwire transport or Entropy ID per softwire transport implementations. This document also strongly recommends to continue advertise Load- balancing Block Sub-TLV [RFC5640] along with Entropy ID Sub-TLV. If an ingress node does not support Entropy ID Sub-TLV, softwire load balancing for L2TPv3-over-IP or GRE can be acheived by procedure specified in [RFC5640]. The encoding of the Sub-TLV is as 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Entropy ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Reserved for future use. Entropy ID Entropy Identifier, used to identify UDP Entropy Tunnel. 6. IANA Considerations IANA is requested to assign Sub-TLV type = 6 for Entropy-ID Sub-TLV, in the BGP Tunnel Encapsulation Attribute Sub-TLVs registry. 7. Security Considerations Same security considerations described in [RFC5512], [RFC5640], and [I-D.ietf-6man-udpchecksums] are applicable. Pignataro, et al. Expires August 22, 2013 [Page 6] Internet-Draft UET-Softwire February 2013 8. Acknowledgement The authors would like to thank Mark Townsley for his review and comments. 9. References 9.1. Normative References [I-D.ietf-6man-udpchecksums] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", draft-ietf-6man-udpchecksums-07 (work in progress), January 2013. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 0768, August 1980. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC5512, April 2009. [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC5565, June 2009. [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- Balancing for Mesh Softwires", RFC5640, August 2009. 9.2. Informative References [I-D.ietf-6man-udpzero] Fairhurst, G. and M. Westerlund, "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums", draft-ietf-6man-udpzero-10 (work in progress), January 2013. Pignataro, et al. Expires August 22, 2013 [Page 7] Internet-Draft UET-Softwire February 2013 Authors' Addresses Carlos Pignataro Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709-4987 US Email: firstname.lastname@example.org Nagendra Kumar Cisco Systems, Inc. Cessna Business Park, Outer Ring Road Bangalore, KARNATAKA 560108 INDIA Email: email@example.com Pradosh Mohapatra Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 US Email: firstname.lastname@example.org Clarence Filsfils Cisco Systems, Inc. Brussels 1000 BELGIUM Email: email@example.com Pignataro, et al. Expires August 22, 2013 [Page 8]