Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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