Subject: [Capwap] cost/benefit analysis: mux vs multiport

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 18 May 2006 09:23:24 -0700 (GMT-07:00)

We've been discussing whether to use separate UDP ports for capwap control/data vs multiplexing these onto one UDP channel. It's been pointed out to me that this debate has led us deep into the weeds, and that in the process, some important big picture points are probably being missed. With that in mind, I set out to objectively summarize the design trade-offs in an open-minded way.

I did a pretty detailed analysis on my own during the Dallas IETF as a result of Sue Hares' numerous comments on the capwap state machine. It seemed very clear to me that the mux header was the simpler (and therefore better) of the two approaches by far, but at that time we had no indications as to why folks would prefer the multi-port approach to the single port approach. We've since seen that at least one vendor and their supplier have a switch architecture in mind that takes advantage of the multi-port approach. We've also heard some QoS arguments, but these seem far less concrete.

In any event, we need to do an objective cost-benefits analysis, and decide one way or the other, and we also want to be sure to document this process so that those coming late to the party understand how we got to where they find us. That's the purpose of this effort. I'm trying to make this as succinct as possible, but we have to capture the salient points, so that will constrain the lower bound on the size of this note. Still, this is as concise as I can make it while still fairly evaluating our options.

We've been discussing two options, but I think there are actually 3:

1) use multiple ports with separate data and control channels, and somehow manage these as a unit, potentially across firewalls and/or NATs (what's in the draft now)

2) use a single UDP channel (and server port), and multiplex discovery, control and data channels over this one session (the mux header proposal)

3) use multiple ports with separate data and control channels, but when NAT is detected, do what IPsec does, i.e. shift onto a single UDP channel, bundling control and data together; that is, have an optional nat-t encapsulation mechanism.

