Authentication, Authorization and F. Alfano
Accounting P. McCann
Internet-Draft Lucent Technologies
Expires: April 23, 2005 H. Tschofenig
Siemens
October 23, 2004
Diameter Quality of Service Application
draft-alfano-aaa-qosprot-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 April 23, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes a Diameter Application that performs
Authentication, Authorization, and Accounting for Quality-of-Service
reservations. This protocol is used by elements along the path of a
given application flow to authenticate a reservation request, ensure
that the reservation is authorized, and to account for resources used
Alfano, et al. Expires April 23, 2005 [Page 1]
Internet-Draft Diameter Quality of Service Application October 2004
during the life of the application flow. Clients that implement the
Diameter QoS Application contact an authorizing entity/application
server that lies anywhere in the network, allowing for a wide variety
of flexible service deployment models.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Deployment architecture . . . . . . . . . . . . . . . . . 4
1.2 Network element functional model . . . . . . . . . . . . . 5
1.3 Requirements for QoS AAA protocol . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. QoS Application messages . . . . . . . . . . . . . . . . . . . 10
4. QoS Authorization session . . . . . . . . . . . . . . . . . . 11
4.1 Authorization models . . . . . . . . . . . . . . . . . . . 11
4.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 12
4.3 Session Establishment . . . . . . . . . . . . . . . . . . 13
4.4 QoS Re-Authorization . . . . . . . . . . . . . . . . . . . 13
4.4.1 Client-side initiated Re-Authorization . . . . . . . . 13
4.4.2 Server-side initiated Re-Authorization . . . . . . . . 13
4.5 Session Termination . . . . . . . . . . . . . . . . . . . 13
4.5.1 Client-side initiated session termination . . . . . . 14
4.5.2 Server-side initiated session termination . . . . . . 14
5. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Diameter QoS Messages . . . . . . . . . . . . . . . . . . . . 16
6.1 QoS-Request (QAR) Command . . . . . . . . . . . . . . . . 16
6.2 QoS-Answer (QAA) Command . . . . . . . . . . . . . . . . . 16
7. Diameter QoS AVPs . . . . . . . . . . . . . . . . . . . . . . 18
7.1 Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 18
7.2 Credit Control . . . . . . . . . . . . . . . . . . . . . . 18
7.3 Authentication/Authorization . . . . . . . . . . . . . . . 19
7.4 Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 19
7.5 Diameter QoS Application Defined AVPs . . . . . . . . . . 19
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1 Normative References . . . . . . . . . . . . . . . . . . . . 30
13.2 Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
A. AVP Formats . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.1 NSIS to Diameter QoS AVPs Mapping . . . . . . . . . . . . 33
A.1.1 NSIS QSpecs Template structure . . . . . . . . . . . . 33
A.1.2 AVP format . . . . . . . . . . . . . . . . . . . . . . 34
A.2 SIP to Diameter QoS AVPs Mapping . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . 38
Alfano, et al. Expires April 23, 2005 [Page 2]
Internet-Draft Diameter Quality of Service Application October 2004
1. Introduction
To meet the quality-of-service needs of applications such as
voice-over-IP in a heavily loaded network, packets belonging to
real-time application flows must be identified and segregated from
other traffic to ensure that bandwidth, delay, and loss rate
requirements are met. In addition, new flows should not be added to
the network when it is at or near capacity, which would result in
degradation of quality for all flows carried by the network.
In some cases, these goals can be achieved with mechanisms such as
differentiated services and/or end-to-end congestion and admission
control. However, when bandwidth is scarce and must be carefully
managed, such as in wide-area cellular networks, or when applications
and transport protocols lack the capability to perform end-to-end
congestion control, explicit reservation techniques are required. In
these cases, the endpoints will send reservation requests to edge
and/or interior nodes along the communication path. In addition to
verifying whether resources are available, the recipient of a
reservation request must also authenticate and authorize the request,
especially in an environment where the endpoints are not trusted. In
addition, these nodes will generate accounting information about the
resources used and attribute usage to the requesting endpoints. This
will enable the owner of the network element to generate
usage-sensitive billing records and to understand how to allocate new
network capacity.
A variety of protocols could be used to make a reservation request,
including RSVP [RFC2210], NSIS [I-D.ietf-nsis-qos-nslp],
link-specific messaging or even SIP/SDP [RFC2327]. This document
focuses on supporting the NSIS QoS NSLP. This will have an
implication on the content and format of the flow identifiers and QoS
attributes that represent a particular reservation request within the
Diameter QoS Application; however, other aspects of its operation
should be easily generalizable to other reservation protocols. The
Diameter QoS Application could be used directly in the context of
these other reservation protocols, given the definition of a suitable
conversion between the representations used by those protocols and
the ones used by NSIS.
The Diameter QoS Application runs between a network element receiving
QoS reservation requests (acting as a AAA client) and the resource
authorizing entity (acting as a AAA server). A high-level picture of
the resulting architecture is shown in Figure 1.
Alfano, et al. Expires April 23, 2005 [Page 3]
Internet-Draft Diameter Quality of Service Application October 2004
+-------------+
| Resource |
| Authorizing |
| Entity |
+-----+-------+
|
|
/\-----+-----/\
//// \\\\
|| ||
| AAA Cloud |
|| ||
\\\\ ////
\-------+-----/
|
+---+--+ +---+--+ +---+--+
Application | | | | | |
===============+ NE +===+ NE +===+ NE +========>>
Flow | | | | | |
+------+ +------+ +------+
Figure 1: An Architecture supporting QoS-AAA
1.1 Deployment architecture
Figure 1 depicts network elements through which application flows
need to pass, a cloud of AAA servers, and an authorizing entity.
Note that there may be more than one router that needs to interact
with the AAA cloud along the path of a given application flow,
although the figure only depicts one for clarity. Routers will
request authorization for QoS from the AAA cloud, which will route
the request to the home network where the home authorizing entity
will return a grant/deny decision.
In more complex deployment models, the authorization will be based on
dynamic application state, so the request must be authenticated and
authorized based on information from one or more application servers.
If defined properly, the interface between the routers and AAA cloud
would be identical in both cases. Routers are therefore insulated
from the details of particular applications and need not know that
application servers are involved at all. Also, the AAA cloud would
naturally encompass business relationships such as those between
network operators and third-party application providers, enabling
flexible intra- or inter-domain authorization, accounting, and
settlement.
Alfano, et al. Expires April 23, 2005 [Page 4]
Internet-Draft Diameter Quality of Service Application October 2004
1.2 Network element functional model
Figure 2 depicts a logical operational model of resource management
in a router.
+-----------------------------------------------------+
| DIAMETER Client |
| Functionality |
| +---------------++---------------++---------------+ |
| | User || Authorization || Accounting | |
| | Authentication|| of QoS || for QoS | |
| +---------------+| Requests || Traffic | |
| +---------------++---------------+ |
+-----------------------------------------------------+
^ ^
v v
+--------------+ +----------+
|QoS Signaling | | Resource |
|Msg Processing|<<<<<>>>>>>>|Management|
+--------------+ +----------+
. ^ | * ^
| v . * ^
+-------------+ * ^
|Signaling msg| * ^
| Processing | * V
+-------------+ * V
| | * V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . * V
| | * .............................
. . * . Traffic Control .
| | * . +---------+.
. . * . |Admission|.
| | * . | Control |.
+----------+ +------------+ . +---------+.
<-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
| Packet | | Interface | .+----------+ +---------+.
===>|Processing|====| Selection |===.| Packet |====| Packet |.=>
| | |(Forwarding)| .|Classifier| Scheduler|.
+----------+ +------------+ .+----------+ +---------+.
.............................
<.-.-> = signaling flow
=====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations
****** = routing table manipulation
Figure 2: Network element functional model
Alfano, et al. Expires April 23, 2005 [Page 5]
Internet-Draft Diameter Quality of Service Application October 2004
Processing of incoming QoS reservation requests include 3 actions:
admission control, authorization and resource reservation.
Admission control local function provides information for available
resources and if they are enough to fulfill requested QoS.
Authorization is performed by Diameter client function which involves
contacting an authorization entity, lying anywhere in the network,
through the AAA cloud introduced in Section 1.1. If both checks
succeed, auhorized QoS parameters /they MIGHT be different from
requested QoS/ are set in the Packet classifier and Packet scheduler
to obtain the authorized QoS. Once the requested service is being
provided, Resource management provides accounting information to the
Authorizing entity using the Diameter client function.
1.3 Requirements for QoS AAA protocol
Intended deployment architecture and functionalities put a number of
requirements on the Diameter QoS application. These requirements are
reviewed in details in [I-D.alfano-aaa-qosreq]. A short list is
provided here:
Inter-domain support
In particular, users may roam outside their home network, leading
to a situation where the network element and authorizing entity
are in different administrative domains.
Identity-based Routing
The QoS AAA protocol MUST route AAA requests to the authorizing
entity based on the identity information given in the QoS
signaling protocol.
Flexible Authentication Support
The QoS AAA protocol MUST support a variety of different
authentication protocols for verification of authentication
information present in QoS signaling messages.
Making an Authorization Decision
The QoS AAA protocol MUST exchange sufficient information between
the authorizing entity and the enforcing entity (and vice versa)
to compute an authorization decision and to execute this decision.
Triggering an Authorization Process
The QoS AAA protocol MUST allow periodic and event triggered
execution of the authorization process, originated at the
Alfano, et al. Expires April 23, 2005 [Page 6]
Internet-Draft Diameter Quality of Service Application October 2004
enforcing entity or even at the authorizing entity.
Associating QoS Reservations and Application State
The QoS AAA protocol MUST carry information sufficient for an
application server to identify the appropriate application session
and associate it with a particular QoS reservation.
Dynamic Authorization
It MUST be possible for QoS AAA protocol to push updates towards
the network element(s) from authorizing entities.
Bearer Gating
The QoS AAA protocol MUST allow the authorizing entity to gate
authorized application flows e.g. based on application state
transitions.
Accounting Records
The QoS AAA protocol MUST define QoS accounting records containing
duration, volume (byte count) usage information and description of
the QoS attributes (e.g., bandwidth, delay, loss rate) that were
supported for the flow.
Sending Accounting Records
The network element MUST send accounting records for a particular
application flow to the authorizing entity for that flow or to
another entity identified by the authorizing entity.
Failure Notification
The QoS AAA protocol MUST allow the network element to report
failures(such as loss of connectivity due to movement of a mobile
node or other reasons for packet loss) to the authorizing entity.
Accounting Correlation
The QoS AAA protocol MUST support the exchange of sufficient
information to allow for correlation between accounting records
generated by the network elements and accounting records generated
by an application server.
Interaction with other AAA Applications
Interaction with other AAA applications such as
[I-D.ietf-aaa-diameter-cc] and [I-D.ietf-aaa-diameter-nasreq] is
required for exchange of authorization, authentication and
Alfano, et al. Expires April 23, 2005 [Page 7]
Internet-Draft Diameter Quality of Service Application October 2004
accounting information.
This document first defines used Diameter messages and Command-Codes.
Then it describes the operation of a Diameter QoS Application. The
following sections enumerate the Diameter message Command-Codes and
AVPs used in these messages.
Alfano, et al. Expires April 23, 2005 [Page 8]
Internet-Draft Diameter Quality of Service Application October 2004
2. 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].
Application Server
An application server is a network entity that exchanges signaling
messages with an application endpoint. It may be a source of
authorization for QoS-enhanced application flows. For example, a
SIP server is one kind of application server.
Application Endpoint
An application endpoint is an entity in an end user device that
exchanges signaling messages with application servers or directly
with other application endpoints. Based on the result of this
signaling, the endpoint will make a request for QoS from the
network. For example, a SIP User Agent is one kind of application
endpoint.
Authorizing Entity
The authorizing entity is that entity responsible for authorizing
QoS requests for a particular application flow. This may be a AAA
server (with a subscriber database) or an application server or
some other entity.
AAA Cloud
A network of AAA proxy/broker arrangements.
Furthermore, we use terminology defined in [RFC3588].
Alfano, et al. Expires April 23, 2005 [Page 9]
Internet-Draft Diameter Quality of Service Application October 2004
3. QoS Application messages
The purposes of QoS Authorization requires definition of new
mandatory AVPs and Command-Codes for the QoS Diameter application.
Two new Diameter messages are defined:
Command-Name Abbrev. Code Reference
QoS-Request QAR XXX 6.1
QoS-Answer QAA XXX 6.2
Also following Diameter-base messages are used:
Command-Name Abbrev. Code Reference
Accounting-Request ACR 271 [RFC3588]
Accounting-Answer ACA 271 [RFC3588]
Re-Auth-Request RAR 258 [RFC3588]
Re-Auth-Answer RAA 258 [RFC3588]
Abort-Session-Request ASR 274 [RFC3588]
Abort-Session-Answer ACA 274 [RFC3588]
Session-Term-Request STR 275 [RFC3588]
Session-Term-Answer STA 275 [RFC3588]
Diameter nodes conforming to this specification MAY advertise support
by including the value of TBD in the Auth-Application-Id or the
Acct-Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer commands [RFC3588].
The value of TBD (TBD) MUST be used as the Application-Id in all QAR
and QAA commands. The value of TBD (TBD) MUST be used as the
Application-Id in all ACR/ACA commands, because this application
defines new, mandatory AVPs for accounting. The value of zero (0)
SHOULD be used as the Application-Id in all STR/STA, ASR/ASA, and
RAR/RAA commands, because these are defined in the Diameter base
protocol and no additional mandatory AVPs for those commands are
defined in this document.
Alfano, et al. Expires April 23, 2005 [Page 10]
Internet-Draft Diameter Quality of Service Application October 2004
4. QoS Authorization session
4.1 Authorization models
In respect to NSIS signaling, different authorization models are
present. They are discussed in details in
[I-D.tschofenig-nsis-aaa-issues]. From the prospective of the
Diameter QoS application these models differ in authentication and
authorization information that need to be carried. Here we focus on
the "Tree party approach" model(Figure 5) and its derivation "Token
based three party approach"(fig-three-party-token-approach).
+--------------+
| Entity |
| authorizing | <......+
| resource | .
| request | .
+------------+-+ .
--^----------|-- . .
///// | | \\\\\ .
// | | \\ .
| QoS | QoS AAA | QoS |.
| authz| protocol |authz |.
| req.| | res. |.
\\ | | // .
\\\\\ | | ///// .
QoS --|----------v-- . .
+-------------+ request +-+------------+ .
| Entity |----------------->| BE | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <.....+
| |<-----------------| reservation | financial
+-------------+ +--------------+ settlement
Figure 5: Three party approach
In "Tree party approach" model, a resource request by the end host is
received at the router in the local network and then forwarded to the
user's home network where authorization is provided. The response is
then returned and resources are granted (in case of a successful
authorization decision). The interaction between the visited network
and the home network establishes the necessary financial
infrastructure to latter charge the user for the consumed resources.
Alfano, et al. Expires April 23, 2005 [Page 11]
Internet-Draft Diameter Quality of Service Application October 2004
financial settlement
...........................+
Authorization V ------- .
Token Request +--------------+ / QoS AAA \ .
+-------------->| Entity | / protocol \ .
| | authorizing +--------------+ \ .
| | resource | | | | .
| +------+ request |<--+----+ | | .
| | +--------------+ |QoS | |QoS |.
| | |authz| |authz|.
| |Authorization |req.+| |res. |.
| |Token |Token| | |.
| | | | | . | .
| | \ | | . / .
| | \ | | / .
| | QoS request |-----V . .
+-------------+ + Authz. Token +--------+-----+ .
| Entity |----------------->| BE | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <....+
| |<-----------------| reservation |
+-------------+ +--------------+
Figure 6: Token based three party approach
The token based three party approach is applicable in environments
where a previous protocol interaction is used to request
authorization tokens (or something similar) to assist the
authorization process at the entity performing the QoS reservation.
A host contacts the Authorizing entity and obtains an authorization
token for a requested service prior to sending a QoS reservation
request. It includes the authorization token in its reservation
request and this token is used in the routers along the flow path for
QoS authorization. (e.g. the authorization token is included in QoS
AAA messages between the router and the Authorizing entity.)
4.2 Session Initiation
The request for a quality of service enabled bearer starts a Diameter
QoS message exchange (Examples). The identity of the user, message
authentication information, and depending on the scenario, the
identity of the QoS authorizing application server and session
identification information, are assembled into a Diameter QoS
Authorization Request (QAR) message by the bearer control element(s)
responsible for resource allocation and sent either to the identified
application server, or to a supporting diameter server in the user's
Alfano, et al. Expires April 23, 2005 [Page 12]
Internet-Draft Diameter Quality of Service Application October 2004
home realm.
The server processes the information and responds with a Diameter QoS
Answer message (QAA) that contains QoS authorization, accounting, and
bearer gating information. Also Session-Timeout, Auth-Lifetime and
Grace-Period AVPs SHOULD be included for specifying the authorization
validity period and session duration. CC-Correlation-ID and
Acc-Multisession-ID AVPs SHOULD be present for accounting session
binding.(Section 5) [RFC3588], [I-D.alfano-aaa-qosreq].
In case of unsuccessful authorization an QAA message, including a
failure code(Result-Code AVP) specifying the rejections reason, is
sent which ends this session.
4.3 Session Establishment
When the QoS authorization exchange completes successfully, the QoS
Diameter application SHOULD start a session context for reporting
accounting information and loss of bearer. Accounting information is
reported as described in [RFC3588] and as extended in this Diameter
application Section 5. Loss of bearer information is reported using
Diameter QoS defined command codes (QAR) and AVPs.
4.4 QoS Re-Authorization
A possible solution is taken from [RFC3588]:(See Open Issues)
4.4.1 Client-side initiated Re-Authorization
Authorization server can specify a period of time for which an
application is authorized to use QoS resources and after which
re-authorization is required. Authorization lifetime is specified in
Authorization-Lifetime and Grace-Period AVPs included in successful
authorization QAA message. In the event of Authorization-Lifetime
expiration the bearer device initiates QAR/QAA message exchange for
re-authorization.
4.4.2 Server-side initiated Re-Authorization
At any time during the QoS session the Authorizing server MAY send
Re-Auth-Request (RAR) message. The Diameter client /the bearer
element/ MUST respond with Re-Auth-Answer (RAA) message. The bearer
element will then send an QoS-Request message with re-authorization
info.
4.5 Session Termination
Alfano, et al. Expires April 23, 2005 [Page 13]
Internet-Draft Diameter Quality of Service Application October 2004
4.5.1 Client-side initiated session termination
A QoS Session may be terminated from the client side by sending a
Session-Termination-Request message to the server. This action is
defined in [RFC3588].
4.5.2 Server-side initiated session termination
At anytime during a session the Authorizing Server may send an
Abort-Session-Request message to the bearer control element
[RFC3588]. Possible reasons are a response to a loss of bearer
report, or session termination at the application layer.
Alfano, et al. Expires April 23, 2005 [Page 14]
Internet-Draft Diameter Quality of Service Application October 2004
5. Accounting
Diameter QoS Application presented in this document use Diameter
Accounting as defined in [RFC3588]. A definition of new Accounting
attributes is necessary. (TBD)
After a successful QoS Authorization the router starts corresponding
Accounting session by sending an Accounting-Request message. The
message SHOULD contain necessary attributes to bind the current
accounting session to the reported QoS session/CC-Correlation-ID AVP
and Acc-MultiSession-ID AVP/. Authorizing server replies to
successfully received Accounting-Request message with
Accounting-Answer message which MAY contain instructions for handling
of the accounting session e.g. Accounting-Interim-Interval AVPs.
After every successful re-authorization procedure the bearer element
SHOULD initiate accounting message exchange.
After successful session termination the bearer element SHOULD
initiate final exchange of accounting messages with the authorizing
server.
Alfano, et al. Expires April 23, 2005 [Page 15]
Internet-Draft Diameter Quality of Service Application October 2004
6. Diameter QoS Messages
This section defines new Diameter message Command-Code [RFC3588]
values that MUST be supported by all Diameter implementations that
conform to this specification. The Command Codes are:
Command-Name Abbrev. Code Reference
QoS-Request QAR XXX 6.1
QoS-Answer QAA XXX 6.2
6.1 QoS-Request (QAR) Command
The QoS-Request message (QAR), indicated by the Command-Code field
set to XXX and 'R' bit set in the Command Flags field, is used by
bearer control elements to request quality of service related
resource authorization for a given flow.
The message MUST carry information to authorize the QoS requestor.
As such it is at minimum necessary to carry enough info to identify
the user. If the QoS-Request is intended for a specific application
server, the Request MUST include session identification AVPs.
Message Format
<QoS-Request> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
{ Auth- Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination Realm }
{ Auth-Request-Type }
[ User-Name ]
[ CC-Correlation-Id ]
[ State ]
* [ AVP ]
6.2 QoS-Answer (QAA) Command
The QoS-Answer message (QAA), indicated by the Command-Code field set
to XXX and 'R' bit cleared in the Command Flags field, is sent in
response to the QoS-Request message. If the QoS-Request message is
processed successfully, the response will include the AVPs to allow
authorization of the QoS resources as well as accounting and bearer
Alfano, et al. Expires April 23, 2005 [Page 16]
Internet-Draft Diameter Quality of Service Application October 2004
gating information.
<QoS-Answer> ::= < Diameter Header: XXX, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ QoS-Auth-Resources ]
[ QoS-Flow-State ]
* [ AVP ]
Alfano, et al. Expires April 23, 2005 [Page 17]
Internet-Draft Diameter Quality of Service Application October 2004
7. Diameter QoS AVPs
Each of the AVPs identified in the QoS-Request and QoS-Answer command
codes and the assignment of their value(s) is given in this section.
7.1 Diameter Base Protocol AVPs
The AVPs in this section are defined in the Base Protocol, and are
included here for reference. For more information, see [RFC3588].
Session-Id AVP
The Diameter QoS Application client MUST create a unique value for
the Session-Id. This value serves the purpose of uniquely
identifier a particular session.
Auth-Application-Id
The Auth-Application-Id is assigned by IANA to Diameter
Applications. The value of the Auth-Application-Id for the
Diameter QoS Application is XXX.
Result-Code AVP
The Result-Code AVP indicates if a particular request was
completed successfully.
Origin-Host
The Origin-Host AVP identifies the endpoint that originated the
Diameter message.
Origin-Realm
The Origin-Realm AVP contains the Realm of the originator of the
Diameter message.
7.2 Credit Control
The AVPs in this section are defined as part of the Diameter draft
[I-D.ietf-aaa-diameter-cc].
CC-Correlation-Id
The CC-Correlation-ID AVP (AVP code TBD) is of type OcterString
and contains information to correlate accounting data generated
for different components of the service, e.g. transport and
Alfano, et al. Expires April 23, 2005 [Page 18]
Internet-Draft Diameter Quality of Service Application October 2004
application level. In the Diameter QoS Application, this AVP is
assigned a value by the Diameter QoS client and sent to the server
in a QAR message.
7.3 Authentication/Authorization
Authentication and authorization is important for the Diameter QoS
application. Therefore, a number of AVPs of related Diameter
applications can be used, such as [I-D.ietf-aaa-eap],
[I-D.ietf-aaa-diameter-sip-app] and [I-D.ietf-aaa-diameter-nasreq]
The details of the required attributes for authentication and
authorization is for further study.
7.4 Accounting AVPs
The Diameter QoS Application uses Diameter Accounting as defined in
[RFC3588]. Diameter base accounting AVPs and Credit-Control AVPs
SHOULD be used.
Acc-Multisession-ID
Acc-Multisession-ID AVP SHOULD be used to link together multiple
related accounting sessions. This AVP MAY be returned by the
Diameter server in an authorization answer, and MUST be used in
all accounting messages for the given session.
7.5 Diameter QoS Application Defined AVPs
This section defines the Quality of Service AVPs that are specific to
the Diameter QoS Application that MAY be included in the Diameter QoS
Application messages.
Description format is taken from QoS NSLP Qspec Template which is
expected to cover all present QoS description methods
[QOS-NSIS-QSPEC]. The template proposed there includes description
of QoS Control information and requested, reserved, available and
minimum QoS which are used in NSIS QoS protocol. For the
authorization purposes not all of the description parameters are
required e.g. only Minimum and Available QoS description MAY be
used. A separate AVP MAY be specified for description of QoS in 3GPP
networks scenarios.
The following table describes the Diameter AVPs in the QoS
Application, their AVP code values, types, possible flag values, and
whether the AVP MAY be encrypted.
Alfano, et al. Expires April 23, 2005 [Page 19]
Internet-Draft Diameter Quality of Service Application October 2004
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST| |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
QoS-Auth- XXX 4.3 Grouped | M | P | | V | Y |
Resources | | | | | |
QoS-Filter-Rule XXX 4.3 Grouped | M | P | | v | Y |
QoS-Flow-State XXX 4.3 Enumerated | M | P | | V | Y |
QoS-SDP XXX 4.3 OctetString | M | P | | V | Y |
QoS-NSIS XXX 4.3 OctetString | M | P | | V | Y |
IPFilter XXX 4.3 IpfltrRule | M | P | | V | Y |
SPI XXX 4.3 Unsigned32 | M | P | | V | Y |
DSCP XXX 4.3 Unsigned32 | M | P | | V | Y |
| | | | | |
-----------------------------------------+----+-----+----+-----+----+
QoS-Auth-Resources
The QoS-Auth-Resources AVP (AVP Code N) is of type Grouped. Each
individual AVP in the grouped QoS-Auth-Resources describes the
value of a resource that has been authorized by an application
server for a particular QoS Request (described by the Session-Id
AVP). The QoS-Auth-Resources AVP is Optional, however one of
QoS-Auth-Resources, or QoS-Flow-State is mandatory in a QAA
message.
QoS-Auth-Resources ::= * [ QoS-Filter-Rule ]
0*1 < QoS-SDP >
0*1 < QoS-NSIS >
The AVPs that are part of QoS-Auth-resource AVP are:
QoS-Filter-Rule
QoS-Filter-Rule::= 0*1 < IPFilter >
0*1 < SPI >
0*1 < DSCP >
The QoS-Filter-Rule AVP is of type Grouped, and provides filter
rules for the packet flow of the user. One or more such AVPs MAY
be present in a QAA response.
Alfano, et al. Expires April 23, 2005 [Page 20]
Internet-Draft Diameter Quality of Service Application October 2004
QoS-SDP
The QoS-SDP AVP is of type OctetString. It contains the SDP data
from the application layer session negotiation. The format of the
data is as specified in [RFC2327].
QoS-NSIS
The QoS-NSIS AVP is of type OctetString. It contains QoS
parameter information. The format will be described in
[I-D.ietf-nsis-qos-nslp] and [I-D.ietf-nsis-qspec]. Note that
this work is still in progress. See Appendix A.1 for a
preliminary packet format.
It is for further investigation whether a more generic formation for
the QoS description in SDP, and NSIS can be compiled.
QoS-Flow-State:
The QoS-Flow-State AVP is of type Enumerated and is used in both
QAR and QAA messages. When included in a QAR message, it
indicates the state of the flow identified by the User-Name and
Session-Id AVPs. When included in a QAA message, it is
instructions to the bearer control element with regard to the
state to which the flow should be set. The supported values are
0 Open
1 Close
2 Maintain
The QoS-Flow-State is an optional AVP. When not included in a QAA
response, the default behavior is to immediately allow the flow of
packets (Open).
IPFilter:
The IPFilter AVP is of type IPflrtRule and represents a flow
identifier used in Packet Clasifier.
SPI:
The SPI AVP is of type Unsigned32 and together with IPFilter AVP
provides support for IPsec protected traffic.
Alfano, et al. Expires April 23, 2005 [Page 21]
Internet-Draft Diameter Quality of Service Application October 2004
DSCP:
The DSCP AVP is of type Unsigned32 and together with IPFilter AVP
provides support for DiffServ marked traffic.
Alfano, et al. Expires April 23, 2005 [Page 22]
Internet-Draft Diameter Quality of Service Application October 2004
8. Examples
This section illustrates a general message flow of QoS authorization
session establishment(Figure 14) and interworking with NSIS (Figure
15).
Figure 14 shows a session for QoS authorization established between
the bearer element and authorizing entity. An incoming QoS
reservation request received at the bearer node invokes sending of
QoS-Request message to the Authorization server. Server replies with
QoS-Answer which grants reservation of certain resources. After the
successful exchange of authorization QAR/QAA messages, bearer node
starts an Accounting session with sending of Accounting-Request
message. Server replies with Accounting-Answer message which MAY
includes instruction for further handling of the accounting session
such as Acc-Interim-Period AVP. Possible Client-side
Re-authorization caused by expiration of Authorization life timer
initiates QAR/QAA message exchange. After successful
re-authorization an accounting message ACR SHOULD be sent. Server
replies to it with ACA message. Session termination is initiated
from the server by sending of Abort-Session-Request message. Client
responds with ASA message and Session-Termination-request message.
After receiving of STA, which finalize the authorization session,
from the server side, final accounting info is sent with ACR message.
ACA message from the server side terminates the accounting session
too.
Router(Diameter client) Diameter Server
-----------> | |
QOS | QoS-Request |
reservation |----------------------------------------------->|
request | |
| QoS-Answer/QoS-Auth-Res./ |
|<-----------------------------------------------|
| |
Start |Accounting-Request/Start,QoS Acc-Msess-ID.../ |
Accounting |----------------------------------------------->|
| Accounting-Answer/...Acc-Interim-Period.../ |
|<-----------------------------------------------|
| |
Authorization| |
LifeTime | |
Expires: | |
Re- | QoS-Request |
Authorization|----------------------------------------------->|
| QoS-Answer/QoS-Auth-Res./ |
|<-----------------------------------------------|
Alfano, et al. Expires April 23, 2005 [Page 23]
Internet-Draft Diameter Quality of Service Application October 2004
| Accounting-Request/Interim, Acc-Msess-ID.../ |
|----------------------------------------------->|
| Accounting-Answer/...Acc-Interim-Period.../ |
|<-----------------------------------------------|
.....................
| | Session
| | Term.
| |initiate
| |by Server
| Abort-Session-Request |<--------
|<-----------------------------------------------|
| Abort-Session-Answer |
|----------------------------------------------->|
| Session-Termination-Request |
|----------------------------------------------->|
| Session-Termination-Answer |
|<-----------------------------------------------|
Accounting | Accounting-Request/Final,Acc-Msess-ID.../ |
end |----------------------------------------------->|
| Accounting-Answer /Final,.../ |
|<-----------------------------------------------|
Figure 14: Diameter QoS Application session
Figure 15 shows the interaction between NSIS, application layer
signaling (e.g., SIP) and the Diameter QoS application. First, a
service request is sent from the client to the application server.
In response, for example, it returns an authorization token to bind
the application layer signaling exchange to the subsequent NSIS
signaling session. The authorization token is attached to the NSIS
signaling message and the message itself is intercepted by the first
NSIS NSLP node. This router then needs to authorize the QoS request
and delegates this responsibility to the Diameter QoS application.
This type of authorization model is described in Section 1 and
Section 3.6 of [I-D.ietf-nsis-qos-nslp]. The Diameter QoS
Authorization Request (QAR), which includes authorization information
and QoS information is, in this case, forwarded to the administrative
domain of the application domain for verification. As a response,
the authorization decision is returned with the Diameter QoS Answer
message (QAA). Finally, the NSIS QoS NLP aware router acts as an
enforcement point. If the authorization decision provided with the
QAA message was successful then the NSIS signaling message is
forwarded along the path. Otherwise, the QoS NSLP returns an error
message to the end host (such as 'Authorization denied').
Diameter QoS
Alfano, et al. Expires April 23, 2005 [Page 24]
Internet-Draft Diameter Quality of Service Application October 2004
Application
Enabled Router Application
Enforcement Pt Server
Application +
Client Domain 1 + Domain 2
| | + |
| Service Request (QoS) |
+------------+------------+------------->
| | + |
| | + |
| Service Response (QoS', Token) |
<------------+------------+-------------+
| | + |
| | + |
|NSIS (Token)| + |
+------------> + |
| | + |
| | -+-- |
| |QAR(Token)- + -QAR(Token)|
| +--------/> + --\-------->
| | / + \ |
| | / + \ |
| | | + | |
| | QAA(QoS) + QAA(QoS) |
| <------+--- + <---+------+
| | | + | |
| | | Diameter | |
| | \ Network / |
| | \ + / |
| | \ + / |
| Authorization \- + -/ |
| Enforcement -+-- |
| Decision + |
| | + |
| | + |
| Allow or Terminate Flow |
<-----------+*+------------------------->
| | + |
| | + |
Figure 15: Message flow with NSIS and Diameter QoS Application
A future version of this document will describe scenarios with other
authorization models.
Alfano, et al. Expires April 23, 2005 [Page 25]
Internet-Draft Diameter Quality of Service Application October 2004
9. Security Considerations
This document describes a mechanism for performing authorization of a
QoS reservation at a third party entity. Thereby, it is necessary
the QoS signaling protocol to forward the necessary information to
the backend AAA server. This functionality is particularly useful in
roaming environments where the authorization decision is most likely
provided at an entity where the user is known i.e. home realm. To
provide proper authorization authentication might be necessary at
least for the generic third party model (described in Section 3.6 of
[I-D.ietf-nsis-qos-nslp]. The concept of an authorization token
based third party approach is also described in the same document.
The impact of the existence of different authorization models is
(with respect to this Diameter QoS application) the ability to carry
different authentication and authorization information.
Further discussions on the authorization handling for QoS signaling
protocols is available with [I-D.tschofenig-nsis-aaa-issues] and
[I-D.tschofenig-nsis-qos-authz-issues].
Alfano, et al. Expires April 23, 2005 [Page 26]
Internet-Draft Diameter Quality of Service Application October 2004
10. Contributors
The authors would like to thank Tseno Tsenov for his contributions to
this document.
Alfano, et al. Expires April 23, 2005 [Page 27]
Internet-Draft Diameter Quality of Service Application October 2004
11. Acknowledgements
Add your name here.
Alfano, et al. Expires April 23, 2005 [Page 28]
Internet-Draft Diameter Quality of Service Application October 2004
12. Open Issues
During our work on this document we identified the following open
issues:
o This Diameter QoS application can reuse a number of other Diameter
applications. This is a big advantage over other approaches.
This interaction and a list of useful attributes needs to be
collected and described. This aspect is for further study.
o The NSIS group is currently working on QoS models. As soon as
results are available it is feasible to incorporate them into this
Diameter application to build a complete solution for QoS
signaling which uses a backend infrastructure.
o Several authorization models have been described in
[I-D.ietf-nsis-qos-nslp]. Section 8 currently addresses only the
third party approach using authorization tokens. Further work is
needed to describe the details of a generic three party scenario.
o Section 4.5 describes the session termination functionality.
Should a new command code for bearer gating purposes be
introduced, i.e., what if the application server wants to
temporarily disable the bearer without terminating the session
with ASR?
o Section 4.4 raises the question of a re-authorizing capability for
the Diameter application. The authors think that such a
re-authorization capability would be desirable (e.g., using with
the RAR/RAA message exchange). Note that it would require the
bearer path signaling protocol (for example RSVP or NSIS) to
support network-initiated re-auth, which might not always be in
place. There should be a failure code for the case where the
underlying bearer signaling protocol does not support it.
o Section 4.4 presents a possible re-authorization solution taken
from [RFC3588]. A time based authorization life period is used.
Adding a re-authorization funtionality with volume-based
authorization period MIGHT be useful. A coresponding metering
funtionality MUST be present at the router.
Alfano, et al. Expires April 23, 2005 [Page 29]
Internet-Draft Diameter Quality of Service Application October 2004
13. References
13.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
13.2 Informative References
[I-D.alfano-aaa-qosreq]
Alfano, F., "Requirements for a QoS AAA Protocol",
draft-alfano-aaa-qosreq-01 (work in progress), October
2003.
[I-D.ietf-aaa-diameter-cc]
Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H.
Hakala, "Diameter Credit-control Application",
draft-ietf-aaa-diameter-cc-06 (work in progress), August
2004.
[I-D.ietf-aaa-diameter-nasreq]
Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
Network Access Server Application",
draft-ietf-aaa-diameter-nasreq-17 (work in progress), July
2004.
[I-D.ietf-aaa-diameter-sip-app]
Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
Canales-Valenzuela, C. and K. Tammi, "Diameter Session
Initiation Protocol (SIP) Application",
draft-ietf-aaa-diameter-sip-app-04 (work in progress),
October 2004.
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-09 (work in progress), August 2004.
[I-D.ietf-nsis-qos-nslp]
Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-04
(work in progress), July 2004.
[I-D.ietf-nsis-qspec]
Ash, J., "QoS-NSLP QSpec Template",
Alfano, et al. Expires April 23, 2005 [Page 30]
Internet-Draft Diameter Quality of Service Application October 2004
draft-ietf-nsis-qspec-01 (work in progress), October 2004.
[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.
[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.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R.
and A. Sastry, "COPS usage for RSVP", RFC 2749, January
2000.
[RFC3313] Marshall, W., "Private Session Initiation Protocol (SIP)
Extensions for Media Authorization", RFC 3313, January
2003.
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session
Authorization Policy Element", RFC 3520, April 2003.
[RFC3521] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session
Set-up with Media Authorization", RFC 3521, April 2003.
Authors' Addresses
Frank M. Alfano
Lucent Technologies
1960 Lucent Lane
Naperville, IL 60563
USA
Phone: +1 630 979 7209
EMail: falfano@lucent.com
Alfano, et al. Expires April 23, 2005 [Page 31]
Internet-Draft Diameter Quality of Service Application October 2004
Peter J. McCann
Lucent Technologies
1960 Lucent Lane
Naperville, IL 60563
USA
Phone: +1 630 713 9359
EMail: mccap@lucent.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Alfano, et al. Expires April 23, 2005 [Page 32]
Internet-Draft Diameter Quality of Service Application October 2004
Appendix A. AVP Formats
This section provides a strawman proposal for the AVPs introduced by
this document. Additionally, the content of the payload is
described. Unlike the approach followed with RSVP (see [RFC2749])
where the entire RSVP message is encapsulated into a COPS message
this approach only includes the relevant fields. This approach
avoids a certain overhead of transmitting fields which are irrelevant
for the AAA infrastructure, it keeps implementations simpler and it
allows to reuse other Diameter AVPs. Finally, it helps to make this
Diameter application less dependent on any particular QoS signaling
protocol or a particular QoS model.
A.1 NSIS to Diameter QoS AVPs Mapping
A future version of this document will contain payload descriptions
of objects introduced by the NSIS protocol suite. Relevant
parameters can be found in [I-D.ietf-nsis-qos-nslp] and in the area
of QoS models (see [I-D.ietf-nsis-qspec] for ongoing work).
Considering that the work on QoS parameters in
[I-D.ietf-nsis-qos-nslp] and [I-D.ietf-nsis-qspec] is ongoing, this
section presents a preliminary attempt for defining a structure of
the AVPs for NSIS QSpec template. Issues stated in Section 7.5
should be taken into account as well.
A.1.1 NSIS QSpecs Template structure
Current proposed structure of the NSIS QSpec template is defined in
[I-D.ietf-nsis-qspec]:
QSP ID
QOS Control Information
Hop Count
Service Schedule
QOS Description
QOS Desired
R - rate
token bucket
r
b
p
m
M
Qos class
Alfano, et al. Expires April 23, 2005 [Page 33]
Internet-Draft Diameter Quality of Service Application October 2004
Priority
QOS Available
non IS hop
IS hops
Available BW
Min latency
MTU
Ctot
Dtot
Csum
Dsum
QOS Reserved
token bucket
R - rate
S - Slack term
Qos class
Priority
Min QoS
token bucket
Qos class
Priority
A.1.2 AVP format
A.1.2.1 QoS Description, Token Bucket parameter
For description of Token Bucket parameter from QoS Descriptions the
following structure taken from [RFC2210] MIGHT be used. For
completeness the RSVP object header is not removed:
Alfano, et al. Expires April 23, 2005 [Page 34]
Internet-Draft Diameter Quality of Service Application October 2004
31 24 23 16 15 8 7 0
+---------------+---------------+---------------+---------------+
| Length (32 bytes) | Class = 9 | C-Type =2 |
+---------------+---------------+---------------+---------------+
| 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 (c) |0| reserved | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - Service header, service number 5 (Controlled-Load)
(d) - Length of controlled-load data, 6 words not including
per-service header
(e) - Parameter ID, parameter 127 (Token Bucket TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including per-service
header
A.1.2.2 QoS Description, QoS Available objects
This structure is taken from [RFC2210]. For completeness the RSVP
object header is not removed:
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Unused | 19 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |x| reserved (d)| 8 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 4 (f) | (g) | 1 (h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Alfano, et al. Expires April 23, 2005 [Page 35]
Internet-Draft Diameter Quality of Service Application October 2004
4 | zero extension of .. IS hop cnt (16-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | 6 (i) | (j) | 1 (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | 8 (l) | (m) | 1 (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 10 (o) | (p) | 1 (q) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | zero extension of .. composed MTU (16-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | 2 (r) |x| reserved (s)| 8 (t) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | 133 (u) | (v) | 1 (w) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
13 | End-to-end composed value for C [Ctot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
14 | 134 (x) | (y) | 1 (z) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
15 | End-to-end composed value for D [Dtot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | 135 (aa | (bb | 1 (cc) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17 | Since-last-reshaping point composed C [Csum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18 | 136 (dd) | (ee) | 1 (ff) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19 | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | 5 (gg |x 0 (hh) | 0 (ii) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Word 1: Message Header:
(a) - Message header and version number
(b) - Message length - 19 words not including header
Words 2-7: Default general characterization parameters
(c) - Per-Service header, service number 1
(Default General Parameters)
(d) - Global Break bit (NON_IS_HOP general parameter 2) (marked x)
(e) - Length of General Parameters data block (8 words)
(f) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS
general parameter)
(g) - Parameter 4 flag byte
(h) - Parameter 4 length, 1 word not including header
Alfano, et al. Expires April 23, 2005 [Page 36]
Internet-Draft Diameter Quality of Service Application October 2004
(i) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH
general parameter)
(j) - Parameter 6 flag byte
(k) - Parameter 6 length, 1 word not including header
(l) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY
general parameter)
(m) - Parameter 8 flag byte
(n) - Parameter 8 length, 1 word not including header
(o) - Parameter ID, parameter 10 (PATH_MTU general parameter)
(p) - Parameter 10 flag byte
(q) - Parameter 10 length, 1 word not including header
Words 11-19: Guaranteed service parameters
(r) - Per-Service header, service number 2 (Guaranteed)
(s) - Break bit
(t) - Length of per-service data, 8 words not including header
(u) - Parameter ID, parameter 133 (Composed Ctot)
(v) - Composed Ctot flag byte
(w) - Composed Ctot length, 1 word not including header
(x) - Parameter ID, parameter 134 (Composed Dtot)
(y) - Composed Dtot flag byte
(z) - Composed Dtot length, 1 word not including header
(aa)- Parameter ID, parameter 135 (Composed Csum).
(bb)- Composed Csum flag byte
(cc)- Composed Csum length, 1 word not including header
(dd)- Parameter ID, parameter 136 (Composed Dsum).
(ee)- Composed Dsum flag byte
(ff)- Composed Dsum length, 1 word not including header
Word 20: Controlled-Load parameters
(gg - Per-Service header, service number 5 (Controlled-Load)
(hh)- Break bit
(ii)- Length of controlled-load data, 0 words not including header
A.2 SIP to Diameter QoS AVPs Mapping
QoS authorization with the Diameter QoS Application requires that
also SIP specific mechanisms are exchanged via Diameter. A future
version of this document will describe the mapping of QoS relevant
parameters of the SDP payload [RFC2327] to QoS parameters of the
QSpec template used in this specification.
Alfano, et al. Expires April 23, 2005 [Page 37]
Internet-Draft Diameter Quality of Service Application October 2004
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
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 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 Internet Society (2004). 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.
Alfano, et al. Expires April 23, 2005 [Page 38]