| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
And that was an error… The TLV Type values should have been
reserved for a ‘cooling’ period to avoid reuse and confusion of legacy
deployments. My guess is that the previous deprecations
did not consider avoiding confusion to legacy deployments of import. I believe
the situation is different now. I also believe that it is very likely that this
TLV may be widely used in current deployments, even if erroneously encoded. We are best served by reserving the TLV
value and avoiding potential confusion on legacy networks. Thanks, Phil From: Hi, I see your point and tend to agree that we
need to mention somewhere that the sub-TLV is reserved to prevent immediate
re-use. We do this ordinary if there is some
common table with the list of sub-TLVs. Unfortunately, such table does not exist
for CST and their subtypes. I tried to find some example similar to
what you proposed (to reserve sub-TLV value). Unfortunately, I did not find any one. Moreover,
I paid attention that some sub-TLVs present in IEEE Std 802.16-2004 in CST
encoding were removed without any Type value reservations. Please, see: "11.13.19.3.3
Classifier error parameter set" & "11.13.19.3.6 PHS error
parameter set" which
deprecates TLVs [145/146].cst.2 and [145/146].cst.5. Both of them are not
still in use. So, I am
not sure we need to reserve the Type. Best
Regards. From: Phillip Barber
[mailto:pbarber@BROADBANDMOBILETECH.COM] Yes, you have to reserve the Type value as
well. Everything else looks good. Thanks, Phil From: This is what I meant Lucy, sorry if it
wasn’t clear. But what do we do with: “ [145/146].cst.3.2” I think for BC reason we need to indicate
Reserved as well, no? Having top level section x.x.3.2 say Reserved may not be
enough. Peretz Feder From: Hi Peretz, The idea is to change the whole TLV into
reserved similar to other deprecated TLVs: 11.13.18.3.3.2 Reserved
The new text you proposed for TLV 3.20
should be placed into new section 11.13.18.3.3.18. It should not include
editorial changes and whole section should be highlighted as new. Best Regards. From: So Lucy: Do you want to deprecate [145/146].cst.3.2
as follow:
and create a new TLV: [145/146].cst.3.20 I believe 3.20 is the next available one IP Type of Service/DSCP (differentiated services codepoint)
Peretz Feder From: Hi, For backward compatibility may be it is
reasonable to define new TLV for DSCP and obsolete the old one. It seems as a
bad practice to change TLV length and also handling rules within the same TLV
encoding. Best Regards. From: Sorry for the pause Phil and Carl, I was
out for a while and will be out for 2 days again this week. How about the following text change: 11.13.18.3.3.2 IP Type of Service/DSCP (differentiated services
codepoint)
Peretz Feder -----Original Message----- 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: 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: 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: 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: 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 ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ |