Re: Proposed Text for Issue 254
From: Abhijit Choudhury (achoudhu) (achoudhucisco.com)
Date: Mon, 11 Jun 2007 11:10:54 -0700 (PDT)
I'm fine with that.
 
Thanks,
Abhijit
 
 
 


From: Dorothy Stanley [mailto:dstanley1389 [at] gmail.com]
Sent: Monday, June 11, 2007 11:06 AM
To: Margaret Wasserman
Cc: Abhijit Choudhury (achoudhu); capwap
Subject: Re: [Capwap] Proposed Text for Issue 254

Abjhit,

I suggest changing "IP protocol" to " transport-layer protocol
(UDP or UDP-Lite)" , as clarified by Margaret,
in the definitions:

 CAPWAP Control Channel: A bi-directional flow defined by the AC IP
 Address, WTP IP Address, AC control port, WTP control
 port and the transport-layer protocol (UDP or UDP-Lite) over which
CAPWAP control packets are sent and received.

CAPWAP Data Channel: A bi-directional flow defined by the AC IP
Address, WTP IP Address, AC data port, WTP data port,
and the transport-layer protocol (UDP or UDP-Lite) over which
CAPWAP data packets are sent and received.

Thanks,

Dorothy


On 6/11/07, Margaret Wasserman <mrw [at] lilacglade.org> wrote:

Hi Abjhit,

By "IP Protocol", do you mean transport-layer protocol?

I agree we should be identifying a CAPWAP connection by the five-
tuple including both IP addresses, the transport-layer protocol
(which will always be UDP or UDP-Lite) and the two UDP/UDP-Lite port
numbers.

Margaret

On Jun 6, 2007, at 7:42 PM, Abhijit Choudhury (achoudhu) wrote:

