Subject: RE: [Diffserv] DSCP --> 802.1p

From: [email-masked]
Date: Sat, 19 May 2001 15:37:06 +0800

Hi Brian/Tina,

So what you are saying is that L3 interface devices (between 2 L2 domains) must perform priority mapping according to the policies used in the two domains. In that case L2 switches should only look at the L2 headers. 

Regarding this I have a few questions - 

1. Does DiffServ require L3 devices to use the user-priority fields of underlying L2 network ? For Int-Serv the ISSLL gououp has defined a mapping method - I hav'nt seen anything like that for Diff-Serv. 

2. Consider the case when the L3 device is not 802.1p compliant. In this cases the packets coming to the switch from the router will not be priority tagged. However 802.1p requires that packets being forwarded on VLAN aware links must be priority tagged. This requires the switch to assign a priority to the packet. The assigned priority could be the default priority (0 for Ethernet) or determined from the ToS/DSCP field. Any suggestions on what the switch must do ?

Thanks and best regards,
-Mubarak.

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Saturday, May 19, 2001 1:55 AM
To: Iliff, Tina
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Diffserv] DSCP --> 802.1p

Terminology alert. Diffserv classification is typically an ingress 
*router* function. A level 2 switch isn't a router. Of course, if the
router and switch functions happen to be in a single box, that's fine,
but it doesn't change the principle.

The point is that it's a level 3 function, whether it's in a host or
an ingress router. A level 2 device shouldn't second-guess the level
3 decision.

   Brian

> "Iliff, Tina" wrote:
> 
> However, are you referring to the application host as the traffic source?  The ISP may provision policy in switches which
> follows SLAs and this priority policy may differ from local policy on the hosts.  In this situation, the policy in the switch
> should override the host marking of the packet.  However, if the policy for the host is managed by the ISP, then this
> situation should not occur.
> 
> Please let me know if I am misunderstanding the discussion.
> Regards,
> Tina Iliff
> 
>           -----Original Message-----
>           From:   Brian E Carpenter [mailto:[email-masked]]
>           Sent:   Friday, May 18, 2001 11:38 AM
>           To:     [email-masked]
>           Cc:     [email-masked]; [email-masked]
>           Subject:        Re: [Diffserv] DSCP --> 802.1p
> 
>           But it's precisely so that switches don't need to commit layer violations that we
>           invented diffserv. If the traffic source has made an informed choice of hardware
>           priority on the basis of diffserv, the switch has no business changing it.
> 
>              Brian
> 
>           N.B. I haven't switched this to the diffserv-interest list because that list
>           has temporarily gone away - as soon as it exists again I will inform this list.
> 
>           [email-masked] wrote:
>           >
>           > Hi,
>           >
>           > Brian: Current switches are hardly L2, since a few incorporate sofisticated flow indentification and matching
>           algorithms. This flow matching is incorporated to monitor flows/assign priority to flows etc. Even the low end
>           switches have the capability of "atleast" checking the ToS IP field. In this case mismatch between L2 packet
>           priority and L3->L2 mapped priority may arise.
> 
>           >
>           > Xiaoning: L3 devices must perform priority regeneration at the edge of an L2 network to assign a L2 priority
>           consistant with the management policies of the L2 network and the service level expected by the packet (as per the
>           DSCP field). Infact the Ethernet standard provided for such priority regenration. However if the edge L3 devives do
>           not do this OR do this incorrectly then I agress with Xiaoning's suggestion that each switch must perform its own
>           L3->L2 mapping i.e. L3 priority must be given precedence over L2 priority.
> 
>           >
>           > -Mubarak.
>           >
>           > -----Original Message-----
>           > From: Nie Xiaoning (CPD AA PP)
>           > Sent: Friday, May 18, 2001 1:07 AM
>           > To: Shridhar Mubaraq Mishra (DC SIN COM); [email-masked]
>           > Subject: AW: [Diffserv] DSCP --> 802.1p
>           >
>           > In a layer 3 processing you may have to map from your DSCP to L2 prio while the received l2 prio was assigned by
>           the previous switch.
> 
>           > As DSCP semantics is defined per hop some policy mechnisms are required to ensure the consisteny of
>           > the "mapping-chain".
>           >
>           > -Xiaoning
>           >
>           > -----Ursprüngliche Nachricht-----
>           > Von: [email-masked] [mailto:[email-masked]]
>           > Gesendet am: Donnerstag, 17. Mai 2001 09:41
>           > An: [email-masked]
>           > Betreff: Re: [Diffserv] DSCP --> 802.1p
>           >
>           > Brian,
>           >
>           > The problem is not so much in mapping but in resolving the following situation-
>           >
>           > When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the
>           mapping process, which priority should be given preference ?
> 
>           >
>           > Regards,
>           > Mubarak.
>

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Andrew Smith" <[email-masked]>
Date: Sat, 19 May 2001 01:34:26 -0700

1. Brian has already answered: no. L3 devices use incoming DSCPs according
to the Diffserv policies in force at that L3 boundary (the L3 device mught
be at a Diffserv "edge" or it might be in the "core"). The IETF standards do
not mention a L3 device looking at L2 information (e.g. a 802.1p->DSCP
mapping). There was no demand for standardisation of DSCP->802.1p mappings,
unlike the case for Intserv (see RFC 2815).

