Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 8 Sep 2008 09:54:26 -0700

Pasi Eronen wrote:

> > > Hmm... for split MAC, what exactly is the frame tunnel mode used?
> > > 802.3 or native 802.11 frames? Or does it vary for management
frames
> > > vs. data frames?
> > 
> > All management frames MUST be encapsulated as 802.11 frames. User
> > data frames can either be in 802.11 or 802.3 format, based on what
> > was communicated by the AC through the IEEE 802.11 Add WLAN message
> > element.
> 
> BTW, the drafts don't seem to describe how the recipient figures 
> out whether the received packet is 802.11 or 802.3?
> 
> Based on a quick look at the frame formats, there's no obvious answer
> (I'm assuming that the "Preamble" and "SFD" fields of the 802.3 frame
> are not actually sent -- although the spec doesn't actually say that,
> and should do so.)

The receiver would know through the 'T' bit of the CAPWAP Header. The
'T' bit is used to specify the type of packet encapsulated. When set to
zero (0), the format is 802.3. When set to one (1), the format is the
native format. The native format is known through the WBID field in the
header.

As far as preamble and SFD, the text only stated that the FCS was
stripped, so yes, we should mention these fields as well (and change FCS
to CRC, which is the proper term for the 802.3 frame). The modified text
reads:

<modified text>
4.4.2.  Data Payload
[...]
   For 802.3 payload frames, the 802.3 frame is encapsulated (excluding
   the IEEE 802.3 Preamble, Start Frame Delimiter (SFD) and CRC
   Fields).  If the encapsulated frame would exceed the transport
   layer's MTU, the sender is responsible for fragmentation of the
   frame, as specified in Section 3.4.  The CAPWAP protocol can support
   IEEE 802.3 frames whose length is defined in the IEEE 802.3as
   specification [FRAME-EXT].
</modified text>

> 
> <snip>
> > > (BTW, Section 4.6.43 says that 802.3 MUST NOT be used with
> > > Split-MAC; should that say MUST NOT be used with Local-MAC?)
> > 
> > Even Local-MAC has a tunneled mode - that was added some time ago to
> > support implementations whose AC could not parse 802.11 frames. So
> > in the tunneled Local MAC case, the tunneled frames are 802.3 -
> > except the MAC management frames which MUST be in 802.11 format. 
> > I see that the text was vague because it referred to Split vs. Local
> > MAC, when it should also reference the tunneling mode.
> 
> Ok, so that text in 4.6.43 needs to be fixed, too?

I think the Split MAC text is fine, but I can add some clarifying text
for the Local MAC case:

<new text>
4.6.43.  WTP MAC Type
[...]
   MAC Type:   The MAC mode of operation supported by the WTP.  The
      following enumerated values are supported:

      0 - Local-MAC:   Local-MAC is the default mode that MUST be
         supported by all WTPs.  When tunneling is enabled (see
         Section 4.6.42), the encapsulated frames MUST be in the 802.3
         format (see Section 4.4.2), unless a wireless management or
         control frame which MAY be in its native format.  Any CAPWAP
         binding needs to specify the format of management and control
         wireless frames.
</new text>

