Subject: RE: [Diffserv] Terminoloby draft: summary

From: Nabil Bitar <[email-masked]>
Date: Thu, 21 Oct 1999 09:27:12 -0400

Dan,
I had a similar issue with the way AF was defined as a PHB group because of 
lack of relationship among the AF classes. I raised these issues some time 
back but there was no consensus that it was necessary to have the 
relationship. I am glad that things are being refined. Regarding the 
comment below, can I interpret it to say that there is actually one AF PHB 
group (i.e. what is called an AF class) and that there are four instances 
of it(i.e. you allocate DSCP's for four of them) that differ in the way hey 
are configured?

Nabil
On Tuesday, October 19, 1999 5:07 PM, Dan Grossman 
[SMTP:[email-masked]] wrote:
> A few edits to Grenville's edits:
>
>
>   2. Definition of a PHB Group
>
>       RFC 2475 defines a PHB group to be:
>
>       "a set of one or more PHBs that can only be meaningfully specified
>       and implemented simultaneously, due to a common constraint applying
>       to all PHBs in the set such as a queue servicing or queue
>       management policy. A PHB group provides a service building block
>       that allows a set of related forwarding behaviors to be specified
>       together (e.g., four dropping priorities).  A single PHB is a

>       special case of a PHB group."
>
>   The first standards track PHB Group is defined in RFC 2497 [3],
>   "Assured Forwarding PHB Group".   Assured
>   Forwarding (AF) is a type of forwarding behavior with some
>   assigned level of queuing resources and three drop precedences.
>   An AF PHB Group consists of three PHBs, and uses three DSCPs.
>
>   RFC 2497 defines twelve DSCPs, corresponding to four independent
>   AF classes - referred to as AF1x, AF2x, AF3x, and AF4x (where
>   'x' is 1, 2, or 3 to represent drop precedence).  Each AF class is
>   one instance of an AF PHB Group.
>
>   There has been confusion expressed that RFC 2497 refers to all
>   four AF classes with their three drop precednences as being part of a 
single
>   PHB Group. However, since each AF
>   class operates entirely independently of the others, (and thus there is 
no
>   common constraint among AF classes as there is among drop precedences
>   within an AF class) this usage is inconsistent
>   with RFC 2475.   The inconsistency exists  for historical reasons,
>   and will be removed in future revisions of the AF specification.  It 
should
>   now be understood that AF is a _type_ of PHB group,
>   and each AF class is an _instance_ of the AF type.
>
>   Authors of new PHB specifications must adhere to the RFC 2475 
definition
>   of PHB Group. RFC 2475 does not prohibit new PHB specifications from
>   assigning enough DSCPs to represent multiple independent instances of
>   their PHB Group. However, such a set of DSCPs must not be
>   referred to as a single PHB Group.
>
>
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>