Re: proposed charter 5 priority levels

In message <OFBAA95066.05652C8C-ON852571F5.004A9C8A-852571F5.004B6690@csc.com>
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.