Subject: [Softwires] Motivation for the IP-in-UDP draft

From: Xuxiaohu <[email-masked]>
Date: Mon, 25 Mar 2013 03:35:51 +0000

Hi all,

As suggested by WG co-chairs at IETF86, I would clarify the motivation for the IP-in-UDP draft (http://tools.ietf.org/html/draft-xu-softwire-ip-in-udp-01) as follows:

In a Softwire Mesh network, distinct customer (i.e. E-IP) traffic flows between a given AFBR pair would be encapsulated with the same IP-based tunnel headers prior to traversing the I-IP transit core. As such, it would be hard for transit routers to achieve a fine-grained load balancing of these tunneled traffic flows across the transit core due to the lack of adequate entropy information.

[RFC5640] describes a method for improving the load balancing efficiency in a network carrying Softwire Mesh service [RFC5565] over Layer Two Tunneling Protocol - Version 3 (L2TPv3) [RFC3931] and Generic Routing Encapsulation (GRE)[RFC2784] encapsulations. However, this method requires core routers to perform hash calculation on the "load-balancing" field contained in tunnel encapsulation headers (i.e., the Session ID field in L2TPv3 headers or the Key field in GRE headers), which is not widely supported by existing core routers. This situation has been affirmed by co-authors of the same RFC in a new draft (http://tools.ietf.org/html/draft-kumar-softwire-uet-00) (see below):

   "...[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..."

Since most existing core routers already support balancing IP traffic flows based on the hash of the five-tuple of UDP packets, by encapsulating Softwire service traffic into UDP tunnels with the source port field being used as an entropy field, it will enable existing core routers to perform efficient load-balancing of the Softwire service traffic without requiring any change to them. This is the motivation for the IP-in-UDP draft (http://tools.ietf.org/html/draft-xu-softwire-ip-in-udp-01).  

Any comments and suggestions are welcome. 

Best regards,
Xiaohu