< draft-tschofenig-dime-diameter-qos-00.txt   draft-tschofenig-dime-diameter-qos-01.txt >
Diameter Maintanence and F. Alfano Diameter Maintanence and F. Alfano
Extensions (DIME) P. McCann Extensions (DIME) P. McCann
Internet-Draft Lucent Technologies Internet-Draft Lucent Technologies
Expires: September 1, 2006 H. Tschofenig Intended status: Informational H. Tschofenig
Siemens Expires: April 23, 2007 Siemens
T. Tsenov T. Tsenov
February 28, 2006 T. Tsou
October 20, 2006
Diameter Quality of Service Application Diameter Quality of Service Application
draft-tschofenig-dime-diameter-qos-00.txt draft-tschofenig-dime-diameter-qos-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 37 skipping to change at page 1, line 38
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 September 1, 2006. This Internet-Draft will expire on April 23, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes a Diameter application that performs This document describes a Diameter application that performs
Authentication, Authorization, and Accounting for Quality of Service Authentication, Authorization, and Accounting for Quality of Service
(QoS) reservations. This protocol is used by elements along the path (QoS) reservations. This protocol is used by elements along the path
skipping to change at page 2, line 17 skipping to change at page 3, line 12
the network, allowing for a wide variety of flexible deployment the network, allowing for a wide variety of flexible deployment
models. models.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Network element functional model . . . . . . . . . . . . . 7 3.1. Network element functional model . . . . . . . . . . . . . 7
3.2. Authorization models . . . . . . . . . . . . . . . . . . . 9 3.2. Authorization models . . . . . . . . . . . . . . . . . . . 9
3.3. QoS authorization considerations . . . . . . . . . . . . . 12 3.3. QoS authorization considerations . . . . . . . . . . . . . 13
4. Diameter QoS Authorization session establishment and 4. Diameter QoS Authorization session establishment and
management . . . . . . . . . . . . . . . . . . . . . . . . . . 16 management . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Parties involved . . . . . . . . . . . . . . . . . . . . . 16 4.1. Parties involved . . . . . . . . . . . . . . . . . . . . . 18
4.2. Initial QoS authorization (Diameter QoS authorization 4.2. Initial QoS authorization (Diameter QoS authorization
session establishment) . . . . . . . . . . . . . . . . . . 16 session establishment) . . . . . . . . . . . . . . . . . . 18
4.3. QoS authorization session re-authorization . . . . . . . . 20 4.3. QoS authorization session re-authorization . . . . . . . . 22
4.3.1. Client-side initiated Re-Authorization . . . . . . . . 20 4.3.1. Client-side initiated Re-Authorization . . . . . . . . 22
4.3.2. Server-side initiated Re-Authorization . . . . . . . . 21 4.3.2. Server-side initiated Re-Authorization . . . . . . . . 24
4.4. Server-side initiated QoS parameter provisioning . . . . . 22 4.4. Server-side initiated QoS parameter provisioning . . . . . 24
4.5. Session Termination . . . . . . . . . . . . . . . . . . . 23 4.5. Session Termination . . . . . . . . . . . . . . . . . . . 25
4.5.1. Client-side initiated session termination . . . . . . 23 4.5.1. Client-side initiated session termination . . . . . . 25
4.5.2. Server-side initiated session termination . . . . . . 24 4.5.2. Server-side initiated session termination . . . . . . 26
5. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6. Diameter QoS authorization application Messages . . . . . . . 28 6. Diameter QoS authorization application Messages . . . . . . . 30
6.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 29 6.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 31
6.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 29 6.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 31
6.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 30 6.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 32
6.4. QoS-Install Answer (QAA) . . . . . . . . . . . . . . . . . 31 6.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 33
6.5. Accounting Request (ACR) . . . . . . . . . . . . . . . . . 31 6.5. Accounting Request (ACR) . . . . . . . . . . . . . . . . . 33
6.6. Accounting Answer (ACA) . . . . . . . . . . . . . . . . . 32 6.6. Accounting Answer (ACA) . . . . . . . . . . . . . . . . . 34
7. Diameter QoS Authorization Application AVPs . . . . . . . . . 33 7. Diameter QoS Authorization Application AVPs . . . . . . . . . 35
7.1. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 33 7.1. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 35
7.2. Credit Control application AVPs . . . . . . . . . . . . . 33 7.2. Credit Control application AVPs . . . . . . . . . . . . . 35
7.3. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 34 7.3. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 36
7.4. Diameter QoS Application Defined AVPs . . . . . . . . . . 35 7.4. Diameter QoS Application Defined AVPs . . . . . . . . . . 37
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . . 42 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 44 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 46
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
12.1. Normative References . . . . . . . . . . . . . . . . . . . 45 12.1. Normative References . . . . . . . . . . . . . . . . . . . 47
12.2. Informative References . . . . . . . . . . . . . . . . . . 45 12.2. Informative References . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 49 Intellectual Property and Copyright Statements . . . . . . . . . . 51
1. Introduction 1. Introduction
To meet the Quality of Service needs of applications such as Voice- To meet the Quality of Service needs of applications such as Voice-
over-IP in a heavily loaded network, packets belonging to real-time over-IP in a heavily loaded network, packets belonging to real-time
application flows must be identified and segregated from other application flows must be identified and segregated from other
traffic to ensure that bandwidth, delay, and loss rate requirements traffic to ensure that bandwidth, delay, and loss rate requirements
are met. In addition, new flows should not be added to the network 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 when it is at or near capacity, which would result in degradation of
quality for all flows carried by the network. quality for all flows carried by the network.
skipping to change at page 6, line 33 skipping to change at page 6, line 33
|| || || ||
\\\\ //// \\\\ ////
\-------+-----/ \-------+-----/
| |
+---+--+ +-----+----+ +---+--+ +---+--+ +-----+----+ +---+--+
| | | NE | | | Application | | | NE | | | Application
+ NE +===+(Diameter +===+ NE +=============>> + NE +===+(Diameter +===+ NE +=============>>
| | | Client) | | | Flow | | | Client) | | | Flow
+------+ +----------+ +------+ +------+ +----------+ +------+
Figure 1: An Architecture supporting QoS-AAA Figure 1: An Architecture supporting QoS-AAA
Figure 1 depicts network elements through which application flows Figure 1 depicts network elements through which application flows
need to pass, a cloud of AAA servers, and an authorizing entity. 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 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, with the AAA cloud along the path of a given application flow,
although the figure only depicts one for clarity. QoS aware network although the figure only depicts one for clarity. QoS aware network
elements will request authorization from the AAA cloud based on an elements will request authorization from the AAA cloud based on an
incoming QoS reservation request. The AAA entities will route the incoming QoS reservation request. The AAA entities will route the
request to a designated AAA authorizing entity, for example in the request to a designated AAA authorizing entity, for example in the
home domain. The home authorizing entity will return the result of home domain. The home authorizing entity will return the result of
skipping to change at page 8, line 46 skipping to change at page 8, line 46
| Packet | | Interface | .+----------+ +---------+. | Packet | | Interface | .+----------+ +---------+.
===>|Processing|====| Selection |===.| Packet |====| Packet |.=> ===>|Processing|====| Selection |===.| Packet |====| Packet |.=>
| | |(Forwarding)| .|Classifier| Scheduler|. | | |(Forwarding)| .|Classifier| Scheduler|.
+----------+ +------------+ .+----------+ +---------+. +----------+ +------------+ .+----------+ +---------+.
............................. .............................
<.-.-> = signaling flow <.-.-> = signaling flow
=====> = data flow (sender --> receiver) =====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations <<<>>> = control and configuration operations
****** = routing table manipulation ****** = routing table manipulation
Figure 2: Network element functional model Figure 2: Network element functional model
Processing of incoming QoS reservation requests includes three Processing of incoming QoS reservation requests includes three
actions: admission control, authorization and resource reservation. actions: admission control, authorization and resource reservation.
The admission control function provides information for available The admission control function provides information for available
resources and determines whether there are enough resources to resources and determines whether there are enough resources to
fulfill the request. Authorization is performed by the Diameter fulfill the request. Authorization is performed by the Diameter
client function which involves contacting an authorization entity client function which involves contacting an authorization entity
through the AAA cloud shown in Section 3. If both checks are through the AAA cloud shown in Section 3. If both checks are
successful, the authorized QoS parameters are set in the packet successful, the authorized QoS parameters are set in the packet
classifier and the packet scheduler. Note that the parameters passed classifier and the packet scheduler. Note that the parameters passed
to the Traffic Control function may be different from requested QoS to the Traffic Control function may be different from requested QoS
(depending on the authorization decision). Once the requested (depending on the authorization decision). Once the requested
resource is granted, the Resource Management function provides resource is granted, the Resource Management function provides
accounting information to the Authorizing entity using the Diameter accounting information to the Authorizing entity using the Diameter
client function. client function.
3.2. Authorization models 3.2. Authorization models
Three fundamental models for authorizing QoS reservations exist: one Three fundamental models for authorizing QoS reservations exist: one
two-party and two three party models. See [I-D.tschofenig-nsis-aaa- two-party and two three party models. See
issues] and in [I-D.tschofenig-nsis-qos-authz-issues] for a more [I-D.tschofenig-nsis-aaa-issues] and in
detailed discussion of authorization models and the impact for QoS [I-D.tschofenig-nsis-qos-authz-issues] for a more detailed discussion
reservations. The notation adopted here is in respect to the entity of authorization models and the impact for QoS reservations. The
that performs the QoS authorization. The authentication of the QoS notation adopted here is in respect to the entity that performs the
requesting entity might be done at the network element as part of the QoS authorization. The authentication of the QoS requesting entity
QoS signaling protocol, or by an off-path protocol run (on the might be done at the network element as part of the QoS signaling
application layer or for network access authentication) or the protocol, or by an off-path protocol run (on the application layer or
authorizing entity might be contacted with request for authentication for network access authentication) or the authorizing entity might be
and authorization of the QoS requesting entity. From the Diameter contacted with request for authentication and authorization of the
QoS application's point of view these models differ in type of QoS requesting entity. From the Diameter QoS application's point of
information that need to be carried. Here we focus on the 'Three view these models differ in type of information that need to be
party model' (Figure 3) and the Token-based three party model' carried. Here we focus on the 'Three party model' (Figure 3) and the
(Figure 4). With the 'Two party model' the QoS resource requesting Token-based three party model' (Figure 4). With the 'Two party
entity is authenticated by the Network Element and the authorization model' the QoS resource requesting entity is authenticated by the
decision is made either locally at the Network Element itself or Network Element and the authorization decision is made either locally
offloaded to a trusted entity (most likely within the same at the Network Element itself or offloaded to a trusted entity (most
administrative domain). In the former case no Diameter QoS protocol likely within the same administrative domain). In the former case no
interaction is required. Diameter QoS protocol interaction is required.
+--------------+ +--------------+
| Entity | | Entity |
| authorizing | <......+ | authorizing | <......+
| resource | . | resource | .
| request | . | request | .
+------------+-+ . +------------+-+ .
--^----------|-- . . --^----------|-- . .
///// | | \\\\\ . ///// | | \\\\\ .
// | | \\ . // | | \\ .
skipping to change at page 10, line 27 skipping to change at page 10, line 27
\\ | | // . \\ | | // .
\\\\\ | | ///// . \\\\\ | | ///// .
QoS --|----------v-- . . QoS --|----------v-- . .
+-------------+ request +-+------------+ . +-------------+ request +-+------------+ .
| Entity |----------------->| NE | . | Entity |----------------->| NE | .
| requesting | | performing | . | requesting | | performing | .
| resource |granted / rejected| QoS | <.....+ | resource |granted / rejected| QoS | <.....+
| |<-----------------| reservation | financial | |<-----------------| reservation | financial
+-------------+ +--------------+ settlement +-------------+ +--------------+ settlement
Figure 3: Three Party Model Figure 3: Three Party Model
With the 'Three party model' a QoS reservation request that arrives With the 'Three party model' a QoS reservation request that arrives
at the Network Element is forwarded to the Authorizing Entity (e.g., at the Network Element is forwarded to the Authorizing Entity (e.g.,
in the user's home network), where the authorization decision is in the user's home network), where the authorization decision is
made. A business relationship, such as a roaming agreement, between made. A business relationship, such as a roaming agreement, between
the visited network and the home network ensures that the visited the visited network and the home network ensures that the visited
network is compensated for the resources consumed by the user via the network is compensated for the resources consumed by the user via the
home network. home network.
financial settlement financial settlement
skipping to change at page 11, line 28 skipping to change at page 11, line 28
| | \ | | . / . | | \ | | . / .
| | \ | | / . | | \ | | / .
| | QoS request |-----V . . | | QoS request |-----V . .
+-------------+ + Authz. Token +--------+-----+ . +-------------+ + Authz. Token +--------+-----+ .
| Entity |----------------->| NE | . | Entity |----------------->| NE | .
| requesting | | performing | . | requesting | | performing | .
| resource |granted / rejected| QoS | <....+ | resource |granted / rejected| QoS | <....+
| |<-----------------| reservation | | |<-----------------| reservation |
+-------------+ +--------------+ +-------------+ +--------------+
Figure 4: Token-based Three Party Model Figure 4: Token-based Three Party Model
The 'Token-based Three Party model' is applicable to environments The 'Token-based Three Party model' is applicable to environments
where a previous protocol interaction is used to request where a previous protocol interaction is used to request
authorization tokens to assist the authorization process at the authorization tokens to assist the authorization process at the
Network Element or the Authorizing Entity. Network Element or the Authorizing Entity.
The QoS resource requesting entity may be involved in an application The QoS resource requesting entity may be involved in an application
layer protocol interaction, for example using SIP, with the layer protocol interaction, for example using SIP, with the
Authorizing Entity. As part of this interaction, authentication and Authorizing Entity. As part of this interaction, authentication and
authorization at the application layer might take place. As a result authorization at the application layer might take place. As a result
skipping to change at page 12, line 19 skipping to change at page 12, line 19
o An identifier referring to a specific application protocol session o An identifier referring to a specific application protocol session
for which the token was issued and for which the token was issued and
o A keyed message digest or digital signature protecting the content o A keyed message digest or digital signature protecting the content
of the authorization token. of the authorization token.
A possible structure for the authorization token and the policy A possible structure for the authorization token and the policy
element carrying it are proposed in context of RSVP [RFC3520], with element carrying it are proposed in context of RSVP [RFC3520], with
the OSP [ETSI-OSP] or as outlined in [I-D.ietf-sipping-trait-authz] the OSP [ETSI-OSP] or as outlined in [I-D.ietf-sipping-trait-authz]
and [I-D.tschofenig-sip-saml]. and [I-D.tschofenig-sip-saml].
In the scenario mentioned above, where the QoS resource requesting
entity is involved in an application layer protocol interaction with
the Authorizing entity, it may be worthwhile to consider a token less
binding mechanism also. The application layer protocol interaction
may have indicated the transport port numbers at the QoS resource
requesting entity where it might receive media streams, for example
in SIP/SDP signalling these port numbers are advertised. The QoS
resource requesting entity may also use these port numbers in some IP
filter indications to the NE performing QoS reservation so that it
may properly tunnel the inbound packets. The NE performing QoS
reservation will forward the QoS resource requesting entity's IP
address and the IP filter indications to the Authorizing entity in
the QoS authz. request. The Authorizing entity will use the QoS
resource requesting entity's IP address and the port numbers in the
IP filter indication, which will match the port numbers advertised in
the earlier application layer protocol interaction, to identify the
right piece of policy information to be sent to the NE performing the
QoS reservation in the QoS authz. response.
A Three party model based on "push" - where the Authorizing entity,
subsequent to a successful application layer authorization, will send
the policy information unsolicited to the NE performing QoS
reservation is shown below.
financial settlement
...........................+
Application Layer V ------- .
Protocol +--------------+ / QoS AAA \ .
+-------------->| | / protocol \ .
| | Authorizing +--------------+ \ .
| | Entity | | | | .
| + |<--+----+ | | .
| +--------------+ |QoS | |QoS |.
| install| |install
| |rsp. | |req. |.
| | | | |.
| | | | . | .
| \ | | . / .
| \ | | / .
V |-----V . .
+-------------+ +--------+-----+ .
| Entity | | NE | .
| requesting | | performing | .
| resource |QoS rsrc granted | QoS | <....+
| |<-----------------| reservation |
+-------------+ +--------------+
Figure 5: Three Party Push Model
In the three party QoS model where the QoS resource requesting entity
is involved in an application layer protocol interaction with the
Authorizing entity, the Authorizing entity may be considered as two
separate functional entities - an Application function (AF)and a
Policy Decision function (PDF). The AF and PDF interact using the
QoS AAA protocol. The AF will pass dynamic QoS-related application
information with the PDF. The PDF will choose the right piece of
policy information to be applied at the Policy Enforcement Point
(PEP) in the NE performing QoS reservation.
The policy information may be pushed to the PEP or may be requested/
pulled by the NE performing QoS reservation. The first message of
the QoS AAA session between the AF and the PDF may include an
indication on whether to use the push or the pull mode.
3.3. QoS authorization considerations 3.3. QoS authorization considerations
A QoS authorization application must meet a number of requirements A QoS authorization application must meet a number of requirements
applicable to a diverse set of networking environments and services. applicable to a diverse set of networking environments and services.
It should be compliant with different deployment scenarios with It should be compliant with different deployment scenarios with
specific QoS signaling models and security issues. Satisfying the specific QoS signaling models and security issues. Satisfying the
requirements listed below while interworking with QoS signaling requirements listed below while interworking with QoS signaling
protocols, a Diameter QoS application should accommodate the protocols, a Diameter QoS application should accommodate the
capabilities of the QoS signaling protocols rather than introducing capabilities of the QoS signaling protocols rather than introducing
functional requirements on them. A list of requirements for a QoS functional requirements on them. A list of requirements for a QoS
skipping to change at page 16, line 37 skipping to change at page 18, line 37
between the the QoS resource requesting entity and the QoS Network between the the QoS resource requesting entity and the QoS Network
Element might be accomplished using the NSIS protocol suite, RSVP or Element might be accomplished using the NSIS protocol suite, RSVP or
a link layer signaling protocol. A description of these protocols is a link layer signaling protocol. A description of these protocols is
also outside the scope of this document and a tight coupling with also outside the scope of this document and a tight coupling with
these protocols is not desirable since this applications aims to be these protocols is not desirable since this applications aims to be
generic. generic.
4.2. Initial QoS authorization (Diameter QoS authorization session 4.2. Initial QoS authorization (Diameter QoS authorization session
establishment) establishment)
Figure 6 shows the protocol interaction between a resource requesting Figure 7 shows the protocol interaction between a resource requesting
entity, a Network Element and the Authorizing Entity. entity, a Network Element and the Authorizing Entity.
A request for a QoS reservation received by a Network Element A request for a QoS reservation received by a Network Element
initiates a Diameter QoS authorization session. The Network Element initiates a Diameter QoS authorization session. The Network Element
generates a QoS-Authorization-Request (QAR) message in which it maps generates a QoS-Authorization-Request (QAR) message in which it maps
required objects from the QoS signaling message to Diameter payload required objects from the QoS signaling message to Diameter payload
objects - Attribute Value Parts (AVPs, [RFC3588]). objects - Attribute Value Pairs (AVPs, [RFC3588]).
+----------------------------------+-------------------------------+ +----------------------------------+-------------------------------+
| QoS authorization data | Diameter QoS AVPs (Section 7) | | QoS authorization data | Diameter QoS AVPs (Section 7) |
+----------------------------------+-------------------------------+ +----------------------------------+-------------------------------+
| Authorizing entity ID (e.g., | Destination-Host | | Authorizing entity ID (e.g., | Destination-Host |
|taken from authorization token or | Destination-Realm | |taken from authorization token or | Destination-Realm |
|from Network Access ID(NAI), | | |from Network Access ID(NAI), | |
|[RFC2486] of the QoS requesting | | |[RFC2486] of the QoS requesting | |
|entity) | | |entity) | |
+----------------------------------+-------------------------------+ +----------------------------------+-------------------------------+
skipping to change at page 18, line 48 skipping to change at page 20, line 48
| |CC-Time,Acc-Multisess-id)| | |CC-Time,Acc-Multisess-id)|
| | +--------+--------------+ | | +--------+--------------+
| | | Report for successful | | | | Report for successful |
| | | QoS reservation | | | | QoS reservation |
| | |Update of reserved QoS | | | |Update of reserved QoS |
| | | resources | | | | resources |
| | +--------+--------------+ | | +--------+--------------+
| |< - - - - ACA - - - - - -+ | |< - - - - ACA - - - - - -+
| | | | | |
Figure 6: Initial QoS request authorization Figure 7: Initial QoS request authorization
The Authorizing Entity keeps authorization session state and SHOULD The Authorizing Entity keeps authorization session state and SHOULD
save additional information for management of the session (e.g., Acc- save additional information for management of the session (e.g., Acc-
Multi-Session-Id, Signaling-Session-Id, authentication data) as part Multi-Session-Id, Signaling-Session-Id, authentication data) as part
of the session state information. A Signaling-session-Id (if of the session state information. A Signaling-session-Id (if
present) SHOULD be used together with the generated Acc-Multi- present) SHOULD be used together with the generated Acc-Multi-
Session-Id AVP (see Section 7.3) for binding the authorization and Session-Id AVP (see Section 7.3) for binding the authorization and
the accounting session information in case of end host mobility the accounting session information in case of end host mobility
(i.e., to correlate the Diameter sessions that are initiated for the (i.e., to correlate the Diameter sessions that are initiated for the
same signaling session from different QoS NE). same signaling session from different QoS NE).
skipping to change at page 20, line 52 skipping to change at page 22, line 52
4.3.1. Client-side initiated Re-Authorization 4.3.1. Client-side initiated Re-Authorization
The Authorizing Entity provides the duration of the authorization The Authorizing Entity provides the duration of the authorization
session as part of the QoS-Authorization-Answer message (QAA). At session as part of the QoS-Authorization-Answer message (QAA). At
any time before expiration of this period, a new QoS-Authorization- any time before expiration of this period, a new QoS-Authorization-
Request message (QAR) MAY be sent to the Authorizing Entity. The Request message (QAR) MAY be sent to the Authorizing Entity. The
transmission of the QAR MAY be triggered when the Network Element transmission of the QAR MAY be triggered when the Network Element
receives a QoS signaling message that requires modification of the receives a QoS signaling message that requires modification of the
authorized parameters of an ongoing QoS session, when authorization authorized parameters of an ongoing QoS session, when authorization
lifetime expires or by an accounting event. (see Section 5)(Figure 7) lifetime expires or by an accounting event. (see Section 5)(Figure 8)
Authorizing Authorizing
End-Host Network Element Entity End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server) QoS Client) QoS Server)
| | | | | |
|=====================Data Flow==========================> |=====================Data Flow==========================>
| | | | | |
| +-------+----------+ | | +-------+----------+ |
| |Authz-time/CC-Time| | | |Authz-time/CC-Time| |
| | expires | | | | expires | |
skipping to change at page 21, line 46 skipping to change at page 23, line 46
| |CC-Time,Acc-Multisess-id)| | |CC-Time,Acc-Multisess-id)|
| | +--------+--------------+ | | +--------+--------------+
| | |Update of QoS resources| | | |Update of QoS resources|
| | |/CC-Time,Cost/ used | | | |/CC-Time,Cost/ used |
| | +--------+--------------+ | | +--------+--------------+
| |< - - - - ACA - - - - - -+ | |< - - - - ACA - - - - - -+
| | | | | |
|=====================Data Flow==========================> |=====================Data Flow==========================>
| | | |
Figure 7: QoS request re-authorization Figure 8: QoS request re-authorization
4.3.2. Server-side initiated Re-Authorization 4.3.2. Server-side initiated Re-Authorization
The Authorizing Entity MAY optionally initiate a QoS re-authorization The Authorizing Entity MAY optionally initiate a QoS re-authorization
by issuing a Re-Auth-Request message (RAR) as defined in the Diameter by issuing a Re-Auth-Request message (RAR) as defined in the Diameter
base protocol [RFC3588]. A Network Element client that receives such base protocol [RFC3588]. A Network Element client that receives such
a RAR message with Session-Id matching a currently active QoS session a RAR message with Session-Id matching a currently active QoS session
acknowledges the request by sending the Re-Auth-Answer (RAA) message acknowledges the request by sending the Re-Auth-Answer (RAA) message
and MUST initiate a QoS reservation re-authorization by sending a and MUST initiate a QoS reservation re-authorization by sending a
QoS-Authorization-Request (QAR) message towards the Authorizing QoS-Authorization-Request (QAR) message towards the Authorizing
skipping to change at page 22, line 22 skipping to change at page 24, line 27
In certain deployment scenarios (mostly applicable for local QoS In certain deployment scenarios (mostly applicable for local QoS
provision) an active control over the QoS resource and QoS enabled provision) an active control over the QoS resource and QoS enabled
data flows from the network side is required. Therefore, the data flows from the network side is required. Therefore, the
Authorizing Entity is enabled to update installed QoS parameters and Authorizing Entity is enabled to update installed QoS parameters and
flow state at the Network Element by sending a QoS-Install Request flow state at the Network Element by sending a QoS-Install Request
message (QIR). Network Elements MUST apply the updates and respond message (QIR). Network Elements MUST apply the updates and respond
with an QoS-Install Answer message (QIA). This functionality, for with an QoS-Install Answer message (QIA). This functionality, for
example, allows the update of already authorized flow status of an example, allows the update of already authorized flow status of an
established QoS reservation due to a change at the application layer established QoS reservation due to a change at the application layer
session (Figure 8). session (Figure 9).
Authorizing Authorizing
End-Host Network Element Entity End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server) QoS Client) QoS Server)
| | | | | |
+===================+=Data Flow==========================> +===================+=Data Flow==========================>
| | +--------+--------------+ | | +--------+--------------+
| | |Data flow preemption | | | |Data flow preemption |
| | +--------+--------------+ | | +--------+--------------+
skipping to change at page 22, line 46 skipping to change at page 25, line 4
| +-------+---------+ | | +-------+---------+ |
| |Update QoS state | | | |Update QoS state | |
| | + | | | | + | |
| | Authz. session | | | | Authz. session | |
| |/QoS-Flow-State= | | | |/QoS-Flow-State= | |
| | CLOSE/ | | | | CLOSE/ | |
| +-------+---------+ | | +-------+---------+ |
+====Data Flow=====>X | +====Data Flow=====>X |
| +- - - - - QIA - - - - - >| | +- - - - - QIA - - - - - >|
| | (Result-Code) | | | (Result-Code) |
Figure 9: Server-side initiated QoS parameter provisioning
Figure 8: Server-side initiated QoS parameter provisioning
The Authorizing Entity MAY initiate a QoS authorization session The Authorizing Entity MAY initiate a QoS authorization session
establishment and QoS reservation state installation (prior to a establishment and QoS reservation state installation (prior to a
request from a Network Element). This function requires that the request from a Network Element). This function requires that the
Authorizing Entity has knowledge of specific information identifying Authorizing Entity has knowledge of specific information identifying
the Network Element that should be contacted and the data flow for the Network Element that should be contacted and the data flow for
which the QoS reservation should be established.(mostly applicable which the QoS reservation should be established.(mostly applicable
for local scenarios) for local scenarios)
4.5. Session Termination 4.5. Session Termination
skipping to change at page 23, line 23 skipping to change at page 25, line 27
The authorization session for an installed QoS reservation state MAY The authorization session for an installed QoS reservation state MAY
be terminated by the Diameter client by sending a Session- be terminated by the Diameter client by sending a Session-
Termination-Request message (STR) to the Diameter server. This is a Termination-Request message (STR) to the Diameter server. This is a
Diameter base protocol function and it is defined in [RFC3588]. Diameter base protocol function and it is defined in [RFC3588].
Session termination can be caused by a QoS signaling messaging Session termination can be caused by a QoS signaling messaging
requesting deletion of the existing QoS reservation state or it can requesting deletion of the existing QoS reservation state or it can
be caused as a result of a soft-state expiration of the QoS be caused as a result of a soft-state expiration of the QoS
reservation state. After a successful termination of the reservation state. After a successful termination of the
authorization session, final accounting messages MUST be exchanged authorization session, final accounting messages MUST be exchanged
(Figure 9). It should be noted that the two sessions (authorization (Figure 10). It should be noted that the two sessions (authorization
and accounting) have independent management by the Diameter base and accounting) have independent management by the Diameter base
protocol, which allows for finalizing the accounting session after protocol, which allows for finalizing the accounting session after
the end of the authorization session. the end of the authorization session.
Authorizing Authorizing
End-Host Network Element Entity End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server) QoS Client) QoS Server)
| | | | | |
|==Data Flow==>X /Stop of the data flow/ | |==Data Flow==>X /Stop of the data flow/ |
skipping to change at page 24, line 42 skipping to change at page 26, line 42
| | Report for successful | | | Report for successful |
| | end of QoS session | | | end of QoS session |
| +--------+--------------+ | +--------+--------------+
|< - - - - ACA - - - - - -+ |< - - - - ACA - - - - - -+
| |
| QoS Responder | QoS Responder
| Node | Node
|<---------QoS-Response----....----+ |<---------QoS-Response----....----+
| | | |
Figure 9: Client-side initiated session termination Figure 10: Client-side initiated session termination
4.5.2. Server-side initiated session termination 4.5.2. Server-side initiated session termination
At anytime during a session the Authorizing Entity MAY send an Abort- At anytime during a session the Authorizing Entity MAY send an Abort-
Session-Request message (ASR) to the Network Element. This is a Session-Request message (ASR) to the Network Element. This is a
Diameter base protocol function and it is defined in [RFC3588]. Diameter base protocol function and it is defined in [RFC3588].
Possible reasons for initiating the ASR message to the Network Possible reasons for initiating the ASR message to the Network
Element are insufficient credits or session termination at the Element are insufficient credits or session termination at the
application layer. The ASR message results in termination of the application layer. The ASR message results in termination of the
authorized session, release of the reserved resources at the Network authorized session, release of the reserved resources at the Network
Element and transmission of an appropriate QoS signaling message Element and transmission of an appropriate QoS signaling message
indicating a notification to other Network Elements aware of the indicating a notification to other Network Elements aware of the
signaling session. A final accounting message exchange MUST be signaling session. A final accounting message exchange MUST be
triggered as a result of this ASR message exchange (Figure 10). triggered as a result of this ASR message exchange (Figure 11).
Authorizing Authorizing
End-Host Network Element Entity End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server) QoS Client) QoS Server)
| | | | | |
|=====================Data Flow==========================> |=====================Data Flow==========================>
| | | |
| |< - - - - ASR - - - - - -+ | |< - - - - ASR - - - - - -+
| | | | | |
skipping to change at page 25, line 46 skipping to change at page 27, line 46
| +--------+--------------+ | +--------+--------------+
| | Report for successful | | | Report for successful |
| | end of QoS session | | | end of QoS session |
| +--------+--------------+ | +--------+--------------+
|< - - - - ACA - - - - - -+ |< - - - - ACA - - - - - -+
| QoS Responder | QoS Responder
| Node | Node
|<---------QoS-Response----....----+ |<---------QoS-Response----....----+
| | | |
Figure 10: Server-side initiated session termination Figure 11: Server-side initiated session termination
5. Accounting 5. Accounting
The Diameter QoS application provides accounting for usage of The Diameter QoS application provides accounting for usage of
reserved QoS resources. Diameter QoS accounting has built-in support reserved QoS resources. Diameter QoS accounting has built-in support
for online, duration based accounting. This accounting is based on for online, duration based accounting. This accounting is based on
the notion that the routers making the QoS Authorization Request the notion that the routers making the QoS Authorization Request
(Diameter QoS clients) are in the best position to determine the cost (Diameter QoS clients) are in the best position to determine the cost
of those resources. This cost represents the financial settlement of those resources. This cost represents the financial settlement
that will be ultimately demanded by the owner of the router if the that will be ultimately demanded by the owner of the router if the
skipping to change at page 26, line 44 skipping to change at page 28, line 44
in the Cost-Information AVPs, the Resource Authorizing Entity can use in the Cost-Information AVPs, the Resource Authorizing Entity can use
the CC-Time AVP to guarantee that the total cost of the session will the CC-Time AVP to guarantee that the total cost of the session will
not exceed a certain threshold, which allows, for example, support of not exceed a certain threshold, which allows, for example, support of
prepaid users. prepaid users.
Each ACR message contains a triplet of QoS-Authorization-Resources Each ACR message contains a triplet of QoS-Authorization-Resources
AVP, Cost-Information AVP, and CC-Time AVP. This represents the AVP, Cost-Information AVP, and CC-Time AVP. This represents the
total time consumed at the given cost for the given resources. Note total time consumed at the given cost for the given resources. Note
that an ACR message MUST be sent separately for each interval defined that an ACR message MUST be sent separately for each interval defined
by the Tariff-Time-Change AVPs and the expiration of the CC-Time by the Tariff-Time-Change AVPs and the expiration of the CC-Time
returned in the QAA (Figure 7). returned in the QAA (Figure 8).
The Network Element starts an accounting session by sending an The Network Element starts an accounting session by sending an
Accounting-Request message (ACR) after successful QoS reservation and Accounting-Request message (ACR) after successful QoS reservation and
activation of the data flow (Figure 6). After every successful re- activation of the data flow (Figure 7). After every successful re-
authorization procedure the Network element MUST initiate an interim authorization procedure the Network element MUST initiate an interim
accounting message exchange (Figure 7). After successful session accounting message exchange (Figure 8). After successful session
termination the Network element MUST initiate a final exchange of termination the Network element MUST initiate a final exchange of
accounting messages for terminating of the accounting session and accounting messages for terminating of the accounting session and
reporting final records for the usage of the QoS resources reserved. reporting final records for the usage of the QoS resources reserved.
(Figure 9). (Figure 10).
6. Diameter QoS authorization application Messages 6. Diameter QoS authorization application Messages
The Diameter QoS Application requires the definition of new mandatory The Diameter QoS Application requires the definition of new mandatory
AVPs and Command-codes (Section 3 of [RFC3588]). Four new Diameter AVPs and Command-codes (Section 3 of [RFC3588]). Four new Diameter
messages are defined along with Command-Codes whose values MUST be messages are defined along with Command-Codes whose values MUST be
supported by all Diameter implementations that conform to this supported by all Diameter implementations that conform to this
specification. specification.
Command-Name Abbrev. Code Reference Command-Name Abbrev. Code Reference
skipping to change at page 31, line 5 skipping to change at page 33, line 5
{ Destination-Realm } { Destination-Realm }
{ Auth-Request-Type } { Auth-Request-Type }
[ Destination-Host ] [ Destination-Host ]
* [ QoS-Authorization-Resources ] * [ QoS-Authorization-Resources ]
[ Session-Timeout ] [ Session-Timeout ]
[ Authz-Session-Lifetime ] [ Authz-Session-Lifetime ]
[ Authz-Grace-Period ] [ Authz-Grace-Period ]
[ Authz-Session-Volume ] [ Authz-Session-Volume ]
* [ AVP ] * [ AVP ]
6.4. QoS-Install Answer (QAA) 6.4. QoS-Install Answer (QIA)
The QoS-Install Answer message (QAA), indicated by the Command-Code The QoS-Install Answer message (QIA), indicated by the Command-Code
field set to TBD and 'R' bit cleared in the Command Flags field is field set to TBD 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.
The message format is defined as follows: The message format is defined as follows:
<QoS-Install-Answer> ::= < Diameter Header: XXX, PXY > <QoS-Install-Answer> ::= < Diameter Header: XXX, PXY >
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Auth-Application-Id }
skipping to change at page 40, line 44 skipping to change at page 42, line 44
| | | | | |
/------------------+--Data Flow---------------------------\ /------------------+--Data Flow---------------------------\
\------------------+--------------------------------------/ \------------------+--------------------------------------/
| | | | | |
.-.-.-.-. SIP signaling .-.-.-.-. SIP signaling
--------- QoS NSLP signaling --------- QoS NSLP signaling
- - - - - Diameter QoS Application messages - - - - - Diameter QoS Application messages
========= Mapping of objects between QoS and AAA protocol ========= Mapping of objects between QoS and AAA protocol
Figure 27: Example for a token-based QoS authorization Figure 28: Example for a token-based QoS authorization
The communication starts with SIP signaling between the two end The communication starts with SIP signaling between the two end
points and the SIP server for negotiation and authorization of the points and the SIP server for negotiation and authorization of the
requested service and its parameters (Figure 27). As a part of the requested service and its parameters (Figure 28). As a part of the
process, the SIP server verifies whether the user at Host A is process, the SIP server verifies whether the user at Host A is
authorized to use the requested service (and potentially the ability authorized to use the requested service (and potentially the ability
to be charged for the service usage). Negotiated session parameters to be charged for the service usage). Negotiated session parameters
are provided to the end host. are provided to the end host.
Subsequently, Host A initiates a QoS signaling message towards Host Subsequently, Host A initiates a QoS signaling message towards Host
B. It sends a QoS NSLP Reserve message, in which it includes B. It sends a QoS NSLP Reserve message, in which it includes
description of the required QoS (QSPEC object) and authorization data description of the required QoS (QSPEC object) and authorization data
for negotiated service session (part of the POLICY_DATA object). for negotiated service session (part of the POLICY_DATA object).
Authorization data includes, as a minimum, the identity of the Authorization data includes, as a minimum, the identity of the
skipping to change at page 45, line 10 skipping to change at page 47, line 10
11. Open Issues 11. Open Issues
Open issues related to this draft are listed at the issue tracker Open issues related to this draft are listed at the issue tracker
available at: http://www.tschofenig.com:8080/diameter-qos/ available at: http://www.tschofenig.com:8080/diameter-qos/
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-nsis-qspec] [I-D.ietf-nsis-qspec]
Ash, J., "QoS-NSLP QSPEC Template", Ash, J., "QoS NSLP QSPEC Template",
draft-ietf-nsis-qspec-08 (work in progress), draft-ietf-nsis-qspec-12 (work in progress), October 2006.
December 2005.
[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.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 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.
skipping to change at page 45, line 42 skipping to change at page 47, line 41
[ETSI-OSP] [ETSI-OSP]
European Telecommunications Standards Institute, European Telecommunications Standards Institute,
"Telecommunications and Internet Protocol Harmonization "Telecommunications and Internet Protocol Harmonization
Over Networks (TIPHON); Open Settlement Protocol (OSP) Over Networks (TIPHON); Open Settlement Protocol (OSP)
for Inter-domain pricing, authorization, and usage for Inter-domain pricing, authorization, and usage
exchange", TS 101 321. exchange", TS 101 321.
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-09 (work in Signaling Transport", draft-ietf-nsis-ntlp-11 (work in
progress), February 2006. progress), August 2006.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., "NSLP for Quality-of-Service signalling", Manner, J., "NSLP for Quality-of-Service Signaling",
draft-ietf-nsis-qos-nslp-09 (work in progress), draft-ietf-nsis-qos-nslp-11 (work in progress), June 2006.
February 2006.
[I-D.ietf-sipping-trait-authz] [I-D.ietf-sipping-trait-authz]
Peterson, J., "Trait-based Authorization Requirements for Peterson, J., "Trait-based Authorization Requirements for
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sipping-trait-authz-02 (work in progress), draft-ietf-sipping-trait-authz-02 (work in progress),
January 2006. January 2006.
[I-D.tschofenig-nsis-aaa-issues] [I-D.tschofenig-nsis-aaa-issues]
Tschofenig, H., "NSIS Authentication, Authorization and Tschofenig, H., "NSIS Authentication, Authorization and
Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 Accounting Issues", draft-tschofenig-nsis-aaa-issues-01
(work in progress), March 2003. (work in progress), March 2003.
[I-D.tschofenig-nsis-qos-authz-issues] [I-D.tschofenig-nsis-qos-authz-issues]
Tschofenig, H., "QoS NSLP Authorization Issues", Tschofenig, H., "QoS NSLP Authorization Issues",
draft-tschofenig-nsis-qos-authz-issues-00 (work in draft-tschofenig-nsis-qos-authz-issues-00 (work in
progress), June 2003. progress), June 2003.
[I-D.tschofenig-sip-saml] [I-D.tschofenig-sip-saml]
Tschofenig, H., "Using SAML for SIP", Tschofenig, H., "SIP SAML Profile and Binding",
draft-tschofenig-sip-saml-04 (work in progress), draft-tschofenig-sip-saml-05 (work in progress),
July 2005. March 2006.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999. RFC 2486, January 1999.
skipping to change at page 49, line 5 skipping to change at page 50, line 40
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Tseno Tsenov Tseno Tsenov
Sofia, Sofia,
Bulgaria Bulgaria
Email: tseno.tsenov@mytum.de Email: tseno.tsenov@mytum.de
Intellectual Property Statement Tina Tsou
Shenzhen,
P.R.C
Email: tena@huawei.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 49, line 29 skipping to change at page 51, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 (2006). 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 39 change blocks. 
109 lines changed or deleted 177 lines changed or added

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