Subject: Re: [Ieprep] proposed charter 5 priority levels

From: John Rosenberg <[email-masked]>
Date: Tue, 26 Sep 2006 19:10:49 -0500

At 05:52 PM 9/26/2006, [email-masked] wrote:

 >Date: Tue, 26 Sep 2006 12:56:15 -0400
 >From: Curtis Villamizar <[email-masked]>

 >In message 
<[email-masked]>
 >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

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2006 22:15:18 -0400

In message <[email-masked]>
> application to get that value used.

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 27 Sep 2006 07:56:02 -0500

> Both the SIP

Both can also be carried in NSIS
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt

Jerry

---

From: John Rosenberg <[email-masked]>
Date: Wed, 27 Sep 2006 17:39:40 -0500

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Sep 2006 16:53:44 -0700

On Sep 27, 2006, at 3:39 PM, John Rosenberg wrote:

> 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.

This is all stated in layer seven words and doesn't much address  
layer 3 issues. The thing is that the layer 7 issues are different  
than teh layer 3 issues, and both have to be addressed.

Yes, I think (as described in RFC 3312), the two would be used  
together. I have some slides at ftp://ftpeng.cisco.com/fred/new-ef if  
you're interested to peruse them.

The big differences between RSVP and NSIS, taken from 33,000 feet,  
are that RSVP works for multicast while NSIS doesn't, NSIS provides a  
firewall traversal mechanism that RSVP doesn't, and RSVP has this all  
spelled out in consensus standards and mostly implemented in vendor  
product that has been proven interoperable, while NSIS is quite a bit  
further behind on the road map.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 28 Sep 2006 01:29:09 -0400

In message <[email-masked]>
John Rosenberg writes:

> controller between dsn precedence levels and DSCP values.

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?

Curtis

---

From: John Rosenberg <[email-masked]>
Date: Thu, 28 Sep 2006 06:21:53 -0500

Curtis -

 >Am I missing something?  Perhaps an authorization or authentication

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 28 Sep 2006 13:51:59 -0500

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

RSVP does not carry a SIP RPH text based namespace or priority-value, and 
NSIS (I believe) does not carry a RPH namespace in text, just a registered 
equivalent of the priority-value

<snip>

>SIP control traffic

SIP messages are always first, prior to any RSVP or NSIS messages, how else 
would a called party know what bandwidth to request in the RESV?

It also doesn't make a lot of sense sending a NSIS REQUEST message 
reserving resources if the called party isn't going to accept the call (for 
whatever reason).  This would be a waste of BW, and could case existing 
calls to be preempted unnecessarily.

>to avoid losing the control traffic.  You'd need
>The SIP priority and DSCP value would be in the RSVP PATH message

"SIP Priority" isn't in any RSVP message. RSVP has its own priority 
indication. They can be mapped to mean the same thing, but they aren't 
always the same thing.  RSVP has no "namespace" equivalent.

>sent

"SIP priority" in a PATH is not correct

>Am I missing something?

see above

>Perhaps an authorization or authentication
>issue?
>
>Curtis
>