1 / 13

Session-Independent Policies: Delivery and Schema Structure

This document proposes a session-independent policy delivery mechanism based on the config-framework, with a focus on policies related to media, protocols, and media routing. It discusses the structure of the policy schema and different approaches for specifying constraints. Conflict resolution and session-specific policies are also addressed.

walll
Download Presentation

Session-Independent Policies: Delivery and Schema Structure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related