Re: [Ieprep] proposed charter 5 priority levels

John Rosenberg <jrrosenberg@lucent.com> Wed, 27 September 2006 22:39 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSi4L-0004hO-Mu; Wed, 27 Sep 2006 18:39:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSi4I-0004ek-O8 for ieprep@ietf.org; Wed, 27 Sep 2006 18:39:54 -0400
Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSi4H-00040Z-E9 for ieprep@ietf.org; Wed, 27 Sep 2006 18:39:54 -0400
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.6/IER-o) with ESMTP id k8RMdgdP023327; Wed, 27 Sep 2006 17:39:42 -0500 (CDT)
Received: from jrrosenberg-04.lucent.com (jrrosenberg.lra.lucent.com [135.244.1.37]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k8RMdgu04957; Wed, 27 Sep 2006 17:39:42 -0500 (CDT)
Message-Id: <6.2.1.2.0.20060927173433.0323abd0@ihmail.ih.lucent.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 27 Sep 2006 17:39:40 -0500
To: curtis@occnc.com
From: John Rosenberg <jrrosenberg@lucent.com>
Subject: Re: [Ieprep] proposed charter 5 priority levels
In-Reply-To: <200609270215.k8R2FI5J006271@workhorse.brookfield.occnc.com >
References: <Your message of "Tue, 26 Sep 2006 19:10:49 CDT." <6.2.1.2.0.20060926190508.03463c30@ihmail.ih.lucent.com> <200609270215.k8R2FI5J006271@workhorse.brookfield.occnc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org

It's been mentioned that both RSVP and NSIS can carry both SIp priority and 
DSCP.

For the uninitiated (e.g. me!) would the use of either of these protocols 
be used in a scenario where:

1) an endpoint sent an INVITE to a call controller withtout RPH, but with 
"dialed digits" that request a DSN precedence level (e.g. Flash);

2) the call controller validated that the requested precedence level is 
authorized;

3) and the call controller then needs to inform the endpoint what specific 
DSCP value (e.g. 41) to put in the bearer packets that the EP generates, 
which value is based on a provisioned mapping resident in the call 
controller between dsn precedence levels and DSCP values.

Thanks,

John



At 09:15 PM 9/26/2006, Curtis Villamizar wrote:
 >
 >In message <6.2.1.2.0.20060926190508.03463c30@ihmail.ih.lucent.com>
 >John Rosenberg writes:
 >>
 >> At 05:52 PM 9/26/2006, ieprep-request@ietf.org wrote:
 >>
 >>  >Date: Tue, 26 Sep 2006 12:56:15 -0400
 >>  >From: Curtis Villamizar <curtis@occnc.com>
 >>
 >>  >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.
 >>  >
 >>
 >> Let me add my voice and suggest that we're really in need of some 
mechanism
 >> that allows the application (e.g. MLPP, ETS, whatever) to determine a
 >> "priority level" for a session and indicate to the endpoint that it's
 >> serving what DSCP value that the endpoint should use for its bearer 
packets.
 >>
 >> It could be a header or parameter in some subset of SIP messages, it could
 >> be an attribute in SDP, it could be something else entirely. I think the
 >> whole question of how many and which DSCP values should be used for some
 >> arbitrary application is a little premature if we don't have a way for the
 >> application to get that value used.
 >>
 >> John Rosenberg
 >
 >
 >The discussion just went full circle.  We already have a SIP priority
 >in RFC4412.  Use of DSCP is only touched on in RFC4190.  Both the SIP
 >priority and DSCP value can be carried in microflow RSVP
 >(draft-briscoe-tsvwg-cl-architecture-03.txt).
 >
 >Which DSCP value seems to be an open issue for now.  Discussion seems
 >to favor a new DSCP EF-like value for ETS.
 >
 >Curtis


_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep