Re: [Tsvwg] [Capwap] ECN support when tunneling user packets in CAPWAP

[<[e-mail]>]

Hi Magnus, 

When we developed the capwap requirements years ago, we wanted to provide for the private corporate internel networks as well as implementations that traverse open IP networks, resulting in some hardware inplementations that target the closed network case.    For this reason, we didn't require full ECN support. 

In order to address your concerns in light of our WG operating procedures, and to prevent causing current implementations to barf, would you agree to allow the spec to require the limited ECN functionality option with text to note that full ECN functionality should be supported in environments that run across the open internet? 

We can then pursue your option to develop full ECN functionality in the next release. 

Would this approach meet your concerns?

Best Regards,
Dorothy
 


-----Original Message-----
From: ext Magnus Westerlund [mailto:[e-mail]] 
Sent: Wednesday, October 15, 2008 2:37 AM
To: capwap
Cc: tsvwg
Subject: [Capwap] ECN support when tunneling user packets in CAPWAP

Hi CAPWAP and TSVWG,

This email is to start off a public discussion about what support for ECN that the CAPWAP protocol
(http://tools.ietf.org/wg/capwap/draft-ietf-capwap-protocol-specification/)
should have. This is to resolve my Discuss.

For the TSVWG people, the CAPWAP protocol is a control protocol of wireless termination point (WTP), like 802.11 access points, from access control (AC). The capwap protocol also have an option to tunnel the wireless frames within the protocol. It is in this context that the usage of ECN is relevant. The wireless frames will commonly carry IP packets. Thus CAPWAP is among other things an IP in IP tunneling protocol, although with some extra layers in between the two IP.

So the issue here is what support of ECN should exist in the tunneling mechanism. ECN (RFC 3168) specifies two options for how tunnels can handle ECN, the full functionality option where ECN is enabled on the outer IP header and the relevant state at the tunnel egress is copied to the inner packet. The limited option where the outer header is set as ECN incapable. With the limited option what could have been a mark if the inner packet is ECN enabled becomes a packet drop thus lowering the utility of the ECN function. The ECN specification have the following wording in section 9.1.1:

   All IP tunnels MUST implement the limited-functionality option, and
   SHOULD support the full-functionality option.

>From my perspective I haven't seen any strong arguments why the 
>protocol
should only support the limited option. CAPWAP is intended to be used in access networks, that is a common location for congestion. Thus, the usage of ECN within this network can have real positive impact on the user applications. Also ECN has been a part of IP at standard track level since 2001 and continue to ignore this part of the IP for easy of implementation does not help improve the Internet. Therefore I really think CAPWAP SHOULD support full ECN. And with SHOULD I see it as there need to be real good reasons why this shouldn't be supported.

The complications with introducing the full ECN support option at this stage is two. One, there already exist implementations that uses this protocol as so far specified (although some updates will be required to cover other modifications found during the IETF last call and IESG review). These are likely to operate with limited option as the specification hasn't discussed ECN at all.

Secondly, there is the interoperability issue between the tunnel ingress and egress if one is going to have this being configurable. The tunnel ingress needs to know the support for ECN handling at the tunnel egress.
Thus the capwap protocol would need an extension to carry that information in each direction. The problem with a full functionality ingress and limited functionality egress is that packets that should have been marked or dropped comes through without indication of congestion.

Thus, the best option to take the current implementations into account and allow for deployment of full functionality where possible would be to add additional signaling to the CAPWAP protocol to indicate the capability of the egress to the ingress and configure the ingress correctly. If this can be introduced in a manner that doesn't make current implementations barf, then a nice incremental deployment story exist.

A second way to introduce full ECN functionality is simply to mandate it and live through a period with functionality failure towards any non specification compliant device.

So the questions are:

- Does they exist arguments that motivates support of limited ECN functionality only?

- Further arguments why CAPWAP really should support ECN?

- Am I over interpreting the requirement for supporting ECN?

Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap