Subject: [Sipping] policy channel protocol

From: Volker Hilt <[email-masked]>
Date: Wed, 02 Feb 2005 16:54:39 -0500

Folks,

for the next revision of the session-specific policy draft 
(http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-spec-policy-01.txt) 
we would like to make progress on the protocol for the policy channel.

This protocol is used for the communication between UA and policy 
server. It needs to perform the following tasks:
1.  Enable the UA to disclose information about the current session and 
the offer/answer exchange to a policy server.
2.  Transmit the session policies from policy server to the UA.

The goal is to define one protocol UAs and policy servers must support. 
There are a number of choices available:
1.  SIP SUBSCRIBE/NOTIFY: the UA subscribes to session policies on the 
policy server and provides session information in the SUBSCRIBE. It 
receives policies in a NOTIFY.
2.  HTTP: the UA sends a HTTP request to the policy server and receives 
the policies in response.
3.  COPS: the UA acts as PEP and submits requests to the policy server 
acting as PDP.
4.  Something else.

I would like to solicit comments, feedback and concerns on the use of 
these protocols for the policy channel.

Thanks much,

Volker

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

---

From: David R Oran <[email-masked]>
Date: Thu, 3 Feb 2005 11:58:08 -0500

On Feb 2, 2005, at 4:54 PM, Volker Hilt wrote:

> (http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-spec- 
> policy-01.txt) we would like to make progress on the protocol for the  
> policy channel.
>
> 1.  Enable the UA to disclose information about the current session  
> and the offer/answer exchange to a policy server.
> The goal is to define one protocol UAs and policy servers must  
> support. There are a number of choices available:
> 2.  HTTP: the UA sends a HTTP request to the policy server and  
> receives the policies in response.
One possibility for "something else" is to use the DMTF "CIM" or  
Cisco's "SG-PIM" (a subset of CIM) as the policy language (it's a UML  
model encoded as an XML schema) and carry it through SOAP/BEEP.

> these protocols for the policy channel.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Volker Hilt <[email-masked]>
Date: Thu, 03 Feb 2005 16:42:18 -0500

David R Oran wrote:
>> 1.  SIP SUBSCRIBE/NOTIFY: the UA subscribes to session policies on 
>> the  policy server and provides session information in the SUBSCRIBE. 
>> It  receives policies in a NOTIFY.
>> 3.  COPS: the UA acts as PEP and submits requests to the policy 
>> server  acting as PDP.
>> 4.  Something else.
>>
I think the policy language is really independent of the transport 
mechanism. There is a simple XML-based policy language in the 
session-independent policy draft (a new revision of that will be out 
soon). If content negotiation reveals that another language (such as 
DMTF CIM) is supported by UA and policy server, this language can of 
course be used too.

Regarding the use of SOAP/BEEP on the policy channel, what would be the 
benefits compared to HTTP? In general, I believe it is a good idea to 
stick with a protocol that is already supported by (or can easily be 
added to) many UAs, except there are strong reasons for doing something 
else. This argument would probably support the use of SIP or HTTP.

Thanks,

Volker

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 3 Feb 2005 21:39:17 -0600

> Regarding the use of SOAP/BEEP on the policy channel, what would be 
> the benefits compared to HTTP? In general, I believe it is a good 
> idea to stick with a protocol that is already supported by (or can 
> easily be added to) many UAs, except there are strong reasons for 
> doing something else. This argument would probably support the use 
> of SIP or HTTP.
>
> Thanks,
>
> Volker

Lots of UAs are HTTP *clients*, but HTTP is a client-server protocol, 
so if you want to talk in both directions using HTTP, you need to 
implement HTTP *server* functionality on the UA. This was one of the 
reasons for BEEP in the first place.

