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

From: <[email-masked]>
Date: Tue, 2 Sep 2008 10:19:20 +0300

Pat Calhoun wrote:

> OK, so I have changed "do not tag" to "set to zero", and added the
> last paragraph:
> 
> <modified/new text>
> 2.6.1.  IEEE 802.11 Data Frames
> [...]
>    The IEEE 802.11 WTP Quality of Service message element's Tagging
>    Policy field indicates how the packets are to be tagged, via the
>    'P' bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (set to zero).
>    The Tagging Policy also includes the 'T' bit, which is used to
>    inform the WTP to not modify any markings set by the station.
>    The expected behavior of these bits is specified below.  When an
>    IEEE 802.11 Update Station QoS message element is received, while
>    the specific "802.1p Tag" or DSCP values may change for a given
>    station, the original Tagging Policy (the use of the 'T', 'D',
>    'P' and 'U' bits) remains the same.
> 
>    The use of DSCP and 802.1p are not mutually exclusive.  An AC MAY
>    request that a WTP use non, either, or both types of QoS mechanisms
>    at the same time.  The 'D' and 'P' bits are independent, while the
>    'T' bit behavior is common for both mechanisms.
> </modified/new text>

The 'U' bit is also common -- and having T/U in common means that
it's *NOT* always possible to use just one of the mechanisms in 
certain way. I think we need separate bits here.