2. IEEE 802.1D
(http://standards.ieee.org/reading/ieee/std/lanman/802.1D-1998.pdf) clause 7
(see particularly Tables 7-1 and 7-2) contains rules for what to do in this
case: 802.1 switch must "regenerate" a user_priority based on a mapping
table; this table contains defaults which may be modified by management (see
e.g. RFC 2674) or which handle the case where no incoming priority is
available. There is no mention in IEEE 802.1D of using the DSCPs.

Of course, these are just the standards. Vendors do different things where
they perceive some advantage in doing so. Call your local switch vendor to
find out.

Hope that helps,

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of [email-masked]
Sent: Saturday, May 19, 2001 12:37 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Diffserv] DSCP --> 802.1p

Hi Brian/Tina,

So what you are saying is that L3 interface devices (between 2 L2 domains)
must perform priority mapping according to the policies used in the two
domains. In that case L2 switches should only look at the L2 headers.

1. Does DiffServ require L3 devices to use the user-priority fields of
underlying L2 network ? For Int-Serv the ISSLL gououp has defined a mapping
method - I hav'nt seen anything like that for Diff-Serv.

2. Consider the case when the L3 device is not 802.1p compliant. In this
cases the packets coming to the switch from the router will not be priority
tagged. However 802.1p requires that packets being forwarded on VLAN aware
links must be priority tagged. This requires the switch to assign a priority
to the packet. The assigned priority could be the default priority (0 for
Ethernet) or determined from the ToS/DSCP field. Any suggestions on what the
switch must do ?

Thanks and best regards,
-Mubarak.

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Saturday, May 19, 2001 1:55 AM
To: Iliff, Tina
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Diffserv] DSCP --> 802.1p

   Brian

> "Iliff, Tina" wrote:
>
> However, are you referring to the application host as the traffic source?
The ISP may provision policy in switches which
> follows SLAs and this priority policy may differ from local policy on the
hosts.  In this situation, the policy in the switch
> should override the host marking of the packet.  However, if the policy
for the host is managed by the ISP, then this
>           > Brian: Current switches are hardly L2, since a few incorporate
sofisticated flow indentification and matching
>           algorithms. This flow matching is incorporated to monitor
flows/assign priority to flows etc. Even the low end
>           switches have the capability of "atleast" checking the ToS IP
field. In this case mismatch between L2 packet
>           > Xiaoning: L3 devices must perform priority regeneration at the
edge of an L2 network to assign a L2 priority
>           consistant with the management policies of the L2 network and
the service level expected by the packet (as per the
>           DSCP field). Infact the Ethernet standard provided for such
priority regenration. However if the edge L3 devives do
>           not do this OR do this incorrectly then I agress with Xiaoning's
suggestion that each switch must perform its own
>           > In a layer 3 processing you may have to map from your DSCP to
L2 prio while the received l2 prio was assigned by
>           > When a switch receives a packet with a certain L2 priority and
a different L2 priority is determined via the

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 19 May 2001 13:56:11 +0300 (EEST)

[email-masked] writes:

 > 1. Does DiffServ require L3 devices to use the user-priority fields
 > of underlying L2 network ? For Int-Serv the ISSLL gououp has defined a
 > mapping method - I hav'nt seen anything like that for Diff-Serv.  

for example, use the same mapping as to the mlps exp field.

-- juha

---

From: Michiel van Everdingen <[email-masked]>
Date: Wed, 23 May 2001 11:59:56 +0200

Hello,

Andrew Smith wrote:
> ..<snip>..
> ..<snip>..

Consider the case in which an L3 device is connected to an 802.3 L2
network (no priorities) and an L2 device bridges the packets from
this 802.3 network to an 802.1p network (with priorities).

Questions:
- Is the L2 device allowed to look into the DSCP to guess L2
  priority to be used on the 802.1p network ?
- If yes, should the mapping DSCP -> 802.1p be standardized
  (looking at e.g. the mapping of mpls exp field as Juha suggests) ?

Thanks,

Michiel

-- 

+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Lucent Technologies - Optical Networking Group - AONe            |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

---

From: "Andrew Smith" <[email-masked]>
Date: Wed, 23 May 2001 08:28:41 -0700

>   priority to be used on the 802.1p network ?

According to 802.1D? No. In reality? Of course.

>  (looking at e.g. the mapping of mpls exp field as Juha suggests) ?

I don't think you'll find a mapping that is acceptable to a large enough set
of people to be useful: we discussed this issue in quite a lot of detail in
the context of ISSLL (see e.g. RFC 2815) - we were thinking about Diffserv
as well as Intserv at the time. One of the main issues is the mapping of a
multi-dimensional 6-bit number space (DSCPs represent things like priority,
guarantees, drop-precedence) onto what is "officially" a single-dimensioned
3-bit space (priority). I say officially because the 802.1D spec does
acknowledge that there are other scheduling disciplines than strict priority
that are worth having in layer-2 equipment; however it does not standardise
any - it leaves it for vendor extensions (which are widely implemented: one
implementation I know effectively treats the 802.1p field as a 3-bit DSCP
and can map it onto any one of the supported queueing mechanisms). I believe
it was Juha and Ran Atkinson who argued, from network operator points of
view, not to attempt standardisation back in 1997 or so. I believe that most
implementors have included a configurable mapping table for this function in
newer equipment. I'm quite surprised that MPLS managed to agree on a
mapping.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Michiel van Everdingen
Sent: Wednesday, May 23, 2001 3:00 AM
To: Diffserv
Subject: Re: [Diffserv] DSCP --> 802.1p

Hello,

Questions:

Thanks,

Michiel

--