Subject: Re: [Capwap] 2-Port/Mux Issue Discussion

From: "Chiu, Ran-Fun" <[email-masked]>
Date: Thu, 5 Oct 2006 17:05:14 -0500

We prefer the two-port solution.

Ran-Fun Chiu
HP Labs

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Thursday, September 21, 2006 1:50 AM
> To: [email-masked]
> Subject: [Capwap] 2-Port/Mux Issue Discussion
> 
> 
> Hi All,
> 
> As many of you know, we have had a technical issue open in the CAPWAP
> WG for some time that is commonly referred to as the 2-port/mux
> issue.  This issue involves a technical choice between:
> 
> - A solution that uses two different well-known UDP ports for
> separate data and control communications (the 2-port solution),
> 
> OR
> 
> - A solution that uses a single well-known UDP port for all
> communication, with control and data traffic distinguished by a
> CAPWAP header value (the mux solution).
> 
> Strong opinions have been expressed on both sides of this issue, and
> the WG has had trouble coming to consensus on a single choice.
> Discussions in this area have included a wide variety of networking
> topics, such as Quality of Service, NAT Traversal and Mobility.
> 
> Given the breadth of the technical issues under discussion, our Area
> Director, Dan Romascanu, decided to solicit advice from the IESG to
> help us understand the technical trade-offs, and to help us
> understand which factors it would be reasonable to consider in our
> working group decision -- specifically whether or not it was
> reasonable for us to consider the hardware implications of this
> decision.  The only IESG members who showed up for the discussion
> were Mark Townsley, one of the Internet ADs, and our two OPS ADs, Dan
> and David Kessens.  We didn't receive a definitive answer from the
> IESG, but a clear message was received from Mark Townsley that it is
> reasonable for the group to consider the hardware implications of our
> work -- both compatibility with currently deployed hardware, and the
> hardware architectures we might want to support in the future.
> 
> After much discussion with the interested IESG members, the document
> editors, the proponents of both solutions and some people who have
> proposed compromise solutions, the chairs believe that the key
> technical difference between these two proposals is which hardware
> architecture(s) they will support.  There are currently two different
> classes of AC hardware deployed, and variants on both of these
> architectures may be deployed in the future:
> 
> - Single-Processor:  In this architecture, the control plane and the
> data plane run on a single processor.  The demultiplexing of control
> and data packets happens on that processor.
> 
> - Separate Data & Control Planes:  In this architecture, the data and
> control planes run on separate processors (and possibly on separate
> cards), typically connected via a switching fabric.  This is a common
> hardware architecture for higher-end routing and switching hardware,
> and it relies on a port-based splitting/load-balancing approach to
> separate the control and data traffic.  For CAPWAP to work
> efficiently on these systems, it must be possible to distinguish the
> control and data traffic in the switching hardware, which is
> typically done based on the five-tuple of the send & recv IP
> addresses, the protocol (UDP), and the send & recv port numbers.  The
> switching hardware cannot do the type of deep packet inspection
> required to demultiplex on CAPWAP header fields.
> 
> The 2-port approach supports both the "Single-Processor" AC
> architecture and the "Separate Data & Control Planes" AC
> architecture.  Proponents of this solution believe that it is
> important to support the "Separate Data & Control Planes"
> architecture efficiently, both for compatibility with currently
> deployed hardware and to allow this hardware architecture to be used
> for future CAPWAP-enabled products.
> 
> The mux approach will only operate efficiently on "Single-Processor"
> systems. as it relies on the ability to demultiplex the control and
> data traffic using CAPWAP header information.  Proponents of this
> solution believe that it will simplify CAPWAP software
> implementation, and that it makes NAT traversal (when the AC and the
> WTPs are on different sides of a NAT) simpler to configure.
> 
> This complexity is a consequence of the choice to tunnel all WLAN
> data traffic to the AC.  In split-MAC local-forwarding mode, only the
> control plane traffic would be sent to the AC, and data plane
> forwarding would be handled by the WTPs themselves.
> 
> We've heard from a couple of strong voices on this issue. but now
> we'd like to hear from the rest of the WG...
> 
> Which hardware architecture(s) does the CAPWAP protocol needs to
> support?
> 
> Specifically, do you think that it should be a requirement to
> support efficient operation on currently deployed and future ACs that
> follow the "Separate Control & Data Planes" architecture described
> above?  Or do you think that it would be acceptable to produce a
> somewhat cleaner and simpler protocol that will not work efficiently
> on those ACs?
> 
> Please send your response by Thursday, October 5th (two weeks from
> today), so that the chairs can gauge the consensus of the WG in this
> matter.
> 
> After we have an understanding of which hardware architecture(s) the
> CAPWAP protocol needs to support, we will make an effort to sort
> through the various proposals and counter-proposals that meet that
> requirement.
> 
> Thanks,
> 
> The CAPWAP Chairs
> Dorothy Gellert, Mahalingam Mani & Margaret Wasserman
> 
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 6 Oct 2006 15:39:12 -0700