> I don't agree with this change.
>
> The issue is that if we don't include IP Protocol in the flow
> definition
>
> (i.e., use a 5-tuple as opposed to the 4 tuple), the definition
> becomes
> Ambigous.
>
> CAPWAP only uses UDP or UDP-Lite. So, if there happens to be a TCP
> flow
> between the WTP and AC (for whatever reason) with the same 4-tuple
> (AC IP Address, WTP IP Address, AC port and WTP port), it shouldn't
> qualify as a CAPWAP connection.  Without using the IP Protocol (UDP or
> UDP-lite)
> there is no way to distinguish between the TCP flow and the UDP/UDP-
> lite
> flow.
>
> I'm fine with the other editorial changes.
> So, I'd propose the following:
>
> <text>
>    CAPWAP Control Channel: A bi-directional flow defined by the AC IP
>    Address, IP Protocol, WTP IP Address, AC control port and WTP
> control
>    port, over which CAPWAP control packets are sent and received.
>
>    CAPWAP Data Channel: A bi-directional flow defined by the AC IP
> Address, WTP
>    IP Address, IP Protocol, AC data port and WTP data port, over which
>    CAPWAP data packets are sent and received.
> </text>
>
> Thanks,
> Abhijit
>
>
>
> -----Original Message-----
> From: Pat Calhoun (pacalhou)
> Sent: Wednesday, June 06, 2007 7:28 AM
> To: Abhijit Choudhury (achoudhu); capwap [at] frascone.com
> Subject: RE: [Capwap] Proposed Text for Issue 254
>
> Abhijit,
>
> In reviewing the latest draft before posting, Dorothy Stanley
> recommended changing the text in section 1.4 to the following:
>
> <text>
>    CAPWAP Control Channel: A bi-directional flow defined by the AC IP
>    Address, WTP IP Address, AC control port and WTP control
>    port, over which CAPWAP control packets are sent and received.
>
>    CAPWAP Data Channel: A bi-directional flow defined by the AC IP
> Address, WTP
>    IP Address, AC data port and WTP data port, over which
>    CAPWAP data packets are sent and received.
> </text>
>
> Are you ok with this?
>
> PatC
>
> ________________________________
>
> From: Abhijit Choudhury (achoudhu)
> Sent: Tuesday, April 24, 2007 7:26 PM
> To: capwap [at] frascone.com
> Subject: Re: [Capwap] Proposed Text for Issue 254
>
>
> Below is the proposed text for Issue 254, which has been updated based
> on feedback on the list.
>
> Thanks,
> Abhijit
>
> -------------------------PROPOSED
> TEXT---------------------------------------
>
> 1. Add the following to Terminology (Section 1.4)
>
>
>
>       CAPWAP Control Channel:  A bi-directional flow defined by AC's
> IP-Addr,
>
>        WTP's IP-Addr, IP protocol, AC's control port and WTP's control
> port,
>
>        over which CAPWAP control packets are sent.
>
>
>
>        CAPWAP Data Channel:  A bi-directional flow defined by IP-Addr,
>
>        WTP's IP-Addr,  IP protocol, AC's data port and WTP's data
> port,
>
>        over which CAPWAP data packets are sent.
>
>
>
> 2. In Section 3.1
>
>     Replace
>
>         CAPWAP protocol control packets sent between the WTP and
> the AC
> use
>         well known UDP port [to be IANA assigned].  CAPWAP protocol
> data
>         packets sent between the WTP and the AC use UDP port [to be
> IANA
>         assigned].
>
>     With
>          CAPWAP protocol control packets sent from the WTP to the
> AC use
>
>          the CAPWAP control channel, as defined in Section 1.4.  The
> CAPWAP
>          control port at the AC is the well known UDP port [to be IANA
> assigned]
>          while the control port at the WTP can be any port selected by
> the
>          implementation at the WTP. CAPWAP protocol data packets sent
> from
>          the WTP to the AC use the CAPWAP data channel, as defined in
> Section 1.4.
>          The CAPWAP data port at the AC is the well known UDP port [to
> be IANA
>          assigned], while the data port at the WTP can be any port
> selected by
>          the implementation at the WTP. In either case, for packets
> sent
> by the
>          AC to the WTP, the source and destination ports are reversed.
>
>
>
> 3. In Section 4.1
>
>     Replace
>
>          Payload Type:  A 4 bit field which specifies the payload type
> that
>           follows the preamble header.  The following values are
> supported:
>
>
>
>           0 -  Clear text.  If the packet is received on the data UDP
> port,
>              the CAPWAP stack MUST treat the packet as a clear text
> CAPWAP
>              data packet.  If received on the control UDP port, the
> CAPWAP
>              stack MUST treat the packet as a clear text CAPWAP
> control
>              packet.  If the control packet is not a Discovery Request
> or
>              Response packet, the packet MUST be dropped.
>
>
>
>           1 -  DTLS Payload.  The packet is a DTLS packet and MAY be a
> data
>              or control packet, based on the UDP port it was
> received on
>              (see Section 3.1).
>
>
>
>     With
>
>          Payload Type:  A 4 bit field which specifies the payload type
> that
>           follows the preamble header.  The following values are
> supported:
>
>
>
>           0 -  Clear text.  If the packet is received on the CAPWAP
> data
> channel,
>              the CAPWAP stack MUST treat the packet as a clear text
> CAPWAP
>              data packet.  If received on the CAPWAP control channel,
> the CAPWAP
>              stack MUST treat the packet as a clear text CAPWAP
> control
>              packet.  If the control packet is not a Discovery Request
> or
>              Response packet, the packet MUST be dropped.
>
>
>
>           1 -  DTLS Payload.  The packet is a DTLS packet and MAY be a
> data
>              or control packet, based on the channel it was
> received on
>              (see Section 3.1).
>
>
>
>
>
> 4. In Section 4.3
>
>    Replace
>
>       Both CAPWAP data messages are transmitted on the data channel
> UDP
> port.
>
>    With
>
>        Both CAPWAP data messages are transmitted on the data channel.
>
> _________________________________________________________________
> 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

Results generated by Tiger Technologies using MHonArc.