draft-ietf-dime-diameter-qos-07.txt   draft-ietf-dime-diameter-qos-08.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: June 21, 2009 H. Tschofenig Expires: November 8, 2009 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.
Aruba Networks Aruba Networks
December 18, 2008 May 7, 2009
Diameter Quality of Service Application Diameter Quality of Service Application
draft-ietf-dime-diameter-qos-07.txt draft-ietf-dime-diameter-qos-08.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 June 21, 2009. This Internet-Draft will expire on November 8, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document describes the framework, messages and procedures for This document describes the framework, messages and procedures for
the Diameter Quality of Service (QoS) application. The Diameter QoS the Diameter Quality of Service (QoS) application. The Diameter QoS
application allows network elements to interact with Diameter servers application allows network elements to interact with Diameter servers
when allocating QoS resources in the network. In particular, two when allocating QoS resources in the network. In particular, two
modes of operation -- Pull and Push -- are defined. modes of operation -- Pull and Push -- are defined.
Table of Contents Table of Contents
skipping to change at page 3, line 35 skipping to change at page 3, line 35
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 . . . . . . . . . 21
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 . . . . . . . . 28 4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 29
4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 29 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 . . . . . . 31 4.4.2. Server-Side Initiated Session Termination . . . . . . 32
5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 33 5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 34
5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 34 5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 35
5.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 34 5.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 35
5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 35 5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 36
5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 36 5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 37
5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 36 5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 37
5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 37 5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 38
6. QoS Application State Machine . . . . . . . . . . . . . . . . 38 6. QoS Application State Machine . . . . . . . . . . . . . . . . 39
6.1. Supplemented States for Push Mode . . . . . . . . . . . . 38 6.1. Supplemented States for Push Mode . . . . . . . . . . . . 39
7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 40 7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 41
7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 40 7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 41
7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 40 7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 41
8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Example Call Flow for Pull Mode . . . . . . . . . . . . . 43 9.1. Example Call Flow for Pull Mode . . . . . . . . . . . . . 44
9.2. Example Call Flow for Push Mode . . . . . . . . . . . . . 45 9.2. Example Call Flow for Push Mode . . . . . . . . . . . . . 46
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 48 10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2. AVP Specific Values . . . . . . . . . . . . . . . . . . . 48 10.2. AVP Specific Values . . . . . . . . . . . . . . . . . . . 49
10.3. AVP Flags . . . . . . . . . . . . . . . . . . . . . . . . 48 10.3. AVP Flags . . . . . . . . . . . . . . . . . . . . . . . . 49
10.4. Application IDs . . . . . . . . . . . . . . . . . . . . . 48 10.4. Application IDs . . . . . . . . . . . . . . . . . . . . . 49
10.5. Command Codes . . . . . . . . . . . . . . . . . . . . . . 49 10.5. Command Codes . . . . . . . . . . . . . . . . . . . . . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . . . 50 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 54
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
14.1. Normative References . . . . . . . . . . . . . . . . . . . 54 14.1. Normative References . . . . . . . . . . . . . . . . . . . 55
14.2. Informative References . . . . . . . . . . . . . . . . . . 54 14.2. Informative References . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
This document describes the framework, messages and procedures for This document describes the framework, messages and procedures for
the Diameter Quality of Service (QoS) Application. The Diameter QoS the Diameter Quality of Service (QoS) Application. The Diameter QoS
Application allows Network Elements (NEs) to interact with Diameter Application allows Network Elements (NEs) to interact with Diameter
servers when allocating QoS resources in the network. servers when allocating QoS resources in the network.
Two modes of operation are defined. In the first, called "Pull" Two modes of operation are defined. In the first, called "Pull"
mode, the network element requests QoS authorization from the mode, the network element requests QoS authorization from the
skipping to change at page 11, line 23 skipping to change at page 11, line 23
the AE via the Diameter client. 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 QoS capability at neither A Category 1 Application Endpoint has no QoS capability at either
the application nor the network level. This type of AppE may set the application or the network level. This type of AppE may set
up a connection through application signaling, but it is incapable up a connection through application signaling, but it is incapable
of specifying resource/QoS requirements through either application of specifying resource/QoS requirements through either application
or network-level signaling. or network-level signaling.
Category 2 Category 2
A Category 2 Application Endpoint only has QoS capability at the A Category 2 Application Endpoint only has QoS capability at the
application level. This type of AppE is able to set up a application level. This type of AppE is able to set up a
connection through application signaling with certain resource/QoS connection through application signaling with certain resource/QoS
requirements (e.g., application attributes), but it is unable to requirements (e.g., application attributes), but it is unable to
signal any resource/QoS requirements at the network level. signal any resource/QoS requirements at the network level.
skipping to change at page 12, line 12 skipping to change at page 12, line 12
[RFC2212] and DiffServ [RFC2474]. In the IntServ scheme, network [RFC2212] and DiffServ [RFC2474]. In the IntServ scheme, network
signaling (e.g., RSVP, NSIS, or link specific signaling) is commonly signaling (e.g., RSVP, NSIS, or link specific signaling) is commonly
used to initiate a request from an AppE for the desired QoS resource. used to initiate a request from an AppE for the desired QoS resource.
In the DiffServ scheme, QoS resources are provisioned based upon some In the DiffServ scheme, QoS resources are provisioned based upon some
predefined QoS service classes rather than AppE-initiated, flow-based predefined QoS service classes rather than AppE-initiated, flow-based
QoS requests. QoS requests.
It is obvious that the eligible QoS scheme is correlated to the It is obvious that the eligible QoS scheme is correlated to the
AppE's capability in the context of QoS authorization. Since AppE's capability in the context of QoS authorization. Since
Category 1 and 2 AppEs cannot initiate the QoS resource requests by Category 1 and 2 AppEs cannot initiate the QoS resource requests by
means of network signaling, the IntServ model is not applicable to means of network signaling, using the current mechanism of IntServ
them in general. Depending on network technology and operator model to signal QoS information across the network is not applicable
to them in general. Depending on network technology and operator
requirements, a Category 3 AppE may either make use of network requirements, a Category 3 AppE may either make use of network
signaling for resource requests or not. signaling for resource requests or not.
The diversity of QoS capabilities of endpoints and QoS schemes of The diversity of QoS capabilities of endpoints and QoS schemes of
network technology leads to the distinction on the interaction mode network technology leads to the distinction on the interaction mode
between QoS authorization system and underlying NEs. When the between QoS authorization system and underlying NEs. When the
IntServ scheme is employed by a Category 3 endpoint, the IntServ scheme is employed by a Category 3 endpoint, the
authorization process is typically initiated by a NE when a trigger authorization process is typically initiated by a NE when a trigger
such as network signaling is received from the endpoint. In the is received from the endpoint such as network QoS signaling. In the
DiffServ scheme, since the NE is unable to request the resource DiffServ scheme, since the NE is unable to request the resource
authorization on its own initiative, the authorization process is authorization on its own initiative, the authorization process is
typically triggered by either the request of AppSs or policies typically triggered by either the request of AppSs or policies
defined by the operator. defined by the operator.
As a consequence, two interaction modes are needed in support of As a consequence, two interaction modes are needed in support of
different combinations of QoS schemes and endpoint's QoS different combinations of QoS schemes and endpoint's QoS
capabilities: Push mode and Pull mode. capabilities: Push mode and Pull mode.
Push mode Push mode
skipping to change at page 13, line 19 skipping to change at page 13, line 19
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
3.3.1. Pull Mode Schemes 3.3.1. Pull Mode Schemes
Three basic authorization schemes for Pull mode exist: one two-party Three types of basic authorization schemes for Pull mode exist: one
and two three-party schemes. The notation adopted here is in respect type of two-party scheme and two types of three-party schemes. The
to the entity that performs the QoS authorization. The notation adopted here is in respect to the entity that performs the
authentication of the QoS requesting entity might be done at the NE QoS authorization. The authentication of the QoS requesting entity
as part of the QoS signaling protocol, or by an off-path protocol run might be done at the NE as part of the QoS signaling protocol, or by
(on the application layer or for network access authentication) or an off-path protocol run (on the application layer or for network
the AE might be contacted with request for authentication and access authentication) or the AE might be contacted with request for
authorization of the QoS requesting entity. From the Diameter QoS authentication and authorization of the QoS requesting entity. From
application's point of view these schemes differ in type of the Diameter QoS application's point of view these schemes differ in
information that need to be carried. Here we focus on the 'Basic type of information that need to be carried. Here we focus on the
Three Party Scheme' (see Figure 3) and the 'Token-based Three Party 'Basic Three Party Scheme' (see Figure 3) and the 'Token-based Three
Scheme' (see Figure 4). In the 'Two Party Scheme', the QoS RRE is Party Scheme' (see Figure 4). In the 'Two Party Scheme', the QoS RRE
authenticated by the NE and the authorization decision is made either is authenticated by the NE and the authorization decision is made
locally at the NE itself or offloaded to a trusted entity (most either locally at the NE itself or offloaded to a trusted entity
likely within the same administrative domain). In the two-party case (most likely within the same administrative domain). In the two-
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 17, line 10 skipping to change at page 17, line 10
process to the AE. In the network-initiated scheme, the AE and/or process to the AE. In the network-initiated scheme, the AE and/or
AppS should derive and determine the QoS requirements according to AppS should derive and determine the QoS requirements according to
application attribute, subscription and endpoint's capability when application attribute, subscription and endpoint's capability when
the endpoint does not explicitly indicate the QoS attributes. The AE the endpoint does not explicitly indicate the QoS attributes. The AE
makes an authorization decision based on application level QoS makes an authorization decision based on application level QoS
information, network policies, end-user subscription, network information, network policies, end-user subscription, network
resource availability, etc., and installs the decision to NE resource availability, etc., and installs the decision to NE
directly. directly.
A Category 1 AppE requires network-initiated Push mode and a Category A Category 1 AppE requires network-initiated Push mode and a Category
2 AppE may use either mode 2 AppE may use either type of Push Mode.
financial settlement financial settlement
...........................+ ...........................+
Application V ------- . Application V ------- .
signaling msg +--------------+ / QoS AAA \ . signaling msg +--------------+ / QoS AAA \ .
+-------------->| | / protocol \ . +-------------->| | / protocol \ .
| | Authorizing +--------------+ \ . | | Authorizing +--------------+ \ .
| | Entity | | | | . | | Entity | | | | .
| + |<--+----+ | | . | + |<--+----+ | | .
| +--------------+ |QoS | |QoS |. | +--------------+ |QoS | |QoS |.
skipping to change at page 21, line 29 skipping to change at page 21, line 29
(i.e., DQA client) and the Authorizing Entity (i.e., DQA server). (i.e., DQA client) and the Authorizing Entity (i.e., DQA server).
The QoS RRE may communicate with the AE using application layer The QoS RRE may communicate with the AE using application layer
signaling for negotiation of service parameters. As part of this signaling for negotiation of service parameters. As part of this
application layer protocol interaction, for example using SIP, application layer protocol interaction, for example using SIP,
authentication and authorization might take place. This message authentication and authorization might take place. This message
exchange is, however, outside the scope of this document. The exchange is, however, outside the scope of this document. The
protocol communication between the QoS resource requesting entity and protocol communication between the QoS resource requesting entity and
the QoS NE might be accomplished using the NSIS protocol suite, RSVP the QoS NE might be accomplished using the NSIS protocol suite, RSVP
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 and a tight coupling with is also outside the scope of this document.
these protocols is not desirable since this applications aims to be
generic.
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-Authz-Request
(QAR, see Section 5.1) message with a new session ID is received, the (QAR, see Section 5.1) message with a new session ID is received, the
skipping to change at page 22, line 4 skipping to change at page 21, line 51
AE operates in the Push mode. Similarly, when a QoS-Install-Request AE operates in the Push mode. Similarly, when a QoS-Install-Request
(QIR, see Section 5.3} with a new session ID is received, the NE (QIR, see Section 5.3} with a new session ID is received, the NE
operates in the Push mode; when other triggers are received, the NE operates in the Push mode; when other triggers are received, the NE
operation in the Pull mode. operation in the Pull mode.
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 generates a QAR message in which the required objects from the QoS
signaling message to Diameter AVPs. signaling message that is converted to Diameter AVPs.
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
skipping to change at page 27, line 38 skipping to change at page 27, line 38
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.
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
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
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 globally routable IP
address. address.
4.3. Session Re-authorization 4.3. Session Re-authorization
skipping to change at page 35, line 15 skipping to change at page 36, line 15
The message format is defined as follows: The message format is defined as follows:
<QoS-Answer> ::= < Diameter Header: [TBD2], PXY > <QoS-Answer> ::= < Diameter Header: [TBD2], PXY >
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Auth-Application-Id }
{ Auth-Request-Type } { Auth-Request-Type }
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
* [ QoS-Resources ] * [ QoS-Resources ]
[ Acc-Multisession-Id ] [ Acct-Multisession-Id ]
[ Session-Timeout ] [ Session-Timeout ]
[ Authz-Session-Lifetime ] [ Authorization-Session-Lifetime ]
[ Authz-Grace-Period ] [ Authorization-Grace-Period ]
* [ AVP ] * [ AVP ]
5.3. QoS-Install Request (QIR) 5.3. QoS-Install Request (QIR)
The QoS-Install Request message (QIR), indicated by the Command-Code The QoS-Install Request message (QIR), indicated by the Command-Code
field set to [TBD3] and 'R' bit set in the Command Flags field is field set to [TBD3] and 'R' bit set in the Command Flags field is
used by AE to install or update the QoS parameters and the flow state used by AE to install or update the QoS parameters and the flow state
of an authorized flow at the transport plane element. of an authorized flow at the transport plane element.
The message MUST carry information for signaling session The message MUST carry information for signaling session
skipping to change at page 35, line 46 skipping to change at page 36, line 46
<QoS-Install-Request> ::= < Diameter Header: [TBD3], REQ, PXY > <QoS-Install-Request> ::= < Diameter Header: [TBD3], 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 ]
* [ QoS-Resources ] * [ QoS-Resources ]
[ Session-Timeout ] [ Session-Timeout ]
[ Authz-Session-Lifetime ] [ Authorization-Session-Lifetime ]
[ Authz-Grace-Period ] [ Authorization-Grace-Period ]
[ Authz-Session-Volume ] [ Authorization-Session-Volume ]
* [ AVP ] * [ AVP ]
5.4. QoS-Install Answer (QIA) 5.4. QoS-Install Answer (QIA)
The QoS-Install Answer message (QIA), indicated by the Command-Code The QoS-Install Answer message (QIA), indicated by the Command-Code
field set to [TBD4] and 'R' bit cleared in the Command Flags field is field set to [TBD4] and 'R' bit cleared in the Command Flags field is
sent in response to the QoS-Install Request message (QIR) for sent in response to the QoS-Install Request message (QIR) for
confirmation of the result of the installation of the provided QoS confirmation of the result of the installation of the provided QoS
reservation instructions. reservation instructions.
skipping to change at page 36, line 48 skipping to change at page 37, line 48
<Re-Auth-Request> ::= < Diameter Header: 258, REQ, PXY > <Re-Auth-Request> ::= < Diameter Header: 258, 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 ]
* [ QoS-Resources ] * [ QoS-Resources ]
[ Session-Timeout ] [ Session-Timeout ]
[ Authz-Session-Lifetime ] [ Authorization-Session-Lifetime ]
[ Authz-Grace-Period ] [ Authorization-Grace-Period ]
[ Authz-Session-Volume ] [ Authorization-Session-Volume ]
* [ AVP ] * [ AVP ]
5.6. Re-Auth-Answer (RAA) 5.6. Re-Auth-Answer (RAA)
The Re-Auth-Answer message (RAA), indicated by the Command-Code field The Re-Auth-Answer message (RAA), indicated by the Command-Code field
set to 258 and the 'R' bit cleared in the Command Flags field, is set to 258 and the 'R' bit cleared in the Command Flags field, is
sent by the NE to the AE in response to the RAR command. sent by the NE to the AE in response to the RAR command.
The message format is defined as follows: The message format is defined as follows:
skipping to change at page 38, line 7 skipping to change at page 39, line 7
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Auth-Application-Id }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Result-Code } { Result-Code }
* [ QoS-Resources ] * [ QoS-Resources ]
* [ AVP ] * [ AVP ]
6. QoS Application State Machine 6. QoS Application State Machine
The QoS application reuses the authorization state machine defined in The QoS application defines its own state machine that is based on
Section 8.1 of the Base Protocol ([RFC3588]) with its own messages as the authorization state machine defined in Section 8.1 of the Base
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
In addition to the reused state machines, the following states are Using the Base Protocol state machine as a basis, the following
supplemented to first 2 state machines in which the session state is states are supplemented to first 2 state machines in which the
maintained on the Server, and MUST be supported in any QoS session state is maintained on the Server. This MUST be supported in
application implementations in support of server initiated push mode any QoS application implementations in support of server initiated
(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
server when it is maintaining state for the session as defined in client when state is maintained on the client as defined in Section
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
event triggers an initial QIR initial event triggers an initial QIR initial
QoS request to the server request QoS request to the server request
Pending Received QIA with a failed Cleanup Idle Pending Received QIA with a failed Cleanup Idle
Result-Code Result-Code
skipping to change at page 40, line 25 skipping to change at page 41, line 25
Attribute Name AVP Code Reference [RFC3588] Attribute Name AVP Code Reference [RFC3588]
Origin-Host 264 Section 6.3 Origin-Host 264 Section 6.3
Origin-Realm 296 Section 6.4 Origin-Realm 296 Section 6.4
Destination-Host 293 Section 6.5 Destination-Host 293 Section 6.5
Destination-Realm 283 Section 6.6 Destination-Realm 283 Section 6.6
Auth-Application-Id 258 Section 6.8 Auth-Application-Id 258 Section 6.8
Result-Code 268 Section 7.1 Result-Code 268 Section 7.1
Auth-Request-Type 274 Section 8.7 Auth-Request-Type 274 Section 8.7
Session-Id 263 Section 8.8 Session-Id 263 Section 8.8
Authz-Lifetime 291 Section 8.9 Authorization-Lifetime 291 Section 8.9
Authz-Grace-Period 276 Section 8.10 Authorization-Grace-Period 276 Section 8.10
Session-Timeout 27 Section 8.13 Session-Timeout 27 Section 8.13
User-Name 1 Section 8.14 User-Name 1 Section 8.14
The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to
Diameter applications. The value of the Auth-Application-Id for the Diameter applications. The value of the Auth-Application-Id for the
Diameter QoS application is TBD. Diameter QoS application is TBD.
7.2. QoS Application Defined AVPs 7.2. QoS Application Defined AVPs
This document reuses the AVPs defined in Section 4 of This document reuses the AVPs defined in Section 4 of
[I-D.ietf-dime-qos-attributes]. [I-D.ietf-dime-qos-attributes].
This section lists the AVPs that are introduced specifically for the This section lists the AVPs that are introduced specifically for the
QoS application. The following new AVPs are defined: Bound-Auth- QoS application. The following new AVPs are defined: Bound-Auth-
Session-Id and the QoS-Authz-Data AVP. Session-Id and the QoS-Authorization-Data AVP.
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|MAY| NOT| NOT| | Attribute Name Code Defined Data Type |MUST| NOT| NOT|
+----------------------------------------------+----+---+----+-----+ +----------------------------------------------+----+--------+-----+
|QoS-Authz-Data TBD 7.2 Grouped | M | P | | V | |QoS-Authorization-Data TBD 7.2 Grouped | M | | V |
|Bound-Auth-Session-Id TBD 7.2 UTF8String | M | P | | 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. |
|P - Indicates the need for encryption for end-to-end security. |
|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
The QoS-Authz-Data AVP (AVP Code TBD) is of type OctetString. It The QoS-Authorization-Data AVP (AVP Code TBD) is of type
is a container that carries application session or user specific OctetString. It is a container that carries application session
data that has to be supplied to the AE as input to the computation or user specific data that has to be supplied to the AE as input
of the authorization decision. to the computation of the authorization decision.
Bound-Authentication-Session-Id Bound-Authentication-Session-Id
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.
skipping to change at page 43, line 44 skipping to change at page 44, line 44
| | | | | |
| +------------+ | | | +------------+ | |
| | NE | | | | | NE | | |
| |(DQA Client)| | | | |(DQA Client)| | |
| +------+-----+ | | | +------+-----+ | |
| | | | | | | |
|QoS NSLP Reserve | | | |QoS NSLP Reserve | | |
+------------------> QAR | | +------------------> QAR | |
| (POLICY_DATA>v +- - - - -<<AAA>>- - - -> | | (POLICY_DATA>v +- - - - -<<AAA>>- - - -> |
| QSPEC) v >===>(Destination-Host, | | | QSPEC) v >===>(Destination-Host, | |
| v >=======>QoS-Authz-Data ++------------+ | | v >=======>QoS-Authorization-Data ++------------+ |
| >===========>QoS-Resources) |Authorize | | | >===========>QoS-Resources) |Authorize | |
| | |QoS resources| | | | |QoS resources| |
| | ++------------+ | | | ++------------+ |
| | QAA | | | | QAA | |
| <- - - - -<<AAA>>- - - -+ | | <- - - - -<<AAA>>- - - -+ |
| |(Result-Code, | | | |(Result-Code, | |
| |QoS-Resources, | | | |QoS-Resources, | |
| |Authz-Lifetime) | | | |Authorization-Lifetime) | |
| +---------+--------+ | | | +---------+--------+ | |
| |Install QoS state1| | | | |Install QoS state1| | |
| |+ Authz. session | | | | |+ Authorization. session | | |
| +---------+--------+ | | | +---------+--------+ | |
| |QoS NSLP Reserve | | |QoS NSLP Reserve |
| +---------------..............---------> | +---------------..............--------->
| | | | | |
| | QoS NSLP Response| | | QoS NSLP Response|
|QoS NSLP Response <---------------..............---------+ |QoS NSLP Response <---------------..............---------+
<------------------+ | <------------------+ |
| | QoS NSLP Query| | | QoS NSLP Query|
|QoS NSLP Query <---------------..............---------+ |QoS NSLP Query <---------------..............---------+
<------------------+ | <------------------+ |
|QoS NSLP Reserve | | |QoS NSLP Reserve | |
+------------------> QAR | | +------------------> QAR | |
| +- - - - -<<AAA>>- - - -> | | +- - - - -<<AAA>>- - - -> |
| | +---+---------+ | | | +---+---------+ |
| | |Authorize | | | | |Authorize | |
| | |QoS resources| | | | |QoS resources| |
| | QAA +---+---------+ | | | QAA +---+---------+ |
| <- - - - -<<AAA>>- - - -+ | | <- - - - -<<AAA>>- - - -+ |
| +---------+--------+ | | | +---------+--------+ | |
| |Install QoS state2| | | |Install QoS state2| |
| |+ Authz. session | | | |+ Authorization. session | |
| +---------+--------+ | | +---------+--------+ |
| | QoS NSLP Reserve | | | QoS NSLP Reserve |
| +---------------..............---------> | +---------------..............--------->
| | QoS NSLP Response| | | QoS NSLP Response|
|QoS NSLP Response <---------------..............---------+ |QoS NSLP Response <---------------..............---------+
<------------------+ | <------------------+ |
| | | | | |
/------------------+--Data Flow---------------------------\ /------------------+--Data Flow---------------------------\
\------------------+--------------------------------------/ \------------------+--------------------------------------/
| | | | | |
skipping to change at page 45, line 21 skipping to change at page 46, line 21
Authorization data includes, as a minimum, the identity of the AE Authorization data includes, as a minimum, the identity of the AE
(e.g., the SIP server) and an identifier of the application service (e.g., the SIP server) and an identifier of the application service
session for which QoS resources are requested. session for which QoS resources are requested.
A QoS NSLP Reserve message is intercepted and processed by the first A QoS NSLP Reserve message is intercepted and processed by the first
QoS aware Network Element. The NE uses the Diameter QoS application QoS aware Network Element. The NE uses the Diameter QoS application
to request authorization for the received QoS reservation request. to request authorization for the received QoS reservation request.
The identity of the AE (in this case the SIP server that is co- The identity of the AE (in this case the SIP server that is co-
located with a Diameter server) is put into the Destination-Host AVP, located with a Diameter server) is put into the Destination-Host AVP,
any additional session authorization data is encapsulated into the any additional session authorization data is encapsulated into the
QoS-Authz-Data AVP and the description of the QoS resources is QoS-Authorization-Data AVP and the description of the QoS resources
included into QoS-Resources AVP. These AVPs are included into a QoS is included into QoS-Resources AVP. These AVPs are included into a
Authorization Request message, which is sent to the AE. QoS Authorization Request message, which is sent to the AE.
A QAR message will be routed through the AAA network to the AE. The A QAR message will be routed through the AAA network to the AE. The
AE verifies the requested QoS against the QoS resources negotiated AE verifies the requested QoS against the QoS resources negotiated
for the service session and replies with QoS-Authorization answer for the service session and replies with QoS-Authorization answer
(QAA) message. It carries the authorization result (Result-Code AVP) (QAA) message. It carries the authorization result (Result-Code AVP)
and the description of the authorized QoS parameters (QoS-Resources and the description of the authorized QoS parameters (QoS-Resources
AVP), as well as duration of the authorization session AVP), as well as duration of the authorization session
(Authorization-Lifetime AVP). (Authorization-Lifetime AVP).
The NE interacts with the traffic control function and installs the The NE interacts with the traffic control function and installs the
skipping to change at page 46, line 14 skipping to change at page 47, line 14
| | | | | | | |
..|....Application layer SIP signaling..........|..............|.. ..|....Application layer SIP signaling..........|..............|..
. | Invite(SDP offer)| | | . . | Invite(SDP offer)| | | .
. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.> | . . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.> | .
. | 100 Trying | | | . . | 100 Trying | | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | . . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .
. |.............................................|..............| . . |.............................................|..............| .
| | +---------+-------------+| | | +---------+-------------+|
| | | Authorize request || | | | Authorize request ||
| | | Keep session data || | | | Keep session data ||
| | |/Authz-time,Session-Id/|| | | |/Authorization-time,Session-Id/||
| | +---------+-------------+| | | +---------+-------------+|
| | | | | | | |
| |<-- - -- - QIR - -- - -- -+ | | |<-- - -- - QIR - -- - -- -+ |
| |(Initial Request,Decision | | | |(Initial Request,Decision | |
| |(QoS-Resources,Authz-time)| | | |(QoS-Resources,Authorization-time)| |
| +-------+---------+ | | | +-------+---------+ | |
| |Install QoS state| | | | |Install QoS state| | |
| | + | | | | | + | | |
| | Authz. session | | | | | Authorization. session | | |
| | /Authz-time/ | | | | | /Authorization-time/ | | |
| +-------+---------+ | | | +-------+---------+ | |
| + - - -- - QIA - - - - - ->| | | + - - -- - QIA - - - - - ->| |
| | (Result-Code, | | | | (Result-Code, | |
| | QoS-Resources) | | | | QoS-Resources) | |
| | +----------+------------+ | | | +----------+------------+ |
| | | Report for successful | | | | | Report for successful | |
| | | QoS reservation | | | | | QoS reservation | |
| | |Update of reserved QoS | | | | |Update of reserved QoS | |
| | | resources | | | | | resources | |
| | +----------+------------+ | | | +----------+------------+ |
skipping to change at page 48, line 18 skipping to change at page 49, line 18
this specification or had their values assigned to existing this specification or had their values assigned to existing
namespaces managed by IANA. namespaces managed by IANA.
10.1. AVP Codes 10.1. AVP Codes
IANA is requested to allocate two AVP codes to the following: IANA is requested to allocate two AVP codes to the following:
Registry: Registry:
AVP Code Attribute Name Reference AVP Code Attribute Name Reference
----------------------------------------------------------- -----------------------------------------------------------
to be assigned QoS-Authz-Data Section 7.2 to be assigned QoS-Authorization-Data Section 7.2
to be assigned Bound-Auth-Session-Id Section 7.2 to be assigned Bound-Auth-Session-Id Section 7.2
10.2. AVP Specific Values 10.2. AVP Specific Values
IANA is requested to allocate the following sub-registry values. IANA is requested to allocate the following sub-registry values.
Sub-registry: Auth-Application-Id AVP Values (code 258) Sub-registry: Auth-Application-Id AVP Values (code 258)
Registry: Registry:
AVP Values Attribute Name Reference AVP Values Attribute Name Reference
------------- ------------------------------------------- ------------- -------------------------------------------
skipping to change at page 48, line 41 skipping to change at page 49, line 41
Sub-registry: Acct-Application-Id AVP Values (code 259) Sub-registry: Acct-Application-Id AVP Values (code 259)
Registry: Registry:
AVP Values Attribute Name Reference AVP Values Attribute Name Reference
------------- ------------------------------------------- ------------- -------------------------------------------
to be assigned DIAMETER-QOS-NOSUPPORT Section 5 to be assigned DIAMETER-QOS-NOSUPPORT Section 5
to be assigned DIAMETER-QOS-SUPPORT Section 5 to be assigned DIAMETER-QOS-SUPPORT Section 5
10.3. AVP Flags 10.3. AVP Flags
There are no new AVP flags defined for either the QoS-Authz-Data AVP There are no new AVP flags defined for either the QoS-Authorization-
or the Bound-Ath-Session-ID AVP. Data AVP or the Bound-Ath-Session-ID AVP.
10.4. Application IDs 10.4. Application IDs
IANA is requested to allocate the following application ID using the IANA is requested to allocate the following application ID using the
next value from the 7-16777215 range. next value from the 7-16777215 range.
Registry: Registry:
ID values Name Reference ID values Name Reference
----------------------------------------------------------- -----------------------------------------------------------
to be assigned Diameter QoS application Section 5 to be assigned Diameter QoS application Section 5
10.5. Command Codes 10.5. Command Codes
IANA is requested to allocate command code values for the following IANA is requested to allocate command code values for the following
from the range 289-299. from the range 289-299.
Registry: Registry:
Code Value Name Reference Code Value Name Reference
----------------------------------------------------------- -----------------------------------------------------------
to be assigned QoS-Authz-Request (QAR) Section 5.1 to be assigned QoS-Authorization-Request (QAR) Section 5.1
to be assigned QoS-Authz-Answer (QAA) Section 5.2 to be assigned QoS-Authorization-Answer (QAA) Section 5.2
to be assigned QoS-Install-Request (QIR) Section 5.3 to be assigned QoS-Install-Request (QIR) Section 5.3
to be assigned QoS-Install-Answer (QIA) Section 5.4 to be assigned QoS-Install-Answer (QIA) Section 5.4
11. Security Considerations 11. Security Considerations
This document describes a mechanism for performing authorization of a This document describes a mechanism for performing authorization of a
QoS reservation at a third party entity. Therefore, sufficient QoS reservation at a third party entity. Therefore, sufficient
information needs to be made available to the Authorizing Entity to information needs to be made available to the Authorizing Entity to
can make such an authorization decision. Information may come from can make such an authorization decision. Information may come from
various sources, including the application layer signaling, the various sources, including the application layer signaling, the
skipping to change at page 54, 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-08 (work in progress), draft-ietf-dime-qos-attributes-11 (work in progress),
October 2008. February 2009.
[I-D.ietf-dime-qos-parameters] [I-D.ietf-dime-qos-parameters]
Korhonen, J. and H. Tschofenig, "Quality of Service Korhonen, J., Tschofenig, H., and E. Davies, "Quality of
Parameters for Usage with the AAA Framework", Service Parameters for Usage with Diameter",
draft-ietf-dime-qos-parameters-07 (work in progress), draft-ietf-dime-qos-parameters-10 (work in progress),
November 2008. March 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.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
August 2005. August 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
14.2. Informative References 14.2. Informative References
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet Schulzrinne, H. and M. Stiemerling, "GIST: General
Signalling Transport", draft-ietf-nsis-ntlp-17 (work in Internet Signalling Transport", draft-ietf-nsis-ntlp-19
progress), October 2008. (work in progress), March 2009.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16
(work in progress), February 2008. (work in progress), February 2008.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
 End of changes. 43 change blocks. 
126 lines changed or deleted 128 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/