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

From: "Iliff, Tina" <[email-masked]>
Date: Fri, 18 May 2001 17:27:21 +0000

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.h
tml

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 May 2001 12:55:09 -0500

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.
> 
>           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.
> 
>           > 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.
>           >
>           > To: Shridhar Mubaraq Mishra (DC SIN COM); [email-masked]
>           > 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
>           >
>           > Von: [email-masked] [mailto:[email-masked]]
>           > 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