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!