Session-Independent Policies draft-ietf-sipping-session-indep-policy-01

1. Session-Independent Policiesdraft-ietf-sipping-session-indep-policy-01 Volker Hilt volkerh@bell-labs.com Gonzalo Camarillo Gonzalo.Camarillo@ericsson.com Jonathan Rosenberg jdrosen@dynamicsoft.com

2. Session-Independent Policies • Major revision since –00. • Session-independent policy delivery mechanism. • Based on the config-framework. • UAs subscribe to policy servers using the following profiles. • user profile: retrieve policies of the users AoR domain. • local profile: retrieve policies of the access network. • Rules when to sent a subscribe.

3. Policy Schema • Generic policy schema defines common elements and attributes. • XML schemas for specific policies. • Media policies • Protocol policies • Media routing policies

4. Policy Schema Structure • Specifying constraints in policy schemas. • Simple restrictions. • Example: maximum bandwidth (mandatory). • UA needs to select multiple values. • Multiple instances can be present in a session. • Example: audio (mandatory), video (allowed), application (denied). • UA needs to select a single value. • One instance needs to be selected for a session. • Example: codec: PCMU (allowed), PCMA (allowed), G729 (denied). • Constraints • Mandatory, allowed, denied.

5. Container-based approach: Containers define the constraining properties of a policy elements. Policy elements modify the working profile (settings used by a UA). <forbid> element values must be removed. <set_all> element values must be added. <set_one> one of the values must be added. <set_any> element values may be added. Characteristic/Issues Well aligned with the data set framework. Based on concept of working profile. Flexible and complex. XML Containers <forbid> <media> <type /> <codec>PCMU</codec> </media> </forbid> <set_all> <media> <maxnoStreams>4 </maxnoStreams> <type>audio</type> </media> </set_all> <set_any> <media> <type>video</type> </media> </set_any>

6. Attribute-based approach: "Policy" attribute defines constraining properties of elements. "Mandatory" - must be used in sessions. "Allow" - may be used in sessions. "Deny" - can not be used in sessions. Policy schemas specify the use of this attribute for elements. Default policies for an element require a separate element. Example: <default-codec> defines policy for codecs not listed. Characteristic Session-based. Required semantics. Simple. XML Attributes <media> <maxnoStreams>4</maxnoStreams> <default-type policy="disallow" /> <type policy="mandatory">audio</type> <type policy="allow">video</type> <default-codec policy="allow" /> <codec policy="deny">PCMU</codec> </media>

7. Conflict Resolution • Session policies from different sources may be in conflict. • General conflict resolution mechanisms are very complex. • Out of scope for this draft!! • Proposal: • Specific rules for merging policies in a policy schema. • Default behavior for conflict’s that can’t be resolved (e.g. “alert user”). • Special treatment for emergency calls?

8. Session-Specific Policiesdraft-hilt-sipping-session-spec-policy-01 Volker Hilt volkerh@bell-labs.com Gonzalo Camarillo Gonzalo.Camarillo@ericsson.com Jonathan Rosenberg jdrosen@dynamicsoft.com

9. Major revision since –00. Mechanism based on the separate channel model. Architecture Proxy: provides the URI of the local policy server to UA. Policy server: receives session information from UA and returns session policies. Policy enforcement point: may be present to enforce policies. Out of scope for this draft. PS A PS B 2 4 1 3 Session-Specific Policies Proxy Proxy UA A Policy Server PS A Policy Server PS B UA B Router w/ Policy Enforcmnt Router w/ Policy Enforcmnt

10. Distributing PS URIs • Two new header fields • Policy-contact header • Convey the policy server URI from proxy to UAs. • Policy-Id header • Used by UAC to identify the policy servers used.

11. Contacting the Policy Server • When / with which information does a UA contact the PS? • Offer: generally needed for session-specific policies. • Answer: needed if policies apply to answer-specific information (e.g., IP address and port). • BYE: needed by PS to free resources (e.g. close firewall pinholes, terminate asynchronous policy updates). • Proposal: PS provides indication on policy channel. • Offer cycle is mandatory. • Flag for “answer required” in offer cycle. • PS closes policy channel when done.

12. Policy Channel • Proposal: SUBSCRIBE/NOTIFY-based mechanism. • Same mechanism as session-independent policies. • Use of SIP authentication and authorization mechanisms. • Allows asynchronous policy updates. • Content indirection for policy delivery. • Subscription terminated when session ends or policy server has no policy updates. • Issue • Offers and answers need to be carried in SUBSCRIBE bodies.

13. Policy Channel - Flow UA PS SUBSCRIBE PS <offer> • UA subscribes to policies at PS. • Offer in SUBSCRIBE body. • UA refreshes subscription. • Offer and answer in SUBSCRIBE body. • Alternative: separate subscription for answer. • PS notifies UA about policy updates. • UA terminates subscription when session ends. NOTIFY <policyOffer> answer="yes" SUBSCRIBE PS <offer> <answer> NOTIFY <policyOffer> <policyAnswer> NOTIFY <policyOffer‘> <policyAnswer‘> SUBSCRIBE PS Expires=0 NOTIFY