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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Requirements notation
• 3. UDP Entropy Tunnel Encapsulation
• 4. Procedure to use UDP Entropy Tunnel Encapsulation
• 4.1. Ingress node procedure
• 4.2. Egress node procedure
• 5. Entropy ID Sub-TLV
• 6. IANA Considerations
• 7. Security Considerations
• 8. Acknowledgement
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

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 [RFC2119].

3. UDP Entropy Tunnel Encapsulation

This section defines the UDP Entropy Tunnel encapsulation format 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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   +--------+    +--------+

			

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:

• Generate Entropy value using any hashing algorithm and populate the Source port with the value.
• Copy the "Entropy ID" value received from remote endpoint to E-ID field.
• Populate the P-ID field with Softwire encapsulation protocol (e.g, L2TPv3, GRE-in-IP, IP-in-IP etc.)
• 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.

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.

8. Acknowledgement

The authors would like to thank Mark Townsley for his review and comments.

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses