| Re: Proposed Text for Issue 254 | <– Date –> <– Thread –> |
|
From: Dorothy Stanley (dstanley1389 |
|
| Date: Mon, 11 Jun 2007 11:06:17 -0700 (PDT) | |
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
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
- Re: Proposed Text for Issue 254, (continued)
-
Re: Proposed Text for Issue 254 Abhijit Choudhury (achoudhu), April 24 2007
-
Re: Proposed Text for Issue 254 Pat Calhoun (pacalhou), June 6 2007
- Re: Proposed Text for Issue 254 Abhijit Choudhury (achoudhu), June 6 2007
- Re: Proposed Text for Issue 254 Margaret Wasserman, June 11 2007
- Re: Proposed Text for Issue 254 Dorothy Stanley, June 11 2007
- Re: Proposed Text for Issue 254 Abhijit Choudhury (achoudhu), June 11 2007
-
Re: Proposed Text for Issue 254 Pat Calhoun (pacalhou), June 6 2007
-
Re: Proposed Text for Issue 254 Abhijit Choudhury (achoudhu), April 24 2007
Results generated by Tiger Technologies using MHonArc.