Dear authors,
The CAPWAP Data channel carries the IEEE 802.11
management traffic (like IEEE 802.11 Action Frames). The station's
data frames are locally bridged, i.e., not carried over the CAPWAP
data channel. The station's data frames are handled by the Access
Router.
Data Channel, Data channel, data channel. Be consistent
That was one source of confusion (had to re-read the text)
Later on, I see
As shown in the figure there is still a CAPWAP control and
data channel between the WTP and AC, wherein the CAPWAP data channel
carries the stations' management traffic.
That's the point, the figures 1 and 2 don't show the CAPWAP control and
data channels.
The figures would benefit from something like this
Locally Bridged
+-----+ Data Frames +----------------+
| WTP |==================| Access Router |
+-----+\\ +----------------+
\\
\\
\\ CAPWAP Control Channel: +--------+
++=========================+ AC |
// CAPWAP Data Channel: +--------+
// IEEE 802.11 management traffic
//
+-----+// +----------------+
| WTP |==================| Access Router |
+=====+ Locally Bridged +----------------+
Data Frames
Figure 1: Centralized Control with Distributed Data
And as bonus points, a figure before that, to explain how CAPWAP works
without local briding
+-----+
| WTP |
+-----+\\
\\
\\
\\ CAPWAP Control Channel: +--------+
++=========================+ AC |
// CAPWAP Data Channel: +--------+
// - IEEE 802.11 management traffic
// - Data Frames
+-----+//
| WTP |
+=====+
- Terminology
1. OLD:
Wireless Termination Point (WTP), The physical or network entity that
contains an RF antenna and wireless Physical Layer (PHY) to transmit
and receive station traffic for wireless access networks.
NEW
Wireless Termination Point (WTP): The physical or network entity that
contains an RF antenna and wireless Physical Layer (PHY) to transmit
and receive station traffic for wireless access networks.
2. I guess that the definitions comes from the CAPWAP RFCs. You might want to
provide references
3. 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.
Well, if the mode is local bridging, not quite :-)
-
+-+-+-+-+-+-+ |
| Tunnel | |
| Failure | |
+-+-+-+-+-+-+ |
|WTP Alternate Tunnel Failure Indication |
|(report failure) |
|---------------------------------------->|
| |
+-+-+-+-+-+-+-+ |
| Tunnel | |
| Established | |
+-+-+-+-+-+-+-+ |
|WTP Alternate Tunnel Failure Indication |
|(report clearing failure) |
|---------------------------------------->|
| |
Figure 3: Setup of Alternate Tunnel
What if no tunnels can be established. What is the default behavior: all
data frames sent to the AC? Or no communication? Or it is simply an AC
deployment decision?
Maybe you want a have sentence such as
For the case where AC is unreachable but the tunnel end point is
still reachable, the WTP behavior is up to the implementation. For
example, the WTP could either choose to tear down the tunnel or let
the existing user's traffic continue to be tunneled.
- I don't feel comfortable with
* 0: CAPWAP. This refers to a CAPWAP data channel described in
[RFC5415 <http://tools.ietf.org/html/rfc5415>][RFC5416]. Additional
description in
[I-D.xue-opsawg-capwap-alt-tunnel-information
<http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-03#ref-I-D.xue-opsawg-capwap-alt-tunnel-information>].
* 1: L2TP. This refers to tunnel encapsulation described in
[RFC2661 <http://tools.ietf.org/html/rfc2661>].
* 2: L2TPv3. This refers to tunnel encapsulation described in
[RFC3931 <http://tools.ietf.org/html/rfc3931>].
* 3: IP-in-IP. This refers to tunnel encapsulation described in
[RFC2003 <http://tools.ietf.org/html/rfc2003>].
* 4: PMIPv6. This refers to the tunneling encapsulation
described in [RFC5213 <http://tools.ietf.org/html/rfc5213>]
* 5: GRE-IPv4. This refers to GRE encapsulation with IPv4 as the
delivery protocol as described in [RFC2784
<http://tools.ietf.org/html/rfc2784>]
* 6: GRE-IPv6. This refers to GRE encapsulation with IPv6 as the
delivery protocol as described in [RFC2784
<http://tools.ietf.org/html/rfc2784>]
And
Tunnel-Type: This specification defines the Alternate Tunnel
Encapsulations Type message element. This element contains a
field Tunnel-Type. The namespace for the field is 16 bits
(0-65535)). This specification defines values, zero (0) through
six (6) and can be found inSection 3.2
<http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-03#section-3.2>.
Future allocations of
values in this name space are to be assigned by IANA using the
"Specification Required" policy. IANA needs to create a registry
called CAPWAP Alternate Tunnel-Types. The registry format is
given below.
Tunnel-Type Type Value Reference
CAPWAP 0
L2TP 1
L2TPv3 2
IP-IP 3
PMIPv6 4
GRE-IPv4 5
GRE-IPv6 6
In the first paragraph, you give the references, which is good. So they
should be in the IANA section (second paragraph) as well. Btw, you have
foreseen the Reference column. Then comes the problem, you can't have a
reference in IANA to
[I-D.xue-opsawg-capwap-alt-tunnel-information
<http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-03#ref-I-D.xue-opsawg-capwap-alt-tunnel-information>],
which is btw an informative reference in the draft, and not even a WG
document.
So the question is: do you need the reference to this draft in paragraph
1. I don't think so.
OLD:
* 0: CAPWAP. This refers to a CAPWAP data channel described in
[RFC5415 <http://tools.ietf.org/html/rfc5415>][RFC5416]. Additional
description in
[I-D.xue-opsawg-capwap-alt-tunnel-information
<http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-03#ref-I-D.xue-opsawg-capwap-alt-tunnel-information>]
NEW:
* 0: CAPWAP. This refers to a CAPWAP data channel described in
[RFC5415 <http://tools.ietf.org/html/rfc5415>][RFC5416].
- Security Considerations.
So you're telling that, because the CAPWAP Control Channel is protected
by DTLS, there are no chance for someone else that the AC to send or
resend a WLAN Config. Response to redirect the traffic to another tunnel
destination?
What if someone just pretends to the tunnel end point?
Regards, Benoit
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