> > For DSCP, there seem to be three valid options for the outer
> > header (only in Split MAC case): "use system default" (the DSCP
> > field is always there with some value), "use NNNNNN", (sent in the
> > CAPWAP message element), or "copy from inner header" (if it's
> > IPv4/IPv6, and encryption is not done in AC; otherwise, use system
> > default, I guess), and two choices for the inner header (both
> > Split and Local MAC): "don't touch", and "replace with NNNNNN" (if
> > it's IPv4/IPv6, and encryption is not done in AC).
> > 
> > Two of the six (3x2) combinations, two ("copy from inner header"+
> > "replace with NNNNNN", and "use system default"+"replace with
> > NNNNNN") probably don't make sense/are not important, so we have
> > four left, requiring two bits:
> > 
> >   00 "use system default"+"don't touch" (what is meant by 
> >      "untagged" now, I guess)
> >   01 "use NNNNNN"+"don't touch" (not valid for local MAC)
> >   10 "copy from inner header"+"don't touch" (not valid for 
> >       local MAC)
> >   11 "use NNNNNN"+"replace with NNNNNN" 
> 
> I'm not sure that I understand why the confusion exists. Let me break
> this down and see if I can understand where the issue is. First, let's
> tackle Local MAC (they are separate because the behavior is 
> different):
> 
>    D=1, T=0:   The WTP re-marks the DSCP field in the station's packet
>       to either the default, or the station specific DSCP policy.
> <PRC> This means the WTP changes the DSCP field to either the default,
> or the station policy.
>
>    D=1, T=1:   The WTP does not modify the DSCP field in the station's
>       packets.
> <PRC> The WTP leaves the DSCP field as-is

>    D=0, T=0:   The WTP sets the DSCP field in the station's packet to
>       zero (0).  This bit combination MUST NOT be set if the 
>       'U' bit is not set.
> <PRC> The WTP sets the DSCP field to zero (0) - meaning it overrides
> the field. This is basically the same as the 'U' option - meaning we
> could remove that option, but I was trying to minimize changes to
> the protocol.

Yes, the local MAC is mostly fine, except that D=0,T=0 combination
is never needed for anything (since the AC can get exactly the same
behavior with D=1,T=0).

> Now let's take a look at Split MAC:
>    D=1, T=0:   The WTP marks the outer header's DSCP field based on
>       either the default or the station specific DSCP policy.
>       Similarly, the WTP also re-marks the inner packet header's DSCP
>       field to the same DSCP value.  If encryption services 
>       are provided by the AC (see Section 6.15), the WTP does not 
>       modify the inner packet.
> <PRC> Similar to the Local MAC, the WTP re-marks the DSCP field to the
> default, or station policy. Both the outer and inner packet 
> is modified, depending upon whether encryption is done at the AC.

Ok, this would be what I called "use NNNNNN"+"replace with NNNNNN".
 
>    D=1, T=1:   The WTP marks the outer header's DSCP field 
>       based on the
>       value set in the inner packet header's DSCP field.  Further the
>       WTP does not modify the inner packet header's DSCP field.  This
>       option is invalid if the AC is providing encryption services,
>       since the inner packet would be encrypted, and therefore not
>       readable by the WTP.  If this option is set while the AC is
>       providing encryption services, the WTP must provide the services
>       defined in the "D=1, T=0" option.
> <PRC> If encryption services are provided at the WTP, the outer DSCP
> field is set to the value found in the inner packet. If encryption is
> done at the AC, then this option is invalid, and the WTP is to use the
> "D=1, T=0" option instead.

Ok, this would be "copy from inner header"+"don't touch"

>    D=0, T=0:   The WTP sets the DSCP field of the inner and 
>       outer packet header to zero (0).  If encryption services are 
>       provided by the AC, the WTP MUST NOT modify the inner packet 
>       header's DSCP field. This bit combination MUST NOT be set if 
>       the 'U' bit is not set.
> <PRC> Both the outer and inner DSCP fields are set to zero (0).

This is redundant (as exactly the same behavior can be had with
D=1,T=1), and it's sort of unintuitive that even when the 'D' (DSCP)
bit is set to zero, you're still modifying DSCP field of the inner
packet.

More importantly, however, these three combinations don't include the
combination "use NNNNNN"+"don't touch": i.e. use the DSCP value from
the CAPWAP message element for the outer header, but don't modify the
inner header.

> > For 802.1p, I'm not quite sure what the options are. Can the
> > packet received from the STA contain a 802.1Q header (I guess a
> > packet received from a host over wired Ethernet could contain it)?
> > If it does, is it guaranteed to be the same value as the User
> > Priority field of the QoS Control field of the IEEE 802.11 header?
> 
> First, the 802.11 protocol does not permit an 802.1Q header to be
> sent over the air, so the WTP never sees the header. Instead, we
> rely on the QoS control field - it is the only thing the WTP will
> see (from a link layer priority field perspective). 

OK, this clarifies things.

> Second, just to make sure that we are clear about where the 802.1Q
> header is inserted, I have made a small change to the text. To make
> sure that this is clear, I have modified the first sentence and
> added the last two sentences to the end of the first paragraph:
> 
> <new-modified text>
> 2.6.1.1.  802.1p Support
> [...]
>    The actual treatment is identical in both Split and Local MAC
>    mode, except that the former requires the 802.1Q header to be
>    added to the station's packet vs. the outer packet header.  The
>    IEEE 802.11 does not permit the station's packet to include an
>    802.1Q header.  Instead, the QoS mechanisms defined in the IEEE
>    802.11 standard are used by stations to mark a packet's priority.
> </new-modified text>

Should this be "except the latter.."?

> and then we provide the actual behavior description for the bits,
> which for this case it is OK to include in a single block for both
> Split and Local MAC. The text reads:
> 
>    P=1, T=0:   The WTP marks the priority field in the 802.1Q header,
>       which is added to the station's packet (in a Local MAC mode) or
>       outer packet header (in a Split MAC mode), to either 
>       the default, or the station specific 802.1p policy.
> <PRC> So in this case we add an 802.1Q header, and set the priority
> field based on the default, or the user policy.
> 
>    P=1, T=1:   The WTP marks the priority field in the 802.1Q header,
>       which is added to the station's packet (in a Local MAC mode) or
>       outer packet header (in a Split MAC mode), to the value found in
>       User Priority field of the QoS Control field of the IEEE 802.11
>       header.  If the QoS Control field is not present in the IEEE
>       802.11 header, then the packet is handled as defined in 
>       the above option.
> <PRC> In this case, we copy the value of the User Priority 
> field in the QoS Control field to the 802.1Q header. This is 
> *similar* to the DSCP behavior, where we use a station set value.
> 
>    P=0, T=0:   The WTP sets the priority field in the 802.1Q header to
>       zero (0), if present.  This bit combination MUST NOT be 
>       set if the 'U' bit is not set.
> <PRC> If the header exists, then the value is set to zero (0).
> 
> So the behavior for both DSCP *and* 802.1p is very similar in all
> cases, except we are dealing with different fields in the packet.

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?

(I'm wondering if the inner packet can also have its own field
somewhere...)

(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?)

> Maybe if you could provide me more clarity on what above is causing
> the confusion, then I could clean that up. From the e-mail you sent,
> I wonder if you just read the first section, and didn't read the bit
> descriptions, which led to the confusion.
> 
> > The current text seems to suggest there'd be three combinations
> > which make sense, needing two bits. So two for DSCP + two for
> > 802.1p would be the same amount of bits as now.
> 
> There are three bits. The 'T' bit behavior is the same, regardless of
> whether DSCP or 802.1p was used. Then DSCP and 802.1p can be set
> separately - and in combination.

I think most of the confusion comes from having the 'T' and 'U'
bits in common, which means that DSCP and 802.1p behavior *cannot*
be set completely separately.

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 2 Sep 2008 14:58:26 -0700

> The 'U' bit is also common -- and having T/U in common means that it's
*NOT* always possible to use just one of the mechanisms in certain way.
I think we need separate bits here.

I was trying to keep as much of the original protocol as possible, but
it is clear from this exchange that we will have to deviate and simply
define new bits that have a much clearer behavior.

> This is redundant (as exactly the same behavior can be had with
D=1,T=1), and it's sort of unintuitive that even when the 'D' (DSCP) bit
is set to zero, you're still modifying DSCP field of the inner packet.

OK, In this new proposal, below, I have simply moved away from trying to
overload bits and we will no longer see this issue.

> More importantly, however, these three combinations don't include the
combination "use NNNNNN"+"don't touch": i.e. use the DSCP value from the
CAPWAP message element for the outer header, but don't modify the inner
header.

I believe all cases are now covered.

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.

Just to ensure we are clear, I have changed the SHALL to MUST, and added
an "All" at the beginning, in section 6.1, which now reads:
6.1.  IEEE 802.11 Add WLAN
[...]

      All IEEE 802.11
      management frames SHALL be tunneled using 802.11 Tunnel mode.

> (I'm wondering if the inner packet can also have its own field

No. There is no assumption that the tunnel is a trunked port. That's not
to say that we couldn't have done this before, but that has never been
discussed on the list, was never considered a requirement, so I am
reticent to change that at this point. This would impact current
implementations.

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.

> > the confusion, then I could clean that up. From the e-mail you sent,
I 
> > wonder if you just read the first section, and didn't read the bit 
802.1p 
> > > would be the same amount of bits as now.
> > 
> bits in common, which means that DSCP and 802.1p behavior *cannot* be
set completely separately.

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:

<new text>

   When the WLAN is created on the WTP, a default Quality of Service
   policy is established through the IEEE 802.11 WTP Quality of Service
   message element (see Section 6.22).  This default policy will cause
   the WTP to use the default QoS values for any station associated with
   the WLAN in question.  The AC MAY also override the policy for a
   given station, by sending the IEEE 802.11 Update Station QoS message
   element (see Section 6.20), known as a station specific QoS policy.

   Beyond the default, and per station QoS policy, the IEEE 802.11
   protocol also allows a station to request special QoS treatment for a
   specific flow through the TSPEC information elements found in the
   IEEE 802.11-2007's QoS Action Frame.  Alternatively, stations MAY
   also use the WiFi Alliance's WMM specification instead to request QoS
   treatment for a flow (see [WMM]).  This requires the WTP to observe
   the Status Code in the IEEE 802.11-2007 and WMM QoS Action ADDTS
   responses from the AC, and provide the services requested in the
   TSPEC information element.  Similarly, the WTP MUST observe the
   Reason Code information element in the IEEE 802.11-2007 and WMM QoS
   Action DELTS responses from the AC by removing the policy associated
   with the TSPEC.

   The IEEE 802.11 WTP Quality of Service message element's Tagging
   Policy field indicates how the packets are to be tagged, known as the
   Tagging Policy.  There are five bits defined, two of which are used
   to indicate the type of QoS to be used by the WTP.  The first is the
   'P' bit which is set to inform the WTP it is to use the 802.1p QoS
   mechanism.  When set, the 'Q' bit is used to inform the WTP which
   802.1p priority values it is to use.

   The 'D' bit is set to inform the WTP it is to use the DSCP QoS
   mechanism.  When set, the 'I' and 'O' bits are used to inform the 
   WTP which values it is to use in the inner header, in the station's
   original packet, or the outer header, the latter of which is only
   valid when tunneling is enabled.

   When an IEEE 802.11 Update Station QoS message element is received,
   while the specific 802.1p priority or DSCP values may change for a
   given station, known as the station specific policy, the original
   Tagging Policy (the use of the five bits) remains the same.

   The use of the DSCP and 802.1p QoS mechanisms are not mutually
   exclusive.  An AC MAY request that a WTP use none, one or both types
   of QoS mechanisms at the same time.

2.6.1.1.  802.1p Support

   The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station
   QoS message elements include the "802.1p Tag" field, which is the
   802.1p priority value.  This value is used by the WTP by adding an
   802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set
   according to the policy provided.  Note this tagging is only valid
   for interfaces that support 802.1p.  The actual treatment does not
   change for either Split or Local MAC modes, or when tunneling is
   used.  The only exception is when tunneling is used, the 802.1Q
   header is added to the outer packet (tunneled) header.  The IEEE
   802.11 standard does not permit the station's packet to include an
   802.1Q header.  Instead, the QoS mechanisms defined in the IEEE
   802.11 standard are used by stations to mark a packet's priority.
   When the 'P' bit is set in the Tagging Policy, the 'Q' bit has the
   following behavior:

   Q=1:   The WTP marks the priority field in the 802.1Q header to
      either the default, or the station specific 802.1p policy.

   Q=0:   The WTP marks the priority field in the 802.1Q header to the
      value found in User Priority field of the QoS Control field of the
      IEEE 802.11 header.  If the QoS Control field is not present in
      the IEEE 802.11 header, then the behavior described under 'Q=1' is
      used.

2.6.1.2.  DSCP Support

   The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station
   QoS message elements also provide a "DSCP Tag", which is used by the
   WTP when the 'D' bit is set to mark the DSCP field of both the IPv4
   and IPv6 headers (see [RFC2474]).  When DSCP is used, the WTP marks
   the inner packet (the original packet received by the station) when
   the 'I' bit is set.  Similarly, the WTP marks the outer packet
   (tunnel header's DSCP field) when the 'O' bit is set.

   When the 'D' bit is set, the treatment of the packet differs based
   whether the WTP is tunneling the station's packets to the AC.
   Tunneling does not occur in a Local MAC mode when the AC has
   communicated that tunneling is not required, as part of the IEEE
   802.11 Add WLAN message element Section 6.1.  In the case where
   tunneling is not used, the 'I' and 'O' bits have the following
   behavior:

   O=1:   This option is invalid when tunneling is not enabled for
      station data frames.

   O=0:   This option is invalid when tunneling is not enabled for
      station data frames.

   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.

   I=0:   The WTP MUST NOT modify the DSCP field in the station's
      packet.

   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.

   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.

   I=0:   The WTP MUST NOT modify the DSCP field in the station's
      packet.

   The IP header also includes the Explicit Congestion Notification
   (ECN) bits [RFC3168].  When packets received from stations are
   encapsulated by the WTP, the ECN bits are set to zero (0) in the
   outer header.  The WTP does not modify the ECN bits in the original
   station's packet header.  This mode of operation is detailed as the
   "limited functionality option" in [RFC3168].

2.6.2.  IEEE 802.11 MAC Management Messages

   It is recommended that IEEE 802.11 MAC Management frames be sent by
   both the AC and the WTP with appropriate Quality of Service values,
   listed below, to ensure that congestion in the network minimizes
   occurrences of packet loss.  Note that the QoS Mechanism specified in
   Tagging Policy is used as specified by the AC in the IEEE 802.11 WTP
   Quality of Service message element (see Section 6.22).  However, the
   station specific policy is not used for IEEE 802.11 MAC Management
   frames.

6.22.  IEEE 802.11 WTP Quality of Service
[...]

   Tagging Policy:   A bit field indicating how the WTP is to mark
      packets for QoS purposes.  The required WTP behavior is defined in
      Section 2.6.1.  The field has the following format:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Rsvd |P|Q|D|O|I|
        +-+-+-+-+-+-+-+-+

      Rsvd:  A set of reserved bits for future use.  All implementations
         complying with this protocol MUST set to zero any bits that are
         reserved in the version of the protocol supported by that
         implementation.  Receivers MUST ignore all bits not defined for
         the version of the protocol they support.

      P:   When set, the WTP is to employ the 802.1p QoS mechanism (see
         Section 2.6.1.1), and the WTP is to use the 'Q' bit.

      Q:   When the 'P' bit is set, the 'Q' bit is used by the AC to
         communicate to the WTP how 802.1p QoS is to be enforced.
         Details on the behavior of the 'Q' bit is specified in
         Section 2.6.1.1.

      D:   When set, the WTP is to employ the DSCP QoS mechanism (see
         Section 2.6.1.2), and the WTP is to use the 'O' and 'I' bits.

      O:   When the 'D' bit is set, the 'O' bit is used by the AC to
         communicate to the WTP how DSCP QoS is to be enforced on the
         outer (tunneled) header.  Details on the behavior of the 'O'
         bit is specified in Section 2.6.1.2.

      I:   When the 'D' bit is set, the 'I' bit is used by the AC to
         communicate to the WTP how DSCP QoS is to be enforced on the
         station's packet (inner) header.  Details on the behavior of
         the 'I' bit is specified in Section 2.6.1.2.
</new text>

I hope this addresses your specific concerns. Thank you very much for
your patience, and guidance through this complex issue.

PatC

---

From: <[email-masked]>
Date: Mon, 8 Sep 2008 12:20:59 +0300

Pat Calhoun wrote:

> 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.)

<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?)
> 
> 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?

> 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):

<snip>
>    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?

Best regards,
Pasi