| RE: Another Way to Think about CAPWAP | <– Date –> <– Thread –> |
|
From: Pat R. Calhoun (pcalhoun |
|
| Date: Mon, 17 Nov 2003 19:02:43 -0600 (CST) | |
We should actually be creating at least 2 separate categories for
interchange:
Control - Configuration,statistics, events, actions - This could be a
TCP based stream to provide immediate indication as to whether the AP-AC
connection has been lost. Encrypted if necessary.
<PRC> I guess you'd better provide your definition of immediate, because
TCP doesn't provide this.
Data - This could be UDP/IP_in_IP encapsulation to avoid congestion. If
the packet is lost the original client will most likely re-transmit.
<PRC> Right - so don't forward 802.11 mac mgmt frames, and reconstruct
a protocol that does the same thing that 802.11 mac, except extend it
for every standard the IEEE publishes.
PatC
-----Original Message-----
From: Yang, Lily L [mailto:lily.l.yang [at] intel.com]
Sent: Monday, November 17, 2003 7:29 PM
To: Rama Krishna Prasad; James Kempf; Pat R. Calhoun; Paulo Francisco;
Jim Murphy; Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to Think about CAPWAP
BTW, while we are on it, may I ask why UDP is assumed here? I know that
is what LWAPP uses, but I don't really know why though. Why isn't
reliability needed for LWAPP, given that configuration messages are
mission critical for the WLAN operation.
-----Original Message-----
From: lwapp-admin [at] frascone.com [mailto:lwapp-admin [at] frascone.com] On
Behalf Of Rama Krishna Prasad
Sent: Monday, November 17, 2003 4:19 PM
To: James Kempf; Pat R. Calhoun; Paulo Francisco; Jim Murphy; Branislav
Meandzija; LWAPP
Subject: Re: [Lwapp] Another Way to Think about CAPWAP
I think, breaking down the problem into secure transport and
signaling/configuration
is very good.
Secure transport can be achieved by IPSEC/IKE or even L2TPoverIPSEC.
This group can concentrate on defining signaling/configuration protocol
based on UDP, that is
required to signal messages from AP and configuration information from
AC to AP.
Rama Krishna
Intoto Inc.
www.intotoinc.com
----- Original Message -----
From: "James Kempf" <kempf [at] docomolabs-usa.com>
To: "Pat R. Calhoun" <pcalhoun [at] airespace.com>; "Paulo Francisco"
<paulo [at] chantrynetworks.com>; "Jim Murphy"
<jmurphy [at] trapezenetworks.com>; "Branislav Meandzija"
<bran [at] arraycomm.com>; "LWAPP" <lwapp [at] frascone.com>
Sent: Monday, November 17, 2003 3:11 PM
Subject: Re: [Lwapp] Another Way to Think about CAPWAP
> >There is also the tunnel setup protocol, which is what LWAPP
basically
> > is.
>
> So considering the alternatives, here is how they would set up:
>
> IP in IP - no setup protocol.
>
> IPsec - IKE for key exchange, then everything going between the two
> endpoints to the indicated port is encrypted using ESP. If transport
mode is
> used, there's no tunnel overhead. One could also use the new BEET
(Bound End
> to End Tunnel) mode to reduce transport overhead for tunnel mode, but
that
> is currently somewhat controversial among IETF security folks.
>
> TLS over UDP - TLS to set up on the indicated port, then everything is
> encrypted at the transport layer.
>
> L2 tunnel - no setup protocol (so far as I am aware, perhaps 802 has
> something though).
>
> The charter requires an existing tunnel mechanism to be used, so two
out of
> the three would already have a mechanism. Perhaps there are more
mechanisms
> I'm missing?
>
> Or is there something else required to set up the tunnel besides
agreeing on
> a port number and encapsulation format?
>
> >LWAPP also consists of an in-band configuration protocol to the AP -
> allowing
> >a state machine to use the same control mechanism from the AC to the
AP.
>
> Is this to keep the state machine synchronized between the two sides?
Or is
> there some other reason for it?
>
> jak
>
> _______________________________________________
> Lwapp mailing list
> Lwapp [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/lwapp
_______________________________________________
Lwapp mailing list
Lwapp [at] frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp
- RE: Another Way to Think about CAPWAP, (continued)
- RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 17 2003
- RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 17 2003
- RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 17 2003
- RE: Another Way to Think about CAPWAP Mani, Mahalingam (Mahalingam), November 17 2003
- RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 17 2003
- RE: Another Way to Think about CAPWAP Paulo Francisco, November 17 2003
- RE: Another Way to Think about CAPWAP Yang, Lily L, November 17 2003
- RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 17 2003
- RE: Another Way to Think about CAPWAP Pat R. Calhoun, November 18 2003
Results generated by Tiger Technologies using MHonArc.