I fully support the two port approach, and thank Margaret for clearly
describing the issue.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> As many of you know, we have had a technical issue open in 
> the CAPWAP WG for some time that is commonly referred to as 
> the 2-port/mux issue.  This issue involves a technical choice between:
> 
> communication, with control and data traffic distinguished by 
> a CAPWAP header value (the mux solution).
> 
> Discussions in this area have included a wide variety of 
> networking topics, such as Quality of Service, NAT Traversal 
> and Mobility.
> 
> Given the breadth of the technical issues under discussion, 
> our Area Director, Dan Romascanu, decided to solicit advice 
> from the IESG to help us understand the technical trade-offs, 
> and to help us understand which factors it would be 
> reasonable to consider in our working group decision -- 
> specifically whether or not it was reasonable for us to 
> consider the hardware implications of this decision.  The 
> only IESG members who showed up for the discussion were Mark 
> Townsley, one of the Internet ADs, and our two OPS ADs, Dan 
> and David Kessens.  We didn't receive a definitive answer 
> from the IESG, but a clear message was received from Mark 
> Townsley that it is reasonable for the group to consider the 
> hardware implications of our work -- both compatibility with 
> currently deployed hardware, and the hardware architectures 
> we might want to support in the future.
> 
> After much discussion with the interested IESG members, the 
> document editors, the proponents of both solutions and some 
> people who have proposed compromise solutions, the chairs 
> believe that the key technical difference between these two 
> proposals is which hardware
> architecture(s) they will support.  There are currently two 
> different classes of AC hardware deployed, and variants on 
> both of these architectures may be deployed in the future:
> 
> - Single-Processor:  In this architecture, the control plane 
> and the data plane run on a single processor.  The 
> demultiplexing of control and data packets happens on that processor.
> 
> - Separate Data & Control Planes:  In this architecture, the 
> data and control planes run on separate processors (and 
> possibly on separate cards), typically connected via a 
> switching fabric.  This is a common hardware architecture for 
> higher-end routing and switching hardware, and it relies on a 
> port-based splitting/load-balancing approach to separate the 
> control and data traffic.  For CAPWAP to work efficiently on 
> these systems, it must be possible to distinguish the control 
> and data traffic in the switching hardware, which is 
> addresses, the protocol (UDP), and the send & recv port 
> numbers.  The switching hardware cannot do the type of deep 
> packet inspection required to demultiplex on CAPWAP header fields.
> 
> architecture efficiently, both for compatibility with 
> currently deployed hardware and to allow this hardware 
> architecture to be used for future CAPWAP-enabled products.
> 
> systems. as it relies on the ability to demultiplex the 
> control and data traffic using CAPWAP header information.  
> Proponents of this solution believe that it will simplify 
> CAPWAP software implementation, and that it makes NAT 
> traversal (when the AC and the WTPs are on different sides of 
> a NAT) simpler to configure.
> 
> This complexity is a consequence of the choice to tunnel all 
> WLAN data traffic to the AC.  In split-MAC local-forwarding 
> mode, only the control plane traffic would be sent to the AC, 
> and data plane forwarding would be handled by the WTPs themselves.
> 
> We've heard from a couple of strong voices on this issue. but 
> now we'd like to hear from the rest of the WG...
> 
> Which hardware architecture(s) does the CAPWAP protocol needs 
> to support?
> 
> support efficient operation on currently deployed and future 
> ACs that follow the "Separate Control & Data Planes" 
> architecture described above?  Or do you think that it would 
> be acceptable to produce a somewhat cleaner and simpler 
> protocol that will not work efficiently on those ACs?
> 
> Please send your response by Thursday, October 5th (two weeks 
> from today), so that the chairs can gauge the consensus of 
> the WG in this matter.
> 
> After we have an understanding of which hardware 
> architecture(s) the CAPWAP protocol needs to support, we will 
> make an effort to sort through the various proposals and 
> counter-proposals that meet that requirement.
> 
> Thanks,
> 
> The CAPWAP Chairs