Hello Rex:
Are you referring to the following from RFC 4594?
If yes, it is allowing 64 values:
From RFC 4594
1.4.4. Differentiated Services Code Point (DSCP)
The DSCP is a number in the range 0..63 that is placed into an IP
packet to mark it according to the class of traffic it belongs in.
Half of these values are earmarked for standardized services, and the
other half of them are available for local definition.
1.5. Key Service Concepts
While Differentiated Services is a general architecture that may be
used to implement a variety of services, three fundamental forwarding
behaviors have been defined and characterized for general use. These
are basic Default Forwarding (DF) behavior for elastic traffic, the
Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF)
behavior for real-time (inelastic) traffic. The facts that four code
points are recommended for AF and that one code point is recommended
for EF are arbitrary choices, and the architecture allows any
reasonable number of AF and EF classes simultaneously. The choice of
four AF classes and one EF class in the current document is also
arbitrary, and operators MAY choose to operate more or fewer of
either.
PF: Is the above what you refer to as: "4 sticks in my grey matter
RAM"
On 9/7/2006 11:25 AM, Rex Buddenberg wrote:
No longer correct. When the Diffserv working group in IETF formed, they
looked at the question in some depth. Up to this point, the TOS byte
existed in the IPv4 header but was never used and never defined. The DS
group quickly figured out that 2**8 was a non-feasible answer and in
reality, only about 4 categories makes any sense. The reason is found
in the way routers handle priorities: each DSCP requires the router to
set up a queue for it and sort datagrams into that queue. At about four
queues, the CPU requirements for sorting head up an exponential scale
and cost more than any benefits to be gained. The experimentation
showed that non-priv traffic did indeed get poorer treatment (that's the
stuff in the lowest priority queue). But the priv traffic also
suffered!
So when the TOS field was renamed 'DS byte', only a handful (4 sticks in
my mind) of DSCPs were defined.
On Thu, 2006-09-07 at 01:29 -0400, Peretz Feder wrote:
TOS bits are 8 bit field. They can provide 256 DSCP values, no?
On 9/5/2006 1:09 PM, Rex Buddenberg wrote:
As you think through this, it might help to bone up on diff-serv.
Appears to me that what you're really getting to is 'how do we map the
DSCPs to the QOS mechanisms in 802.16?' There are only a few DSCP
values (4 sticks in my grey matter RAM).
On Tue, 2006-09-05 at 15:57 +0530, vimalraj s wrote:
Hi Lee,
According to my understanding
1. An 802.16 system shall not open a seperate connection for each
upper layer protocol if packets
form upper layer protocols have the same QoS requirements.It means
that if a SS has two
clients and both the clients supports Rtps & BE service,if the Rtps
service from client_1
has same Qos parameter as of client_2 supporting Rtps service,then
both the data traffic can go
through same connection?????
if i went wrong plz correct me.
2. If the above statement is right then, if any one of the QOs
parameters(max sustained rate,min
reserved rate,Max latency,jitter,traffic priority...mandatory
parameter for Rtps) varies then a seperate
connection is to be established for a same scheduling service type
(Rtps/BE)????
please clarify my doubt...
thanks
vimal