draft-ietf-dime-diameter-qos-09.txt   draft-ietf-dime-diameter-qos-10.txt 
Diameter Maintenance and D. Sun, Ed. Diameter Maintenance and D. Sun, Ed.
Extensions (DIME) Alcatel-Lucent Extensions (DIME) Alcatel-Lucent
Internet-Draft P. McCann Internet-Draft P. McCann
Intended status: Standards Track Motorola Labs Intended status: Standards Track Motorola Labs
Expires: January 14, 2010 H. Tschofenig Expires: February 3, 2010 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
T. Tsou T. Tsou
Huawei Huawei
A. Doria A. Doria
Lulea University of Technology Lulea University of Technology
G. Zorn, Ed. G. Zorn, Ed.
Network Zen Network Zen
July 13, 2009 August 2, 2009
Diameter Quality of Service Application Diameter Quality of Service Application
draft-ietf-dime-diameter-qos-09.txt draft-ietf-dime-diameter-qos-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on February 3, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 30 skipping to change at page 3, line 30
3.2.1. Endpoint Categories . . . . . . . . . . . . . . . . . 11 3.2.1. Endpoint Categories . . . . . . . . . . . . . . . . . 11
3.2.2. Interaction Modes Between the Authorizing Entity 3.2.2. Interaction Modes Between the Authorizing Entity
and Network Element . . . . . . . . . . . . . . . . . 11 and Network Element . . . . . . . . . . . . . . . . . 11
3.3. Authorization Schemes . . . . . . . . . . . . . . . . . . 13 3.3. Authorization Schemes . . . . . . . . . . . . . . . . . . 13
3.3.1. Pull Mode Schemes . . . . . . . . . . . . . . . . . . 13 3.3.1. Pull Mode Schemes . . . . . . . . . . . . . . . . . . 13
3.3.2. Push Mode Schemes . . . . . . . . . . . . . . . . . . 16 3.3.2. Push Mode Schemes . . . . . . . . . . . . . . . . . . 16
3.4. QoS Application Requirements . . . . . . . . . . . . . . . 17 3.4. QoS Application Requirements . . . . . . . . . . . . . . . 17
4. QoS Application Session Establishment and Management . . . . . 21 4. QoS Application Session Establishment and Management . . . . . 21
4.1. Parties Involved . . . . . . . . . . . . . . . . . . . . . 21 4.1. Parties Involved . . . . . . . . . . . . . . . . . . . . . 21
4.2. Session Establishment . . . . . . . . . . . . . . . . . . 21 4.2. Session Establishment . . . . . . . . . . . . . . . . . . 21
4.2.1. Session Establishment for Pull Mode . . . . . . . . . 21 4.2.1. Session Establishment for Pull Mode . . . . . . . . . 22
4.2.2. Session Establishment for Push Mode . . . . . . . . . 24 4.2.2. Session Establishment for Push Mode . . . . . . . . . 24
4.2.3. Discovery and Selection of Peer Diameter QoS 4.2.3. Discovery and Selection of Peer Diameter QoS
Application Node . . . . . . . . . . . . . . . . . . . 27 Application Node . . . . . . . . . . . . . . . . . . . 27
4.3. Session Re-authorization . . . . . . . . . . . . . . . . . 28 4.3. Session Re-authorization . . . . . . . . . . . . . . . . . 28
4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 29 4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 29
4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 30 4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 30
4.4. Session Termination . . . . . . . . . . . . . . . . . . . 31 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 31
4.4.1. Client-Side Initiated Session Termination . . . . . . 31 4.4.1. Client-Side Initiated Session Termination . . . . . . 31
4.4.2. Server-Side Initiated Session Termination . . . . . . 32 4.4.2. Server-Side Initiated Session Termination . . . . . . 32
5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 34 5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 34
skipping to change at page 6, line 26 skipping to change at page 6, line 26
It offers authentication, authorization and accounting services to It offers authentication, authorization and accounting services to
applications in flexible local and roaming scenarios. Diameter applications in flexible local and roaming scenarios. Diameter
[RFC3588] and RADIUS [RFC2865] are both widely deployed AAA [RFC3588] and RADIUS [RFC2865] are both widely deployed AAA
protocols. protocols.
Application Endpoint (AppE) Application Endpoint (AppE)
An Application Endpoint is an entity in an end-user device that An Application Endpoint is an entity in an end-user device that
exchanges signaling messages with Application Servers (see below) exchanges signaling messages with Application Servers (see below)
or directly with other Application Endpoints. Based on the result or directly with other Application Endpoints. Based on the result
of this signaling, the Endpoint may make a request for QoS from of this signaling, the Endpoint may make a request for QoS from
the network. For example, a SIP Agent is one kind of Application the network. For example, a SIP User Agent is one kind of
Endpoint. Application Endpoint.
Application Server (AppS) Application Server (AppS)
An Application Server is an entity that exchanges signaling An Application Server is an entity that exchanges signaling
messages with an Application Endpoint (see above). It may be a messages with an Application Endpoint (see above). It may be a
source of authorization for QoS-enhanced application flows. For source of authorization for QoS-enhanced application flows. For
example, a SIP server is one kind of Application Server. example, a SIP server is one kind of Application Server.
Authorizing Entity (AE) Authorizing Entity (AE)
The Authorizing Entity is a Diameter server that supports the QoS The Authorizing Entity is a Diameter server that supports the QoS
application. It is responsible for authorizing QoS requests for a application. It is responsible for authorizing QoS requests for a
skipping to change at page 11, line 10 skipping to change at page 11, line 10
Processing of incoming QoS reservation requests includes three Processing of incoming QoS reservation requests includes three
actions: admission control, authorization and resource reservation. actions: admission control, authorization and resource reservation.
The admission control function provides information about available The admission control function provides information about available
resources and determines whether there are enough resources to resources and determines whether there are enough resources to
fulfill the request. Authorization is performed by the Diameter fulfill the request. Authorization is performed by the Diameter
client, which involves contacting an authorization entity through the client, which involves contacting an authorization entity through the
AAA cloud shown in Section 3. If both checks are successful, the AAA cloud shown in Section 3. If both checks are successful, the
authorized QoS parameters are set in the packet classifier and the authorized QoS parameters are set in the packet classifier and the
packet scheduler. Note that the parameters passed to the Traffic packet scheduler. Note that the parameters passed to the Traffic
Control function may be different from requested QoS (depending on Control function may be different from the ones requested QoS
the authorization decision). Once the requested resource is granted, (depending on the authorization decision). Once the requested
the Resource Management function provides accounting information to resource is granted, the Resource Management function provides
the AE via the Diameter client. accounting information to the AE via the Diameter client.
3.2. Implications of Endpoint QoS Capabilities 3.2. Implications of Endpoint QoS Capabilities
3.2.1. Endpoint Categories 3.2.1. Endpoint Categories
The QoS capabilities of Application Endpoints are varied, and can be The QoS capabilities of Application Endpoints are varied, and can be
categorized as follows: categorized as follows:
Category 1 Category 1
A Category 1 Application Endpoint has no QoS capability at either A Category 1 Application Endpoint has no QoS capability at either
skipping to change at page 13, line 6 skipping to change at page 13, line 6
Pull mode Pull mode
The QoS authorization process is triggered by the network The QoS authorization process is triggered by the network
signaling received from end-user equipment or by a local event in signaling received from end-user equipment or by a local event in
the NE according to pre-configured policies, and authorization the NE according to pre-configured policies, and authorization
decisions are produced upon the request of the NE. In order to decisions are produced upon the request of the NE. In order to
support the pull mode, the NE (i.e., Diameter client) will support the pull mode, the NE (i.e., Diameter client) will
initiate a Diameter authorization session to communicate with the initiate a Diameter authorization session to communicate with the
authorizing entity (i.e., Diameter server). authorizing entity (i.e., Diameter server).
For Category 1 and 2 Application Endpoints, Push mode is required. For Category 1 and 2 Application Endpoints, Push mode is required.
For a Category 3 AppE, either Push mode or Pull mode may be used. For a Category 3 AppE, either Push mode or Pull mode MAY be used.
Push mode is applicable to certain networks, for example, Cable Push mode is applicable to certain networks, for example, Cable
network, DSL, Ethernet, and Diffserv-enabled IP/MPLS as defined by network, DSL, Ethernet, and Diffserv-enabled IP/MPLS as defined by
other SDOs (e.g., ETSI TISPAN and ITU-T}. The Pull mode is more other SDOs (e.g., ETSI TISPAN and ITU-T}. The Pull mode is more
appropriate to IntServ-enabled IP networks or certain wireless appropriate to IntServ-enabled IP networks or certain wireless
networks such as the GPRS networks defined by 3GPP. Some networks networks such as the GPRS networks defined by 3GPP. Some networks
(for example, WiMAX) may require both Push and Pull modes. (for example, WiMAX) may require both Push and Pull modes.
3.3. Authorization Schemes 3.3. Authorization Schemes
skipping to change at page 13, line 34 skipping to change at page 13, line 34
an off-path protocol run (on the application layer or for network an off-path protocol run (on the application layer or for network
access authentication) or the AE might be contacted with request for access authentication) or the AE might be contacted with request for
authentication and authorization of the QoS requesting entity. From authentication and authorization of the QoS requesting entity. From
the Diameter QoS application's point of view these schemes differ in the Diameter QoS application's point of view these schemes differ in
type of information that need to be carried. Here we focus on the type of information that need to be carried. Here we focus on the
'Basic Three Party Scheme' (see Figure 3) and the 'Token-based Three 'Basic Three Party Scheme' (see Figure 3) and the 'Token-based Three
Party Scheme' (see Figure 4). In the 'Two Party Scheme', the QoS RRE Party Scheme' (see Figure 4). In the 'Two Party Scheme', the QoS RRE
is authenticated by the NE and the authorization decision is made is authenticated by the NE and the authorization decision is made
either locally at the NE itself or offloaded to a trusted entity either locally at the NE itself or offloaded to a trusted entity
(most likely within the same administrative domain). In the two- (most likely within the same administrative domain). In the two-
party case no Diameter QoS protocol interaction is required. party case no Diameter QoS protocol interaction is REQUIRED.
+--------------+ +--------------+
| Entity | | Entity |
| authorizing | <......+ | authorizing | <......+
| resource | . | resource | .
| request | . | request | .
+------------+-+ . +------------+-+ .
--^----------|-- . . --^----------|-- . .
///// | | \\\\\ . ///// | | \\\\\ .
// | | \\ . // | | \\ .
skipping to change at page 15, line 47 skipping to change at page 15, line 47
of this interaction, authentication and authorization at the of this interaction, authentication and authorization at the
application layer might take place. As a result of a successful application layer might take place. As a result of a successful
authorization decision, which might involve the user's home AAA authorization decision, which might involve the user's home AAA
server, an authorization token is generated by the AE (e.g., the SIP server, an authorization token is generated by the AE (e.g., the SIP
proxy and an entity trusted by the SIP proxy) and returned to the end proxy and an entity trusted by the SIP proxy) and returned to the end
host for inclusion into the QoS signaling protocol. The host for inclusion into the QoS signaling protocol. The
authorization token will be used by a NE that receives the QoS authorization token will be used by a NE that receives the QoS
signaling message to authorize the QoS request. Alternatively, the signaling message to authorize the QoS request. Alternatively, the
Diameter QoS application will be used to forward the authorization Diameter QoS application will be used to forward the authorization
token to the user's home network. The authorization token allows the token to the user's home network. The authorization token allows the
authorization decision performed at the application layer protocol authorization decision performed at the application layer can be
run to be associated with a corresponding QoS signaling session. associated with a corresponding QoS signaling session. Note that the
Note that the authorization token might either refer to established authorization token might either refer to established state
state concerning the authorization decision or the token might itself concerning the authorization decision or the token might itself carry
carry the authorized parameters (protected by a digital signature or the authorized parameters (protected by a digital signature or a
a keyed message digest to prevent tampering). In the latter case the keyed message digest to prevent tampering). In the latter case the
authorization token may contain several pieces of information authorization token may contain several pieces of information
pertaining to the authorized application session, but at minimum it pertaining to the authorized application session, but at minimum it
should contain: should contain:
o An identifier for the AE (for example, an AppS) that issued the o An identifier for the AE (for example, an AppS) that issued the
authorization token authorization token
o An identifier referring to a specific application protocol session o An identifier referring to a specific application protocol session
for which the token was issued and for which the token was issued and
o A keyed message digest or digital signature protecting the content o A keyed message digest or digital signature protecting the content
of the authorization token of the authorization token
skipping to change at page 16, line 33 skipping to change at page 16, line 33
these port numbers are advertised). The QoS RRE may also use these these port numbers are advertised). The QoS RRE may also use these
port numbers in some IP filter indications to the NE performing QoS port numbers in some IP filter indications to the NE performing QoS
reservation so that it may properly tunnel the inbound packets. The reservation so that it may properly tunnel the inbound packets. The
NE performing QoS reservation will forward the QoS resource NE performing QoS reservation will forward the QoS resource
requesting entity's IP address and the IP filter indications to the requesting entity's IP address and the IP filter indications to the
AE in the QoS authorization request. The AE will use the QoS RRE's AE in the QoS authorization request. The AE will use the QoS RRE's
IP address and the port numbers in the IP filter indication, which IP address and the port numbers in the IP filter indication, which
will match the port numbers advertised in the earlier application will match the port numbers advertised in the earlier application
layer protocol interaction, to identify the right piece of policy layer protocol interaction, to identify the right piece of policy
information to be sent to the NE performing the QoS reservation in information to be sent to the NE performing the QoS reservation in
the QoS authz. response. the QoS Authorization. response.
3.3.2. Push Mode Schemes 3.3.2. Push Mode Schemes
The push mode can be further divided into two types: endpoint- The push mode can be further divided into two types: endpoint-
initiated and network-initiated. In the former case, the initiated and network-initiated. In the former case, the
authorization process is triggered by AppS in response to an explicit authorization process is triggered by AppS in response to an explicit
QoS request from an endpoint through application signaling, e.g. QoS request from an endpoint through application signaling, e.g.
SIP; in the latter case, the authorization process is triggered by SIP; in the latter case, the authorization process is triggered by
the AppS without an explicit QoS request from an endpoint. the AppS without an explicit QoS request from an endpoint.
skipping to change at page 18, line 11 skipping to change at page 18, line 11
QoS signaling protocols rather than introducing functional QoS signaling protocols rather than introducing functional
requirements on them. A list of requirements for a QoS authorization requirements on them. A list of requirements for a QoS authorization
application is provided here: application is provided here:
Inter-domain support Inter-domain support
In particular, users may roam outside their home network, leading In particular, users may roam outside their home network, leading
to a situation where the NE and AE are in different administrative to a situation where the NE and AE are in different administrative
domains. domains.
Identity-based Routing Identity-based Routing
The QoS AAA protocol MUST route AAA requests to the Authorizing The Diameter QoS application MUST route AAA requests to the
Entity, based on the provided identity of the QoS requesting Authorizing Entity, based on the provided identity of the QoS
entity or the identity of the AE encoded in the provided requesting entity or the identity of the AE encoded in the
authorization token. provided authorization token.
Flexible Authentication Support Flexible Authentication Support
The QoS AAA protocol MUST support a variety of different The Diameter QoS application MUST support a variety of different
authentication protocols for verification of authentication authentication protocols for verification of authentication
information present in QoS signaling messages. The support for information present in QoS signaling messages. The support for
these protocols MAY be provided indirectly by tying the signaling these protocols MAY be provided indirectly by tying the signaling
communication for QoS to a previous authentication protocol communication for QoS to a previous authentication protocol
exchange (e.g., using network access authentication). exchange (e.g., using network access authentication).
Making an Authorization Decision Making an Authorization Decision
The QoS AAA protocol MUST exchange sufficient information between The Diameter QoS application MUST exchange sufficient information
the AE and the enforcing entity (and vice versa) to compute an between the AE and the enforcing entity (and vice versa) to
authorization decision and to execute this decision. compute an authorization decision and to execute this decision.
Triggering an Authorization Process Triggering an Authorization Process
The QoS AAA protocol MUST allow periodic and event triggered The Diameter QoS application MUST allow periodic and event
execution of the authorization process, originated at the triggered execution of the authorization process, originated at
enforcing entity or even at the AE. the enforcing entity or even at the AE.
Associating QoS Reservations and Application State Associating QoS Reservations and Application State
The QoS AAA protocol MUST carry information sufficient for an AppS The Diameter QoS application MUST carry information sufficient for
to identify the appropriate application session and associate it an AppS to identify the appropriate application session and
with a particular QoS reservation. associate it with a particular QoS reservation.
Dynamic Authorization Dynamic Authorization
It MUST be possible for the QoS AAA protocol to push updates It MUST be possible for the Diameter QoS application to push
towards the NE(s) from authorizing entities. updates towards the NE(s) from authorizing entities.
Bearer Gating Bearer Gating
The QoS AAA protocol MUST allow the AE to gate (i.e., enable/ The Diameter QoS application MUST allow the AE to gate (i.e.,
disable) authorized application flows based on, e.g., application enable/disable) authorized application flows based on, e.g.,
state transitions. application state transitions.
Accounting Records Accounting Records
The QoS AAA protocol may define QoS accounting records containing The Diameter QoS application may define QoS accounting records
duration, volume (byte count) usage information and description of containing duration, volume (byte count) usage information and
the QoS attributes (e.g., bandwidth, delay, loss rate) that were description of the QoS attributes (e.g., bandwidth, delay, loss
supported for the flow. rate) that were supported for the flow.
Sending Accounting Records Sending Accounting Records
The NE SHOULD be able to send accounting records for a particular The NE SHOULD be able to send accounting records for a particular
QoS reservation state to an accounting entity. QoS reservation state to an accounting entity.
Failure Notification Failure Notification
The QoS AAA protocol MUST allow the NE to report failures, such as The Diameter QoS application MUST allow the NE to report failures,
loss of connectivity due to movement of a mobile node or other such as loss of connectivity due to movement of a mobile node or
reasons for packet loss, to the authorizing entity. other reasons for packet loss, to the authorizing entity.
Accounting Correlation Accounting Correlation
The QoS AAA protocol may support the exchange of sufficient The Diameter QoS application may support the exchange of
information to allow for correlation between accounting records sufficient information to allow for correlation between accounting
generated by the NEs and accounting records generated by an AppS. records generated by the NEs and accounting records generated by
an AppS.
Interaction with other AAA Applications Interaction with other AAA Applications
Interaction with other AAA applications such as Diameter Network Interaction with other AAA applications such as Diameter Network
Access (NASREQ) application [RFC4005] is required for exchange of Access (NASREQ) application [RFC4005] is required for exchange of
authorization, authentication and accounting information. authorization, authentication and accounting information.
In deployment scenarios where authentication of the QoS reservation In deployment scenarios where authentication of the QoS reservation
requesting entity (e.g., the user) is done by means outside the requesting entity (e.g., the user) is done by means outside the
Diameter QoS application protocol interaction, the AE is contacted Diameter QoS application protocol interaction, the AE is contacted
only with a request for QoS authorization. Authentication might have only with a request for QoS authorization. Authentication might have
taken place already via the interaction with the Diameter NASREQ taken place already via the interaction with the Diameter NASREQ
application or as part of the QoS signaling protocol (e.g., Transport application or as part of the QoS signaling protocol (e.g., Transport
Layer Security (TLS) [RFC4346] in the General Internet Signaling Layer Security (TLS) [RFC5246] in the General Internet Signaling
Transport (GIST) protocol [I-D.ietf-nsis-ntlp]). Transport (GIST) protocol [I-D.ietf-nsis-ntlp]).
Authentication of the QoS reservation requesting entity to the AE is Authentication of the QoS reservation requesting entity to the AE is
necessary if a particular Diameter QoS application protocol run necessary if a particular Diameter QoS application protocol cannot be
cannot be related (or if there is no intention to relate it) to a related (or if there is no intention to relate it) to a prior
prior authentication. In this case the AE MUST authenticate the QoS authentication. In this case the AE MUST authenticate the QoS
reservation requesting entity in order to authorize the QoS request reservation requesting entity in order to authorize the QoS request
as part of the Diameter QoS protocol interaction. as part of the Diameter QoS protocol interaction.
The document refers to three types of sessions that need to be The document refers to three types of sessions that need to be
properly correlated. properly correlated.
QoS Signaling Session QoS Signaling Session
The time period during which a QoS signaling protocol establishes, The time period during which a QoS signaling protocol establishes,
maintains and deletes a QoS reservation state at the QoS network maintains and deletes a QoS reservation state at the QoS network
element is referred to as QoS signaling session. Different QoS element is referred to as QoS signaling session. Different QoS
skipping to change at page 21, line 38 skipping to change at page 21, line 38
or a link layer signaling protocol. A description of these protocols or a link layer signaling protocol. A description of these protocols
is also outside the scope of this document. is also outside the scope of this document.
4.2. Session Establishment 4.2. Session Establishment
The Pull and Push modes use a different set of command codes for The Pull and Push modes use a different set of command codes for
session establishment. For other operations, such as session session establishment. For other operations, such as session
modification and termination, they use the same set of command codes. modification and termination, they use the same set of command codes.
The selection of Pull mode or Push mode operation is based on the The selection of Pull mode or Push mode operation is based on the
trigger of the QoS Authorization session. When a QoS-Authz-Request trigger of the QoS Authorization session. When a QoS-Authorization-
(QAR, see Section 5.1) message with a new session ID is received, the Request (QAR, see Section 5.1) message with a new session ID is
AE operates in the Pull mode; when other triggers are received, the received, the AE operates in the Pull mode; when other triggers are
AE operates in the Push mode. Similarly, when a QoS-Install-Request received, the AE operates in the Push mode. Similarly, when a QoS-
(QIR, see Section 5.3} with a new session ID is received, the NE Install-Request (QIR, see Section 5.3} with a new session ID is
operates in the Push mode; when other triggers are received, the NE received, the NE operates in the Push mode; when other triggers are
operation in the Pull mode. received, the NE operation in the Pull mode.
The QoS authorization session is typically established per subscriber
base (i.e.all requests with the same user ID), but it is also
possible to be established on per node or per request base. The
concurrent sessions between an NE and an AE are identified by
different Session-ID.
4.2.1. Session Establishment for Pull Mode 4.2.1. Session Establishment for Pull Mode
A request for a QoS reservation or local events received by a NE can A request for a QoS reservation or local events received by a NE can
trigger the initiation of a Diameter QoS authorization session. The trigger the initiation of a Diameter QoS authorization session. The
NE generates a QAR message in which the required objects from the QoS NE converts the required objects from the QoS signaling message to
signaling message that is converted to Diameter AVPs. Diameter AVPs and generates a QAR message.
Figure 6 shows the protocol interaction between a Resource Requesting Figure 6 shows the protocol interaction between a Resource Requesting
Entity, a Network Element and the Authorizing Entity. Entity, a Network Element and the Authorizing Entity.
The AE's identity, information about the application session and/or The AE's identity, information about the application session and/or
identity and credentials of the QoS RRE, requested QoS parameters, identity and credentials of the QoS RRE, requested QoS parameters,
signaling session identifier and/or QoS enabled data flows signaling session identifier and/or QoS enabled data flows
identifiers MAY be encapsulated into respective Diameter AVPs and identifiers MAY be encapsulated into respective Diameter AVPs and
included in the Diameter message sent to the AE. The QAR is sent to included in the Diameter message sent to the AE. The QAR is sent to
a Diameter server that can either be the home server of the QoS a Diameter server that can either be the home server of the QoS
requesting entity or an AppS. requesting entity or an AppS.
+-----------------------------------------------+-------------------+ +------------------------------------------+------------------------+
| QoS-specific Input Data | Diameter AVPs | | QoS-specific Input Data | Diameter AVPs |
+-----------------------------------------------+-------------------+ +------------------------------------------+------------------------+
| Authorizing entity ID (e.g., Destination-Host | Destination-Host | | Authorizing entity ID (e.g., | Destination-Host |
| taken from authorization token, | Destination-Realm | | Destination-Host taken from | Destination-Realm |
| Destination-Realm or derived from the NAI of | | | authorization token, Destination-Realm | |
| the QoS requesting entity) | | | or derived from the NAI of the QoS | |
| requesting entity) | |
| | | | | |
| Authorization Token Credentials of the QoS | QoS-Authz-Data | | Authorization Token Credentials of the | QoS-Authorization-Data |
| requesting entity | User-Name | | QoS requesting entity | User-Name |
| | | | | |
| QoS parameters | QoS-Resources | | QoS parameters | QoS-Resources |
+-----------------------------------------------+-------------------+ +------------------------------------------+------------------------+
Table 1: Mapping Input Data to QoS AVPs--Pull Mode Table 1: Mapping Input Data to QoS AVPs--Pull Mode
Authorization processing starts at the Diameter QoS server when it Authorization processing starts at the Diameter QoS server when it
receives the QAR. Based on the information in the QoS- receives the QAR. Based on the information in the QoS-
Authentication-Data, User-Name and QoS-Resources AVPs the server Authentication-Data, User-Name and QoS-Resources AVPs the server
determines the authorized QoS resources and flow state (enabled/ determines the authorized QoS resources and flow state (enabled/
disabled) from locally available information (e.g., policy disabled) from locally available information (e.g., policy
information that may be previously established as part of an information that may be previously established as part of an
application layer signaling exchange, or the user's subscription application layer signaling exchange, or the user's subscription
skipping to change at page 25, line 26 skipping to change at page 25, line 26
should be contacted and the data flow for which the QoS reservation should be contacted and the data flow for which the QoS reservation
should be established. This information can be statically configured should be established. This information can be statically configured
or dynamically discovered, see Section 4.2.3 for details. or dynamically discovered, see Section 4.2.3 for details.
+-----------------------------------------+-------------------------+ +-----------------------------------------+-------------------------+
| QoS-specific Input Data | Diameter AVPs | | QoS-specific Input Data | Diameter AVPs |
+-----------------------------------------+-------------------------+ +-----------------------------------------+-------------------------+
| Network Element ID | Destination-Host | | Network Element ID | Destination-Host |
| | Destination-Realm | | | Destination-Realm |
| | | | | |
| Authorization Token Credentials of the | QoS-Authz-Data | | Authorization Token Credentials of the | QoS-Authorization-Data |
| QoS requesting entity | User-Name | | QoS requesting entity | User-Name |
| | | | | |
| QoS parameters | QoS-Resources | | QoS parameters | QoS-Resources |
+-----------------------------------------+-------------------------+ +-----------------------------------------+-------------------------+
Table 2: Mapping Input Data to QoS AVPs--Push Mode Table 2: Mapping Input Data to QoS AVPs--Push Mode
Authorization processing starts at the Diameter QoS server when it Authorization processing starts at the Diameter QoS server when it
receives a request from a RRE through an AppS (e.g., SIP Invite) or receives a request from a RRE through an AppS (e.g., SIP Invite) or
is triggered by a local event (e.g., pre-configured timer). Based on is triggered by a local event (e.g., pre-configured timer). Based on
skipping to change at page 27, line 27 skipping to change at page 27, line 27
For an extension of the authorization period, a new QoS-Install- For an extension of the authorization period, a new QoS-Install-
Request/Answer message or QoS-Authorization-Request/Answer message Request/Answer message or QoS-Authorization-Request/Answer message
exchange SHOULD be initiated. Further aspects of QoS authorization exchange SHOULD be initiated. Further aspects of QoS authorization
session maintenance is discussed in Section 4.3, Section 4.4 and session maintenance is discussed in Section 4.3, Section 4.4 and
Section 8. Section 8.
The indication of QoS reservation and activation of the data flow can The indication of QoS reservation and activation of the data flow can
be provided by the QoS-Install-Answer message immediately. In the be provided by the QoS-Install-Answer message immediately. In the
case of successful enforcement, the Result-Code (= DIAMETER_SUCCESS, case of successful enforcement, the Result-Code (= DIAMETER_SUCCESS,
(see Section 7.1)) information is provided in the QIA message. Note (see Section 7.1)) information is provided in the QIA message. Note
that the reserved QoS resources reported in the QIA message MAY be that the reserved QoS resources reported in the QIA message may be
different than those initially authorized with the QIR message, due different than those initially authorized with the QIR message, due
to the QoS signaling specific behavior (e.g., receiver-initiated to the QoS signaling specific behavior (e.g., receiver-initiated
reservations with One-Path-With-Advertisements) or specific process reservations with One-Path-With-Advertisements) or specific process
of QoS negotiation along the data path. When path coupled signaling of QoS negotiation along the data path. When path coupled signaling
is used for QoS reservation along the data path, QAR/QAA may be used is used for QoS reservation along the data path, QAR/QAA MAY be used
to update the results of QoS reservation and enforcement following to update the results of QoS reservation and enforcement following
the establishment of data flows. the establishment of data flows. In the case Multiple AEs control
the same NE, the NE should make the selection on the authorization
decision to be enforced based on the priority of the request.
4.2.3. Discovery and Selection of Peer Diameter QoS Application Node 4.2.3. Discovery and Selection of Peer Diameter QoS Application Node
Discovery of Diameter QoS application nodes Discovery of Diameter QoS application nodes
The Diameter QoS application node may obtain information of its peer The Diameter QoS application node may obtain information of its peer
nodes (e.g., FQDN, IP address) through static configuration or nodes (e.g., FQDN, IP address) through static configuration or
dynamic discovery as described in [RFC3588]. In particular, the NE dynamic discovery as described in [RFC3588]. In particular, the NE
shall perform the relevant operation for Pull mode; the AE shall shall perform the relevant operation for Pull mode; the AE shall
perform the relevant operations for Push mode. perform the relevant operations for Push mode.
Selection of peer Diameter QoS application node Selection of peer Diameter QoS application node
Upon receipt of a trigger to initiate a new Diameter QoS Upon receipt of a trigger to initiate a new Diameter QoS
authorization session, the Diameter QoS application node selects and authorization session, the Diameter QoS application node selects and
retrieves the location information of the peer node and based on some retrieves the location information of the peer node and based on some
index information provided by the RRE. For instance, it can be the index information provided by the RRE. For instance, it can be the
Authorization Entity's ID stored in the authorization token, the end- Authorization Entity's ID stored in the authorization token, the end-
user's identity (e.g., NAI [RFC4282]) or globally routable IP user's identity (e.g., NAI [RFC4282]) or a globally routable IP
address. address.
4.3. Session Re-authorization 4.3. Session Re-authorization
Client and server-side initiated re-authorizations are considered in Client and server-side initiated re-authorizations are considered in
the design of the Diameter QoS application. Whether the re- the design of the Diameter QoS application. Whether the re-
authorization events are transparent for the resource requesting authorization events are transparent for the resource requesting
entity or result in specific actions in the QoS signaling protocol is entity or result in specific actions in the QoS signaling protocol is
outside the scope of the Diameter QoS application. It is directly outside the scope of the Diameter QoS application. It is directly
dependent on the capabilities of the QoS signaling protocol. dependent on the capabilities of the QoS signaling protocol.
skipping to change at page 34, line 13 skipping to change at page 34, line 13
Figure 11: Server-Side Initiated Session Termination Figure 11: Server-Side Initiated Session Termination
5. QoS Application Messages 5. QoS Application Messages
The Diameter QoS Application requires the definition of new mandatory The Diameter QoS Application requires the definition of new mandatory
AVPs and Command-codes (see Section 3 of [RFC3588]). Four new AVPs and Command-codes (see Section 3 of [RFC3588]). Four new
Diameter messages are defined along with Command-Codes whose values Diameter messages are defined along with Command-Codes whose values
MUST be supported by all Diameter implementations that conform to MUST be supported by all Diameter implementations that conform to
this specification. this specification.
+---------------------+---------+--------+-------------+ +---------------------------+---------+--------+-------------+
| Command Name | Abbrev. | Code | Reference | | Command Name | Abbrev. | Code | Reference |
+---------------------+---------+--------+-------------+ +---------------------------+---------+--------+-------------+
| QoS-Authz-Request | QAR | [TBD1] | Section 5.1 | | QoS-Authorization-Request | QAR | [TBD1] | Section 5.1 |
| | | | | | | | | |
| QoS-Authz-Answer | QAA | [TBD2] | Section 5.2 | | QoS-Authorization-Answer | QAA | [TBD2] | Section 5.2 |
| | | | | | | | | |
| QoS-Install-Request | QIR | [TBD3] | Section 5.3 | | QoS-Install-Request | QIR | [TBD3] | Section 5.3 |
| | | | | | | | | |
| QoS-Install-Answer | QIA | [TBD4] | Section 5.4 | | QoS-Install-Answer | QIA | [TBD4] | Section 5.4 |
+---------------------+---------+--------+-------------+ +---------------------------+---------+--------+-------------+
Table 3: Diameter QoS Commands Table 3: Diameter QoS Commands
In addition, the following Diameter Base protocol messages are used In addition, the following Diameter Base protocol messages are used
in the Diameter QoS application: in the Diameter QoS application:
+-----------------------+---------+------+-----------+ +-----------------------+---------+------+-----------+
| Command-Name | Abbrev. | Code | Reference | | Command-Name | Abbrev. | Code | Reference |
+-----------------------+---------+------+-----------+ +-----------------------+---------+------+-----------+
| Re-Auth-Request | RAR | 258 | [RFC3588] | | Re-Auth-Request | RAR | 258 | [RFC3588] |
skipping to change at page 34, line 49 skipping to change at page 34, line 49
| Abort-Session-Answer | ASA | 274 | [RFC3588] | | Abort-Session-Answer | ASA | 274 | [RFC3588] |
| | | | | | | | | |
| Session-Term-Request | STR | 275 | [RFC3588] | | Session-Term-Request | STR | 275 | [RFC3588] |
| | | | | | | | | |
| Session-Term-Answer | STA | 275 | [RFC3588] | | Session-Term-Answer | STA | 275 | [RFC3588] |
+-----------------------+---------+------+-----------+ +-----------------------+---------+------+-----------+
Table 4: Diameter Base Commands Table 4: Diameter Base Commands
Diameter nodes conforming to this specification MAY advertise support Diameter nodes conforming to this specification MAY advertise support
by including the value of [TBD5] in the Auth-Application-Id or the for the Diameter QoS Application by including the value of [TBD5] in
Acct-Application-Id AVP of the Capabilities-Exchange-Request and the Auth-Application-Id or the Acct-Application-Id AVP of the
Capabilities-Exchange-Answer commands, see [RFC3588]. Capabilities-Exchange-Request and Capabilities-Exchange-Answer
commands, see [RFC3588].
The value of {TBD5] MUST be used as the Application-Id in all QAR/QAA The value of {TBD5] MUST be used as the Application-Id in all QAR/QAA
and QIR/QIA commands. and QIR/QIA commands.
The value of zero (0) SHOULD be used as the Application-Id in all The value of zero (0) SHOULD be used as the Application-Id in all
STR/STA, ASR/ASA, and RAR/RAA commands, because these commands are STR/STA, ASR/ASA, and RAR/RAA commands, because these commands are
defined in the Diameter base protocol and no additional mandatory defined in the Diameter base protocol and no additional mandatory
AVPs for those commands are defined in this document. AVPs for those commands are defined in this document.
5.1. QoS-Authorization Request (QAR) 5.1. QoS-Authorization Request (QAR)
skipping to change at page 35, line 39 skipping to change at page 35, line 39
<QoS-Request> ::= < Diameter Header: [TBD1], REQ, PXY > <QoS-Request> ::= < Diameter Header: [TBD1], REQ, PXY >
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Auth-Application-Id }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Auth-Request-Type } { Auth-Request-Type }
[ Destination-Host ] [ Destination-Host ]
[ User-Name ] [ User-Name ]
* [ QoS-Resources ] * [ QoS-Resources ]
[ QoS-Authz-Data ] [ QoS-Authorization-Data ]
[ Bound-Auth-Session-Id ] [ Bound-Auth-Session-Id ]
* [ AVP ] * [ AVP ]
5.2. QoS-Authorization Answer (QAA) 5.2. QoS-Authorization Answer (QAA)
The QoS-Authorization-Answer message (QAA), indicated by the Command- The QoS-Authorization-Answer message (QAA), indicated by the Command-
Code field set to [TBD2] and 'R' bit cleared in the Command Flags Code field set to [TBD2] and 'R' bit cleared in the Command Flags
field is sent in response to the QoS-Authorization-Request message field is sent in response to the QoS-Authorization-Request message
(QAR). If the QoS authorization request is successfully authorized, (QAR). If the QoS authorization request is successfully authorized,
the response will include the AVPs to allow authorization of the QoS the response will include the AVPs to allow authorization of the QoS
skipping to change at page 39, line 16 skipping to change at page 39, line 16
The QoS application defines its own state machine that is based on The QoS application defines its own state machine that is based on
the authorization state machine defined in Section 8.1 of the Base the authorization state machine defined in Section 8.1 of the Base
Protocol ([RFC3588]). The Qos state machine uses own messages as Protocol ([RFC3588]). The Qos state machine uses own messages as
defined in Section 5 and QoS AVPs as defined in Section 7. defined in Section 5 and QoS AVPs as defined in Section 7.
6.1. Supplemented States for Push Mode 6.1. Supplemented States for Push Mode
Using the Base Protocol state machine as a basis, the following Using the Base Protocol state machine as a basis, the following
states are supplemented to first 2 state machines in which the states are supplemented to first 2 state machines in which the
session state is maintained on the Server. This MUST be supported in session state is maintained on the Server. Thses MUST be supported
any QoS application implementations in support of server initiated in any QoS application implementations in support of server initiated
push mode (see (Section 4.2.2)). push mode (see (Section 4.2.2)).
The following states are supplemented to the state machine on the The following states are supplemented to the state machine on the
client when state is maintained on the client as defined in Section client when state is maintained on the client as defined in Section
8.1 of the Base Protocol [RFC3588]: 8.1 of the Base Protocol [RFC3588]:
SERVER, STATEFUL SERVER, STATEFUL
State Event Action New State State Event Action New State
------------------------------------------------------------- -------------------------------------------------------------
Idle An application or local Send Pending Idle An application or local Send Pending
skipping to change at page 42, line 11 skipping to change at page 42, line 11
The following table describes the Diameter AVPs newly defined in this The following table describes the Diameter AVPs newly defined in this
document for usage with the QoS Application, their AVP code values, document for usage with the QoS Application, their AVP code values,
types, possible flag values, and whether the AVP may be encrypted. types, possible flag values, and whether the AVP may be encrypted.
+-------------------+ +-------------------+
| AVP Flag rules | | AVP Flag rules |
+----------------------------------------------|----+--------+-----+ +----------------------------------------------|----+--------+-----+
| AVP Section | | SHLD| MUST| | AVP Section | | SHLD| MUST|
| Attribute Name Code Defined Data Type |MUST| NOT| NOT| | Attribute Name Code Defined Data Type |MUST| NOT| NOT|
+----------------------------------------------+----+--------+-----+ +----------------------------------------------+----+--------+-----+
|QoS-Authorization-Data TBD 7.2 Grouped | M | | V | |QoS-Authorization-Data TBD 7.2 OctetString| M | | V |
|Bound-Auth-Session-Id TBD 7.2 UTF8String | M | | V | |Bound-Auth-Session-Id TBD 7.2 UTF8String | M | | V |
+----------------------------------------------+----+--------+-----+ +----------------------------------------------+----+--------+-----+
|M - Mandatory bit. An AVP with "M" bit set and its value MUST be | |M - Mandatory bit. An AVP with "M" bit set and its value MUST be |
| supported and recognized by a Diameter entity in order the | | supported and recognized by a Diameter entity in order the |
| message, which carries this AVP, to be accepted. | | message, which carries this AVP, to be accepted. |
|V - Vendor specific bit that indicates whether the AVP belongs to | |V - Vendor specific bit that indicates whether the AVP belongs to |
| a address space. | | a address space. |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
QoS-Authz-Data QoS-Authz-Data
skipping to change at page 43, line 7 skipping to change at page 43, line 7
The Bound-Authentication-Session AVP (AVP Code TBD) is of type The Bound-Authentication-Session AVP (AVP Code TBD) is of type
UTF8String. It carries the id of the Diameter authentication UTF8String. It carries the id of the Diameter authentication
session that is used for the network access authentication (NASREQ session that is used for the network access authentication (NASREQ
authentication session). It is used to tie the QoS authorization authentication session). It is used to tie the QoS authorization
request to a prior authentication of the end host done by a co- request to a prior authentication of the end host done by a co-
located application for network access authentication (Diameter located application for network access authentication (Diameter
NASREQ) at the QoS NE. NASREQ) at the QoS NE.
8. Accounting 8. Accounting
A NE may start an accounting session by sending an Accounting-Request A NE MAY start an accounting session by sending an Accounting-Request
message (ACR) after successful QoS reservation and activation of the message (ACR) after successful QoS reservation and activation of the
data flow (see Figure 6 and Figure 7). After every successful re- data flow (see Figure 6 and Figure 7). After every successful re-
authorization procedure (see Figure 8 and Figure 9), the NE may authorization procedure (see Figure 8 and Figure 9), the NE MAY
initiate an interim accounting message exchange. After successful initiate an interim accounting message exchange. After successful
session termination (see Figure 10 and Figure 11), the NE may session termination (see Figure 10 and Figure 11), the NE may
initiate a final exchange of accounting messages for terminating of initiate a final exchange of accounting messages for terminating of
the accounting session and reporting final records for the usage of the accounting session and reporting final records for the usage of
the QoS resources reserved. It should be noted that the two sessions the QoS resources reserved. It should be noted that the two sessions
(authorization and accounting) have independent management by the (authorization and accounting) have independent management by the
Diameter base protocol, which allows for finalizing the accounting Diameter base protocol, which allows for finalizing the accounting
session after the end of the authorization session. session after the end of the authorization session.
The detailed QoS accounting procedures are out of scope in this The detailed QoS accounting procedures are out of scope in this
skipping to change at page 51, line 37 skipping to change at page 51, line 37
sender by the Network Element would be that an attacker could spoof sender by the Network Element would be that an attacker could spoof
the identity of a "legitimate" Authorizing Entity in order to the identity of a "legitimate" Authorizing Entity in order to
allocate resources, change resource assignments or free resources. allocate resources, change resource assignments or free resources.
The adversary can also manipulate the state at the Network Element in The adversary can also manipulate the state at the Network Element in
such a way that it leads to a denial of service attack by, for such a way that it leads to a denial of service attack by, for
example, setting the allowed bandwidth to zero or allocating the example, setting the allowed bandwidth to zero or allocating the
entire bandwidth available to a single flow. entire bandwidth available to a single flow.
A consequence of not authenticating the Network Element to an A consequence of not authenticating the Network Element to an
Authorizing Entity is that an attacker could impact the policy based Authorizing Entity is that an attacker could impact the policy based
admission control procedure run by the Authorizing Entity to provide admission control procedure operated by the Authorizing Entity that
a wrong view of the resources used in the network. Failing to provides a wrong view of the resources used in the network. Failing
provide the required credentials should be subject to logging. to provide the required credentials should be subject to logging.
Authorization refers to whether a particular Authorizing Entity is Authorization refers to whether a particular Authorizing Entity is
authorized to signal a Network Element with requests for one or more authorized to signal a Network Element with requests for one or more
applications, adhering to a certain policy profile. Failing the applications, adhering to a certain policy profile. Failing the
authorization process might indicate a resource theft attempt or authorization process might indicate a resource theft attempt or
failure due to administrative and/or credential deficiencies. In failure due to administrative and/or credential deficiencies. In
either case, the Network Element should take the proper measures to either case, the Network Element should take the proper measures to
log such attempts. log such attempts.
Integrity is required to ensure that a Diameter message has not been Integrity is required to ensure that a Diameter message has not been
skipping to change at page 52, line 14 skipping to change at page 52, line 14
Authorizing Entity potentially causing a denial of service. Authorizing Entity potentially causing a denial of service.
Confidentiality protection of Diameter messages ensures that the Confidentiality protection of Diameter messages ensures that the
signaling data is accessible only to the authorized entities. When signaling data is accessible only to the authorized entities. When
signaling messages from the Application Server, via the Authorizing signaling messages from the Application Server, via the Authorizing
Entity towards the Network Element traverse untrusted networks, lack Entity towards the Network Element traverse untrusted networks, lack
of confidentiality will allow eavesdropping and traffic analysis. of confidentiality will allow eavesdropping and traffic analysis.
Additionally, Diamater QoS messages may carry authorization tokens Additionally, Diamater QoS messages may carry authorization tokens
that require confidentiality protection. that require confidentiality protection.
Lastly, there can be security vulnerability to the applications
traversing a Network Element when a resource on a Network Element is
controlled by multiple Authorizing Entities. The operation of a
Network Element may be disrupted due to conflicting directives from
multiple Authorizing Entities. Care must be taken in deployment to
ensure that Network Elements are impacted by misconfiguration.
Diameter offers security mechanisms to deal with the functionality Diameter offers security mechanisms to deal with the functionality
demanded in the paragraphs above. In particular, Diameter offers demanded in the paragraphs above. In particular, Diameter offers
communication security between neighboring Diameter peers using communication security between neighboring Diameter peers using
Transport Layer Security (TLS) or IPsec. Authorization capabilities Transport Layer Security (TLS) or IPsec. Authorization capabilities
are application specific and part of the overal implementation. are application specific and part of the overal implementation.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank John Loughney and Allison Mankin for The authors would like to thank John Loughney and Allison Mankin for
their input to this document. In September 2005 Robert Hancock, their input to this document. In September 2005 Robert Hancock,
skipping to change at page 55, line 12 skipping to change at page 55, line 12
your significant draft contributions and for being the driving force your significant draft contributions and for being the driving force
for the first few draft versions. for the first few draft versions.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-dime-qos-attributes] [I-D.ietf-dime-qos-attributes]
Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
and A. Lior, "Quality of Service Attributes for Diameter", and A. Lior, "Quality of Service Attributes for Diameter",
draft-ietf-dime-qos-attributes-12 (work in progress), draft-ietf-dime-qos-attributes-13 (work in progress),
June 2009. July 2009.
[I-D.ietf-dime-qos-parameters] [I-D.ietf-dime-qos-parameters]
Korhonen, J., Tschofenig, H., and E. Davies, "Quality of Korhonen, J., Tschofenig, H., and E. Davies, "Quality of
Service Parameters for Usage with Diameter", Service Parameters for Usage with Diameter",
draft-ietf-dime-qos-parameters-11 (work in progress), draft-ietf-dime-qos-parameters-11 (work in progress),
May 2009. May 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 56, line 42 skipping to change at page 56, line 42
"Session Authorization Policy Element", RFC 3520, "Session Authorization Policy Element", RFC 3520,
April 2003. April 2003.
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for
Session Set-up with Media Authorization", RFC 3521, Session Set-up with Media Authorization", RFC 3521,
April 2003. April 2003.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Authors' Addresses Authors' Addresses
Dong Sun (editor) Dong Sun (editor)
Alcatel-Lucent Alcatel-Lucent
600 Mountain Ave 600 Mountain Ave
Murray Hill, NJ 07974 Murray Hill, NJ 07974
USA USA
Phone: +1 908 582 2617 Phone: +1 908 582 2617
Email: dongsun@alcatel-lucent.com Email: dongsun@alcatel-lucent.com
 End of changes. 49 change blocks. 
105 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/