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

Re: [STDS-802-16] SPAM-LOW: RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????



Lucy: Reserved section 11.13.18.3.3.2 and reserved value for 145/146.cst.3.20 should be acceptable.

 

11.13.18.3.3.2 Reserved

 

Type

Length

Value

[145/146].cst.3.2

3

Reserved

 

 

 

11.3.18.3.3.18 IP Type of Service/DSCP (differentiated services codepoint) Value

The value of this field specifies the matching parameters for the IP type of service/DSCP (IETF RFC 2474). The values are managed by IANA under the Differentiated Services Field Codepoints registry.  If this field is omitted, then comparison of the IP packet ToS byte for this entry is irrelevant.

 

Type

Length

Value

[145/146].cst.3.20

1

DSCP value

 

 

Peretz Feder


From: Lucy Pollak [mailto:lucy.pollak@ALTAIR-SEMI.COM]
Sent: Wednesday, October 22, 2008 12:22 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] SPAM-LOW: RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????

 

OK,

May be you also have some idea how this reservation will appear to be?

Do you agree with Peretz's proposal: "Reserved" section name and inside the table with reserved value field?

If section is not empty it seems for me it could not be named as "Reserved", is it correct?

The other solution is to add CST table for all CST TLVs and sub-TLVs and mark this TLV (together with 2 I mentioned) as reserved. I do not like this solution because of two-level depth of deprecated TLV ([145/146].cst.3.2). It will complicate the table.

 

What do you think?

 

Best Regards.

Lucy Pollak


From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Wednesday, October 22, 2008 4:16 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] SPAM-LOW: RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????

 

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: Lucy Pollak [mailto:lucy.pollak@altair-semi.com]
Sent: Wednesday, October 22, 2008 6:26 AM
To: Phillip Barber; Feder, Peretz (Peretz); STDS-802-16@LISTSERV.IEEE.ORG
Subject: SPAM-LOW: RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????

 

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.

Lucy Pollak


From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Tuesday, October 21, 2008 2:15 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????

 

Yes, you have to reserve the Type value as well.

 

Everything else looks good.

 

Thanks,

Phil

 


From: Feder, Peretz (Peretz) [mailto:pfeder@ALCATEL-LUCENT.COM]
Sent: Monday, October 20, 2008 4:06 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????

 

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: Lucy Pollak [mailto:lucy.pollak@altair-semi.com]
Sent: Monday, October 20, 2008 4:22 PM
To: Feder, Peretz (Peretz); STDS-802-16@LISTSERV.IEEE.ORG
Subject: [WARNING - NOT VIRUS SCANNED] RE: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????

 

Hi Peretz,

The idea is to change the whole TLV into reserved similar to other deprecated TLVs:

11.13.18.3.3.2 Reserved IP Type of Service/DSCP (differentiated services codepoint) Range and Mask field

The values of this field specify the matching parameters for the IP type of service/DSCP (IETF RFC 2474) byte range and mask. An IP packet with IP type of service (ToS) byte value “ip-tos” matches this parameter if tos-low ≤ (ip-tos AND tos-mask) ≤ tos-high. If this field is omitted, then comparison of the IP packet ToS byte for this entry is irrelevant.

 

And also strikethrough table here.

 

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.

Lucy Pollak


From: Feder, Peretz (Peretz) [mailto:pfeder@ALCATEL-LUCENT.COM]
Sent: Monday, October 20, 2008 9:35 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [WARNING - NOT VIRUS SCANNED] Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????

 

So Lucy:

 

Do you want to deprecate [145/146].cst.3.2 as follow:

 

Type

Length

Value

[145/146].cst.3.2

3

Reserved

 

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) Range and mask field Value. The values of this field specifiesy the matching parameters for the IP type of service/DSCP (IETF RFC 2474). The values are managed by IANA under the Differentiated Services Field Codepoints registry.  byte range and mask. An IP packet with IP type of service (ToS) byte value “ip-tos” matches this parameter if tos-low ≤ (ip-tos AND tos-mask) ≤ tos-high. If this field is omitted, then comparison of the IP packet ToS byte for this entry is irrelevant.

 

Type

Length

Value

[145/146].cst.3.20

1

DSCP value

 

 

Peretz Feder

 


From: Lucy Pollak [mailto:lucy.pollak@ALTAIR-SEMI.COM]
Sent: Monday, October 20, 2008 8:24 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: [WARNING - NOT VIRUS SCANNED] Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????

 

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.

Lucy Pollak


From: Feder, Peretz (Peretz) [mailto:pfeder@ALCATEL-LUCENT.COM]
Sent: Monday, October 20, 2008 7:59 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] SV: Re: [STDS-802-16] DSCP Mask and Range??????

 

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) Range and mask field Value. The values of this field specifiesy the matching parameters for the IP type of service/DSCP (IETF RFC 2474). The values are managed by IANA under the Differentiated Services Field Codepoints registry.  byte range and mask. An IP packet with IP type of service (ToS) byte value “ip-tos” matches this parameter if tos-low ≤ (ip-tos AND tos-mask) ≤ tos-high. If this field is omitted, then comparison of the IP packet ToS byte for this entry is irrelevant.

 

Type

Length

Value

[145/146].cst.3.2

1 3

DSCP value tos-low, tos-high, tos-mask

 

Peretz Feder

 

-----Original Message-----
From: Phillip Barber [mailto:pbarber@broadbandmobiletech.com]
Sent: Monday, October 13, 2008 10:53 AM
To: Feder, Peretz (Peretz); STDS-802-16@LISTSERV.IEEE.ORG
Subject: 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

 

 





************************************************************************************
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.
************************************************************************************






************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************