IETF67 DIME WG Towards the specification of a Diameter Resource Control Application Dong Sun IETF 67, San Diego, Nov 2006 draft-sun-dime-diameter-resource-control-requirements-00.txt

IETF67 DIME WG Current Diameter QoS Application Focus on QoS authorization triggered by path-coupled signaling (e.g. RSVP/NSIS) from endpoints, assuming –The endpoints are always able to understand network QoS requirements and initiate the QoS request through network layer signaling –The QoS authorization results are pulled by the network elements (named as Pull mode) Integrated models imply –The Authorizing server and application server are collocated within the same operator domain The existing mechanisms and parameters concerns about the QoS as the only resource to be controlled

IETF67 DIME WG Other resource control scenarios A number of endpoints and network technologies may not have QoS capabilities or may not be able to support path coupled signaling –The endpoints can be cateogrized into 3 types, 1) no any QoS capabilities; 2) only support the request at the application layer; 3) understand network QoS and support network layer signaling –Some networks does not support path-coupled signaling for QoS reservation on a per flow basis, e.g. Cable, DSL, Ethernet and MPLS –SPs may not intend to rely on endpoints for network QoS request due to complexity, scalability and cost-effectiveness issues. The resources controlled by a policy framework are extended more than the QoS, such as – Address latching and media relay, security and deep packet inspection According to the rationale of NGN as defined by ETSI TISPAN and ITU-T, application functions (e.g. SIP proxy, IMS) should be totally independent of transport networks and can be in different domains –The trigger for application session may be different from that for resource control session

IETF67 DIME WG Functional requirements of resource control application New resource control mode – Push Mode is needed in support of other scenarios –The resource control request is initiated by the network (e.g. application functions) rather than path-coupled signaling from endpoints –The resource control decisions are directly pushed down to the network elements (i.e. Policy enforcement point) by the decision function (i.e. policy decision point) –The network elements are still allowed to request the re- authorization of resource control decisions due to special events (e.g. change of certain policies or failure recovery) It is highly desirable to develop a universal functional model to support both Push mode and Pull mode

IETF67 DIME WG Functional model >|Application| | |Functions | | | ^ | | | v | | | Resource | | | Control | | | Server | | |(Diameter | | | Server) | | | |^ | Resource control || | Protocol || | (Diameter) || v v| | End | | Resource | | User | | Control | | Equipment| | Client | |(Diameter | | Client) | Network Element

IETF67 DIME WG Development on Diameter Resource Control Application A pair of new commands is needed to support Push mode to allow the Diameter server to initiate a new session –Policy-Install-Request/Answer (PIR/PIA) are proposed A few new mandatory AVPs are needed to support new commands –PI-Request-Type and PI-Request-Number are proposed Additional AVPs are needed to support broad resource control capabilities, e.g. NAT traversal/NAPT, deep packet inspection The data structure of basic resource control AVPs should take into account other SDOs’ work, e.g. rule based data structure defined by 3GPP Certain mechanisms are needed –Discovery/selection of communicating party and –Binding of resource control request with Diameter session –Hard state and soft state Issues –Stateful Vs. stateless

IETF67 DIME WG Thank you!