Subject: [Sip] Resource-Priority header

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 15 Nov 2001 14:00:57 -0500

A first draft reflecting the discussion on the mailing list is at

http://www.ietf.org/internet-drafts/draft-polk-sip-resource-00.txt

Comments are appreciated.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Wed, 21 Nov 2001 11:08:36 EST

The following comments address issues brought about by the concept that calls 
may "leak" between network domains and that somehow the way in which 
Resource-priority Header values are defined must take this fact into account.

In a previous e-mail on the subject, Henning had written: "Having different 
name spaces in the same header doesn't seem wise to me. Either the name space 
needs to be labeled (CRP: 16 ;domain="foo.com") or it should be the same. 
Messages always "leak" between domains, which would make things confusing."

I'd like to get a broader discussion on this, since it was brought up in 
regard to this subject as one of the reasons for defining the priority values 
in this way.

Yes we should avoid labeling the name space for Priority as was done in 
Q.735, but if it is true that "messages always leak between domains", then 
such labeling is required for many reasons besides the interpretation of 
Priority in order to prevent misrouted, mishandled calls. This is a 
fundamental QOS requirement in telephony networks and must be addressed for 
SIP as a whole.

Definition of the Resource-Priority header should continue on the presumption 
that "leakage" does not occur, or at least, is not a significant problem.

In a message dated 11/20/01 1:13:06 PM Eastern Standard Time, 
[email-masked] writes:

> At 10:24 PM 11/19/2001 -0500, [email-masked] wrote:
>  >To all,
>  >
>  >I have the following comments on draft-polk-sip-resource-00:
>  >
>  >
>  >It is essential that a network using a different set of values be able to 
do 
>  >so without relating their meanings and relative precedence level with 
those
>  >of another network, when it is not intended that the two sets be used 
>  >together. 
>  
>  This header is not mandatory. Your  second network doesn't have to adhere 
to it
>  at all.

The situation being addressed ("leakage" between networks) is one in which 
both networks need to use the Resource-priority Header, but use a different 
definition of values, which may in fact include some common values. (Many 
would likely have a "routine".)
>  
>  >The stipulation that unknown values should be treated as "routine" 
>  >might solve the problem of values "leaking" from another domain into the 
one 
>  >using the definitions in Section 3. 
>  
>  See above

I intended to mean by this and following comments that "leakage" could be 
detected and the errant calls prevented from erroneously getting a high 
priority if the two networks used a completely different set of definitions 
and each defined a default for "unknown" values and further that there was an 
assurance that intermediate network elements did not erroneously "know" about 
the values of that other network and act on them.
>  
>  >It would have to be part of the 
>  >definition for each network to specify what "default" is used for unknown 
>  >values. It may not always be the lowest. 
>  
>  That's a implementation issue.
>  
>  >In addition, every network defining 
>  >new values would have to use a completely different set.
>  
>  Not true

See above.
>  
>  >
>  >However, since it would not be under the control of the user of a network 
>  >whether or not intermediate routers, etc. "know" the meaning of other 
values 
>  >defined for other networks, the user might be unaware of the network's 
>  >actions resulting from its knowledge of the values defined for other 
networks 
>  >(in case of "leakage"). For example, given the current definitions in 
Section 
>  >3, if another network defined a set of five values of (lowest to highest) 
of 
>  >"flash", "more-than-flash", "flash-plus1", super-flash", and 
>  >"extremely-high-flash", then one of its lowest precedence calls (flash) 
>  >"leaking" over into the other network would be treated as a relatively 
high 
>  >precedence call in that other network.
>  
>  This would only be true if they also called their SIP Header 
Resource-Priority,
>  which this group should not allow. If they still do, this is a proprietary
>  implementation -- and they will likely reap the benefits of not being 
Standard.

Again, I was referring to the case in which both networks are SIP and use the 
Resource-priority Header.

I don't understand the statement about the group not allowing "they" to call 
"their" SIP Header Resource-Priority. Does this refer to the possibility of 
another group (not the IETF) defining additional headers for the SIP 
protocol? Clearly this can't happen.
>  
>  >
>  >In fact, all SIP applications, not just this one, must be defined on the 
>  >presumption that "leakage" between network segments or domains can not 
> occur. 
>  
>  You are referring to Leakage, this header is optional to the UA, and in 
and of
>  itself, doesn't cause anything to happen in the network itself.
>  
>  Most of what you say would be true if the header Standardized within the 
SIP
>  Protocol were Mandatory, but it is neither yet, so no problems. If it
>  becomes a part of SIP with its current spirit of language (meaning only  
little
>  things are changed), then it is up to each domain to implement and react to
>  what this header means within this domain.

