Re: proposed charter 5 priority levels

Curtis -

At 12:29 AM 9/28/2006, Curtis Villamizar wrote:
 >
 >In message <[email protected]>
 >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