Option 3 has never been discussed (and personally, I don't like it), but I think we have to give everything a fair hearing, so there it is. Also, it's important to note that the IPsec group was faced with a nearly identical problem - traversing NAT with two independent datagram channels - so it is instructive to look at how it was ultimately solved, keeping in mind that backward-compatibility was a hard requirement for them, but not for us.

In order to summarize the various costs/benefits in a manageable way, I've approached this like a capwap session walk-through, addressing the issues as they are encountered during session establishment. That's what's below, with a separate section devoted to each issue, and subsections under them, one for each of the transport options described above.

1. Differentiating Discovery Messages

If we are encrypting the control channel, we need to be able to differentiate discovery messages (currently a type of control message) from other control channel messages, as discovery messages are not secured.

1.1 Option (1) - multi-port

Assume we have one port for the control channel and one for data. The first implication we encounter relates to discovery messages - either they need their own port, or we need to modify the discovery message header so as to render it precisely unambiguous when compared to DTLS. Currently, there is some ambiguity.

Here's the first few words of the latest proposed capwap header, which would be at the head of the discovery message:

     0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VERSION|   RID   | HLEN  |W|F|L|M|          Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Fragment ID          |     Frag Offset         |Rsv-2|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Here's the DTLS record header, which will be present after dtls negotiation starts:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
     |    type       |    protocol version           |  epoch
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
       epoch, cont   |       (6 byte sequence #)
     /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The type will be from TLS; the ClientHello is 0x16, or 00010110 (other tls types of interest are similar), and the dtls protocol version will be 0xFEFF, and any dtls version changes will just decrement the first version byte (FE, FD, FC, etc). This translates to the following bits:

    1   6    F    E    F   F
  0001 0110 1111 1110 1111 1111

Putting this into the capwap header:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|0 1 1 0 1|1 1 1 1|1|1|0|1|1 1 1 1 1 1 1
    |VERSION|   RID   | HLEN  |W|F|L|M|          Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

or, 

VERSION..: 0001
RID......: 01101 (13)
HLEN.....: 1111 (15)
W........: 1
F........: 1
L........: 1
M........: 0

Changing DTLS types will just effect the RID. Obviously, there's some ambiguity here. We have three choices: 

(a) carefully check every incoming packet against capwap state; if dtls is expected, treat the packet as dtls; otherwise, treat it as discovery and in either case, if anything looks "funny" or questionable (i.e. reserved bits are set), treat it as an error. Note that this does not allow you to push packets directly into your dtls engine; instead, you have to de-mux them first. Also, it doesn't quite feel deterministic (if discovery messages are sent once dtls is established, they will erroneously be treated as bogus dtls messages), and it means the reserved bits can never be used in a way that might result in ambiguity.

(b) modify the capwap header to be sure this *never* happens, e.g. by adding a "magic cookie" to the beginning which will never match a dtls packet. This feels pretty hacky, but would probably work - but it requires per-packet de-muxing checks, and adds bytes to the capwap header - that is, it is a pseudo mux header.

(c) use a different UDP port for discovery; requires yet another firewall rule, but since per-packet disambiguation would be costly in some ways, this is the most logical approach.

So, looks like multi-port works best with three ports, not two.

1.2 Option (2) Mux header

Assume we have a tri-valued mux header (discovery, control, data). One firewall rule for capwap, no header type ambiguities. Very simple - no other special considerations for discovery. 

1.3 Option (3), multi-port with special nat-t mechanism

Recall that in this scenario, once NAT is detected, the two channels are bundled together over one port - that would occur post-discovery, so this is equivalent to option (1) for discovery.

2. NAT detection

In some (but not all) cases, we must detect and adapt to NATs along the AC-WTP path. 

2.1 Option (1), multi-port

If we use separate UDP ports, we must either add code to detect the presence of NAT(s) in the WTP-AC path, or we must assume they are always there. If we assume they are always there, we have to deal with NAT-T processing even when we don't need it. If we don't assume this, we have to support multiple code paths. Yuk.

So, how do we do NAT detection? The WTP transmits its IP address in either a discover or join message. The AC compares this with the address in the packet header, and informs the WTP if they are different. If we do it in the discover, the WTP has to indicate that NAT-T is required in the JOIN request.

2.2 Option (2), mux header

If we use a mux header, we don't need NAT detection, or any other special processing relating to NATs.

2.3 Option (3), multi-port with special nat-t mechanism

Same as option (1), except that behavior is different once NATs are detected.

3. Channel Binding

We must be able to unambiguously identify which data channel goes with which control channel, and manage these as a unit - this is what is meant by channel binding.

3.1 Option (1), multi-port

Assume the control channel is established, and the heartbeat (echo req/reply) is running there. Using our handy-dandy NAT detection scheme, the WTP and AC learned that one or more NATs are inline. So, the AC has to give the WTP a unique session identifier (should probably be the session ID from the control channel). Someone suggested using a BSSID, but this is 802.11-specific, and we'd need additional solutions for other radio types, so it's not a good approach. Assuming the session ID is used, the WTP has to initiate a data channel "connection" containing this session ID, and then a heartbeat has to start over this channel to keep NAT bindings in place along the path

Note that this connection does not necessarily have the same IP as the control channel (L3/4 switching, load balancing, multihomed NAT device, etc), and this must be taken into account.

Also note that a NAT'd channel can "fail" rather arbitrarily and unpredictably. For example, there is no standard way to handle resource contention on NAT devices. Some simply drop new session requests, and others toss out an existing one to make room for the new one. Hence, behavior will not be deterministic, and we must expect and plan for random channel failures, including the inability to establish a data channel once we have a control channel in place. More error handling and control session teardown/recovery in this case.

If the data channel heartbeat fails, one approach is to tear down the control channel and restart from scratch, even if it is still working. An acknowledged error message could be sent over the existing control channel prior to teardown, but then you must set a timer in case it is not acknowledged, and deal with this somehow. 

A better alternative is to instead maintain the working control channel and establish a new data channel, binding it to the existing control channel, but this would require coordination to minimize STA downtime (is there some way to shift associated STAs to the new channel without loss of connectivity?),  and we have to handle error conditions (i.e. what if we can't establish a new data channel?)

Also, you must decide which side detects the failure and deals with it, and/or how to deal with race conditions and collisions if both sides detect it and react more or less simultaneously.

Okay, that was data channel failure - if instead the control channel fails, the WTP must be the one to reinitiate a new control channel (it is effectively re-joining, and currently the AC can't initiate a join, and besides, it is behind a NAT). Then, it must tell the AC to tear down the old data channel and clean up any STA associations with that channel (or, the AC must track the WTPs original non-NAT'd IP as part of its session context, and clean up automagically). In the meantime, the same STAs may be reassociating over the new data channel. More mucking around with error conditions, housekeeping, etc.

3.2 Option (2), mux header

If the UDP channel goes away (i.e. NAT binding fails somewhere along the path), the whole session, data and control, times out as a unit. Both sides detect this and clean up both control and data as a unit (it's one single session, and no tear-down messages are required). If the WTP detects it first and rejoins before the AC cleans up the old session, the AC needs to detect this.  

3.3 Option (3), multi-port with special nat-t mechanism

Similar to option (2) if there is NAT. If not, it's more like option (1), and the channels shouldn't usually fail. Still, we must detect/handle it if one or both do fail.

3.4 Summarizing Channel Bindings

We have to be able to manage channels as a unit, and detect when one fails. If we use separate ports, this task is much more complex than if channels are multiplexed over one port. Also, channel failure is more likely for multiple port approaches.

If we assume random NAT failures with equal likelihood for either channel (which seems entirely reasonable), channel failure is twice as likely with two ports as it is with the mux header.

The mux header approach requires no special channel binding - it's implicit. That entirely eliminates all associated complexity.

4. Keepalives/heartbeats

This ties in closely to the channel binding, but deserves it's own section. Note that for any NAT traversal scenario, we need to keep the NAT channel open, and this requires periodic heartbeats. Also note that due to channel binding requirements, if we have independent control and data channels (separate ports), it is possible for the data channel to fail independently of the control channel, hence we must detect this - we need a data channel heartbeat.

4.1 Option (1), multi-port

We must manage heartbeats over both channels. If one fails, this requires potentially asymmetric repairs as described in section 3.1. Note that this is independent of NAT; since it is always possible to lose one channel and not the other, implementations must be prepared to deal with this.

4.2 Option (2) - mux header

The existing control channel echo req/rsp serves as an implicit heartbeat - no additonal effort required.

4.3 Option (3), multi-port with special nat-t mechanism 

Same as (1) - note that we need heartbeats on the separate data channel with or without NAT.

5. Intermediate firewall configuration

Firewalls between the AC and WTP must be configured to permit capwap through. One rule per AC for mux vs three rules per AC for the multi-port approach, and maybe with an additional rule if we use a 4th port for NAT traversal.

6. Summarizing

There is no question that using a mux header is far simpler than either of the multi-port approaches. Simpler means more likely to interoperate, and also more likely to be correctly implemented, which has both operational and security implications, though they are difficult to precisely quantify.

Also, it is clear from this analysis that the two-port approach requires a data channel heartbeat (and all associated processing complexity) regardless of whether NATs are present or not.

By far, channel binding and multi-channel maintenance are the largest issues here, and especially when NATs are in the picture. The question we have to answer is this: is there some value in the multiport approach that makes it worth it to take on all this complexity and the associated operational and interop issues? 

I'm going to stop short of offering an opinion here, although I definitely have one. I think this will work better if this note remains objective. You can hear my opinions in follow-ups :-)

--Scott

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Michael Vakulenko <[email-masked]>
Date: Thu, 18 May 2006 20:32:41 +0200

Scott,

Your analysis is very impressive. Its complexity and length of this 
email thread probably indicates that no single approach (mux or 
multiport) works well for all product architectures and deployment scenarios.

I suggest rather simple way to resolve this. Let's allow AC decide 
which UDP port shall be used for data messages and configure WTP 
accordingly. I.e., control connection is always established on a 
pre-defined well-known port. Following that the AC will configure the 
WTP to use certain UDP port for data messages. This can be done in 
Join Response message. The port can be the same as the well-known 
control port or different, depending on AC architecture or network 
considerations.

Impact on WTP implementation is negligible (software only), impact on 
draft specification is negligible (additional message element). 
Benefits are many, including flexibility in AC vendor differentiation 
and supported network deployment scenarios.

-- Michael V.
         www.WaveCompass.com

At 06:23 PM 5/18/2006, Scott G. Kelly wrote:

>We've been discussing whether to use separate UDP ports for capwap 
>control/data vs multiplexing these onto one UDP channel. It's been 
>pointed out to me that this debate has led us deep into the weeds, 
>and that in the process, some important big picture points are 
>probably being missed. With that in mind, I set out to objectively 
>summarize the design trade-offs in an open-minded way.
>
>I did a pretty detailed analysis on my own during the Dallas IETF as 
>a result of Sue Hares' numerous comments on the capwap state 
>machine. It seemed very clear to me that the mux header was the 
>simpler (and therefore better) of the two approaches by far, but at 
>that time we had no indications as to why folks would prefer the 
>multi-port approach to the single port approach. We've since seen 
>that at least one vendor and their supplier have a switch 
>architecture in mind that takes advantage of the multi-port 
>approach. We've also heard some QoS arguments, but these seem far 
>less concrete.
>
>In any event, we need to do an objective cost-benefits analysis, and 
>decide one way or the other, and we also want to be sure to document 
>this process so that those coming late to the party understand how 
>we got to where they find us. That's the purpose of this effort. I'm 
>trying to make this as succinct as possible, but we have to capture 
>the salient points, so that will constrain the lower bound on the 
>size of this note. Still, this is as concise as I can make it while 
>still fairly evaluating our options.
>
>1) use multiple ports with separate data and control channels, and 
>somehow manage these as a unit, potentially across firewalls and/or 
>NATs (what's in the draft now)
>
>2) use a single UDP channel (and server port), and multiplex 
>discovery, control and data channels over this one session (the mux 
>header proposal)
>
>3) use multiple ports with separate data and control channels, but 
>when NAT is detected, do what IPsec does, i.e. shift onto a single 
>UDP channel, bundling control and data together; that is, have an 
>optional nat-t encapsulation mechanism.
>
>Option 3 has never been discussed (and personally, I don't like it), 
>but I think we have to give everything a fair hearing, so there it 
>is. Also, it's important to note that the IPsec group was faced with 
>a nearly identical problem - traversing NAT with two independent 
>datagram channels - so it is instructive to look at how it was 
>ultimately solved, keeping in mind that backward-compatibility was a 
>hard requirement for them, but not for us.
>
>In order to summarize the various costs/benefits in a manageable 
>way, I've approached this like a capwap session walk-through, 
>addressing the issues as they are encountered during session 
>establishment. That's what's below, with a separate section devoted 
>to each issue, and subsections under them, one for each of the 
>transport options described above.
>
>
>If we are encrypting the control channel, we need to be able to 
>differentiate discovery messages (currently a type of control 
>message) from other control channel messages, as discovery messages 
>are not secured.
>
>Assume we have one port for the control channel and one for data. 
>The first implication we encounter relates to discovery messages - 
>either they need their own port, or we need to modify the discovery 
>message header so as to render it precisely unambiguous when 
>compared to DTLS. Currently, there is some ambiguity.
>
>Here's the first few words of the latest proposed capwap header, 
>which would be at the head of the discovery message:
>
>      0                   1                   2                   3
>The type will be from TLS; the ClientHello is 0x16, or 00010110 
>(other tls types of interest are similar), and the dtls protocol 
>version will be 0xFEFF, and any dtls version changes will just 
>decrement the first version byte (FE, FD, FC, etc). This translates 
>to the following bits:
>
>     1   6    F    E    F   F
>Changing DTLS types will just effect the RID. Obviously, there's 
>some ambiguity here. We have three choices:
>
>(a) carefully check every incoming packet against capwap state; if 
>dtls is expected, treat the packet as dtls; otherwise, treat it as 
>discovery and in either case, if anything looks "funny" or 
>questionable (i.e. reserved bits are set), treat it as an error. 
>Note that this does not allow you to push packets directly into your 
>dtls engine; instead, you have to de-mux them first. Also, it 
>doesn't quite feel deterministic (if discovery messages are sent 
>once dtls is established, they will erroneously be treated as bogus 
>dtls messages), and it means the reserved bits can never be used in 
>a way that might result in ambiguity.
>
>(b) modify the capwap header to be sure this *never* happens, e.g. 
>by adding a "magic cookie" to the beginning which will never match a 
>dtls packet. This feels pretty hacky, but would probably work - but 
>it requires per-packet de-muxing checks, and adds bytes to the 
>capwap header - that is, it is a pseudo mux header.
>
>(c) use a different UDP port for discovery; requires yet another 
>firewall rule, but since per-packet disambiguation would be costly 
>in some ways, this is the most logical approach.
>
>Assume we have a tri-valued mux header (discovery, control, data). 
>One firewall rule for capwap, no header type ambiguities. Very 
>simple - no other special considerations for discovery.
>
>
>Recall that in this scenario, once NAT is detected, the two channels 
>are bundled together over one port - that would occur 
>post-discovery, so this is equivalent to option (1) for discovery.
>
>
>2. NAT detection
>
>If we use separate UDP ports, we must either add code to detect the 
>presence of NAT(s) in the WTP-AC path, or we must assume they are 
>always there. If we assume they are always there, we have to deal 
>with NAT-T processing even when we don't need it. If we don't assume 
>this, we have to support multiple code paths. Yuk.
>
>So, how do we do NAT detection? The WTP transmits its IP address in 
>either a discover or join message. The AC compares this with the 
>address in the packet header, and informs the WTP if they are 
>different. If we do it in the discover, the WTP has to indicate that 
>NAT-T is required in the JOIN request.
>
>
>We must be able to unambiguously identify which data channel goes 
>with which control channel, and manage these as a unit - this is 
>what is meant by channel binding.
>
>
>Assume the control channel is established, and the heartbeat (echo 
>req/reply) is running there. Using our handy-dandy NAT detection 
>scheme, the WTP and AC learned that one or more NATs are inline. So, 
>the AC has to give the WTP a unique session identifier (should 
>probably be the session ID from the control channel). Someone 
>suggested using a BSSID, but this is 802.11-specific, and we'd need 
>additional solutions for other radio types, so it's not a good 
>approach. Assuming the session ID is used, the WTP has to initiate a 
>data channel "connection" containing this session ID, and then a 
>heartbeat has to start over this channel to keep NAT bindings in 
>place along the path
>
>Note that this connection does not necessarily have the same IP as 
>the control channel (L3/4 switching, load balancing, multihomed NAT 
>device, etc), and this must be taken into account.
>
>Also note that a NAT'd channel can "fail" rather arbitrarily and 
>unpredictably. For example, there is no standard way to handle 
>resource contention on NAT devices. Some simply drop new session 
>requests, and others toss out an existing one to make room for the 
>new one. Hence, behavior will not be deterministic, and we must 
>expect and plan for random channel failures, including the inability 
>to establish a data channel once we have a control channel in place. 
>More error handling and control session teardown/recovery in this case.
>
>If the data channel heartbeat fails, one approach is to tear down 
>the control channel and restart from scratch, even if it is still 
>working. An acknowledged error message could be sent over the 
>existing control channel prior to teardown, but then you must set a 
>timer in case it is not acknowledged, and deal with this somehow.
>
>A better alternative is to instead maintain the working control 
>channel and establish a new data channel, binding it to the existing 
>control channel, but this would require coordination to minimize STA 
>downtime (is there some way to shift associated STAs to the new 
>channel without loss of connectivity?),  and we have to handle error 
>conditions (i.e. what if we can't establish a new data channel?)
>
>Also, you must decide which side detects the failure and deals with 
>it, and/or how to deal with race conditions and collisions if both 
>sides detect it and react more or less simultaneously.
>
>Okay, that was data channel failure - if instead the control channel 
>fails, the WTP must be the one to reinitiate a new control channel 
>(it is effectively re-joining, and currently the AC can't initiate a 
>join, and besides, it is behind a NAT). Then, it must tell the AC to 
>tear down the old data channel and clean up any STA associations 
>with that channel (or, the AC must track the WTPs original non-NAT'd 
>IP as part of its session context, and clean up automagically). In 
>the meantime, the same STAs may be reassociating over the new data 
>channel. More mucking around with error conditions, housekeeping, etc.
>
>
>If the UDP channel goes away (i.e. NAT binding fails somewhere along 
>the path), the whole session, data and control, times out as a unit. 
>Both sides detect this and clean up both control and data as a unit 
>(it's one single session, and no tear-down messages are required). 
>If the WTP detects it first and rejoins before the AC cleans up the 
>old session, the AC needs to detect this.
>
>Similar to option (2) if there is NAT. If not, it's more like option 
>(1), and the channels shouldn't usually fail. Still, we must 
>detect/handle it if one or both do fail.
>
>
>We have to be able to manage channels as a unit, and detect when one 
>fails. If we use separate ports, this task is much more complex than 
>if channels are multiplexed over one port. Also, channel failure is 
>more likely for multiple port approaches.
>
>If we assume random NAT failures with equal likelihood for either 
>channel (which seems entirely reasonable), channel failure is twice 
>as likely with two ports as it is with the mux header.
>
>The mux header approach requires no special channel binding - it's 
>implicit. That entirely eliminates all associated complexity.
>
>
>4. Keepalives/heartbeats
>
>This ties in closely to the channel binding, but deserves it's own 
>section. Note that for any NAT traversal scenario, we need to keep 
>the NAT channel open, and this requires periodic heartbeats. Also 
>note that due to channel binding requirements, if we have 
>independent control and data channels (separate ports), it is 
>possible for the data channel to fail independently of the control 
>channel, hence we must detect this - we need a data channel heartbeat.
>
>We must manage heartbeats over both channels. If one fails, this 
>requires potentially asymmetric repairs as described in section 3.1. 
>Note that this is independent of NAT; since it is always possible to 
>lose one channel and not the other, implementations must be prepared 
>to deal with this.
>
>
>The existing control channel echo req/rsp serves as an implicit 
>heartbeat - no additonal effort required.
>
>
>Firewalls between the AC and WTP must be configured to permit capwap 
>through. One rule per AC for mux vs three rules per AC for the 
>multi-port approach, and maybe with an additional rule if we use a 
>4th port for NAT traversal.
>
>
>6. Summarizing
>
>There is no question that using a mux header is far simpler than 
>either of the multi-port approaches. Simpler means more likely to 
>interoperate, and also more likely to be correctly implemented, 
>which has both operational and security implications, though they 
>are difficult to precisely quantify.
>
>Also, it is clear from this analysis that the two-port approach 
>requires a data channel heartbeat (and all associated processing 
>complexity) regardless of whether NATs are present or not.
>
>By far, channel binding and multi-channel maintenance are the 
>largest issues here, and especially when NATs are in the picture. 
>The question we have to answer is this: is there some value in the 
>multiport approach that makes it worth it to take on all this 
>complexity and the associated operational and interop issues?
>
>I'm going to stop short of offering an opinion here, although I 
>definitely have one. I think this will work better if this note 
>remains objective. You can hear my opinions in follow-ups :-)
>
>
>--Scott
>

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 18 May 2006 12:55:50 -0700 (PDT)

HI,

Very good message. I'm glad you wrote up the issue with the discovery
message.

Here is a question for you:

What is the difference between
 1) a LOCAL MAC WTP that tunnels all of the data traffic for WTP
    clients (the STAs) over a tunnel that just happens to terminate
    at the AC, and 
 2) a SPLIT MAC WTP that uses separate transport addresses for
    control and WTP client data traffic

They look the same to me except for the following:
 1) the AC has to configure the LOCAL MAC WTP as to
    the VLAN tag, and Qos markings of STA data traffic.
    Where with SPLIT MAC, this is done by the AC.
 2) the status and statistics of STA data traffic
    must be sent periodically by the WTP to the AC
    for LOCAL MAC WTPs, where with SPLIT MAC WTPs,
    the AC counts this directly.
Of course in the SPLIT MAC WTP case where separate
transport addresses are used, then it is a "local
matter" how the configuration and intrumentation
values are done on the AC.

Regards,
/david t. perkins