I understand that the Resource-Header is optional to the UA, but I don't see 
a relationship to the point about "leakage".

Not sure what you mean by "in and of itself, [this header] doesn't cause 
anything to happen in the network itself". That is the fundamental purpose of 
the header - to provide the ability to control access to network resources to 
set-up and maintain a call. If it didn't, we wouldn't care where it "leaked", 
except for maybe a security issue.

The issue I was addressing was the notion of "leakage", as mentioned in 
Henning's previous e-mails on the subject. 
>  >Mike Pierce
>  >Artel
>  James M. Polk
>  Consulting Engineer
>  Office of the CTO
>  Cisco Systems

---

From: [email-masked]
Date: Wed, 21 Nov 2001 11:08:33 EST

In a message dated 11/20/01 1:13:06 PM Eastern Standard Time, 
[email-masked] writes:

>  >Definition of values: Although the specific tokens defined in Section 3 
are 
>  >the ones required for the US military application (and may be usable in 
other 
>  >such environments), it would appear to be advisable to define the token 
>  >values in a more generic way within the standard. This would facilitate 
the 
>  >use of the resource-priority header in other networks that may use other 
>  >words to describe the levels. For example, a network could choose to use 
>  >three levels and call them "important", "regular", and "not-so-important".
>  
>  We chose what was originally defined in RFC791 "Internet Protocol", nothing
>  more, nothing less (other than not including the non-UA priority levels 
defined
>  in 791 for inter-network node communications)
>  
Yes, I understand that the values came from RFC791, which came directly from 
US military requirements. Remember, at that time the work on Internet 
specification was very much a US government research project. Along with the 
efforts now to internationalize IP and to make this particular priority 
capability more general in application, it seems advisable to make the 
definitions more generic, while allowing any network environment or 
application to use the values as they want.

As you noted, a hospital would likely want 3 levels. I'm certain they have a 
standard terminology for these 3 levels. Do hospitals need to register these 
with IANA? If the definition of the Resource Priority header were generic 
(maybe the textual equivalent of numeric values), then a hospital application 
could associate their 3 levels with 3 of the values (e.g., a labeled button 
on the phone puts a specific value in the Header). There would be no 
implemention unique to the application nor any need to register with IANA, or 
any SLA or anything of the sort. When installing a phone, someone would 
simply insert a label in a button on the phone, just like is commonly done 
today, and the button would cause a certain "numeric" value to be used. Of 
course, there could be hospital unique software which provides meainingful 
icons or words for the levels.

My point about Q.735 using numeric values in the message was in relation to 
the above. While Q.735 gives an actual meaning that probably relates to the 
label on a button on the phone, the protocol only passes a number (the 
"relative" value). Yes, I know that SIP is text based, but that doesn't mean 
that everything must be totally based on English words that represent the 
currently understood intended use.
>  >
>  >For two different networks, one could not say whether 
>  >"important" in one should be above or below "flash" in the other, nor 
should 
>  >one need to define this. 
>  
>  This would and must be solved with an SLA if this header's effect is to
>  propagate past domain boundaries. As for comparing two network's treatment
>  levels, the Resource Header is stated as not an absolute but a relative
>  ordering

I understand, if two network are intended to work together and wish to use 
different definitions of Resource-priority levels, there must be service 
level agreeements between them for handling traffic across domain boundaries. 
This would include the ability to equate different levels, which is why I 
commented that any IANA registration would require this option of specifying 
equality. "Flash" (in the US) might be equivalent to "Instantanee" (in 
France).

However, I was talking about the case when there are two completely 
independent sets of Priority values, e.g., the 5-level military one and the 
3-level hospital one, and they are not intended to interwork. It must be 
possible to define each independently from the other. The IANA registration 
should not require specifying how a level of one set fits in with the levels 
of the other. As you said, they are "relative", not "absolute", therefore, 
they can only be compared within their own set.

If the need to interwork occurs, that is, take two independent networks and 
have them exchange traffic, then SLAs would define the relationship. It might 
not be a fixed relationship. For example, if hospital traffic were carried 
through a military network, the relation between their levels and the 
military network's levels on Sept 10 and on Sept 12 would likely be 
different. Changing this relationship can not require a IANA re-registration 
or a modification of equipment all around the world.

