Re: proposed charter 5 priority levels

Curtis,

rfc-4190 does touch upon some of the points you bring up below.

as for the group advocating a specific set of DSCP code points (new  
or current) in support of ETS, your impression is correct that IEPREP  
has not done so.  this is because that would have been considered a  
specific solution, which has been out of bounds of the group.  Hence  
the interest in modifying the charter.

-ken


On Sep 26, 2006, at 12:56 PM, Curtis Villamizar wrote:

>
> In message <OFBAA95066.05652C8C- 
> [email protected]>
> Janet P Gunn writes:
>>
>>
>> As RFC 4412 makes perfectly clear, the RPH serves a dual role of  
>> signalling
>> priority across an IP network (e.g. from an originating circuit  
>> switched
>> access network to a terminating circuit switched access network)  
>> as well as
>> signalling  priority within the IP network.
>>
>> For each of the namespaces described in RFC 4412, the number of  
>> priority
>> values (5 in most cases, 6 in one) is driven by the former role,  
>> based on
>> the number of priority values in use, or being considered, in the  
>> access
>> network priority scheme.
>>
>> The issue of how many priority levels to differentiate WITHIN the IP
>> network is an issue currently being addressed by vendors and  
>> providers.
>>
>> Janet
>
>
> Janet,
>
> You are right, but you may be just focusing on SIP which is one peice
> of the puzzle.
>
> RFC 4412 does not make it perfectly clear whether we need 1 DSCP code
> point, EF, or 5 DSCP code points (IP Prec 0-4?)  or 15 DSCP code
> points (the 4 AF classes plus one more AF class.  Or is it some
> multiple of 6?  This RFC doesn't even mention DSCP.
>
> I'm sorry but this may be my mistake in that when I'm thinking of
> priority and preemption I'm not sure based on reading the many things
> written about ETS whether we are talking about just 5 SIP classes and
> maybe 5 microflow RSVP classes (to be defined?) or 5 classes of AF
> service carrying non-SIP traffic (where diffserv only defines 4).
>
> I'm still not sure if IEPREP is calling for 1 or 5 or 6 or 15 or 18
> new DSCP code points, or 0 (best answer IMHO).  I suspect that
> anything more than what is now defined will be experimental for a
> while, until deployed.  This also impacts whether providers using MPLS
> within the AS need to deploy a full diffserv-TE implementation.  SIP
> and MPLS/TE might be all that is needed in an intra-provider ETS
> deployment.  Microflow RSVP might be needed if the SIP GW and MPLS/TE
> ingress are not the same box and the amount of bandwidth allocated to
> the ETS is not fixed but is allocated on demand but otherwise no.  SIP
> (RFC4412) seems to assume a policy server in the sky to be defined
> later that will assure that the bandwidth is available.
>
> Whether this traffic crosses AS boundaries may impact whether
> microflow RSVP is needed to carry the requirements across AS
> boundaries.  I don't think inter-AS RSVP/TE is anywhere close to
> reality at this point.  Microflow RSVP across a dedicated (maybe
> tunnelled) inter-AS interface may be more palitable and covers
> non-VOIP/non-SIP services.
>
> The real challenge is making an ETS work in the real world where a
> natural disaster (or worse) has taken out a good part of the physical
> infrastructure.  The solution may need to adapt to whatever level of
> infrastructure is left.  A fixed allocation and a largely static
> configuration might not work at all under those circumstances.  The
> ETS has to work as best as possible within the disaster area.  That is
> part of what we are trying to accomplish I hope.
>
> Curtis
>
>
>
>> Curtis Villamizar <[email protected]> wrote on 09/26/2006 01:21:39 AM:
>>
>>
>>>
>>> As long as the number of priority/preemption classes remains too  
>>> open
>>> ended, the mapping onto DSCP and Diffserv-TE remains uncertain.  For
>>> example, there has to be a strong technical justification for five
>>> priority classes, not just "because ITU specified five" before there
>>> is much of a chance for a set of new DSCP values to be assigned as
>>> anything other than experimental.
>
> _______________________________________________
> Ieprep mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ieprep