Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????
Peretz,
Yes, implementation specific, especially since the Diffserve code point
assignment is happening at a layer higher than MAC and the 802.16
peer-to-peer link is acting just as transparent transport for the Protocol
SDUs.
Thanks,
Phil
-----Original Message-----
From: Feder, Peretz (Peretz) [mailto:pfeder@ALCATEL-LUCENT.COM]
Sent: Sunday, October 12, 2008 9:55 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????
Correct Carl and Phil:
Let's change the present text of section 11.13.18.3.3.2 so that this value
is simply inherited from the upper IP setting.
Now, we have to consider that a BS may need to set its own DSCP value for
the uplink packets arriving from the MS (even if already marked). But even
for such purpose I do believe it will be implementation specific and most
likely an operator configuration, no?
Peretz Feder
-----Original Message-----
From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Saturday, October 11, 2008 9:44 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????
Well, I stand corrected. Apparently someone does remember and has come
forward :)
It sounds like we need to re-write this section to simply reference the
Diffserv code point allocation RFCs. Since 802.16 is a pee-to-peer PHY/MAC
communication channel, the TLV in 802.16 should just be a payload for the
Diffserv code point value assigned by a higher layer, though it is possible
for 802.16 to use this information to prosecute bearer traffic scheduling. I
guess my point is that the 802.16 MAC should not set the value of this TLV,
it should inherit it from the higher layer, when Diffserv value is present
in the IP header.
Thanks,
Phil
-----Original Message-----
From: Eklund, Carl (NSN - FI/Espoo) [mailto:carl.eklund@NSN.COM]
Sent: Saturday, October 11, 2008 1:49 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????
Peretz, Phil,
Around 2000 when we were writing the original spec DiffServ and the DSCP
definitions were still work in progress. It may have been since multiple
proposals for the DSCP encodings were around, we looked at the proposals and
noticed that by masking some bits you would be get a 'by QoS sorted range'
that could then be split in ranges. However, since it is so long since this
was put into the spec the reasons might have been different.
BR Carl
-----Ursprungligt meddelande-----
Från: ext Phillip Barber
Skickat: 2008.10.10 22.18.50
Till: Phillip Barber;STDS-802-16@LISTSERV.IEEE.ORG
Ämne: Re: [STDS-802-16] DSCP Mask and Range??????
Peretz,
I assumed from your statement:
Whoever brought this text in, can you provide the logic behind this section
please?
that you were insinuating that this somehow had changed since originally
incorporated in the standard. After all, it has been in there since at least
IEEE 802.16-2001 (I did a little more research and found that the existing
language goes back at least this far).
So, this is most certainly not a recent change. It has been in the standard
for around eight years. So I really doubt that we are going to be able to
track back to the original contributors and get them to validate the
rationale behind the current text.
That being said, I have no idea how the current language is supposed to
correlate to the Diffserv code point value assignments that the existing
RFCs define.
FYI, here is some text that I use as reference for Diffserv code point. I
can't remember where I got this from, someplace on the internet, but it is
not my original work:
IP Precedence and Differentiated Services (DiffServ)
DiffServ is concerned with classifying packets as they enter the local
network. This classification then applies to Flow of traffic where a Flow is
defined by 5 elements; Source IP address, Destination IP, Source port,
Destination port and the transport protocol. A flow that has been classified
or marked can then be acted upon by other QoS mechanisms. Multiple flows can
therefore be dealt with in a multitude of ways depending on the requirements
of each flow. Packets are first Classified according to their current DSCP.
Then they are separated into queues where one queue may be routed via a
marking mechanism and another queue may be examined more closely. After
further examination additional packets may be sent for marking or be sent
direct to the shaping/dropping mechanisms where all packets end up before
leaving the interface.
The IP header has a field called the Type of Service (TOS) that sits between
the Header Length field and the Total Length field. (Refer to IP Datagram
TOS <http://www.rhyshaden.com/ipdgram.htm#tos> field for a view of the Type
Of Service field in the IP header.) Traditionally, IP Precedence has used
the first three bits of the TOS field to give 8 possible precedence values.
* 000 (0) - Routine
* 001 (1) - Priority
* 010 (2) - Immediate
* 011 (3) - Flash
* 100 (4) - Flash Override
* 101 (5) - Critical
* 110 (6) - Internetwork Control
* 111 (7) - Network Control
DiffServ introduces the concept of the DiffServ Code Point (DSCP) that uses
the first 6 bits of the TOS field thereby giving 26 = 64 different values.
RFC <http://www.ietf.org/rfc/rfc2474.txt> 2474 describes the Differentiated
Services (DS) field and the DiffServ Code Point (DSCP).
With DiffServ each router handles each packet differently. The concept of
Per-Hop Forwarding Behaviour (PHB) is introduced where classes are developed
such as Business, Telecommuter, Residential etc. that can be offered by an
ISP as different levels of service. A Per-Hop Behaviour is effectively a way
of forwarding a particular flow or group of flows (Behaviour Aggregate) of
traffic on a DiffServ node. A flow, or flows, of packets marked with a
particular DSCP in the DS field will be subject to a particular method of
forwarding and rules as encapsulated in the Behaviour Aggregate. This
Aggregate has three elements to it (or three colours) which determine
whether the router interface 1) Drops the datagram, 2) Sends the datagram or
3) reclassifies it. This three-colour marker is detailed in RFC 2697
<http://www.ietf.org/rfc/rfc2697.txt> . For instance 5 flows can be treated
as a Behaviour Aggregate so they are treated similarly as a group in most
respects. Each flow is then distinguished by an additional Drop Probability
and Forwarding Behaviour. Be aware that as the Drop Preference value
increases, so the probability of being dropped increases!
The following table illustrates the DSCP values:
Per Hop Behaviour (PHB)
DiffServ Code Point (DSCP)
IP Precedence
Default
0
000000
Assured Forwarding
Low Drop Probability
Medium Drop Probability
High Drop Probability
Class 1
AF11
AF12
AF13
1
001010
001100
001110
Class 2
AF21
AF22
AF23
2
010010
010100
010110
Class 3
AF31
AF32
AF33
3
011010
011100
011110
Class 4
AF41
AF42
AF43
4
100010
100100
100110
Expedited Forwarding
EF
5
101110
The values in decimal are given in the following table:
DSCP
Binary
Decimal
Default
000000
0
CS1
001000
8
AF11
001010
10
AF12
001100
12
AF13
001110
14
CS2
010000
16
AF21
010010
18
AF22
010100
20
AF23
010110
22
CS3
011000
24
AF31
011010
26
AF32
011100
28
AF33
011110
30
CS4
100000
32
AF41
100010
34
AF42
100100
36
AF43
100110
38
CS5
101000
40
EF
101110
46
CS6
110000
48
CS7
111000
56
We can observe the construction of the DSCP values by taking the example for
the Per Hop Behaviour AF32. AF32 is derived from the binary 011100. The red
section is where the 3 comes from in AF32 and is the Behaviour Aggregate.
The blue section is where the 2 comes from in AF32 and is the Drop
Probability. The final green section with the 0 is ignored.
The decimal IP Precedence value is derived from the red portion and is also
called the Class Selector (CS). Often the DSCPs are configured in decimal.
The decimal value is derived from all 6 bits of the DiffServ field as you
will see from the table.
Notice how the three Most Significant Bits (MSB) determine the Class and map
directly to the IP Precedence bits. The Class Selector Code Points all have
the form xxx000. The three LSBs determine the Drop Probabilities and are
ignored by IP Precedence-only devices. Also notice that the LSB is always
'0'.
Packets from different sources can have the same DSCP value and so can be
grouped together as a Behaviour Aggregate and treated in the same manner. A
packet with a DSCP not mapped to one of the above PHB i.e. different from
the recommendations, will have its DSCP mapped to the Default PHB of 000000.
Be aware that the table is recommending the values and different
manufacturers could use different ones.
Expedited Forwarding within DiffServ is as close as you can get to IntServ
as it provides low-loss, low-latency, low-jitter and guaranteed bandwidth.
Assured Forwarding is described in RFC 2597
<http://www.ietf.org/rfc/rfc2597.txt> and Expedited Forwarding is described
in RFC 2598 <http://www.ietf.org/rfc/rfc2598.txt> .
To manage the policies you need to use a Common Open Policy Service (COPS).
I can also recommend RFC 3086 and RFC 4594 for reference.
And I think you may be mistaken on using RFC 2457 as a reference.
Thanks,
Phillip Barber
Chief Scientist
Wireless Advanced Research and Standards
Huawei Technologies Co., LTD.
_____
From: Feder, Peretz (Peretz) [mailto:pfeder@ALCATEL-LUCENT.COM]
Sent: Friday, October 10, 2008 1:04 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] DSCP Mask and Range??????
I know Phil it has been included from day one. I am missing the rational
here; it makes little sense to specify a range for a value that it is very
deterministic in all the relevant RFCs.
This old text needs a better rational 4 years later when applied to the RFCs
mentioned below.
Peretz Feder
_____
From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Friday, October 10, 2008 1:11 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] DSCP Mask and Range??????
Peretz,
Nobody changed it. It is exactly as it appears in IEEE 802.16-2004. There
has been no subsequent modification.
Thanks,
Phillip Barber
Chief Scientist
Wireless Advanced Research and Standards
Huawei Technologies Co., LTD.
_____
From: Feder, Peretz (Peretz) [mailto:pfeder@ALCATEL-LUCENT.COM]
Sent: Thursday, October 09, 2008 10:22 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] DSCP Mask and Range??????
IEEE colleagues:
I assume no response and no interest means that nobody really cares if the
strange ip-tos mask is removed, yes?
Peretz Feder
_____
From: Feder, Peretz (Peretz)
Sent: Wednesday, October 08, 2008 4:43 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: RE: [STDS-802-16] status of three drafts towards Sponsor Ballot
Dear IEEE 802.16 Colleagues,
Section 11.13.18.3.3.2 Type of Service/DSCP (differentiated services
codepoint)Range and Mask field talks about ip-tos mask.
What it the idea behind the use of DSCP range and tos mask as described in
that section?
These terms are not mentioned in RFC 2474.
In RFC2457 DiffServ, RFC2597 and RFC3246 AF and EF classes are defined and
they all refer to discrete values for DiffServ, no mention of mask or a
range.
The IANA registry for these DSCP values is not contiguous, how can a range
or a mask be applied.
http://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml
Whoever brought this text in, can you provide the logic behind this section
please?
Thanks in advance, Peretz Feder