Not sure what environments you're thinking of, but lots of network 
administrators have opinions about which direction HTTP initiates 
across their network boundaries (think, "firewalls that allow 
*outgoing* HTTP requests, but not *incoming* HTTP requests"). Piling 
another application protocol on top of HTTP often trips over this.

I confess to being a closet BEEP fan, but I read 
ftp://ftp.rfc-editor.org/in-notes/rfc3205.txt before reading 
ftp://ftp.rfc-editor.org/in-notes/rfc3117.txt...

Spencer

---

From: Volker Hilt <[email-masked]>
Date: Fri, 04 Feb 2005 00:22:52 -0500

Spencer Dawkins wrote:
>> the benefits compared to HTTP? In general, I believe it is a good idea 
>> to stick with a protocol that is already supported by (or can easily 
>> be added to) many UAs, except there are strong reasons for doing 
>> something else. This argument would probably support the use of SIP or 
>> HTTP.
> 
> Lots of UAs are HTTP *clients*, but HTTP is a client-server protocol, so 
> if you want to talk in both directions using HTTP, you need to implement 
> HTTP *server* functionality on the UA. This was one of the reasons for 
> BEEP in the first place.
> 
Yes, HTTP works fine if the UA fetches policies from a policy server, 
i.e. the UA is the HTTP client and the policy server is a HTTP server. 
If asynchronous updates are needed for session-specific policies, the 
situation changes. The policy server would need to send the updated 
policies to the UA, which would reverse the HTTP roles.

> administrators have opinions about which direction HTTP initiates across 
> their network boundaries (think, "firewalls that allow *outgoing* HTTP 
> requests, but not *incoming* HTTP requests"). Piling another application 
> protocol on top of HTTP often trips over this.
> 
I think this boils down to the question whether asynchronous policy 
updates are a requirement for session-specific policies. If they are, 
things get ugly with HTTP.

> ftp://ftp.rfc-editor.org/in-notes/rfc3117.txt...
The issue with using BEEP for the policy channel is that it would add 
complexity to most UAs since it's a new protocol not widely supported. I 
don't believe this is a killer argument but I would hope that it is 
possible to find a solution that is based on available protocols without 
being a stretch for them (SUBSCRIBE/NOTIFY comes to mind here). Having 
said this, I'll put BEEP on the list of protocol candidates.

Thanks,

Volker

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 13 Feb 2005 12:59:25 +0200

Hi,

if we could use the same delivery mechanism (SUBS/NOTIFY) and a similar 
XML-based format in session-independent policies (i.e., configuration) 
and in session-specific policies, it would be a good thing.

The only difference is that, while in session-independent policies the 
user agent does not need to provide any information to the policy 
server, in session-specific policies, the user agent needs to provide 
the policy server with a set of data about the session (i.e., media IP 
addresses and port numbers).

So, an alternative approach would be to use an asymmetric policy 
channel. The usual SUBS/NOTIFY to get policy information, and a channel 
from the UA to the policy server to upload session information. This 
channel could be based on, for example, HTTP or SIP PUBLISH.

My 0.02 EUR...

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Feb 2005 21:28:47 -0500

> channel could be based on, for example, HTTP or SIP PUBLISH.

How about using the body of the SUB to convey the the session info?

I can rationalize this as a "filter" if you imagine that the session 
specific info is part of the total set of information that could be 
retrieved via the subscription, and providing the session info simply 
limits that to the info about a particular session. And the default if 
you don't provide session info just doesn't happen to include any of the 
session specific policy.

	Paul

>>>> the  policy server and provides session information in the 
>>>> SUBSCRIBE. It  receives policies in a NOTIFY.
>>> Cisco's "SG-PIM" (a subset of CIM) as the policy language (it's a 
>>> UML  model encoded as an XML schema) and carry it through SOAP/BEEP.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Feb 2005 11:19:26 -0500

Gonzalo Camarillo wrote:
> Hi Paul,
> inline:
> Gonzalo wrote:
>>> channel. The usual SUBS/NOTIFY to get policy information, and a
>>
>>
>> channel
>>
> Paul answered:
> In a sense it could be considered a filter, but once you identify the 
> session you want policy information about, you would still need to 
> provide further information (e.g., the IP addresses in the answer when 
> you receive it)... so, you would need to be refreshing your subscription 
> continuosly.

True. Not necessarily a bad thing. But with consequences to be considered.

> What I had in mind is that you could get all the policy information 
> related to all your sessions over a single subscription. That way, if 
> you happen to be receiving session-independent policies, you could 
> receive session-specific policies over the same subscription. Something 
> like:
> 
> <policy Session-ID="all">
>   <disallowed-codec>G.711</disallowed-codec>
> </policy>
> <policy Session-ID="123asdv54">
>   <disallowed-codec>AMR</disallowed-codec>
> </policy>
> 
> 
> The XML document would also inform the client about which information 
> the server needs to know (e.g., the IP addresses used to send and 
> receive media). The channel used by the client to send such information 
> to the server could be based on SIP PUBLISH or HTTP.

I think that should be possible while still using the SUB for the upload 
of session info. The "filter" would simply have elements indicating each 
session as well as one indicating that it wants session independent info 
as well.

This does start to have some nasty properties - each update to session 
data causes a a retransmit of all selected policy, including all the 
session independent policy. That could be big, and is not appealing.

I'm just not very thrilled by the idea of establishing an https 
connection for session specific policy management each time a call is 
made - which seems like a plausble scenario. Would be much better if 
some more-or-less permanent path could be used for this. UAs operating 
in an environment where policy is being enforced this way are likely to 
have a permanent secure connection to a proxy in the domain of the 
policy server. It would be nice to be able to reuse that.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 22 Feb 2005 16:44:56 +0200

Hi,

> This raises the issue of whether there should be a separate subscription
> 
> for session-independent policies and the session-specific policies for 
> each session or if there should be one subscription over which policies 
> are exchanged. The issue I can see with such a master subscription is 
> that it requires session-independent and session-specific policies to 
> come from the same server. Also there might be issues with the 
> management of these subscriptions and their termination.

The idea could be to have a single subscription per user. If the server 
provides both session-independent and session-specific policies, it 
sends them over this single subscription. If the server only has one 
type of policies, it sends them in the same way.

Anyway, having multiple subscriptions would also be alright... what I am 
concerned with is the uplink channel. I still find the idea of using 
SUBSCRIBE bodies an overstretch of the filter semantics...

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 22 Feb 2005 10:19:58 +0200

Hi Paul,

inline:

Gonzalo

---

From: Volker Hilt <[email-masked]>
Date: Tue, 22 Feb 2005 09:36:08 -0500

Gonzalo, Paul,

some comments are inline.

> you receive it)... so, you would need to be refreshing your subscription 
Well, this is true if a session identification is acting as filter and 
policies are essentially tied to this id. If the session description 
itself is considered to be the filter for policies, it would probably 
make sense to refresh the subscription when the underlying session 
description changes. The policy server would then return the policies 
that apply to the modified session.

Essentially there are two occasions when session information changes: 
when an answer is received that needs to be sent to the policy server 
and when the session description is modified (i.e. a re-INVITE/UPDATE is 
exchanged). In these occasion, the subscription to policies needs to be 
updated to reflect the new session.

Thanks,

Volker

-- 
Volker Hilt                      Bell Labs / Lucent Technologies
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733