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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 25 Aug 2008 13:59:09 -0700

Hi Pasi,
 
You had the following comment:
 
> I'm not sure "WTP MUST trust" is best possible phrasing; in this case,
> the WTP doesn't use the value for anything, so it doesn't really
> "trust" it (any more than it "trusts", say, the destination IP address
> field).
> 
> If it would copy the inner DSCP Tag to CAPWAP data plane tunnel's IP
> header, then "trust" might be appropriate... but I case this wasn't
> intended? So the intended logic would be:
> 
> D=1 and T=1: mark data plane tunnel's IP header (with DSCP value
>   from this message element, not from inner IP header); don't change
>   the inner IP header sent by STA.
> D=1 and T=0: mark data plane tunnel's IP header (with DSCP value
>   from this message element, not from inner IP header); also replace
>   the DSCP field in the inner IP header with this value (if it's
>   IPv4/IPv6, and encryption isn't done in WTP)
> D=0 and T=0: use default DSCP value for data plane tunnel's IP
>   header; don't touch the inner IP header.
> D=0 and T=1: use default DSCP value for data plane tunnel's IP 
>  header; don't touch the inner IP header
> 
> Or are the D/T bits supposed to be orthogonal, so the last
> case would replace the DSCP field in the inner header?

and
 
> >       T:   When set, this indicates that any QoS markings on packets
> >          received from stations are to be trusted and honored.
> 
> As I commented above, "trusted and honored" describes perhaps the
> intent, but I'm not sure what, exactly, an implementation would do
> here. IMHO this would be best phrased as talking about processing
> specific header fields (adding header with value X; copying value
> from one place to another; replacing an existing value).

OK, this is a valid comment, so I have accepted all of your proposed text changes and modified the following text to address the issues you have raised
 
<modified text>
2.6.  CAPWAP Data Channel QoS Behavior
   The CAPWAP IEEE 802.11 binding specification provides procedures to
   allow for the WTP to enforce Quality of Service on IEEE 802.11 Data
   Frames and MAC Management messages.
 
2.6.1.  IEEE 802.11 Data Frames
   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, via the 'P'
   bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (do not tag).  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.
 
2.6.1.1.  802.1p Support
   The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station
   QoS message elements provide an "802.1p Tag", which 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 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 following options are
   possible:
 
   P=1, T=0:   The WTP marks the priority field in the 802.1Q header,
      which is added to the station's packet or outer packet header, to
      either the default, or the station specific DSCP policy.

   P=1, T=1:   The WTP marks the priority field in the 802.1Q header,
      which is added to the station's packet or outer packet 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 packet is handled as defined
      in the above option.
 
   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.
 
   P=0, T=1:   This is an invalid bit combination.
 
   Note that if the 'U' bit was set, then the WTP MUST NOT set the
   802.1Q header's priority field.  Note that in this case, the 'P', 'D'
   and 'T' bits MUST NOT be set.
 
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]).  Unlike 802.1p, the WTP can mark
   either the inner packet (the original packet received by the
   station), or the outer packet's IP header.  If the 'D' bit is not
   set, the WTP MUST NOT mark either the inner or outer packet's IP
   header's DSCP field.
 
   Assuming the 'D' bit is set, the treatment of the packet differs
   based on whether the WTP is operating in a Split or Local MAC mode.
   For Local MAC mode, the WTP does not tunnel packets to the AC, and
   there is therefore no outer packet to mark.  In this case, there are
   three possible mode of operations:
 
   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.
 
   D=1, T=1:   The WTP does not modify the DSCP field in the station's
      packets.
 
   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.
 
   D=0, T=1:   This is an invalid bit combination.
 
   For Split MAC mode, 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, there are two
   options:
 
   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.
 
   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
      modifyable 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.
 
   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.
 
   D=0, T=1:   This is an invalid bit combination.
 
   Note that if the 'U' bit was set, then the WTP MUST ensure that
   neither the outer or inner packet header's DSCP field is set.  Note
   that in this case, the 'P', 'D' and 'T' bits MUST NOT be set.
 
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 Tagging Policy used is
   specified by the AC in the IEEE 802.11 WTP Quality of Service message
   element (see Section 6.22), except that in this case the 'T' bit is
   not observed.
[...]

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
        +-+-+-+-+-+-+-+-+
        |Reservd|T|D|P|U|
        +-+-+-+-+-+-+-+-+

      Reserved:  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.

      T:   When set, this indicates that the WTP MUST NOT modify any QoS
         markings on packets received from stations.

      D:   When set, this indicates that the WTP is to use DSCP to
         provide Quality of Service.

      P:   When set, this indicates that the WTP is to use 802.1p to
         provide Quality of Service.

      U:   When set, this indicates that the CAPWAP packets should be
         untagged.  When set, the 'T', 'D' and 'P' bits MUST NOT be set.
         If any other bits are set, the WTP will follow the behavior
         specified by the 'U' bit.
</modified text>

Let me know if this addresses all of your concerns.

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: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 25 Aug 2008 14:47:58 -0700

I forgot to addess one more of your comments:
 
> (BTW -- this discussion about DSCP reminded me that the spec doesn't
> say anything about the ECN bits...)
 
That was in fact intentional. The LWAPP and CAPWAP specs never got into specifying how the ECN bits are to be used. I would recommend that we leave the use of ECN for a subsequent version of the protocol. At this point we can either continue to be silent about it, or simply add a statement at the end of section 2.6.1.2 to the effect of:
 
<possible text>
The CAPWAP protocol does not make use of ECN [RFC3168], therefore the ECN bits in the DSCP field MUST be set to zero (Not-ECT).
</possible text>
 
PatC
________________________________