What we can not tolerate in a military network is a situation in which, 
though mis-definition, mistakes in implementing the SLA, "leakage" between 
domains, cheating, or whatever, some traffic could get a higher priority than 
"Flash-Override". (Except for CRITIC/ECP, the use of which I'm not familiar.) 
In Q.735, this is ensured by "Flash-override" being assigned the value "0" 
which indicate the highest possible. The protocol guarantees that nothing can 
be higher.

Mike Pierce
Artel

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 21 Nov 2001 11:23:37 -0500

I'd like to keep the current wording.

One thing that always confuse me is when objections are
raised that imply customers can change the values of
fields in the protocol.  Except in very unusual instances,
they can't.  A UA implementor can.

So, if a vendor wants to create a 3 value system for
hospitals, he can do that, either with an RFC, or just
by registering the values with IANA.  The hospital would
not do that, and could not create a 3 value system
unless they have the source code to the UA, or some vendor
decided to create worlds most flexible (and thus least
interoperable) priority implementation.

If said vendor created said system, and they wanted interwork
with a U.S. Military system, they would have to define how
the interwork was accomplished, and implement it.  

If there were multiple vendors who wanted 3 value systems
for hospitals, with interwork, then they would get together
and write a document, get IANA to reserve the names, and then
anyone who wanted to build an interoperable system could do that.
The difference between the document giving a meaning to a number,
and it defining a new name for IANA to register is small,
and clarity favors meaningful names.

In this case, the most common desire is to interwork with
MLPP systems, the original names are very appropriate, and the
text gives appropriate extension mechanisms for coming up with
alternative systems.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 11:09 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sip] Resource-Priority Header
> 
>

---

From: [email-masked]
Date: Wed, 21 Nov 2001 14:31:44 EST

In a message dated 11/21/01 11:25:05 AM Eastern Standard Time, 
[email-masked] writes:

(My comments in-line:)

>  they can't.  A UA implementor can.

I did not mean to imply that a user can or should change the values. However, 
in a previous e-mail, Henning objected to using just plain numbers rather 
than the textual strings for the reason that "Just like message encoding, I 
find textual labels less error-prone, so the basic 791 set should, in my 
opinion, have names, not numbers." as if he expected the customer to be 
typing in the priority value and making mistakes like we do when we enter web 
addresses. Of course, it should only be an issue for the UA implementor. 
However, I could easily expect a UA implementor to provide a user selectable 
option to tell the UA what priority levels it should use, especially if we 
create a situation in which multiple sets of values are defined. That might 
allowt in customer to change the values (and probably make mistakes). Is the 
IETF going to say that a UA implementor is not allowed to provide this 
capability?

I would expect the UA implementor for a hospital telephone system to want to 
use and define the priority values for use in a hospital environment - and no 
- I don't expect that they would use a subset of the US military terms. But 
they might likely want to use "Routine" as one of their values.
>  interoperable) priority implementation.

My concern is with the notion that a vendor can assign new values "just by 
registering the values with IANA". According to the wording in the draft, 
that means they can define all the values they want and specify that they are 
all above "Flash Override". This has serious implications. On the other hand, 
for some cases, it would be necessary to specify that a new value (a specific 
text string) should be equivalent to an existing value (specific text 
string). The current wording doesn't seem to allow this possibility.
>  the interwork was accomplished, and implement it.  

I believe that part of an interworking agreement would be defining the 
relationships between the priority levels used in the two specific networks 
that used two different sets of values. The text in the draft indicates that 
the relationship is registered with IANA, thereby casting it in concrete and 
not under the control of the networks wanting to interwork.
>  and clarity favors meaningful names.

There is a major difference between these approaches. As has been done in a 
number of other standards and drafts, including several in the IETF, the 
protocol can define a priority value as a number, say 0-15 (or the textual 
equivalent). Networks or groups of vendor that use the protocol can associate 
a subset of these numbers to the names that they use. No RFC or IANA 
registration is needed. There is no lack of clarity: the customer using the 
service (person) never sees any of this - they just push a button or select 
an icon. The implementor certainly understands either method. All network 
equipment simply compares the numbers, or a limited, non-extendable set of 
text names - no confusion and no obsolescence . And I would say "flexibility 
favors generic names".
Mike Pierce
Artel