| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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
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
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.
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:
The values in
decimal are given in the following table:
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 and Expedited Forwarding is described in RFC 2598. 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, From: Feder, Peretz
(Peretz) [mailto:pfeder@ALCATEL-LUCENT.COM] 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] Peretz, Nobody changed it. It is exactly as it
appears in IEEE 802.16-2004. There has been no subsequent modification. Thanks, From: Feder, Peretz
(Peretz) [mailto:pfeder@ALCATEL-LUCENT.COM] 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) 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 |