From: Pat Calhoun (pacalhou)
Sent: Mon 8/25/2008 1:59 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Capwap] Issue 171: Pasi nits on binding spec

Hi Pasi,

and

 
<modified text>

 
 
2.6.1.1.  802.1p Support

 

 
2.6.1.2.  DSCP Support

 

 

 

 

[...]

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Reservd|T|D|P|U|
        +-+-+-+-+-+-+-+-+

Thanks again,

PatC

---

From: <[email-masked]>
Date: Tue, 26 Aug 2008 10:19:47 +0300

Pat Calhoun wrote:
> That was in fact intentional. The LWAPP and CAPWAP specs never got
> into specifying how the ECN bits are to be used. I would recommend
> that we leave the use of ECN for a subsequent version of the
> protocol. At this point we can either continue to be silent about
> it, or simply add a statement at the end of section 2.6.1.2 to the
> effect of:
>  
> <possible text>
> The CAPWAP protocol does not make use of ECN [RFC3168], therefore the
> ECN bits in the DSCP field MUST be set to zero (Not-ECT).
> </possible text>

How to construct the outer IP header for tunneled data packets (when
doing Split MAC) is an important detail for any spec doing tunneling,
so I don't think being silent about it would be a good choice.

RFC 3168 does have discussion (in Section 9) of various ways of 
doing ECN with tunnels. I think what you're proposing would be the
"limited-functionality" option (ECN is preserved in the inner header,
but disabled in the outer header). I don't have enough expertise in ECN 
to really know which of the options would be the best... 

(BTW, the text should be specific that only the ECN bits in the 
*outer* header are set to zero -- the ECN bits in the inner header
are not modified even if the DSCP tag is modified. And the ECN
bits are not really *in* the DSCP field, but next to it.)

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 26 Aug 2008 10:06:21 -0700

OK - thanks for the pointer. In that case, I would propose the following
text:

<new text>
2.6.1.2.  DSCP Support
[...]
   The DSCP field also includes the Explicit Congestion Notification
   (ECN) bits.  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].
</new text>

If this is OK with you, are you comfortable with the rest of the text at
this point? I'd like to know if I can close out the remaining issues.
These are:
171 - This issue
161 - IANA Issues. I had responded to your comments about the vendor ID,
etc. I think we are done, but need confirmation
158 - Allocation of WBID. You had commented that we need to provide some
guidance to IANA when dealing with a Designated Expert request. I had
provided some text. I think we are done here as well, but need
confirmation.
??? - RSN Handling at WTP. You had asked me to add some additional
language to help provide guidance on how the WTP deals with the RSN
information element. I believe this is closed, but need confirmation.

PatC 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 26, 2008 12:20 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: RE: [Capwap] Issue 171: Pasi nits on binding spec

> that we leave the use of ECN for a subsequent version of the protocol.

> At this point we can either continue to be silent about it, or simply 
> add a statement at the end of section 2.6.1.2 to the effect of:
>  
> <possible text>

How to construct the outer IP header for tunneled data packets (when
doing Split MAC) is an important detail for any spec doing tunneling, so
I don't think being silent about it would be a good choice.

RFC 3168 does have discussion (in Section 9) of various ways of doing
ECN with tunnels. I think what you're proposing would be the
"limited-functionality" option (ECN is preserved in the inner header,
but disabled in the outer header). I don't have enough expertise in ECN
to really know which of the options would be the best... 

(BTW, the text should be specific that only the ECN bits in the
*outer* header are set to zero -- the ECN bits in the inner header are
not modified even if the DSCP tag is modified. And the ECN bits are not
really *in* the DSCP field, but next to it.)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Thu, 28 Aug 2008 14:44:57 +0300

Pat Calhoun wrote:

> OK, this is a valid comment, so I have accepted all of your proposed
> text changes and modified the following text to address the issues
> you have raised
>  
> <modified text>

Fine so far..

>    original Tagging Policy (the use of the 'T', 'D', 'P' and 'U' bits)

I think the usage of bits need some further work.

There isn't really such a thing as "untagged" DSCP packet; the field
is always there (it can be tagged with value 000000, of course).
Also, it'd be more logical if the 802.1p and DSCP bits were
orthogonal (you could use either one of them, neither, or both -- ).

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" 

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?

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.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Thu, 28 Aug 2008 14:50:49 +0300

Pat Calhoun wrote:

> OK - thanks for the pointer. In that case, I would propose the
> following text:
> 
> <new text>
> 2.6.1.2.  DSCP Support
> [...]

The ECN bits are not *included* in the DSCP field (which is 6 bits);
they're the 2 bits next to the DSCP field. Otherwise, works for me.

> If this is OK with you, are you comfortable with the rest of the
> text at this point? I'd like to know if I can close out the
> remaining issues.  These are:
>
> 171 - This issue

Not quite yet...

> 161 - IANA Issues. I had responded to your comments about the 
> vendor ID, etc. I think we are done, but need confirmation

Looks OK.

> 158 - Allocation of WBID. You had commented that we need to provide
> some guidance to IANA when dealing with a Designated Expert
> request. I had provided some text. I think we are done here as well,
> but need confirmation.

I'd be happier if the WBID field would be large enough not to make
scarcity an issue.. but I guess the text you provided is OK, too.

> information element. I believe this is closed, but need confirmation.

I think the proposed text probably covers everything.

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 28 Aug 2008 12:23:49 -0700

> Also, it'd be more logical if the 802.1p and DSCP bits were orthogonal
(you could use either one of them, neither, or both -- ).

OK, so I have changed "do not tag" to "set to zero", and added the last
paragraph:

<modified/new text>
   bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (set to zero).  The

   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>

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

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.

   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.

<PRC> Both the outer and inner DSCP fields are set to zero (0).

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

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.

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.

PatC