[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Authentication, Authorization and                              F. Alfano
Accounting                                                     P. McCann
Internet-Draft                                       Lucent Technologies
Expires: August 25, 2005                                   H. Tschofenig
                                                                 Siemens
                                                       February 21, 2005


                Diameter Quality of Service Application
                    draft-alfano-aaa-qosprot-02.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a Diameter Application that performs
   Authentication, Authorization, and Accounting for Quality of Service
   (QoS) reservations.  This protocol is used by elements along the path
   of a given application flow to authenticate a reservation request,



Alfano, et al.           Expires August 25, 2005                [Page 1]


Internet-Draft    Diameter Quality of Service Application  February 2005


   ensure that the reservation is authorized, and to account for
   resources consumed during the lifetime of the application flow.
   Clients that implement the Diameter QoS application contact an
   authorizing entity/application server that is located somewhere in
   the network, allowing for a wide variety of flexible deployment
   models.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1   Network element functional model . . . . . . . . . . . . .  6
     3.2   Requirements for a QoS AAA protocol  . . . . . . . . . . .  7
   4.  QoS Application Messages . . . . . . . . . . . . . . . . . . . 10
   5.  QoS Authorization session  . . . . . . . . . . . . . . . . . . 11
     5.1   Authorization models . . . . . . . . . . . . . . . . . . . 11
     5.2   Session Initiation . . . . . . . . . . . . . . . . . . . . 12
     5.3   Session Establishment  . . . . . . . . . . . . . . . . . . 13
     5.4   QoS Re-Authorization . . . . . . . . . . . . . . . . . . . 13
       5.4.1   Client-side initiated Re-Authorization . . . . . . . . 13
       5.4.2   Server-side initiated Re-Authorization . . . . . . . . 14
     5.5   Session Termination  . . . . . . . . . . . . . . . . . . . 14
       5.5.1   Client-side initiated session termination  . . . . . . 14
       5.5.2   Server-side initiated session termination  . . . . . . 14
   6.  Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Diameter QoS Messages  . . . . . . . . . . . . . . . . . . . . 16
     7.1   QoS-Request (QAR) Command  . . . . . . . . . . . . . . . . 16
     7.2   QoS-Answer (QAA) Command . . . . . . . . . . . . . . . . . 16
   8.  Diameter QoS AVPs  . . . . . . . . . . . . . . . . . . . . . . 18
     8.1   Diameter Base Protocol AVPs  . . . . . . . . . . . . . . . 18
     8.2   Credit Control . . . . . . . . . . . . . . . . . . . . . . 18
     8.3   Authentication/Authorization . . . . . . . . . . . . . . . 19
     8.4   Accounting AVPs  . . . . . . . . . . . . . . . . . . . . . 19
     8.5   Diameter QoS Application Defined AVPs  . . . . . . . . . . 19
   9.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 26
   11.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
   12.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
   13.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . 29
   14.   References . . . . . . . . . . . . . . . . . . . . . . . . . 30
     14.1  Normative References . . . . . . . . . . . . . . . . . . . 30
     14.2  Informative References . . . . . . . . . . . . . . . . . . 30
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
       Intellectual Property and Copyright Statements . . . . . . . . 33






Alfano, et al.           Expires August 25, 2005                [Page 2]


Internet-Draft    Diameter Quality of Service Application  February 2005


1.  Introduction

   To meet the Quality of Service needs of applications such as
   Voice-over-IP in a heavily loaded network, packets belonging to
   real-time application flows must be identified and segregated from
   other traffic to ensure that bandwidth, delay, and loss rate
   requirements are met.  In addition, new flows should not be added to
   the network when it is at or near capacity, which would result in
   degradation of quality for all flows carried by the network.

   In some cases, these goals can be achieved with mechanisms such as
   differentiated services and/or end-to-end congestion and admission
   control.  However, when bandwidth is scarce and must be carefully
   managed, such as in cellular networks, or when applications and
   transport protocols lack the capability to perform end-to-end
   congestion control, explicit reservation techniques are required.  In
   these cases, the endpoints will send reservation requests to edge
   and/or interior nodes along the communication path.  In addition to
   verifying whether resources are available, the recipient of a
   reservation request must also authenticate and authorize the request,
   especially in an environment where the endpoints are not trusted.  In
   addition, these nodes will generate accounting information about the
   resources used and attribute usage to the requesting endpoints.  This
   will enable the owner of the network element to generate
   usage-sensitive billing records and to understand how to allocate new
   network capacity.

   A variety of protocols could be used to make a QoS request, including
   RSVP [RFC2210], NSIS [I-D.ietf-nsis-qos-nslp], link-specific
   signaling or even SIP/SDP [RFC2327].  This document focuses on
   supporting the NSIS QoS NSLP.  This will have an implication on the
   content and format of the flow identifiers and QoS attributes that
   represent a particular reservation request within the Diameter QoS
   application; however, other aspects of its operation can easily be
   generalized to other QoS signaling protocols.  The Diameter QoS
   application could be used directly in the context of these other
   reservation protocols, given the definition of a suitable conversion
   between the representations used by those protocols and the ones used
   by NSIS.












Alfano, et al.           Expires August 25, 2005                [Page 3]


Internet-Draft    Diameter Quality of Service Application  February 2005


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The following terms are used in this document:

   Application Server

      An application server is a network entity that exchanges signaling
      messages with an application endpoint.  It may be a source of
      authorization for QoS-enhanced application flows.  For example, a
      SIP server is one kind of application server.

   Application Endpoint

      An application endpoint is an entity in an end user device that
      exchanges signaling messages with application servers or directly
      with other application endpoints.  Based on the result of this
      signaling, the endpoint will make a request for QoS from the
      network.  For example, a SIP User Agent is one kind of application
      endpoint.

   Authorizing Entity

      The authorizing entity is that entity responsible for authorizing
      QoS requests for a particular application flow.  This may be a AAA
      server (with a subscriber database) or an application server or
      some other entity.

   AAA Cloud

      A network of AAA proxy/broker arrangements.


   Furthermore, we use terminology defined in [RFC3588].














Alfano, et al.           Expires August 25, 2005                [Page 4]


Internet-Draft    Diameter Quality of Service Application  February 2005


3.  Framework

   The Diameter QoS application runs between a network element receiving
   QoS reservation requests (acting as a AAA client) and the resource
   authorizing entity (acting as a AAA server).  A high-level picture of
   the resulting architecture is shown in Figure 1.


                                 +-------------+
                                 | Resource    |
                                 | Authorizing |
                                 | Entity      |
                                 +-----+-------+
                                       |
                                       |
                                /\-----+-----/\
                            ////               \\\\
                          ||                       ||
                         |         AAA Cloud         |
                          ||                       ||
                            \\\\               ////
                                \-------+-----/
                                        |
                         +---+--+   +---+--+   +---+--+
            Application  |      |   |      |   |      |
          ===============+  NE  +===+  NE  +===+  NE  +========>>
               Flow      |      |   |      |   |      |
                         +------+   +------+   +------+

              Figure 1: An Architecture supporting QoS-AAA

   Figure 1 depicts network elements through which application flows
   need to pass, a cloud of AAA servers, and an authorizing entity.
   Note that there may be more than one router that needs to interact
   with the AAA cloud along the path of a given application flow,
   although the figure only depicts one for clarity.  Routers will
   request authorization for QoS from the AAA cloud, which will route
   the request, for example, to the home network where the home
   authorizing entity will return a grant/deny decision.

   In more complex deployment models, the authorization will be based on
   dynamic application state, so the request must be authenticated and
   authorized based on information from one or more application servers.
   If defined properly, the interface between the routers and AAA cloud
   would be identical in both cases.  Routers are therefore insulated
   from the details of particular applications and need not know that
   application servers are involved at all.  Also, the AAA cloud would
   naturally encompass business relationships such as those between



Alfano, et al.           Expires August 25, 2005                [Page 5]


Internet-Draft    Diameter Quality of Service Application  February 2005


   network operators and third-party application providers, enabling
   flexible intra- or inter-domain authorization, accounting, and
   settlement.

3.1  Network element functional model

   Figure 2 depicts a logical operational model of resource management
   in a router.


          +-----------------------------------------------------+
          | DIAMETER Client                                     |
          | Functionality                                       |
          | +---------------++---------------++---------------+ |
          | | User          || Authorization || Accounting    | |
          | | Authentication|| of QoS        || for QoS       | |
          | +---------------+| Requests      || Traffic       | |
          |                  +---------------++---------------+ |
          +-----------------------------------------------------+
                 ^                            ^
                 v                            v
            +--------------+            +----------+
            |QoS Signaling |            | Resource |
            |Msg Processing|<<<<<>>>>>>>|Management|
            +--------------+            +----------+
                 .  ^   |              *      ^
                 |  v   .            *        ^
            +-------------+        *          ^
            |Signaling msg|       *           ^
            | Processing  |       *           V
            +-------------+       *           V
                 |      |         *           V
     ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                 .      .         *           V
                 |      |         *     .............................
                 .      .         *     .   Traffic Control         .
                 |      |         *     .                +---------+.
                 .      .         *     .                |Admission|.
                 |      |         *     .                | Control |.
       +----------+    +------------+   .                +---------+.
   <-.-|  Input   |    | Outgoing   |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
       |  Packet  |    | Interface  |   .+----------+    +---------+.
   ===>|Processing|====| Selection  |===.|  Packet  |====| Packet  |.=>
       |          |    |(Forwarding)|   .|Classifier|     Scheduler|.
       +----------+    +------------+   .+----------+    +---------+.
                                        .............................
           <.-.-> = signaling flow
           =====> = data flow (sender --> receiver)



Alfano, et al.           Expires August 25, 2005                [Page 6]


Internet-Draft    Diameter Quality of Service Application  February 2005


           <<<>>> = control and configuration operations
           ****** = routing table manipulation

               Figure 2: Network element functional model

   Processing of incoming QoS reservation requests includes three
   actions: admission control, authorization and resource reservation.

   The admission control function provides information for available
   resources and determines whether there are enough resources to
   fulfill the request.  Authorization is performed by the Diameter
   client function which involves contacting an authorization entity
   through the AAA cloud shown in Section 3.  If both checks are
   successful, the authorized QoS parameters are set in the packet
   classifier and the packet scheduler.  Note that the parameters passed
   to the Traffic Control function may be different from requested QoS
   (depending on the authorization decision).  Once the requested
   resource is granted, the Resource Management function provides
   accounting information to the Authorizing entity using the Diameter
   client function.

3.2  Requirements for a QoS AAA protocol

   Intended deployment architecture and functionalities put a number of
   requirements on the Diameter QoS application.  These requirements are
   reviewed in detail in [I-D.alfano-aaa-qosreq].

   A short list is provided here:
   Inter-domain support

      In particular, users may roam outside their home network, leading
      to a situation where the network element and authorizing entity
      are in different administrative domains.

   Identity-based Routing

      The QoS AAA protocol MUST route AAA requests to the authorizing
      entity based on the identity information given in the QoS
      signaling protocol.

   Flexible Authentication Support

      The QoS AAA protocol MUST support a variety of different
      authentication protocols for verification of authentication
      information present in QoS signaling messages.






Alfano, et al.           Expires August 25, 2005                [Page 7]


Internet-Draft    Diameter Quality of Service Application  February 2005


   Making an Authorization Decision

      The QoS AAA protocol MUST exchange sufficient information between
      the authorizing entity and the enforcing entity (and vice versa)
      to compute an authorization decision and to execute this decision.

   Triggering an Authorization Process

      The QoS AAA protocol MUST allow periodic and event triggered
      execution of the authorization process, originated at the
      enforcing entity or even at the authorizing entity.

   Associating QoS Reservations and Application State

      The QoS AAA protocol MUST carry information sufficient for an
      application server to identify the appropriate application session
      and associate it with a particular QoS reservation.

   Dynamic Authorization

      It MUST be possible forthe QoS AAA protocol to push updates
      towards the network element(s) from authorizing entities.

   Bearer Gating

      The QoS AAA protocol MUST allow the authorizing entity to gate
      (i.e., enable/disable) authorized application flows based on e.g.,
      application state transitions.

   Accounting Records

      The QoS AAA protocol MUST define QoS accounting records containing
      duration, volume (byte count) usage information and description of
      the QoS attributes (e.g., bandwidth, delay, loss rate) that were
      supported for the flow.

   Sending Accounting Records

      The network element MUST send accounting records for a particular
      application flow to the authorizing entity for that flow or to
      another entity identified by the authorizing entity.

   Failure Notification

      The QoS AAA protocol MUST allow the network element to report
      failures(such as loss of connectivity due to movement of a mobile
      node or other reasons for packet loss) to the authorizing entity.




Alfano, et al.           Expires August 25, 2005                [Page 8]


Internet-Draft    Diameter Quality of Service Application  February 2005


   Accounting Correlation

      The QoS AAA protocol MUST support the exchange of sufficient
      information to allow for correlation between accounting records
      generated by the network elements and accounting records generated
      by an application server.

   Interaction with other AAA Applications
      Interaction with other AAA applications such as Diameter Credit
      Control [I-D.ietf-aaa-diameter-cc] and Diameter NASREQ
      [I-D.ietf-aaa-diameter-nasreq] is required for exchange of
      authorization, authentication and accounting information.


   This document first defines Diameter messages and Command-Codes.
   Then it describes the operation of a Diameter QoS application and
   enumerates the Diameter message Command-Codes and AVPs used in these
   messages.

































Alfano, et al.           Expires August 25, 2005                [Page 9]


Internet-Draft    Diameter Quality of Service Application  February 2005


4.  QoS Application Messages

   This document requires the definition of new mandatory AVPs and
   Command-Codes for the QoS Diameter application.  Two new Diameter
   messages are defined:

   Command-Name             Abbrev.        Code       Reference
   QoS-Request              QAR            XXX        6.1
   QoS-Answer               QAA            XXX        6.2

   The following Diameter-base messages are used:

   Command-Name             Abbrev.        Code       Reference
   Accounting-Request       ACR            271        RFC 3588
   Accounting-Answer        ACA            271        RFC 3588
   Re-Auth-Request          RAR            258        RFC 3588
   Re-Auth-Answer           RAA            258        RFC 3588
   Abort-Session-Request    ASR            274        RFC 3588
   Abort-Session-Answer     ACA            274        RFC 3588
   Session-Term-Request     STR            275        RFC 3588
   Session-Term-Answer      STA            275        RFC 3588

   Diameter nodes conforming to this specification MAY advertise support
   by including the value of TBD in the Auth-Application-Id or the
   Acct-Application-Id AVP of the Capabilities-Exchange-Request and
   Capabilities-Exchange-Answer commands [RFC3588].

   The value of TBD (TBD) MUST be used as the Application-Id in all QAR
   and QAA commands.  The value of TBD (TBD) MUST be used as the
   Application-Id in all ACR/ACA commands, because this application
   defines new, mandatory AVPs for accounting.  The value of zero (0)
   SHOULD be used as the Application-Id in all STR/STA, ASR/ASA, and
   RAR/RAA commands, because these are defined in the Diameter base
   protocol and no additional mandatory AVPs for those commands are
   defined in this document.
















Alfano, et al.           Expires August 25, 2005               [Page 10]


Internet-Draft    Diameter Quality of Service Application  February 2005


5.  QoS Authorization session

5.1  Authorization models

   With respect to NSIS signaling, different authorization models have
   been investigated and discussed in detail in
   [I-D.tschofenig-nsis-aaa-issues] and in
   [I-D.tschofenig-nsis-qos-authz-issues].  From the Diameter QoS
   application's point of view these models differ in type of
   information that need to be carried.  Here we focus on the 'Three
   party approach' model (Figure 5) and the 'Token based three party
   approach'(Figure 6).


                                        +--------------+
                                        | Entity       |
                                        | authorizing  | <......+
                                        | resource     |        .
                                        | request      |        .
                                        +------------+-+        .
                                        --^----------|--   .    .
                                   /////  |          |  \\\\\   .
                                 //       |          |       \\ .
                                |     QoS | QoS AAA  | QoS     |.
                                |    authz| protocol |authz    |.
                                |     req.|          | res.    |.
                                 \\       |          |       // .
                                   \\\\\  |          |  /////   .
                          QoS           --|----------v--   .    .
       +-------------+    request       +-+------------+        .
       |  Entity     |----------------->| BE           |        .
       |  requesting |                  | performing   |        .
       |  resource   |granted / rejected| QoS          |  <.....+
       |             |<-----------------| reservation  | financial
       +-------------+                  +--------------+ settlement

                     Figure 5: Three Party Approach

   In the 'Three party approach' model, a resource request by the end
   host is received at the router in the local network and then sent to
   the user's home network (after processing) where authorization is
   provided.  The response is then returned and resources are granted
   (in case of a successful authorization decision).  The interaction
   between the visited network and the home network establishes the
   necessary financial infrastructure to later charge the user for the
   consumed resources.





Alfano, et al.           Expires August 25, 2005               [Page 11]


Internet-Draft    Diameter Quality of Service Application  February 2005


                               financial settlement
                                ...........................+
      Authorization             V             -------      .
      Token Request   +--------------+      / QoS AAA \    .
      +-------------->| Entity       |     /  protocol \   .
      |               | authorizing  +--------------+   \  .
      |               | resource     |   |          |    | .
      |        +------+ request      |<--+----+     |    | .
      |        |      +--------------+  |QoS  |     |QoS  |.
      |        |                        |authz|     |authz|.
      |        |Authorization           |req.+|     |res. |.
      |        |Token                   |Token|     |     |.
      |        |                         |    |     | .  | .
      |        |                          \   |     | . /  .
      |        |                            \ |     | /    .
      |        |      QoS request             |-----V .    .
    +-------------+ + Authz. Token   +--------+-----+      .
    |  Entity     |----------------->| BE           |      .
    |  requesting |                  | performing   |      .
    |  resource   |granted / rejected| QoS          | <....+
    |             |<-----------------| reservation  |
    +-------------+                  +--------------+

               Figure 6: Token based three party approach

   The token based three party approach is applicable in environments
   where a previous protocol interaction is used to request
   authorization tokens (or something similar) to assist the
   authorization process at the entity performing the QoS reservation.
   A host contacts the Authorizing entity and obtains an authorization
   token for a requested service prior to sending a QoS reservation
   request.  It includes the authorization token in its reservation
   request and this token is used in the routers along the flow path for
   QoS authorization.  (e.g.  the authorization token is included in QoS
   AAA messages between the router and the Authorizing entity.)

5.2  Session Initiation

   A request for a QoS enabled transport plane service starts a Diameter
   QoS message exchange (see Section 9).  The identity of the user,
   message authentication information, signaling session identification
   and depending on the scenario, the identity of the QoS authorizing
   application server and authorization token, are assembled into a
   Diameter QoS Authorization Request (QAR) message by the transport
   plane control element(s) responsible for resource allocation and sent
   either to the identified application server, or to a supporting
   Diameter server in the user's home realm.




Alfano, et al.           Expires August 25, 2005               [Page 12]


Internet-Draft    Diameter Quality of Service Application  February 2005


   The authorization server evaluates the information in the token to
   determine the session for which QoS resource information is being
   requested.  It can be assumed that the server was involved in some
   off-path resource negotiation signaling earlier on and at that time
   resources were validated against a user subscription (see Figure 6).
   The server responds with QoS-Authorization-Answer (QAA) message,
   which includes the authorized QoS resources, gating information and
   accounting coordination ID, which will be used for reporting
   accounting information for the session.  Also authorization session
   management information (lifetime, session timeout, grace period) is
   provided (see Section 6, [RFC3588] and [I-D.alfano-aaa-qosreq]).

   In case of an unsuccessful authorization, the QAA message, including
   a failure code (Result-Code AVP) specifying the rejection reason, is
   sent and terminates this session.  Since the QoS reservation request
   is rejected, the QoS signaling protocol sends a negative response
   message to it's peer in order to terminate the signaling session.

5.3  Session Establishment

   When the QoS authorization exchange completes successfully and the
   authorization session is established, requested QoS resources are
   reserved at the router.  Based on the gating information (see
   Section 8.5) included in the QAA message, the corresponding transport
   flow may be allowed to pass through the node.  If not, then an
   additional command for enabling of the transport plane service is
   required from the Authorizing entity.  Until the enabling command is
   received packets SHOULD be given only best-effort treatment or MAY be
   dropped.  Once the authorized transport flow starts passing through
   the node, an AAA accounting session should be established between the
   transport.  Accounting information is reported as described in
   [RFC3588] and as extended in this Diameter application Section 6.
   Loss of bearer information is reported using Diameter QoS defined
   command codes (QAR) and AVPs.

5.4  QoS Re-Authorization

   Ths section describes client- and server-side reauthorization
   handling by the Diameter QoS application.

5.4.1  Client-side initiated Re-Authorization

   The Authorization server can specify a period of time for which an
   application is authorized to use the QoS resources and after which
   re-authorization is required.  The authorization lifetime is
   specified in the Authorization-Lifetime and the Grace-Period AVPs
   that are included in a successful authorization QAA message.  In the
   event of Authorization-Lifetime expiration the transport plane



Alfano, et al.           Expires August 25, 2005               [Page 13]


Internet-Draft    Diameter Quality of Service Application  February 2005


   element initiates QAR/QAA message exchange for re-authorization.

5.4.2  Server-side initiated Re-Authorization

   At any time during the QoS session the Authorizing server MAY send
   Re-Auth-Request (RAR) message.  The Diameter client /the transport
   plane element/ MUST respond with Re-Auth-Answer (RAA) message.  The
   transport plane element will then send an QoS-Request message with
   re-authorization info.

5.5  Session Termination

5.5.1  Client-side initiated session termination

   A QoS Authorization Session may be terminated from the client side by
   sending a Session-Termination-Request message to the server.  This is
   Base Diameter protocol functionality and it is defined in [RFC3588].
   Session termination can be caused by an NSIS tear down message or via
   a loss of bearer report.  After a successful termination of the
   authorization session, final accounting messages should be exchanged
   and accounting session should be finalized, too.

5.5.2  Server-side initiated session termination

   At anytime during a session the Authorizing server may send an
   Abort-Session-Request message to the transport plane element
   [RFC3588].  Possible reasons are insufficient credits or session
   termination at the application layer.  This results in termination of
   the authorization session, release of the reserved resources at the
   node and sending notification to other transport plane nodes aware of
   the signaling session.  Final accounting message exchange must also
   be terminated.



















Alfano, et al.           Expires August 25, 2005               [Page 14]


Internet-Draft    Diameter Quality of Service Application  February 2005


6.  Accounting

   The Diameter QoS application presented in this document reuses
   Diameter Accounting as defined in [RFC3588].  A definition of new
   Accounting attributes is necessary, but left for further study.

   After a successful QoS authorization and start of the transport plane
   flow, the router starts the corresponding Accounting session by
   sending an Accounting-Request message.  The message SHOULD contain
   necessary attributes to bind the current accounting session to the
   reported QoS session/CC-Correlation-ID AVP and Acc-MultiSession-ID
   AVP.  The Accounting server replies to a successfully received
   Accounting-Request message with an Accounting-Answer message which
   MAY contain instructions for handling of the accounting session,
   e.g., the Accounting-Interim-Interval AVPs.

   After every successful re-authorization procedure the transport plane
   node SHOULD initiate accounting message exchange.

   After successful session termination the transport plane node SHOULD
   initiate final exchange of accounting messages with the accounting
   server.





























Alfano, et al.           Expires August 25, 2005               [Page 15]


Internet-Draft    Diameter Quality of Service Application  February 2005


7.  Diameter QoS Messages

   This section defines new Diameter message Command-Code [RFC3588]
   values that MUST be supported by all Diameter implementations that
   conform to this specification.  The Command Codes are:


   Command-Name             Abbrev.        Code       Reference
   QoS-Request              QAR            XXX        6.1
   QoS-Answer               QAA            XXX        6.2


7.1  QoS-Request (QAR) Command

   The QoS-Request message (QAR), indicated by the Command-Code field
   set to XXX and 'R' bit set in the Command Flags field, is used by
   transport plane control elements to request quality of service
   related resource authorization for a given flow.

   The message MUST carry information to authorize the QoS requestor.
   As such, it is at minimum necessary to carry enough information to
   identify the user.  If the QoS-Request is intended for a specific
   application server, the QoS-Request MUST include a session
   identification AVPs.

   The message format is defined as follows:


   <QoS-Request> ::= < Diameter Header: XXX, REQ, PXY >
                           < Session-Id >
                           { Auth- Application-Id }
                           { Origin-Host }
                           { Origin-Realm }
                           { Destination-Host }
                           { Destination Realm }
                           { Auth-Request-Type }
                           [ User-Name ]
                           [ CC-Correlation-Id ]
                           [ State ]
                       *   [ AVP ]


7.2  QoS-Answer (QAA) Command

   The QoS-Answer message (QAA), indicated by the Command-Code field set
   to XXX and 'R' bit cleared in the Command Flags field, is sent in
   response to the QoS-Request message.  If the QoS-Request message is
   processed successfully, the response will include the AVPs to allow



Alfano, et al.           Expires August 25, 2005               [Page 16]


Internet-Draft    Diameter Quality of Service Application  February 2005


   authorization of the QoS resources as well as accounting and
   transport plane gating information.

   The message format is defined as follows:


   <QoS-Answer>        ::= < Diameter Header: XXX, PXY >
                           < Session-Id >
                           { Auth-Application-Id }
                           { Result-Code }
                           { Origin-Host }
                           { Origin-Realm }
                           [ QoS-Auth-Resources ]
                           [ QoS-Flow-State ]
                       *   [ AVP ]




































Alfano, et al.           Expires August 25, 2005               [Page 17]


Internet-Draft    Diameter Quality of Service Application  February 2005


8.  Diameter QoS AVPs

   Each of the AVPs identified in the QoS-Request and QoS-Answer command
   codes and the assignment of their value(s) is given in this section.

8.1  Diameter Base Protocol AVPs

   The AVPs in this section are defined in the Base Protocol, and are
   included here for reference.  For more information, see [RFC3588].

   Session-Id AVP

      Identifier of the AAA session established between the router,
      acting as a Diameter client, and the Authorization entity, the
      Diameter server, for QoS authorization.  The Diameter client MUST
      create a unique value for the Session-Id that will identify the
      particular session.

   Auth-Application-Id

      The Auth-Application-Id is assigned by IANA to Diameter
      applications.  The value of the Auth-Application-Id for the
      Diameter QoS application is XXX.

   Result-Code AVP

      The Result-Code AVP indicates if a particular request was
      completed successfully.

   Origin-Host

      The Origin-Host AVP identifies the endpoint that originated the
      Diameter message.

   Origin-Realm

      The Origin-Realm AVP contains the Realm of the originator of the
      Diameter message.


8.2  Credit Control

   The AVPs in this section are defined as part of the Diameter Credit
   Control document [I-D.ietf-aaa-diameter-cc].







Alfano, et al.           Expires August 25, 2005               [Page 18]


Internet-Draft    Diameter Quality of Service Application  February 2005


   CC-Correlation-Id

      The CC-Correlation-ID AVP (AVP code TBD) is of type OcterString
      and contains information to correlate accounting data generated
      for different components of the service, e.g.  transport and
      application level.  In the Diameter QoS application, this AVP is
      assigned a value by the Diameter QoS client and sent to the server
      in a QAR message.

8.3  Authentication/Authorization

   Authentication and authorization is important for the Diameter QoS
   application.  Therefore, a number of AVPs of related Diameter
   applications can be used, such as [I-D.ietf-aaa-eap],
   [I-D.ietf-aaa-diameter-sip-app] and [I-D.ietf-aaa-diameter-nasreq]

   The details of the required attributes for authentication and
   authorization is for further study.

8.4  Accounting AVPs

   The Diameter QoS application uses Diameter Accounting as defined in
   [RFC3588].  Diameter base accounting AVPs and Credit-Control AVPs
   SHOULD be used.

   Acc-Multisession-ID

      Acc-Multisession-ID AVP SHOULD be used to link multiple accounting
      sessions together.  At the authorizing entity, the Diameter
      session ID is bound to the NSIS-Session-ID.  Additionally, the
      Acc-Multisession-ID SHOULD be used with these IDs, allowing the
      correlation of accounting information.  This AVP MAY be returned
      by the Diameter server in an Authorization answer, and MUST be
      used in all accounting messages for the given session.

8.5  Diameter QoS Application Defined AVPs

   This section defines the Quality of Service AVPs that are specific to
   the Diameter QoS application and MAY be included in the Diameter QoS
   application messages.  Unlike the approach followed with RSVP (see
   [RFC2749]), where the entire RSVP message is encapsulated into a COPS
   message, only the relevant fields SHOULD be included.  This approach
   avoids a certain overhead of transmitting fields which are irrelevant
   for the AAA infrastructure.  It keeps implementations simpler and it
   allows to reuse other Diameter AVPs.  Finally, it helps to make this
   Diameter application less dependent on any particular QoS signaling
   protocol or a particular QoS model.




Alfano, et al.           Expires August 25, 2005               [Page 19]


Internet-Draft    Diameter Quality of Service Application  February 2005


   The following table describes the Diameter AVPs in the QoS
   Application, their AVP code values, types, possible flag values, and
   whether the AVP MAY be encrypted.


                                            |    AVP Flag rules      |
                                            |----+---+----+-----|----+
                     AVP  Section           |    |   |SHLD| MUST|    |
   Attribute Name    Code Defined Data Type |MUST|MAY| NOT|  NOT|Encr|
   -----------------------------------------|----+---+----+-----|----|
   NSIS-Session-ID   XXX  4.3    UTF8String | M  | P |    |  V  | Y  |
   QoS-Auth-         XXX  4.3    Grouped    | M  | P |    |  V  | Y  |
   Resources                                |    |   |    |     |    |
   QoS-Filter-Rule   XXX  4.3    Grouped    | M  | P |    |  v  | Y  |
   QoS-Flow-State    XXX  4.3    Enumerated | M  | P |    |  V  | Y  |
   QoS-NSIS          XXX  4.3   OctetString | M  | P |    |  V  | Y  |
   IPFilter          XXX  4.3   IpfltrRule  | M  | P |    |  V  | Y  |
   SPI               XXX  4.3   Unsigned32  | M  | P |    |  V  | Y  |
   DSCP              XXX  4.3   Unsigned32  | M  | P |    |  V  | Y  |
   -----------------------------------------+----+---+----+-----+----+

   NSIS-Session-ID

      NSIS-Session-ID AVP is of type UTF8String and contains a copy of
      the NSIS Session ID, which is unique identifier of the signaling
      session that remains unchanged for the duration of the session.
      It is added into QoS-Authorization-Request message for
      identification of the signaling session that requests
      authorization.

   QoS-Auth-Resources

      The QoS-Auth-Resources AVP (AVP Code N) is of type Grouped.  Each
      individual AVP in the grouped QoS-Auth-Resources describes the
      value of a resource that has been authorized by an application
      server for a particular QoS Request (described by the Session-Id
      AVP).  The QoS-Auth-Resources AVP is Optional, however one of
      QoS-Auth-Resources, or QoS-Flow-State is mandatory in a QAA
      message.


   QoS-Auth-Resources ::=  *  [ QoS-Filter-Rule ]
                          0*1 < QoS-NSIS >

   The AVPs that are part of QoS-Auth-resource AVP are:






Alfano, et al.           Expires August 25, 2005               [Page 20]


Internet-Draft    Diameter Quality of Service Application  February 2005


   QoS-Filter-Rule


   QoS-Filter-Rule::=  0*1 < IPFilter >
                          0*1 < SPI >
                          0*1 < DSCP >

       The QoS-Filter-Rule AVP is of type Grouped, and provides filter
      rules for the packet flow of the user.  One or more such AVPs MAY
      be present in a QAA response.

   QoS-NSIS

      The QoS-NSIS AVP is of type OctetString.  It contains QoS
      parameter information.  Description format is taken from QoS NSLP
      Qspec Template which is expected to cover all present QoS
      description methods [I-D.ietf-nsis-qspec].  The template proposed
      there includes description of QoS Control information and
      requested, reserved, available and minimum QoS which are used in
      NSIS QoS protocol.  For the authorization purposes not all of the
      description parameters are required e.g.  only Minimum and
      Available QoS description MAY be used.  Considering that the work
      on the QoS parameters is ongoing, a future version of this
      document will contain payload descriptions of objects introduced
      in [I-D.ietf-nsis-qos-nslp] and [I-D.ietf-nsis-qspec].  A separate
      AVP MAY be specified for description of QoS in 3GPP networks
      scenarios.

   QoS-Flow-State:

      The QoS-Flow-State AVP is of type Enumerated and is used in QAA
      messages.  It gives indication by the Authorizing entity how the
      flow MUST be treated.  When included in a QAA message, it is
      instructions to the transport plane control element with regard to
      the state to which the flow should be set.  The supported values
      are


   0  Open     - Enable the transport plane service, for which
                 the signaling is done
   1  Close    - Disable the transport plane service
   2  Maintain - Current state(enabled/disabled) of the transport
                 plane service is maintained


      The QoS-Flow-State is an optional AVP.  When not included in a QAA
      response, the default behaviour is to immediately allow the flow
      of packets (Open).



Alfano, et al.           Expires August 25, 2005               [Page 21]


   IPFilter:

      The IPFilter AVP is of type IPflrtRule and represents a flow
      identifier used in Packet Clasifier.

   SPI:

      The SPI AVP is of type Unsigned32 and together with IPFilter AVP
      provides support for IPsec protected traffic.

   DSCP:

      The DSCP AVP is of type Unsigned32 and together with IPFilter AVP
      provides support for DiffServ marked flow identification.  For
      this purpose, DSCP does not imply any QoS description.  Full
      description of the QoS is provided in NSIS-QoS AVP.





































Alfano, et al.           Expires August 25, 2005               [Page 22]


Internet-Draft    Diameter Quality of Service Application  February 2005


9.  Examples

   This section illustrates a general message flow of QoS authorization
   session establishment(Figure 14) and interworking with NSIS
   (Figure 15).

   Figure 14 shows the protocol exchange between the Diameter Client and
   the Diameter Server.  An incoming QoS reservation request received at
   the transport plane element invokes sending of QoS-Request message to
   the Authorization server.  Server replies with QoS-Answer which
   grants reservation of certain resources.  After the successful
   exchange of authorization QAR/QAA messages, the transport plane node
   starts an accounting session by sending an Accounting-Request
   message.  The server replies with an Accounting-Answer message that
   MAY include instructions for further handling of the accounting
   session, such as the Acc-Interim-Period AVP.  A possible client-side
   re-authorization caused by expiration of the authorization life-timer
   initiates a QAR/QAA message exchange.  After successful
   re-authorization an accounting message ACR SHOULD be sent.  The
   server replies to it with an ACA message.  A session termination that
   is initiated by the server will be sent using an
   Abort-Session-Request message.  The client responds with an ASA
   message and a Session-Termination-request message.  After receiving
   the STA message sent by the server, which finalizes the authorization
   session, final accounting information is sent with the ACR message.
   The ACA message from the server also terminates the accounting
   session.


              Router(Diameter client)               Diameter Server
   -----------> |                                            |
   QOS          | QoS-Request                                |
   reservation  |------------------------------------------->|
   request      |                                            |
                |              QoS-Answer/QoS-Auth-Res./     |
                |<-------------------------------------------|
                |                                            |
    Start       |Acc-Request/Start,QoS Acc-Msess-ID.../      |
    Accounting  |------------------------------------------->|
                |    Acc-Answer/...Acc-Interim-Period.../    |
                |<-------------------------------------------|
                |                                            |
   Authorization|                                            |
   LifeTime     |                                            |
   Expires:     |                                            |
   Re-          | QoS-Request                                |
   Authorization|------------------------------------------->|
                |       QoS-Answer/QoS-Auth-Res./            |



Alfano, et al.           Expires August 25, 2005               [Page 23]


Internet-Draft    Diameter Quality of Service Application  February 2005


                |<-------------------------------------------|
                | Acc-Request/Interim, Acc-Msess-ID.../      |
                |------------------------------------------->|
                |    Acc-Answer/...Acc-Interim-Period.../    |
                |<-------------------------------------------|
                             .....................
                |                                            | Session
                |                                            |   Term.
                |                                            |initiate
                |                                            |by Server
                |        Abort-Session-Request               |<--------
                |<-------------------------------------------|
                | Abort-Session-Answer                       |
                |------------------------------------------->|
                | Session-Termination-Request                |
                |------------------------------------------->|
                |             Session-Termination-Answer     |
                |<-------------------------------------------|
   Accounting   |    Acc-Request/Final,Acc-Msess-ID.../      |
      end       |------------------------------------------->|
                |               Acc-Answer /Final,.../       |
                |<-------------------------------------------|

              Figure 14: Diameter QoS Application Session

   Figure 15 shows the interaction between NSIS, application layer
   signaling (e.g., SIP) and the Diameter QoS application.  First, a
   service request is sent from the client to the application server.
   In response, for example, it returns an authorization token to bind
   the application layer signaling exchange to the subsequent NSIS
   signaling session.  The authorization token is attached to the NSIS
   signaling message and the message itself is intercepted by the first
   NSIS QoS NSLP node.  This router then needs to authorize the QoS
   request and delegates this responsibility to the Diameter QoS
   application.  This type of authorization model is described in
   Section 1 and in Section 3.6 of [I-D.ietf-nsis-qos-nslp].  The
   Diameter QoS Authorization Request (QAR), which includes
   authorization and QoS information, is forwarded to the administrative
   domain of the application domain for verification.  As a response,
   the authorization decision is returned with the Diameter QoS Answer
   (QAA) message.  Finally, the NSIS QoS NLP aware router acts as an
   enforcement point.  If the authorization decision provided with the
   QAA message was successful then the NSIS signaling message is
   forwarded further along the path.  Otherwise, the QoS NSLP returns an
   error message to the end host (such as 'Authorization denied').


                Diameter QoS



Alfano, et al.           Expires August 25, 2005               [Page 24]


Internet-Draft    Diameter Quality of Service Application  February 2005


                Application
                Enabled Router                Application
                Enforcement Pt                  Server
     Application                    +
     Client                Domain 1 + Domain 2
          |            |            +             |
          |          Service Request (QoS)        |
          +------------+------------+------------->
          |            |            +             |
          |            |            +             |
          |      Service Response (QoS', Token)   |
          <------------+------------+-------------+
          |            |            +             |
          |            |            +             |
          |NSIS (Token)|            +             |
          +------------>            +             |
          |            |            +             |
          |            |           -+--           |
          |            |QAR(Token)- +  -QAR(Token)|
          |            +--------/>  +  --\-------->
          |            |       /    +     \       |
          |            |       /    +     \       |
          |            |      |     +      |      |
          |            | QAA(QoS)   +   QAA(QoS)  |
          |            <------+---  +  <---+------+
          |            |      |     +      |      |
          |            |      |  Diameter  |      |
          |            |       \ Network  /       |
          |            |       \    +     /       |
          |            |        \   +    /        |
          |      Authorization   \- +  -/         |
          |      Enforcement       -+--           |
          |      Decision           +             |
          |            |            +             |
          |            |            +             |
          |  Allow or Terminate Flow              |
          <-----------+*+------------------------->
          |            |            +             |
          |            |            +             |

     Figure 15: Message flow with NSIS and Diameter QoS Application

   A future version of this document will describe scenarios with other
   authorization models.







Alfano, et al.           Expires August 25, 2005               [Page 25]


Internet-Draft    Diameter Quality of Service Application  February 2005


10.  Security Considerations

   This document describes a mechanism for performing authorization of a
   QoS reservation at a third party entity.  Thereby, it is necessary
   the QoS signaling protocol to forward the necessary information to
   the backend AAA server.  This functionality is particularly useful in
   roaming environments where the authorization decision is most likely
   provided at an entity where the user can be authorized, such as in
   the home realm.  To provide proper authorization, authentication
   might be necessary at least for the generic third party model
   (described in Section 3.6 of [I-D.ietf-nsis-qos-nslp]).  Please note
   that authentication is not provided to the QoS NSLP router but
   torwards the users home network.  The concept of an authorization
   token based third party approach is also described in the same
   document.  The impact of the existence of different authorization
   models is (with respect to this Diameter QoS application) the ability
   to carry different authentication and authorization information.

   Further discussions on the authorization handling for QoS signaling
   protocols is available with [I-D.tschofenig-nsis-aaa-issues] and
   [I-D.tschofenig-nsis-qos-authz-issues].






























Alfano, et al.           Expires August 25, 2005               [Page 26]


Internet-Draft    Diameter Quality of Service Application  February 2005


11.  Contributors

   The authors would like to thank Tseno Tsenov for his contributions to
   this document.















































Alfano, et al.           Expires August 25, 2005               [Page 27]


Internet-Draft    Diameter Quality of Service Application  February 2005


12.  Acknowledgements

   Add your name here.
















































Alfano, et al.           Expires August 25, 2005               [Page 28]


Internet-Draft    Diameter Quality of Service Application  February 2005


13.  Open Issues

   During our work on this document we identified the following open
   issues:

   o  This Diameter QoS application can reuse a number of other Diameter
      applications.  This is a big advantage over other approaches.
      This interaction and a list of useful attributes needs to be
      collected and described.  This aspect is for further study.

   o  The NSIS group is currently working on QoS models.  As soon as
      results are available it is feasible to incorporate them into this
      Diameter application to build a complete solution for QoS
      signaling which uses a backend infrastructure.

   o  Several authorization models have been described in
      [I-D.ietf-nsis-qos-nslp].  Section 9 currently addresses only the
      third party approach using authorization tokens.  Further work is
      needed to describe the details of a generic three party scenario.

   o  Section 5.5 describes the session termination functionality.
      Should a new command code for transport plane gating purposes be
      introduced, i.e., what if the application server wants to
      temporarily disable the transport plane service without
      terminating the session with ASR?

   o  Section 5.4 raises the question of a re-authorizing capability for
      the Diameter application.  The authors think that such a
      re-authorization capability would be desirable (e.g., using with
      the RAR/RAA message exchange).  Note that it would require the
      transport plane signaling protocol (for example RSVP or NSIS) to
      support network-initiated re-auth, which might not always be in
      place.  There should be a failure code for the case where the
      underlying transport plane signaling protocol does not support it.

   o  Section 5.4 presents a possible re-authorization solution taken
      from [RFC3588].  A time based authorization life period is used.
      Adding a re-authorization functionality with volume-based
      authorization period MIGHT be useful.  A corresponding metering
      functionality MUST be present at the router.

   o  The terminology regarding the 'transport plane node' needs further
      refinement.








Alfano, et al.           Expires August 25, 2005               [Page 29]


Internet-Draft    Diameter Quality of Service Application  February 2005


14.  References

14.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

14.2  Informative References

   [I-D.alfano-aaa-qosreq]
              Alfano, F., "Requirements for a QoS AAA Protocol",
              Internet-Draft draft-alfano-aaa-qosreq-01, October 2003.

   [I-D.ietf-aaa-diameter-cc]
              Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H.
              Hakala, "Diameter Credit-control Application",
              Internet-Draft draft-ietf-aaa-diameter-cc-06, August 2004.

   [I-D.ietf-aaa-diameter-nasreq]
              Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
              Network Access Server Application",
              Internet-Draft draft-ietf-aaa-diameter-nasreq-17, July
              2004.

   [I-D.ietf-aaa-diameter-sip-app]
              Garcia-Martin, M., "Diameter Session Initiation Protocol
              (SIP) Application",
              Internet-Draft draft-ietf-aaa-diameter-sip-app-06,
              February 2005.

   [I-D.ietf-aaa-eap]
              Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
              Authentication Protocol (EAP) Application",
              Internet-Draft draft-ietf-aaa-eap-10, November 2004.

   [I-D.ietf-nsis-qos-nslp]
              Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
              Quality-of-Service signaling",
              Internet-Draft draft-ietf-nsis-qos-nslp-05, October 2004.

   [I-D.ietf-nsis-qspec]
              Ash, J., "QoS-NSLP QSpec Template",
              Internet-Draft draft-ietf-nsis-qspec-03, February 2005.

   [I-D.tschofenig-nsis-aaa-issues]



Alfano, et al.           Expires August 25, 2005               [Page 30]


Internet-Draft    Diameter Quality of Service Application  February 2005


              Tschofenig, H., "NSIS Authentication, Authorization and
              Accounting Issues",
              Internet-Draft draft-tschofenig-nsis-aaa-issues-01, March
              2003.

   [I-D.tschofenig-nsis-qos-authz-issues]
              Tschofenig, H., "QoS NSLP Authorization Issues",
              Internet-Draft draft-tschofenig-nsis-qos-authz-issues-00,
              June 2003.

   [RFC2210]  Wroclawski, J., "The Use of RSVP with IETF Integrated
              Services", RFC 2210, September 1997.

   [RFC2327]  Handley, M. and V. Jacobson, "SDP: Session Description
              Protocol", RFC 2327, April 1998.

   [RFC2749]  Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R.
              and A. Sastry, "COPS usage for RSVP", RFC 2749, January
              2000.

   [RFC3313]  Marshall, W., "Private Session Initiation Protocol (SIP)
              Extensions for Media Authorization", RFC 3313, January
              2003.

   [RFC3520]  Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session
              Authorization Policy Element", RFC 3520, April 2003.

   [RFC3521]  Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session
              Set-up with Media Authorization", RFC 3521, April 2003.


Authors' Addresses

   Frank M. Alfano
   Lucent Technologies
   1960 Lucent Lane
   Naperville, IL  60563
   USA

   Phone: +1 630 979 7209
   Email: falfano@lucent.com










Alfano, et al.           Expires August 25, 2005               [Page 31]


Internet-Draft    Diameter Quality of Service Application  February 2005


   Peter J. McCann
   Lucent Technologies
   1960 Lucent Lane
   Naperville, IL  60563
   USA

   Phone: +1 630 713 9359
   Email: mccap@lucent.com


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com

































Alfano, et al.           Expires August 25, 2005               [Page 32]


Internet-Draft    Diameter Quality of Service Application  February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Alfano, et al.           Expires August 25, 2005               [Page 33]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/