Diameter Maintenance and D. Sun
Extensions (DIME) Z. Zeltsan
Internet Draft Alcatel-Lucent
Expires: September 2007 March 2, 2007
Towards the Specification of a Diameter Resource Control
Application: gaps, functional requirements and models, and
implementations
draft-sun-dime-diameter-resource-control-requirements-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Sun Expires September 2007 [Page 1]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
Abstract
This I-D is to analyze the gaps in the ongoing work of the QoS
application in the DIME WG, discuss the extension of the scope of QoS
application to a generic resource control application for a variety
of network technologies and use cases, and investigate potential
mechanisms to support additional resource control scenarios. The
current Diameter Quality of Service Application (draft-tschofenig-
dime-diameter-qos-01.txt) is limited to an environment where network
elements triggered by certain mechanisms (e.g. path-coupled QoS
signaling such as RSVP or NSIS initiated by end-hosts) can request
QoS authorization of network resources. It does not address
environments where end-hosts and/or network elements is unable to
issue a resource request initiatively. In such environments, a
different mode of operations is needed to allow an authorizing entity
to not just authorize QoS resources upon the receipt of the request
from network elements but also directly authorize resources and
dictate routers/switches to enforce the decisions without the request
from network elements. The new mode of operations also lends itself
to address resource control in general. It can control resources for
the purpose beyond QoS support, such as NAPT, media latching, and
packet filtering.
Sun Expires September 2007 [Page 2]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
Table of Contents
1. Terminology....................................................4
2. Functional models and requirements.............................6
2.1. Implications of end user capabilities and QoS mechanisms..6
2.1.1. End user equipment capabilities......................6
2.1.2. QoS mechanisms.......................................7
2.2. Resource control models...................................7
2.3. Functional requirements...................................9
2.4. Functional framework......................................9
2.5. Schematic examples of use cases..........................11
3. New Commands and AVPs of Diameter resource control application for
Push model.......................................................14
3.1. Command codes............................................14
3.1.1. Policy-Install-Request command......................15
3.1.2. Policy-Install-Answer command.......................15
3.2. New AVPs.................................................16
3.2.1. PI-Request-Type AVP.................................16
3.2.2. PI-Request-Number AVP...............................16
3.2.3. Other resource control AVPs.........................17
4. Procedures....................................................17
4.1. Session initiation.......................................18
4.1.1. Session initiation for Push Model...................18
4.1.2. Session initiation for Pull Model...................21
4.2. Session modification.....................................23
4.3. Session termination......................................25
4.4. Specific event actions...................................27
5. Selection and binding mechanisms..............................27
6. IANA Considerations...........................................27
6.1. Command Codes............................................27
6.2. AVP Codes................................................27
6.3. Application Identifier...................................28
7. Security Considerations.......................................28
8. Acknowledgments...............................................28
9. References....................................................29
9.1. Normative References.....................................29
9.2. Informative References...................................29
Authors' Addresses...............................................31
Intellectual Property Statement..................................31
Disclaimer of Validity...........................................32
Copyright Statement..............................................32
Acknowledgment...................................................32
Sun Expires September 2007 [Page 3]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
Introduction
This I-D is to address the gaps in the ongoing discussion of the QoS
application in the DIME WG, discuss the extension of the scope of QoS
application to a generic resource control application for a variety
of network technologies and use cases, and investigate potential
mechanisms to support additional resource control scenarios.
The current Diameter Quality of Service Application [draft-
tschofenig-dime-diameter-qos-01.txt] and its predecessors is limited
to an environment where network elements triggered by certain
mechanisms (e.g. path-coupled QoS signaling such as RSVP or NSIS
initiated by end-hosts) can request QoS authorization of network
resources. It does not address environments where end-hosts and/or
network elements is unable to issue a resource request initiatively.
In such environments, a different mode of operations is needed to
allow an authorizing entity (the policy decision point in the [draft-
tschofenig-dime-diameter-qos-01.txt] nomenclature) to not just
authorize QoS resources upon the receipt of the request from network
elements but also directly authorize resources and dictate
routers/switches to enforce the decisions without the request from
network elements. Current frameworks and mechanisms defined in
[draft-tschofenig-dime-diameter-qos-01.txt] are not sufficient to
support those scenarios and further extension and enhancement is
needed to support a universal resource control framework. The new
mode of operations also lends itself to address resource control in
general. It can control resources for the purpose beyond QoS support,
such as NAPT, media latching, and packet filtering such as described
in [ITU-T RACF] and [TISPAN RACS].
This I-D analyzes the relationship between QoS mechanisms/end user
equipment's capabilities and resource control modes, and discusses
functional requirements and functional framework to ensure the
completeness of the protocol development for purpose of general
resource control. Finally, this document describes some enhancements
of Diameter protocol for Push mode of resource control, which can
also be extended to support Pull mode of resource control and leads
to a universal functional framework for different types of end user
equipments and quality of service mechanisms offered in the same
network.
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Sun Expires September 2007 [Page 4]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
The following terms are used in this document:
Application Functions
The application functions (AF) is a functional entity responsible for
controlling the application layer session and interacting with the
end user equipment at the application level. It may extract/derive
the end user resource request from the received application signaling
message. The AF can be an application server or SIP proxy.
Diameter Resource Control Application
It is the AAA application protocol that is defined in this
document and is used for the purpose of resource control.
End User Equipment
The end user equipment (UE) is a functional entity responsible for
establishing a user application session with the network. Its
resource control and signaling capabilities may vary.
Pull Mode
In this mode, the network layer signaling received from the end user
equipment triggers the resource control session. The Resource Control
Enforcement Entity then pulls the resource control decisions from the
server. The Diameter resource control application shall support this
mode.
Push Mode
In this mode, application functions or changes in local network
conditions received trigger the resource control session. The
Resource Control Decision Entity then pushes the resource control
decisions to the client. The Diameter resource control application
shall support this mode.
Resource Control Enforcement Entity
The Resource Control Enforcement Entity (RCE) is a functional entity
responsible for enforcing resource control decisions on gate
operation (open/close the gate) and other QoS resources and network
resources, i.e. policy enforcement point (PEP) as defined in
[RFC2753]. A Diameter client collocates with the RCE in the same
network element for a Diameter resource control session.
Resource Control Decision Entity
Sun Expires September 2007 [Page 5]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
The Resource Control Decision Entity (RCD) is a functional entity
responsible for making decisions on resource authorization,
reservation and commitment according to a set of information such as
service information, network policy, end user subscription and
network resource availability, i.e. policy decision point (PDP) as
defined in [RFC2753]. A Diameter server collocates with the RCD in
the same network element for a Diameter resource control session.
Resource Control Session
This is a Diameter session that supports the Diameter resource
control application.
Resource Control Decision
A set of information including the resource control actions and the
relevant IP media flows to that these actions need to be applied.
2. Functional models and requirements
This section discusses the implications of underlying network QoS
mechanisms and various end user capabilities on policy based resource
control approach, and summarizes functional models and requirements.
2.1. Implications of end user capabilities and QoS mechanisms
2.1.1. End user equipment capabilities
The end user equipment's (UE) capabilities are varied in relation to
resource control, which can be categorized as follows:
o Category 1: No resource control capability in both application and
network layers. This type of end user equipment may set up a
connection through application layer signaling, but it is unable
to provide specific resource/QoS requirements either through
application layer signaling e.g. SIP or through network layer
signaling e.g. RSVP or NSIS (or does not support network layer
signaling at all).
o Category 2: Only has resource control capability in the
application layer. This type of end user equipment is able to set
up a connection through application layer signaling with certain
resource requirements (e.g. application level service attributes),
but it is unable to provide specific network level resource
requirements (e.g., network QoS class) through network layer
signaling e.g., RSVP or NSIS (or does not support network layer
signaling at all).
Sun Expires September 2007 [Page 6]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
o Category 3: Has resource control capability in the network layer.
This type of end user equipment may set up a connection through an
application layer signaling and translate service characteristics
into network level resource requirements (e.g. network QoS class)
locally, and request the resources through network layer signaling
e.g. RSVP or NSIS.
2.1.2. QoS mechanisms
A couple of different QoS mechanisms are employed commonly in packet
networks. Those QoS mechanisms can be categorized into two models:
intserv [RFC1633] and diffserv [RFC2475]. In the intserv model,
network layer signaling e.g RSVP [2210], NSIS [I-D.ietf-nsis-qos-
nslp], or link specific signaling is commonly used to initiate a
request from end user equipment for desired QoS resource of a media
flow. In the diffserv model, the QoS resources are provisioned based
on some predefined QoS service classes rather than QoS requests on a
per flow basis.
It is obvious that the QoS mechanisms have some correlation with the
UEs capability in terms of resource control process. Since category 1
and 2 UEs cannot initiate the resource requests through the network
layer signaling, the intserv model is not applicable to them in
general. Category 3 UEs may decide whether or not to use the network
layer signaling for requesting the resource or not based on network
requirements and operator's configuration.
The diversity of QoS capabilities of UEs and networks results in
differences in how the resource control system interacts with
underlying network elements. In the intserv model, the resource
control session is typically initiated by network element when a
trigger such as the network layer signaling is received from the end
user equipment, and resource authorization decisions are produced
upon the request of the network element (i.e. Resource Control
Enforcement Entity). In the diffserv model, since the network element
is unable to initiatively request the resource authorization, the
resource control session is typically triggered by either application
functions or resource control conditions defined by the operator, and
then the authorization decisions are pushed by the decision function
(i.e. Resource Control Decision Entity) to the network element
without explicit request.
2.2. Resource control models
According to the above analysis, two resource control models are
needed in support of different combinations of QoS mechanisms and
UE's capabilities.
Sun Expires September 2007 [Page 7]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
o Push model: The resource control session is triggered by
application functions or local network conditions (e.g. time of
day on resource usage and QoS classes), and resource control
decisions are pushed by the decision function.
Moreover, the push model can be further divided into two types:
- UE initiated push model
- Network initiated push model
In the former, the resource control session is triggered by
application functions due to the explicit request of UE through
application layer signaling, e.g. SIP; in the latter, the resource
control session is triggered by application functions without
explicit request of UE.
o Pull model: The resource control session is triggered by the
network layer signaling received from end user equipments or by
the local event in the network element according to pre-configured
policies, and resource control decisions are pulled by the network
element.
There are 3 types of modes described in [I-D.tschofenig-nsis-qos-
authz-issues], and [draft-tschofenig-dime-diameter-qos-01.txt].
All of them can be regarded as use cases of Pull model.
The similar resource control models are also addressed in [ITU-T
RACF].
The Pull model is applicable to GPRS networks as defined in [3GPP
PCC] or Intserv enabled IP networks; the Pull model is applicable
to some other networks, for example, Cable network, DSL, Ethernet,
Diffserv enabled IP/MPLS as defined in [CableLabs PCMM], [DSL
Forum Policy Control Framework], [ITU-T RACF] and [TISPAN RACS].
The different resource control models are required in support of
distinctive capabilities of end user equipments. For category 1 and 2
of UEs, the Push model is mandated, in which the resource control
operations are triggered by the application functions, and the
resource control decisions are pushed from the Resource Control
Decision Entity down to the Resource Control Enforcement Entity. For
category 3 of UE, either push model or pull mode is doable, the
operation of Push model is the same as that of category 1/2; in the
Pull model, the resource control operations are triggered by the
network layer signaling received from UEs, and the resource control
Sun Expires September 2007 [Page 8]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
decisions are pulled from the Resource Control Decision Entity by the
Resource Control Enforcement Entity.
However, it is expected that the resource control trends towards the
Push model for all types of UE and network technologies, since the
Pull model requires extra QoS mechanism and interaction in the
network elements that may lead to complexity, scalability and cost-
effectiveness issues.
2.3. Functional requirements
It is worth pointing out that in pull model, the decision function is
still allowed to push down updated decisions, as needed, of an
existing resource control session. Similarly, in push model, the
network element is also allowed to request (pull) the re-
authorization of an existing resource control session.
Therefore, the functional requirements and framework have to take
into both models as a whole when developing the protocol, mechanism
and relevant parameters. The main functional requirements of Diameter
resource control application are hence as follows:
o Shall interwork with various QoS mechanisms and UEs for different
network technologies, i.e., both pull and push models can be
supported within the same functional framework.
o Shall provide broad resource control functions spanning from
network QoS resource control to network accessibility and security
resource control and NAT traversal/NAPT resource control etc.
o Shall perform the admission control on a per flow per subscriber
basis according to multiple facets of network conditions, e.g.
local network policies, resource availability and subscription.
o Shall instruct the enforcement of resource control decisions on
per flow basis.
2.4. Functional framework
A generic functional framework of Diameter resource control
application is illustrated in figure 1. The Resource Control Decision
Entity (RCD) (i.e. the decision function, serving the functionality
of policy decision point as defined in [RFC2753][RFC3084]) is
responsible for authorizing the resource request and formulating
resource control decisions based on service information, network
local policies, end user subscription and network resource
availability etc. The Resource Control Enforcement Entity (RCE) (i.e.
Sun Expires September 2007 [Page 9]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
network element, serving the functionality of policy enforcement
point as defined in [RFC2753][RFC3084]) is responsible for enforcing
the resource control decisions (e.g. opening/closing the gates of IP
flows, limiting the traffic bandwidth, marking/remarking QoS class of
IP packets, metering network resource usage); in addition, it may
support other functions, e.g. media relay and address latching
functions for NAT traversal and NAPT. The application functions
(AF)(e.g. application server, SIP proxy or video headend of IPTV) are
responsible for initiating the resource request and populating the
service information into a resource request message. In this
functional framework the Resource Control Decision Entity (RCD) acts
as a Diameter server and the Resource Control Enforcement Entity
(RCE) acts as a Diameter client.
The Resource Control Decision Entity and application functions can be
collocated in the same physical box within the same provider domain
or distributed throughout the network between different provider
domains. The interaction of the Resource Control Decision Entity and
application functions is outside the scope of this document.
The Resource Control Decision Entity and Resource Control Enforcement
Entity typically shall be located in the same provider's network
domain. There can be multiple Resource Control Decision Entities in
the system for supporting different instances of application
functions. For each service request, only one RCD should make the
final resource control decision. However, the detailed architecture
of the resource control system and its interfaces are implementation
specific and are out of scope of this specification.
Sun Expires September 2007 [Page 10]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
+-----------+
+-------------------->|Application|
| |Functions |
| +-----------+
| ^
| |
| v
| +----------+
| | Resource |
| | Control |
| | Decision |
| | Entity |
| |(Diameter |
| | Server) |
| +----------+
| |^
| Resource control ||
| Protocol ||
| (Diameter) ||
v v|
+-----------+ +---------------+
| End | | Resource |
| User |<------------>| Control |
| Equipment| | Enforcement |
+-----------+ | Entity |
|(Diameter |
| Client) |
+---------------+
Network Element
Figure 1 Resource control functional framework
2.5. Schematic examples of use cases
The schematic examples of use cases for Pull and Push models are
illustrated as follows.
1. Use case for Push model
Sun Expires September 2007 [Page 11]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
+-----------+
+-------------------->|Application|
| |Functions |
| +-----+-----+
| |
| |(2)
| v
| +----------+
| | Resource |
| | Control |
|(1) | Decision |
| | Entity |
| |(Diameter |
| | Server) |
| +-----+----+
| |
| Resource Control |
| Protocol |(3)
| (Diameter) |
| v
+-----------+ +---------------+
| End | | Resource |
| User |<------------>| Control |
| Equipment| | Enforcement |
+-----------+ | Entity |
|(Diameter |
| Client) |
+---------------+
Network Element
Figure 2 Use case for Push model
(1) The End User Equipment requests an application-specific service
by sending a service request (e.g. SIP Invite, HTTP Get,) to
Application Functions. The service request may or may not contain any
explicit parameters for service quality requirement.
(2) The application functions derive resource requirements and
populate service information (e.g. bandwidth, media type and
application description etc.), and send a request to the RCD.
(3) Upon receipt of the request from the AF, the RCD performs the
initial authorization, establishes a new resource control session
(i.e. a Diameter session), makes and pushes down initial resource
control decisions to corresponding RCE node according to the
indication received from the AF or local policies. The RCE enforces
the decisions accordingly to reserve and/or commit network resources.
Sun Expires September 2007 [Page 12]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
2. Use case for Push Model
+-----------+
+-------------------->|Application|
| |Functions |
| +-----+-----+
| |^
| (2)||(3)
| v|
| +----------+
| | Resource |
| | Control |
|(1) | Decision |
| | Entity |
| |(Diameter |
| | Server) |
| +----------+
| ^|
| Resource Control ||
| Protocol (5) ||(6)
| (Diameter) ||
| |v
+-----------+ +------+--------+
| End | (4) | Resource |
| User |<------------>| Control |
| Equipment| | Enforcement |
+-----------+ | Entity |
|(Diameter |
| Client) |
+---------------+
Network Element
Figure 3 Use case for Pull model
(1) The End User Equipment requests an application-specific service
by sending a service request .e.g. SIP Invite, HTTP Get,.to the
Application Functions. The service request may or may not contain any
explicit (application) service quality requirements.
(2) The application functions derive resource requirements and
populate service information (e.g. bandwidth, media type and
application description etc.), and send a request to the RCD.
(3) The Resource Control Decision Entity checks authorization based
on network policy rules etc. If the resources are authorized, an
authorization token (RFC 3520) may be assigned to this service and
informed to the End User Equipment. (The use of authorization token
Sun Expires September 2007 [Page 13]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
is optional. It is possible to perform authorization without the use
of a token.)
(4) The End User Equipment initiates an explicit QoS request for
resource reservation to the Resource Control Enforcement Entity. This
QoS request contains the explicit transport QoS requirement
parameters for an application-specific service. It may also contain
an authorization token assigned at the first phase.
(5) On receipt of the QoS request, the Resource Control Enforcement
Entity sends a request to Resource Control Decision Entity for
resource reservation and admission control that may contain the
authorization token as an option.
(6) The Resource Control Decision Entity makes the final decision of
reservation and admission control. If the request is granted, the
Resource Control Decision Entity provides the decisions to the
Resource Control Enforcement Entity. The Resource Control Enforcement
Entity enforces the decisions accordingly.
3. New Commands and AVPs of Diameter resource control application for
Push model
This section defines a pair of new command codes and several new
mandatory AVPs and describes the usage of these command codes and
AVPs for Diameter resource control application in order to support
the push model.
3.1. Command codes
Section 3.1.1 and 3.1.2 define new Diameter message Command-Code
values that MUST be supported by all Diameter implementations that
conform to this specification. The command codes are as follows:
Command-Name Abbrev. Code Reference
-----------------------------------------------------------
Policy-Install-Request PIR xxx 3.1.1
Policy-Install-Answer PIA xxx 3.1. 2
Sun Expires September 2007 [Page 14]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
3.1.1. Policy-Install-Request command
The Policy-Install-Request (PIR) message, indicated by the Command-
Code field set to TBD and the 'R' bit set in the Command Flags field,
is sent by the RCD to the RCE for originating a resource control
session from the RCD (Diameter server) side with the PI-Request-Type
set to INITIAL_REQUEST, and contains resource control decision
information that is relevant to the initiation. In addition, it may
also update or terminate an existing session from the RCD side with
the PI-Request-Type set to UPDATE_REQUEST or TERMINATION_RQUEST.
The Auth-Application-Id MUST be set to the value xxx, indicating the
Diameter resource control application.
Message Format:
<PI-Request> ::= < Diameter Header: xxx, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ PI-Request-Type }
{ PI-Request-Number }
[ Origin-State-Id ]
[ Auth-Session-State ]
[ Authorization-Lifetime ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ] (note)
Note: The relevant AVPs to QoS, resource control decisions are FFS.
Some high level information is described in section 4.1.2.2.
3.1.2. Policy-Install-Answer command
The PIA command, indicated by the Command-Code field set to TBD and
the 'R' bit cleared in the Command Flags field, is sent by the RCE to
the RCD in response to the PIR command.
Message Format:
<PI-Answer> ::= < Diameter Header: xxx, PXY >
Sun Expires September 2007 [Page 15]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ PI-Request-Type }
{ PI-Request-Number }
[ Result-Code ]
[ Origin-State-Id ]
*[ Proxy-Info ]
*[ AVP ] (note)
3.2. New AVPs
3.2.1. PI-Request-Type AVP
The PI-Request-Type AVP (AVP Code xxx) is of type Enumerated and
contains the reason for sending the policy-install request command.
It MUST be present in all Policy-Install-Request messages. The
following values are defined for the PI-Request-Type AVP:
INITIAL_REQUEST 1
An Initial request is used to initiate a resource control
session from the Diameter Server side, and contains resource control
information that is relevant to the initiation.
UPDATE_REQUEST 2
An Update request contains resource-control information for an
existing resource control session. Update Policy-Install requests
SHOULD be sent every time at the expiry of the allocated quota or
validity time. Further, additional service-specific events MAY
trigger a spontaneous Update request.
TERMINATION_REQUEST 3
A Termination request is sent to terminate a resource control
session and contains resource control information relevant to the
existing session.
3.2.2. PI-Request-Number AVP
The PI-Request-Number AVP (AVP Code xxx) is of type Unsigned32 and
identifies this request within one session. As Session-Id AVPs are
globally unique, the combination of Session-Id and PI-Request-Number
AVPs is also globally unique and can be used in matching policy
install messages with confirmations. An easy way to produce unique
Sun Expires September 2007 [Page 16]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
numbers is to set the value to 0 for a policy-install request of type
INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the
first UPDATE_REQUEST, to 2 for the second, and so on until the value
for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST.
3.2.3. Other resource control AVPs
It is FFS the format and definition of resource control related AVPs
such as QoS AVPs, flow descriptor etc. One option is to adopt the
data structure defined by [I-D.tschofenig-dime-diameter-qos] and its
successor; another option is to adopt the data structure defined by
3GPP Gx [29.212]. No matter what data structure is used, the
following information shall be defined accordingly.
o IP media flow description (e.g. IP 5-tuple (port number can be a
range) and direction)
o QoS information (e.g. authorized bandwidth, network service Class)
o Resource control actions (e.g., gate opening/closing)
o Other resource control information, e.g.,
o NAT traversal/NAPT information (e.g. address latching, address
translation information)
o Usage metering and statistics reporting
Additional AVPs may be defined to further facilitate the resource
control functions and procedure, e.g.,
o Network layer session Identifier (e.g. signaling session ID)
o Reservation priority
o Traffic descriptor (e.g. peak/committed date rate, peak/committed
bucket size and excess bucket size)
4. Procedures
This section elaborates on the example call flows of resource control
application based on aforementioned new command codes, and existing
command codes from the Diameter Base protocol [RFC3588] and the
credit-control application [RFC4006] as follows (other valid command
codes are FFS, such as AAR/AAA [RFC4005], DER/DEA [RFC4072],
ACR/ACA):
Sun Expires September 2007 [Page 17]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
Command-Name Abbrev. Code Reference
-----------------------------------------------------------
Credit-Control-Request CCR 272 RFC 4006
Credit-Control-Answer CCA 272 RFC 4006
Re-Auth-Request RAR 258 RFC 3588
Re-Auth-Answer RAA 258 RFC 3588
Session-Termination-Request STR 275 RFC 3588
Session-Termination-Answer STA 275 RFC 3588
Abort-Session-Request ASR 274 RFC 3588
Abort-Session-Answer ASA 274 RFC 3588
The procedures for Push model and Pull model are quite similar. The
main difference is for the session initiation, i.e., the RCD will
initiate a new session in the Push model; instead, the RCE will
initiate a new session in the Pull model. The session modification
and termination procedures are identical for Push and Pull models.
4.1. Session initiation
4.1.1. Session initiation for Push Model
When the RCD receives a resource control request from the AF, it
shall translate the service information (e.g. media type, media flow
descriptions, application layer QoS (service class and bandwidth)
into network layer information, evaluate network policies (e.g. time
of day), examine UE's subscription (e.g. maximum allowed bandwidth),
and check network resource availability. The resource availability
check may be supported by an element, such as the Transport Resource
Control Functional Entity (TRC-FE) [ITU-T RACF], which interacts with
the RCD to ensure the availability of requested transport network
resources. The detailed procedures for controlling other network
resources e.g. NAT traversal are FFS.
An initial authorization can be admitted by the RCD if for all IP
media flows in the session, all conditions are satisfied. The RCD
may determine the necessary QoS resources (e.g. maximum allowed
bandwidth) and resource control operations as one of following
options:
Sun Expires September 2007 [Page 18]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
o Reserve network resources only (gate status is closed or disabled)
o Reserve and commit network resource (gate status is open or
enabled)
In the Push model, the RCD shall support a selection mechanism to
identify the corresponding RCE and the binding mechanism to correlate
the resource request from the AF with relevant subscriber profile and
IP media flows; and then the RCD shall send a Policy-Install-Request
message with the PI-Request-Type set to "INITIAL_REQUEST" to the RCE
with all decision data.
The RCD may include the authorization lifetime that allows the RCE to
determine how long the authorization decision is valid for this
particular QoS reservation.
In addition, if the RCD needs to maintain resource control session
state in stateful operation (the stateless operation is FFS and
subject to the discussion of DIME group), it should save certain
information for management of the session (e.g. resource control
session ID, resource control decision data etc.).
When the RCE receive the PIR message with new Diameter session ID, it
shall treat it as a new request and initiate a new Diameter session
accordingly if the stateful operation is used.
The RCE shall enforce the resource control decisions of PIR message
received from the RCD. For example, if the resource control decisions
indicate the gate should be open, the RCE shall allocate the
requested bandwidth and open the gate according to IP flow
description (e.g. IP 5-tuple).
The final result of the resource control enforcement is provided in
the Result-Code AVP of the Policy-Install-Answer message sent by the
RCE, in case of successful authorization, the Result-Code is set to
DIAMETER_LIMITED_SUCCESS, (see [RFC3588])).
Sun Expires September 2007 [Page 19]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
End user Resource control Resource control Application
Equipment Enforcement Entity Decision Entity Functions
(Diameter Client) (Diameter Server)
| | | |
| | (1. Trigger)<------- +
| | + |
| | +------------+----------+ |
| | | 2. Authorize request | |
| | | Produce decision data| |
| | | Keep session data | |
| | |/Authz-time,Session-Id/| |
| | +------------+----------+ |
| | | |
| |< -------- (3. PIR) -----+ |
| |(INITIAL_REQUEST, | |
| | Decision(QoS-Resources), | |
| | Authz-time) | |
| +-------+------------+ | |
| |4. Install decisions| | |
| | + | | |
| | Authz. session | | |
| | /Authz-time/ | | |
| +-------+------------+ | |
| | | |
| +--------- (5. PIA) ------>| |
| | (Result-Code) | |
| | | |
| | | |
|=====================(Data Flow)=======================>
| | | |
Figure 4 Session initiation for Push Model
1. A resource control session is initiated by the RCD when a trigger
is received. The trigger can be a resource request from the AF or
a local event due to network policies/conditions.
2. The RCD stores the service information received from the AF and
authorizes the request based on service information, network
resource availability, end user's transport subscription and
provisioned network policies, and determines the resource
reservation operation mode (e.g. reservation only, or reservation
+ commitment).
3. The RCD discovers pertinent RCCs and pushes down policy decisions
to those RCCs using PIR command with the PI-Request-Type set to
"INITIAL-REQUEST".
Sun Expires September 2007 [Page 20]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
4. The RCE installs policy decisions, and performs policy
enforcement operations as needed, e.g., enforcing the authorized
QoS and enabling or disabling IP media flows according to the
corresponding policy decision (e.g. the flow status).
5. The RCE sends PIA to RCD to acknowledge the receipt of PIR.
4.1.2. Session initiation for Pull Model
When the RCE receives the path-coupled QoS signaling from UE or the
trigger of a local event, it initiates a new resource control session
and sends a resource request message to the RCD.
Upon receipt of the request from the RCE, the RCD will perform the
resource control operation, which is same as described in section
4.1.1.
Since the session is initiated from the RCE side, the RCD does not
need to perform the selection of RCE instance. But the RCE should
maintain the linkage with corresponding RCD.
Sun Expires September 2007 [Page 21]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
End user Resource control Resource control Application
Equipment Enforcement Entity Decision Entity Functions
(Diameter Client) (Diameter Server)
|)------> + | |
| (1. Trigger) ----(CCR)---------> + |
| | +------------+----------+ |
| | | 2. Authorize request | |
| | | Produce decision data| |
| | | Keep session data | |
| | |/Authz-time,Session-Id/| |
| | +------------+----------+ |
| | | |
| |< ------- (3. CCA) ------+ |
| |(INITIAL_REQUEST, | |
| | Decision(QoS-Resources), | |
| | Authz-time) | |
| +-------+------------+ | |
| |4. Install decisions| | |
| | + | | |
| | Authz. session | | |
| | /Authz-time/ | | |
| +-------+------------+ | |
| | | |
|<-----(5)+ | |
| |
| | | |
|=====================(Data Flow)=======================>
| | | |
Figure 5 Session initiation for Pull Model
1. Upon receipt of path-coupled QoS signaling or the trigger of
local event, the RCE initiates a new resource control session and
sends a CCR command with the CC-Request-Type AVP set to the value
"INITIAL_REQUEST" (other options e.g. AAR are FFS).
2. This step is the same as step 2 of Push model.
3. The RCD sends the policy decisions to the RCE using CCA command,
including authorized QoS, event triggers etc.
4. This step is the same as step 4 of Push model.
5. The RCE sends path-coupled QoS signaling to the UE to acknowledge
the reservation and may send back a confirmation to RCD.
Sun Expires September 2007 [Page 22]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
4.2. Session modification
The session modification procedure for Push and Pull models is
identical, i.e., the same command codes, AVPs and procedures can be
used for both of them.
The session modification can be triggered by the update request
received from the AF or local network condition (e.g. time of day),
or by the request from the RCE upon the change of network status
according to the specific event indication received from the RCD in
the session initiation (e.g. retrieve and re-authorize the resource
control decisions).
When one of triggers occurs, the RCD shall determine the operation of
the session modification as one of follows: 1) Modification of
requested resources; 2) Commitment of requested resources; 3) Removal
of requested resources.
The RCD produces a set of updated resource control decisions and
sends to the RCE through the RAR command (another option is to use
PIR with the PI-Request-Type set to UPDATE-REQUEST).
Upon receipt of RAR with an existing session ID (or a PIR message
with the PI-Request-Type set to UPDATE-REQUEST), the RCE shall treat
it as a modification request. The RCE shall determine the operations
to enforce the updated decisions as one of follows:
o Install decision for a new IP media flow without committing the
requested resources if the flow/gate status is set to
closed/DISABLED.
o Install decision and commit the requested resources for a new IP
media flow if the flow/gate status is set to open/ENABLED (e.g.
open the gates).
o Modify decision for an existing IP media flow without committing
the requested resources if the flow/gate status is set to
closed/DISABLED (e.g. increase or decrease the allocated
bandwidth, but the RTCP gate may remain the opening status).
o Modify decision and commit the requested resources for an existing
IP media flow if the flow/gate status is set to open/ENABLED (e.g.
open the gates with modified bandwidth).
o Commit the requested resources for an existing IP media flow if
the flow/gate status is set to open/ENABLED (e.g. open the gates
with reserved bandwidth).
Sun Expires September 2007 [Page 23]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
o Revoke the installed decisions and release the committed or
reserved resources for all related IP media flows if the flow/gate
status is set to REMOVED.
The final result of the resource control enforcement is provided in
the Result-Code AVP of the Policy-Install-Answer message sent by the
RCE (or RAA message), in case of successful authorization, the
Result-Code is set to DIAMETER_LIMITED_SUCCESS, (see [RFC3588])).
When the RCE is triggered by the change of network status, it may
send a CCR message with requested specific action to the RCD. The RCD
shall provide the updated decision data through the CCA message.
End user Resource control Resource control Application
Equipment Enforcement Entity Decision Entity Functions
(Diameter Client) (Diameter Server)
| | | |
|======================(Data Flow)======================>
|(------>)| | |
| QoS-Res +(----- (CCR)_-------->)(1. Trigger)<------ +
| | + |
| | +------------+----------+ |
| | | 2. Authorize request | |
| | | Update decision data | |
| | | Keep session data | |
| | |/Authz-time,Session-Id/| |
| | +------------+----------+ |
| | | |
| |< -----(3. RAR/CCA)-------+ |
| |(UPDATE_REQUEST, | |
| | Decision(QoS-Resources), | |
| | Authz-time) | |
| +----------+---------+ | |
| |4. Update decisions | | |
| | + | | |
| | Authz. session | | |
| | /Authz-time/ | | |
| +-------+------------+ | |
| | | |
| +--------- (5. RAA) ------>| |
| | (Result-Code) | |
| | | |
| | | |
|=======================Data Flow=======================>
| | | |
Figure 6 Session modification for Push and Pull models
Sun Expires September 2007 [Page 24]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
1. The resource modification can be triggered by the request from AF
or local event, and by the request from RCE (using CCR command).
2. The RCD re-evaluates the policies and updates policy decisions if
needed, and determines the affected IP media flows, and
corresponding QoS and gate operations.
3. The RCD identifies the affected RCCs and forwards the updated
policy decisions using a Diameter RAR or CCA (the use of PIR in
this case is FFS).
4. The RCE updates policy decisions, and performs policy enforcement
operations as needed, e.g., enforcing the authorized QoS and
enabling or disabling IP media flows according to the modified
policy decision (e.g. the flow status).
5. The RCE responds RAA command to acknowledge the RAR.
4.3. Session termination
The session termination procedure for Push and Pull models is
identical, i.e., the same command codes, AVPs and procedures can be
used for both of them.
The session termination can be triggered by the request received from
the AF when an application session is released or by local network
condition. In addition, the RCE may request the session termination
according to the change of network status or expiry of a session.
When the session termination is triggered by AF or local network
condition, the RCD shall send a ASR message with existing session ID
(or send a PIR message with PI-Request-Type set to "TERMINATION-
REQUEST"), the RCE shall release all network resources and return a
PIA (or ASA).
When the session termination is triggered by the change of network
status or expiry of a session, the RCE shall send a CCR message with
CC-Request-Type set to "TERMINATION-REQUEST", the RCD shall release
all network resources and return a CCA. In addition, the RCD shall
release all resources and notify the AF for affected application
sessions.
Sun Expires September 2007 [Page 25]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
End user Resource control Resource control Application
Equipment Enforcement Entity Decision Entity Functions
(Diameter Client) (Diameter Server)
| | | |
|=======================Data Flow=======================>
|(------>)| | |
| QoS-Res +(----- (CCR)_---->)(1. Trigger)<---------- +
| | + |
| | +------------+----------+ |
| | | 2. Authorize request | |
| | | Release session data | |
| | |/Authz-time,Session-Id/| |
| | +------------+----------+ |
| | | |
| |< ----(3. ASR/CCA)--------+ |
| |(TERMINIAT_REQUEST) | |
| +-------+---------+ | |
| | 4. Release | | |
| | session state | | |
| +-------+---------+ | |
| | | |
| +--------- (5. ASA) ------>| |
| | (Result-Code) | |
| | | |
Figure 7 Session termination
1. The session termination can be triggered by the request from AF
or local event, and by the request from RCE (using CCR command).
2. The RCD determines the affected IP media flows and releases all
resources.
3. The RCD sends ASR to terminate the session if the request is
triggered by AF or local event. or uses CCA to indicate the
release if the request is from the RCE (the use of PIR in this
case is FFS).
4. The RCE releases all local resources.
5. The RCE responds ASA command to acknowledge the ASR as needed.
Sun Expires September 2007 [Page 26]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
4.4. Specific event actions
The RCD may indicate to be notified of certain events (e.g. bearer
failure) by specifying them in the indication of specific event
action through PIR or RAR message.
If an event subscribed by the RCD through PIR or RAR occurs, the RCE
shall send a CCR command to the RCD containing:
o The value of the indication of specific event action, indicating
the event that occurred; and
o Optionally, the appropriate Cause value.
5. Selection and binding mechanisms
The detailed selection and binding mechanisms is FFS.
6. IANA Considerations
This document defines two new Diameter commands, several new AVPs and
a new Diameter application.
6.1. Command Codes
This document defines the following new command codes:
Command-Name Abbrev. Code Reference
-----------------------------------------------------------
Policy-Install-Request PIR xxx 4.1.1.1
Policy-Install-Answer PIA xxx 4.1.1.2
6.2. AVP Codes
This document defines the following new AVPs:
PI-Request-Type
PI-Request-Number
Other resource control AVPs: FFS.
Sun Expires September 2007 [Page 27]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
6.3. Application Identifier
This specification defines new Diameter application called "Diameter
QoS Integrated application" i.e. QoS. The Application Identifier
code for this application is set to TBD.
7. Security Considerations
FFS.
8. Acknowledgments
The author would like to thank Hui-Lan Lu and Ramesh Nagarajan for
their inputs and comments to this document.
Sun Expires September 2007 [Page 28]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,"Diameter
Network Access Server Application", RFC 4005, August 2005.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and
J. Loughney, "Diameter Credit-Control Application", RFC 4006,
August 2005.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, August 2005.
9.2. Informative References
[3GPP PCC] 3GPP TS 23.203 version 1.2.0 (2006-09) (Release 7),
Universal Mobile Telecommunications System (UMTS); Policy and
Charging Control architecture.
[3GPP 29.212] 3GPP TS 29.212 version 0.4.0 (2006-09) (Release 7),
Universal Mobile Telecommunications System (UMTS); Policy and
Charging Control over Gx reference point.
[DSL Forum Policy Control Framework] DSL Forum, "Policy Control
Framework for DSL", WT-134 Rev. 2, April 2006.
[I-D.ietf-nsis-qos-nslp] Manner, J., "NSLP for Quality-of-Service
Signaling", draft-ietf-nsis-qos-nslp-10 (work in progress), March
2006.
[I-D.ietf-nsis-qspec] Ash, J., "QoS-NSLP QSPEC Template", draft-
ietf-nsis-qspec-09 (work in progress), March 2006.
[I-D.tschofenig-nsis-aaa-issues] Tschofenig, H., "NSIS
Authentication, Authorization and Accounting Issues", draft-
tschofenig-nsis-aaa-issues-01(work in progress), March 2003.
Sun Expires September 2007 [Page 29]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
[I-D.tschofenig-nsis-qos-authz-issues] Tschofenig, H., "QoS NSLP
Authorization Issues", draft-tschofenig-nsis-qos-authz-issues-00
(work in progress), June 2003.
[draft-tschofenig-dime-diameter-qos-01.txt] Alfano, F., McCann, P.,
H. Tschofenig, H., Tsenov T. and T. Tsou, "Diameter Quality of
Service Application", April 2007.
[ITU-T RACF] ITU-T Recommendation Y.2111, "Resource and admission
control functions in Next Generation Networks", October 2006.
[CableLabs PCMM] CableLabs, "PacketCable Multimedia Specification",
PKT-SP-MM-I03-051221, December 21, 2005.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview," IETF RFC 1633,
June 1994.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated Services," IETF RFC
2475, December 1998.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January 2000.
[RFC3084] Chan, K., Durham, D., Gai, S., McCloghrie, K., Herzog,
S., Reichmeyer, F., Yavatkar, R., A. Smith, "COPS Usage for Policy
Provisioning (COPS-PR)", RFC 3084, March 2001.
[TISPAN RACS] ETSI ES 282 003: "Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN);
Resource and Admission Control Sub system (RACS); Functional
Architecture".
Sun Expires September 2007 [Page 30]
Diameter Maintenance and D. Sun
Extensions (DIME) Z. Zeltsan
Internet Draft Alcatel-Lucent
Expires: September 2007 March 2, 2007
Authors' Addresses
Dong Sun
Bell Labs, Alcatel-Lucent
101 Crawfords Corner Rd
Holmdel, NJ 07733
USA
Email: dongsun@alcatel-lucent.com
Zachary Zeltsan
Alcatel-Lucent
101 Crawfords Corner Rd
Holmdel, NJ 07733
USA
Email: zeltsan@alcatel-lucent.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
Sun Expires September 2007 [Page 31]
Internet-Draft Towards the Specification of a March 2007
Diameter Resource Control Application
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sun Expires September 2007 [Page 32]