Re: [Ieprep] proposed charter 5 priority levels
John Rosenberg <jrrosenberg@lucent.com> Thu, 28 September 2006 11:23 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GStzj-0006D9-F3; Thu, 28 Sep 2006 07:23:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GStzi-0006D4-Km for ieprep@ietf.org; Thu, 28 Sep 2006 07:23:58 -0400
Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GStzh-0004Fi-B4 for ieprep@ietf.org; Thu, 28 Sep 2006 07:23:58 -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 k8SBNkKR006395; Thu, 28 Sep 2006 06:23:46 -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 k8SBNjd28767; Thu, 28 Sep 2006 06:23:45 -0500 (CDT)
Message-Id: <6.2.1.2.0.20060928061535.03486540@ihmail.ih.lucent.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 28 Sep 2006 06:21:53 -0500
To: curtis@occnc.com
From: John Rosenberg <jrrosenberg@lucent.com>
Subject: Re: [Ieprep] proposed charter 5 priority levels
In-Reply-To: <200609280529.k8S5T9NX002023@workhorse.brookfield.occnc.com >
References: <Your message of "Wed, 27 Sep 2006 17:39:40 CDT." <6.2.1.2.0.20060927173433.0323abd0@ihmail.ih.lucent.com> <200609280529.k8S5T9NX002023@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: d0bdc596f8dd1c226c458f0b4df27a88
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
Curtis - At 12:29 AM 9/28/2006, Curtis Villamizar wrote: > >In message <6.2.1.2.0.20060927173433.0323abd0@ihmail.ih.lucent.com> >John Rosenberg writes: > >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 > > >I'm not sure why the above example is special. An RSVP PATH message >and RESV response (passed back from the IP egress) should precede any >SIP control traffic to avoid losing the control traffic. You'd need >to do that once for all SIP traffic, not per flow. The requested >bandwidth for the control traffic can be tiny. An RSVP PATH message >and RESV response should precede any RTP data flow (bearer packets) to >avoid losing the voice payload. The traffic must be policed to >conform to the parameters sent in RSVP and should be marked with a >fixed DSCP value appropriate for the service. > >The SIP priority and DSCP value would be in the RSVP PATH message sent >before beginning to send RTP traffic (bearer packets). > >For any sort of traffic which didn't involve a SIP setup (or any setup >protocol) you'd just send an RSVP PATH message and wait for the RESV >before sending traffic. If SIP wasn't used then there is no need for >a SIP priority in the RSVP PATH message. > >Am I missing something? Perhaps an authorization or authentication >issue? There is an authorization aspect of this in step 2 above, where the originating call controller determines that that precedence level requested is at or below the maximum authorized for that user. Another, possibly unique, element is that the call controllers on both ends control the DSCP used by the endpoint that each serves. In other words both call controllers have a precedence level to DSCP mapping, and these to mappings *could* be different. So we don't want the originating call controller telling the called end what DSCP to use. We want the originating call controller to tell the orig Endpoint what DSCP to use for bearer, and the term call controller to tell the called Endpoint what bearer DSCP value it should use. So, I'm really not looking for something end-to-end ad much as I'm looking for something on each end, distinctly, call controller to served endpoint. This is an MLPP scenario coming from a DISA requirement, and we're trying to understand how to fulfill the requirement with a recognized mechanism. Thanks, John _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- Re: [Ieprep] proposed charter 5 priority levels John Rosenberg
- Re: [Ieprep] proposed charter 5 priority levels Curtis Villamizar
- RE: [Ieprep] proposed charter 5 priority levels Ash, Gerald R (Jerry), ALABS
- Re: [Ieprep] proposed charter 5 priority levels Curtis Villamizar
- Re: [Ieprep] proposed charter 5 priority levels John Rosenberg
- Re: [Ieprep] proposed charter 5 priority levels Fred Baker
- Re: [Ieprep] proposed charter 5 priority levels Curtis Villamizar
- Re: [Ieprep] proposed charter 5 priority levels John Rosenberg
- Re: [Ieprep] proposed charter 5 priority levels James M. Polk
- Re: [Ieprep] proposed charter 5 priority levels James M. Polk