> 
> > OK, so first, sorry to have taken so long in this exchange. I now
> > understand the issues you are seeing. Again, trying to maintain as
> > much backward compatibility was the key goal, but frankly, we've
> > redefined the bits so much at this point that it is nearly
> > impossible to re-use what was there without introducing redundancy
> > and lack of clarity. So I am now providing a new proposal, which I
> > have to apologize for having to include all of the text, but it is
> > necessary for complete clarity:
> 
> Thanks for being patient with me -- this has been a long thread :)
> The new text looks good to me; there's only one small clarification
> that might be helpful (but isn't absolutely needed):

I'm the one who should be thanking you...

> 
> <snip>
> >    For Split MAC mode, or Local MAC with tunneling enabled, the WTP
> >    needs to contend with both the inner packet (the station's
original
> >    packet), as well as the tunnel header (added by the WTP).  In
this
> >    mode of operation, the bits are treated as follows:
> > 
> >    O=1:   The WTP sets the DSCP field in the tunnel header to 
> >       either the default policy, or the station specific policy if 
> >       one exists.
> > 
> >    O=0:   The WTP sets the DSCP field in the tunnel header to 
> >       the value found in the inner packet's DSCP field.  If
> >       encryption services are provided by the AC (see Section 6.15),
> >       the packet is encrypted, therefore the WTP cannot access the
> >       inner DSCP field, in which case it uses the behavior described
> >       when the 'O' bit is set.
> 
> Perhaps add "This occurs also f the inner packet is not IPv4 or IPv6,
> and thus does not have a DSCP field." ?
> 
> <snip>
> 
> >    I=1:   The WTP sets the DSCP field in the station's packet 
> >       to either the default policy, or the station specific policy
> >       if one exists.  If encryption services are provided by the AC
> >       (see Section 6.15), the packet is encrypted, therefore the WTP
> >       cannot access the inner DSCP field, in which case it uses the
> >       behavior described when the 'I' bit is not set.
> 
> Same here?

I have made the requested change.

Thanks again!

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

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

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 10:40:02 +0300

Pat Calhoun wrote:

> > Based on a quick look at the frame formats, there's no obvious
> > answer (I'm assuming that the "Preamble" and "SFD" fields of the
> > 802.3 frame are not actually sent -- although the spec doesn't
> > actually say that, and should do so.)
> 
> The receiver would know through the 'T' bit of the CAPWAP
> Header. The 'T' bit is used to specify the type of packet
> encapsulated.  When set to zero (0), the format is 802.3. When set
> to one (1), the format is the native format. The native format is
> known through the WBID field in the header.

Thanks -- I had missed the 'T' bit! That makes things obvious.

> stripped, so yes, we should mention these fields as well (and change
> FCS to CRC, which is the proper term for the 802.3 frame). The
> modified text reads:

BTW, both 802.3-2005 and 802.3as-2006 call it the "Frame Check
Sequence (FCS)" field, not CRC (but I don't think there's much
danger of confusion here).

>          binding needs to specify the format of management and control

BTW -- it seems the edits have changed the section numbering. I think
the text about WTP MAC Type (4.6.46 in version -11) is fine. I was
just wondering whether the text about WTP Frame Tunnel Mode (4.6.43 in 
version -11) is correct when it says 802.3 frame tunnel mode MUST NOT
be used with Split-MAC?

(If the text is correct, it wouldn't hurt to repeat the requirement
in the binding spec, Add WLAN message element, saying that Tunnel
Mode field MUST have value 2 if MAC Mode is Split-MAC.)

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 9 Sep 2008 09:10:32 -0700

> BTW, both 802.3-2005 and 802.3as-2006 call it the "Frame Check
Sequence (FCS)" field, not CRC (but I don't think there's much danger of
confusion here).

Well... That'll teach me not to use the cliff notes version. I've
changed it back to FCS.
> BTW -- it seems the edits have changed the section numbering. I think
the text about WTP MAC Type (4.6.46 in version -11) is fine. I was just
wondering whether the text about WTP Frame Tunnel Mode (4.6.43 in
version -11) is correct when it says 802.3 frame tunnel mode MUST NOT be
used with Split-MAC?

Yes - that is correct and I am changing all of the reference through my
last pass before submission to the ID editor.

> (If the text is correct, it wouldn't hurt to repeat the requirement in
the binding spec, Add WLAN message element, saying that Tunnel Mode
field MUST have value 2 if MAC Mode is Split-MAC.)

OK, then I have added the following sentence to the binding spec:

<new text>
6.1.  IEEE 802.11 Add WLAN
[...]
   Tunnel Mode:   This field specifies the frame tunneling type to be
[...]
      1 - 802.3 Tunnel:   All user traffic is to be tunneled to the AC
         in 802.3 format (see Section 4.3 in
         [I-D.ietf-capwap-protocol-specification]).  Note that this
         option MUST NOT be selected with Split-MAC mode.
</new text>

So I believe we have closed out the last issue, and are now ready to
move the document forward. I again want to thank you for your help in
improving the quality of the specs.

PatC