[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
RAP Working Group                                             Pat Calhoun
INTERNET DRAFT                                              Michael Speer
Category: Internet Draft                           Sun Microsystems, Inc.
Title: draft-calhoun-diameter-qos-00.txt                       Ken Peirce
Date: May 1998                                           3Com Corporation






                                DIAMETER
                             QOS Extension
                  <draft-calhoun-diameter-qos-00.txt>



Status of this Memo

   This document is an Internet-Draft. 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.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

Abstract

   This document describes a simple client/server model for supporting
   QOS policies. A router that supports RSVP or one of the proposed
   differentiated service schemes will require a policy database and a
   means to access it. This document describes the extensions to a
   protocol based originally on RADIUS [1] called DIAMETER[2]. This
   document does not describe the policy database or policy enforcement.







Calhoun, Peirce          expires November 1998                  [Page 1]


INTERNET DRAFT                                                  May 1998


Table of Contents
      1.0  Introduction
      1.1  Definitions
      2.0  Command Codes
      2.1  Bandwidth-Request (BRQ)
      2.2  Bandwidth-Response (BRP)
      3.0  DIAMETER AVPs
      3.1  Source-Address
      3.2  Destination-Address
      3.3  Source-Port
      3.4  Destination-Port
      3.5  Protocol
      3.6  RSVP-Service-Type
      3.7  Token-Bucket-Rate
      3.8  Token-Bucket-Size
      3.9  Peak-Data-Rate
      3.10 Minimum-Policed-Unit
      3.11 Maximum-Packet-Size
      3.12 QOS-Rate
      3.13 Slack-Term
      3.14 Inbound-Interface
      3.15 Outbound-Interface
      3.16 QOS-Service-Type
      3.17 Inbound-TOS-Value
      3.18 Outbound-TOS-Value
      3.19 Session-Timeout
      4.0  Client Server interaction examples
      4.1  Bandwidth-Request (BRQ)  Client -> Policy Server
      4.1.1 Bandwidth-Request with Differentiated Services
      4.1.2 Bandwidth-Request with Integrated Services
      4.2  Bandwidth-Response (BRP)  Policy Server -> Client
      4.2.1 Bandwidth-Response with Differentiated Services
      4.1.2 Bandwidth-Response with Integrated Services
      4.3  Integration with Resource-Management
      4.3.1 Session-Reclaim-Request (SRR) Policy Server -> Client
      4.3.2 Session-Reclaim-Response (SRP) Policy Server -> Client
      4.3.3 Session-Free-Request (SFR) Client -> Policy Server
      4.3.4 Session-Free-Response (SFP) Policy Server -> Client
      4.3.5 Query-Resource-Request (QRR) Policy Server -> Client
      4.3.6 Query-Resource-Response (QRS) Client -> Policy Server
      4.4  Cross-domain Integrated-Services with DIAMETER
      5.0  Security Considerations
      6.0  References
      7.0  Acknowledgements
      8.0  Author's Address






Calhoun, Peirce          expires November 1998                  [Page 2]


INTERNET DRAFT                                                  May 1998


1.0  Introduction

   This document describes extensions to DIAMETER, a protocol superset
   of RADIUS and a work in progress. RADIUS is based on a client/server
   model and was originally used for authentication and accounting
   purposes. RADIUS in itself is not an extensible protocol largely due
   to its very limited command and attribute address space. In addition,
   the RADIUS protocol assumes that there cannot be any unsolicited
   messages from a server to a client. In order to support new services,
   such as RSVP or differentiated services policy, it is imperative that
   a policy server be able to send unsolicited messages to clients on a
   network, and this is one of the two primary motivations of the
   DIAMETER protocol.

   The other primary motivation for DIAMETER is that its implementation
   represents a small modification to a RADIUS server. RADIUS servers
   are used to control the authentication and accounting of millions of
   internet users each day. The RADIUS source code is freely available
   and these servers are resident at the "edges" of the network. Current
   trends in the area of quality of service(qos) and differentiated
   services indicate that overhead intensive protocols, like RSVP, will
   be used at the edges of the internet, while more scaleable
   differentiated services solutions will be employed within the
   backbone fabric. This places the DIAMETER server at the correct
   location within the network to service RSVP/Diff-Serv requests.


1.1  Definitions

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

   MUST      This word, or the adjective "required", means that the
             definition is an absolute requirement of the
             specification.

   MUST NOT  This phrase means that the definition is an absolute
             prohibition of the specification.

   SHOULD    This word, or the adjective "recommended", means that
             there may exist valid reasons in particular circumstances
             to ignore this item, but the full implications must be
             understood and carefully weighed before choosing a
             different course.

   MAY       This word, or the adjective "optional", means that this
             item is one of an allowed set of alternatives.  An
             implementation which does not include this option MUST



Calhoun, Peirce          expires November 1998                  [Page 3]


INTERNET DRAFT                                                  May 1998


             be prepared to interoperate with another implementation
             which does include the option.


2.0  Command Codes

   This document defines the following DIAMETER Commands. All DIAMETER
   implementations supporting this extension MUST support all of the
   following commands:

      Command Name          Command Code
      -----------------------------------
      Bandwidth-Request         300
      Bandwidth-Response        301


2.1  Bandwidth-Request (BRQ)

   Description

      A Bandwidth-Request message is sent by the client to the server
      and is used to request that the server examine the proposed QOS
      flow against the current policy and available bandwidth for the
      policy.

      The Session-Id MUST accompany this command.

      A summary of the Bandwidth-Request packet format is shown below.
      The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.




Calhoun, Peirce          expires November 1998                  [Page 4]


INTERNET DRAFT                                                  May 1998


   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Command Type

      The Command Type field MUST be set to 300 (Bandwidth-Request).


2.2  Bandwidth-Response (BRP)

   Description

      Bandwidth-Response packets are sent by the server to the client to
      in response to an Bandwidth-Request message. This packet follows
      the DIAMETER rules and include the attributes that accompanied the
      request in addition to other attributes appropriate for the
      corresponding request.

      The Session-Id AVP MUST accompany this command.

      A summary of the Bandwidth-Response packet format is shown below.
      The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Command Type




Calhoun, Peirce          expires November 1998                  [Page 5]


INTERNET DRAFT                                                  May 1998


      The Command Type field MUST be set to 301 (Bandwidth-Response).


3.0  DIAMETER AVPs

   This section will define the mandatory AVPs which MUST be recognized
   by all DIAMETER implementations supporting this extension. The
   following AVPs are defined in this document:

      Attribute Name       Attribute Code
      -----------------------------------
      Source-Address            300
      Destination-Address       301
      Source-Port               302
      Destination-Port          303
      Protocol                  304
      RSVP-Service-Type         305
      Token-Bucket-Rate         306
      Token-Bucket-Size         307
      Peak-Data-Rate            308
      Minimum-Policed-Unit      309
      Maximum-Packet-Size       310
      QOS-Rate                  311
      Slack-Term                312
      Inbound-Interface         313
      Outbound-Interface        314
      QOS-Service-Type          315
      Inbound-TOS-Value         316
      Outboud-TOS-Value         317
      Session-Timeout            27


3.1  Source-Address

   Description

      This attribute contains the source address of the proposed QOS
      flow. The absence of this AVP or the presence of this AVP with a
      value of 0 represents a wildcard filter.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Address                            |



Calhoun, Peirce          expires November 1998                  [Page 6]


INTERNET DRAFT                                                  May 1998


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      300     Source-Address

   AVP Length

      The length of this attribute MUST be at least 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Address

      The Address field contains the source address of the QOS flow.


3.2  Destination-Address

   Description

      This attribute contains the destination address of the proposed
      QOS flow.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      301     Destination-Address

      AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.




Calhoun, Peirce          expires November 1998                  [Page 7]


INTERNET DRAFT                                                  May 1998


   Address

      The Address field contains the destination address of the QOS
      flow.


3.3  Source-Port

   Description

      This attribute contains the source port of the proposed QOS flow.
      The absence of this AVP or the presence of this AVP with a value
      of 0 represents a wildcard filter.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      302     Source-Port

   AVP Length

      The length of this attribute MUST be at least 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the source port of the QOS flow.
      Regardless of the size of the field, the value MUST be between 0
      and 65535.


3.4  Destination-Port

   Description

      This attribute contains the destination port of the proposed QOS



Calhoun, Peirce          expires November 1998                  [Page 8]


INTERNET DRAFT                                                  May 1998


      flow.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      303     Destination-Port

      AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the destination port of the QOS flow.
      Regardless of the size of the field, the value MUST be between 0
      and 65535.


3.5  Protocol

   Description

      This attribute contains the protocol of the proposed QOS flow.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code



Calhoun, Peirce          expires November 1998                  [Page 9]


INTERNET DRAFT                                                  May 1998


      304     Protocol

      AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the IP protocol.


3.6  RSVP-Service-Type

   Description

      The RSVP-Service-Type AVP contains the reservation type.

      When present in the BRQ, the value of this AVP was copied from the
      RESV TSpec [8]. When present in the BRP, the value returned is to
      be used within the RESV TSpec.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      305     RSVP-Service-Type

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32



Calhoun, Peirce          expires November 1998                 [Page 10]


INTERNET DRAFT                                                  May 1998


      The Integer32 field contains the RSVP-Service-Type. The following
      values have been defined:

         RSVP-Controlled-Load       1 RSVP-Guaranteed            2

      Implementation Note: When the RSVP-Service-Type value is set to
      RSVP-Guaranteed, the QOS-Rate and the Slack-Term AVPs MUST be
      present.


3.7  Token-Bucket-Rate

   Description

      The Token-Bucket-Rate AVP contains the token bucket rate.

      When present in the BRQ, the value of this AVP was copied from the
      RESV TSpec [8].

      When present in the BRP for integrated services, the value
      returned is to be used within the RESV TSpec. When present in the
      BRP for differentiated services the value returned contains
      information pretinent for the router on how to handle the TOS
      returned.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      306     Token-Bucket-Rate

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32



Calhoun, Peirce          expires November 1998                 [Page 11]


INTERNET DRAFT                                                  May 1998


      The Integer32 field contains the Token-Bucket-Rate.


3.8  Token-Bucket-Size

   Description

      The Token-Bucket-Size AVP contains the token bucket size.

      When present in the BRQ, the value of this AVP was copied from the
      RESV TSpec [8].

      When present in the BRP for integrated services, the value
      returned is to be used within the RESV TSpec. When present in the
      BRP for differentiated services the value returned contains
      information pretinent for the router on how to handle the TOS
      returned.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      307     Token-Bucket-Size

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the Token-Bucket-Size.


3.9  Peak-Data-Rate

   Description



Calhoun, Peirce          expires November 1998                 [Page 12]


INTERNET DRAFT                                                  May 1998


      The Peak-Data-Rate AVP contains the peak data rate.

      When present in the BRQ, the value of this AVP was copied from the
      RESV TSpec [8].

      When present in the BRP for integrated services, the value
      returned is to be used within the RESV TSpec. When present in the
      BRP for differentiated services the value returned contains
      information pretinent for the router on how to handle the TOS
      returned.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      308     Peak-Data-Rate

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the Peak-Data-Rate.


3.10  Minimum-Policed-Unit

   Description

      The Minimum-Policed-Unit AVP contains the minimum policed unit.

      When present in the BRQ, the value of this AVP was copied from the
      RESV TSpec [8].

      When present in the BRP for integrated services, the value



Calhoun, Peirce          expires November 1998                 [Page 13]


INTERNET DRAFT                                                  May 1998


      returned is to be used within the RESV TSpec. When present in the
      BRP for differentiated services the value returned contains
      information pretinent for the router on how to handle the TOS
      returned.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      309     Minimum-Policed-Unit

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the Minimum-Policed-Unit.


3.11  Maximum-Packet-Size

   Description

      The Maximum-Packet-Size AVP contains the MTU size.

      When present in the BRQ, the value of this AVP was copied from the
      RESV TSpec [8].

      When present in the BRP for integrated services, the value
      returned is to be used within the RESV TSpec. When present in the
      BRP for differentiated services the value returned contains
      information pretinent for the router on how to handle the TOS
      returned.

      0                   1                   2                   3



Calhoun, Peirce          expires November 1998                 [Page 14]


INTERNET DRAFT                                                  May 1998


      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      310     Maximum-Packet-Size

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the Maximum-Packet-Size.


3.12  QOS-Rate

   Description

      The QOS-Rate AVP contains the rate. This AVP MUST be present if
      the RSVP-Service-Type is set to RSVP-Guaranteed.

      When present in the BRQ, the value of this AVP was copied from the
      RESV TSpec [8].

      When present in the BRP for integrated services, the value
      returned is to be used within the RESV TSpec. When present in the
      BRP for differentiated services the value returned contains
      information pretinent for the router on how to handle the TOS
      returned.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |



Calhoun, Peirce          expires November 1998                 [Page 15]


INTERNET DRAFT                                                  May 1998


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      311     QOS-Rate

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the QOS-Rate.


3.13  Slack-Term

   Description

      The QOS-Rate AVP contains the delay. This AVP MUST be present if
      the RSVP-Service-Type is set to RSVP-Guaranteed.

      When present in the BRQ, the value of this AVP was copied from the
      RESV TSpec [8].

      When present in the BRP for integrated services, the value
      returned is to be used within the RESV TSpec. When present in the
      BRP for differentiated services the value returned contains
      information pretinent for the router on how to handle the TOS
      returned.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code



Calhoun, Peirce          expires November 1998                 [Page 16]


INTERNET DRAFT                                                  May 1998


      312     Slack-Term

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the Slack-Term.


3.14  Inbound-Interface

   Description

      This attribute contains the IP Address of the Inbound Interface.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      313     Inbound-Interface

      AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Address

      The Address field contains the inbound interface address.





Calhoun, Peirce          expires November 1998                 [Page 17]


INTERNET DRAFT                                                  May 1998


3.15  Outbound-Interface

   Description

      This attribute contains the IP Address of the Outbound Interface.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      314     Outbound-Interface

      AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Address

      The Address field contains the outbound interface address.


3.16  QOS-Service-Type

   Description

      This attribute contains the QOS Service Type. When present in the
      BRQ it contains an indication to the server of the inbound QOS
      type. When found in a BRP, it contains an indication to the client
      on the type of QOS to use for the flow.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |



Calhoun, Peirce          expires November 1998                 [Page 18]


INTERNET DRAFT                                                  May 1998


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      315     QOS-Service-Type

      AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the QOS Service Type. The following
      values values have been defined:

         RSVP                       1 TOS                        2


3.17  Inbound-TOS-Value

   Description

      This attribute contains the value in the IP Header's Type-of-
      Service field [4] for inbound packets.

      When present in the BRQ, the value of this AVP was copied from the
      user's packet that initiated the BRQ. When found in the BRP the
      value returned contains the TOS to expect for the flow.

      Caveat: It is still unclear whether a TOS value is a mutable
      field. This issue is still under debate in the diff-serv working
      group.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Octet      |
      +-+-+-+-+-+-+-+-+



Calhoun, Peirce          expires November 1998                 [Page 19]


INTERNET DRAFT                                                  May 1998


   AVP Code

      316     Inbound-TOS-Value

      AVP Length

      The length of this attribute MUST be 9.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Octet

      The Octet field contains the Differentiated Services Type of
      Service value.


3.18  Outbound-TOS-Value

   Description

      This attribute contains the value in the IP Header's Type-of-
      Service field [4] for inbound packets.

      When present in the BRQ, the value of this AVP is a suggestion by
      the initiator on the TOS value to use for the flow. When found in
      the BRP, it contains the TOS value to use for the flow.

      Caveat: It is still unclear whether a TOS value is a mutable
      field. This issue is still under debate in the diff-serv working
      group.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Octet      |
      +-+-+-+-+-+-+-+-+

   AVP Code

      317     Outbound-TOS-Value

      AVP Length



Calhoun, Peirce          expires November 1998                 [Page 20]


INTERNET DRAFT                                                  May 1998


      The length of this attribute MUST be 9.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.

   Octet

      The Octet field contains the Differentiated Services Type of
      Service value.


3.19  Session-Timeout

   Description

      The Hold Off Timer is used to specify the length of time for which
      a given policy is valid, or the length of time the client should
      wait before asking the policy server for a new policy value for a
      given Session-Id. This timer acts as a simple mechanism to prevent
      denial of service attacks on a policy server. It also works to
      ensure that policy information must be renewed periodically.

      Times are encoded as 32-bit integer values and are in units of
      seconds.  The time value is treated as a delta from the point at
      which the client receives the message containing the Hold Off
      Timer.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      27     Session-Timeout

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags




Calhoun, Peirce          expires November 1998                 [Page 21]


INTERNET DRAFT                                                  May 1998


      The flag field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is 4 octets, containing a 32-bit unsigned
      integer with the maximum number of seconds the flow is valid.

      A value of zero means that this flow has an unlimited number of
      seconds before termination.


4.0  Client Server interaction examples

   The following examples describe possible interactions between the
   client and server for RAP procedures. The examples below show RSVP as
   the reservation protocol, but other attributes could easily be
   defined for handling differentiated services.

   DIAMETER already has extensions to support IPSEC and other policy
   entities[3].

   Note that it is possible for a router to generate a BRQ for
   integrated services and receive a BRP that states that differentiated
   services is to be used. This allows the Policy Router to make the
   determination on when to bridge from one method to the other.


4.1  Bandwidth-Request (BRQ)  Client -> Policy Server

4.1.1 Bandwidth-Request with Differentiated Services

   When a device receives a packet for a new data stream with a specific
   TOS value, the router needs to ensure that the sender/receiver pair
   is authorized to allocate bandwidth, and more importantly that there
   is enough bandwidth to allocate to the user according to the policy
   (where the policy can define the amount of bandwidth a whole network
   can allocate at any given time and the user's request must be
   evaluated against all existing allocation of other nodes within that
   network).


      +--------+     +--------+            +--------+
      |        |     |        |            |        |
      |  Host  |-----| Router |------------|  Dest  |
      |        |     |        |            |        |
      +--------+     +--------+            +--------+
                         |
                         |   +--------+



Calhoun, Peirce          expires November 1998                 [Page 22]


INTERNET DRAFT                                                  May 1998


                         |   |        |
                         +---| Policy |
                             |        |
                             +--------+

   The router does this by sending a BRQ message to it's local DIAMETER
   server and includes such information as the source and destination
   address/port numbers and MAY include a prefered Rate and Depth for
   the flow. The request MAY also includes the QOS-DS-Value found in the
   user's packet.

   The Server evaluates the request against the known policy for the
   user (or the network the user belongs to) and ensures that the user
   is authorized and that the current allocation for the user/network
   fits within the policy. If all conditions are true, the Server
   formulates an Allocate-Bandwidth-Response message that includes the
   Rate, Depth as well as the value to be used in the TOS field of the
   IP Header.

   The format of a simple Bandwidth-Request message is as follows:

   Bandwidth-Request ::= <DIAMETER Header>
                         <Bandwidth-Request Command AVP>
                         <Session-Id AVP>
                         <Source-Address AVP>
                         <Destination-Address AVP>
                         <Protocol AVP>
                         <QOS-Service-Type AVP>
                         <Inbound-Interface AVP>
                         [<Outbound-Interface AVP>]
                         [<Source-Port AVP>]
                         [<Destination-Port AVP>]
                         [<Inbound-TOS-Value AVP>]
                         [<Outbound-TOS-Value AVP>]

   The mechanism described above can work equally well if the DIAMETER
   client is the host that wishes to setup an end-to-end QOS flow. In
   this case the client issues an Allocate-Bandwidth-Request message
   with the source and destination addresses, but does not need to
   include the TOS-DS-Value AVP since that information is not known at
   the time of the request.


4.1.2 Bandwidth-Request with Integrated Services

   The client sends information found in the RSVP message to the
   server.The client provides the server with a unique Session-Id AVP
   which is used in subsequent DIAMETER messages as a handle to identify



Calhoun, Peirce          expires November 1998                 [Page 23]


INTERNET DRAFT                                                  May 1998


   the particular flow.

   Once a session is established any subsequent modifications to the
   request can be made using the message with a RRQ using previously
   established Session-Id. For example, when a change in a reservation
   happens on a refresh, the router will simply supply the new
   information in a RRQ message with the existing session associated
   with the reservation state.

   The format of a simple Bandwidth-Request message is as follows:

   Bandwidth-Request ::= <DIAMETER Header>
                         <Bandwidth-Request Command AVP>
                         <Session-Id AVP>
                         <RSVP-Service-Type AVP>
                         <Source-Address AVP>
                         <Destination-Address AVP>
                         <Protocol AVP>
                         <QOS-Service-Type AVP>
                         <Inbound-Interface AVP>
                         [<Outbound-Interface AVP>]
                         [<Source-Port AVP>]
                         [<Destination-Port AVP>]
                         [<Token-Bucket-Rate AVP>]
                         [<Token-Bucket-Size AVP>]
                         [<Peak-Data-Rate AVP>]
                         [<Minimum-Policed-Unit AVP>]
                         [<Maximum-Packet-Size AVP>]
                         [<QOS-Rate AVP>]
                         [<Slack-Term AVP>]
                         [<Session-Timeout AVP>]

   The additional objects are optional and can give more information on
   the RSVP state.


4.2  Bandwidth-Response (BRP)  Policy Server -> Client

4.2.1 Bandwidth-Response with Differentiated Services

   When the policy server determines that a BRW falls within the
   parameters of the configured policy, a BRP message is forwarded to
   the DIAMETER client. The response contains the information necessary
   for the router to understand how to treat the flow.

   The format of the Bandwidth-Response message is as follows:

   Bandwidth-Response ::= <DIAMETER header>



Calhoun, Peirce          expires November 1998                 [Page 24]


INTERNET DRAFT                                                  May 1998


                          <Bandwidth-Response Command AVP>
                          <Session-Id AVP>
                          <Result-Code AVP>
                          <QOS-Service-Type AVP>
                          <Inbound-TOS-Value AVP>
                          <Outbound-TOS-Value AVP>
                          <Token-Bucket-Rate AVP>
                          <Token-Bucket-Size AVP>
                          <Peak-Data-Rate AVP>
                          <Minimum-Policed-Unit AVP>
                          <Maximum-Packet-Size AVP>
                          <QOS-Rate AVP>
                          <Slack-Term AVP>
                          [<Session-Timeout AVP>]

   If the TOS value received by the router is different than the one
   found in the user's packet upon reception the router MUST translate
   all incoming packets with the value received by the server. This
   mechanism allows a mapping from the user's network to the local
   network.


4.1.2 Bandwidth-Response with Integrated Services

   The server responds to the BRQ with a BRP message that includes the
   Session-Id AVP and the response.  In addition, the response may
   include policy information that is different from the request. This
   assumes wholesale replacement of a previously received policy
   object(s) with appropriate modifications.

   Outstanding requests are matched to responses with the identifier
   field.

   The format of the Bandwidth-Response message is as follows:

   Bandwidth-Response ::= <DIAMETER header>
                          <Bandwidth-Response Command AVP>
                          <Session-Id AVP>
                          <Result-Code AVP>
                          <QOS-Service-Type>
                          <RSVP-Service-Type AVP>
                          <Token-Bucket-Rate AVP>
                          <Token-Bucket-Size AVP>
                          <Peak-Data-Rate AVP>
                          <Minimum-Policed-Unit AVP>
                          <Maximum-Packet-Size AVP>
                          <QOS-Rate AVP>
                          <Slack-Term AVP>



Calhoun, Peirce          expires November 1998                 [Page 25]


INTERNET DRAFT                                                  May 1998


                          [<Session-Timeout AVP>]

   The additional objects are optional and can give more information on
   replacement of policy objects, and can permit the extension of policy
   enforcement capabilities.


4.3  Integration with Resource-Management

   Document [2] specifies the Resource-Token AVP that is used to carry
   information required for a DIAMETER server to rebuild its state
   information in the event of a crash or some other event that would
   cause the server to loose its state information.

   When creating the Resource-Token AVP, the following AVPs MUST be
   present, in addition to the AVPs listed in [2]; the Source-Address,
   Source-Port, Destination-Address, Destination-Port, QOS-Rate and
   QOS-Depth AVPs. Any additional AVP MAY be included if the AVP is a
   resource that is being managed.

   This document discusses the bandwidth allocation messages which is
   analogous to session creation. A message is required for the client
   to the server to perform session teardown. This is handled using the
   Session-Free-Request/Response messages defined in [2].


4.3.1  Session-Reclaim-Request (SRR) Policy Server -> Client

   The server can send a non-solicited message to request that an
   existing session be pre-empted. This is done by sending a SRR to the
   client. The client MUST respond with a SRP message.

   The format of the SRR with QOS extension attributes is:

   <Session-Reclaim-Request> ::= <DIAMETER Header>
                                 <Session-Reclaim-Request Command AVP>
                                 <Session-ID AVP>

   Note that the Session-Id is reconstructed by the Client as the
   DIAMETER header will include the correct 16 identifier.


4.3.2  Session-Reclaim-Response (SRP) Policy Server -> Client

   This message indicates whether the Session-Reclaim-Request was
   successfully processed or not. Upon successful response, the server
   must assume that the requested session has been terminated.




Calhoun, Peirce          expires November 1998                 [Page 26]


INTERNET DRAFT                                                  May 1998


   The format of the SRP with QOS extension attributes is:

   Session-Reclaim-Response ::= <DIAMETER Header>
                                <Session-Reclaim-Response Command AVP>
                                <Session-ID AVP>
                                <Result-Code AVP>

   Note that the Session-Id is reconstructed by the Client as the
   DIAMETER header will include the correct 16 identifier.


4.3.3  Session-Free-Request (SFR) Client -> Policy Server

   This message indicates to the server that the PATH or RESV state has
   been deleted. This will be used by the server to initiate appropriate
   clean up actions. Reasons may include: PATH_ or RESV_TEAR, pre-
   emption, SNMP, loss of soft state.

   The format of the SFR message is as follows:

   <Session-Free-Request>  ::= <DIAMETER Header>
                               <Session-Free-Request Command AVP>
                               <Session-Id AVP>


4.3.4  Session-Free-Response (SFP) Policy Server -> Client

   This message indicates to the Client that the corresponding Session-
   Free-Request has been acknowledged. This is always a positive
   acknowledgement.

   The format of the SFR message is as follows:

   <Session-Free-Response>  ::= <DIAMETER Header>
                                <Session-Free-Response Command AVP>
                                <Session-Id AVP>
                                <Result-Code AVP>


4.3.5  Query-Resource-Request (QRR) Policy Server -> Client

   The server uses this message to request a list of state that has been
   approved and not yet deleted.  A case where this would be used is in
   server connection startup time.

   The format of the QRR with QOS extension attributes is as follows:

   <Query-Resource-Request>  ::= <DIAMETER Header>



Calhoun, Peirce          expires November 1998                 [Page 27]


INTERNET DRAFT                                                  May 1998


                                 <Query-Resource-Request Command AVP>
                                 <Session-Id AVP>

   If the Session-Id is recognized, the server is querying about the
   state of a particular request. The absence of the Session-Id AVP
   indicates that the server wishes to synchronize all the state.


4.3.6  Query-Resource-Response (QRS) Client -> Policy Server

   This message from the client includes the original request attributes
   and the identifier corresponds to that of the corresponding request.

   The format of the QRS message is as follows:

   <Query-Resource-Response>  ::= <DIAMETER Header>
                                  <Query-Resource-Response Command AVP>
                                  <Result-Code AVP>
                                  <Resource-Token AVP #1>
                                  <Resource-Token AVP #2>
                                  <Resource-Token AVP #n>


4.4  Cross-domain Differentiated-Services with DIAMETER

   There exists a strong case where the destination of the user's packet
   does not belong to the network owning the DIAMETER Server. This is
   still an area requiring much research but one could envision the
   DIAMETER server communicating with a Route Server in order to
   determine the path of the packet.

   Note the following is an example only. Research in this area is still
   under way in the WG and this document will be revised once a solution
   has been proposed.


      +--------+     +--------+   +--------+   +--------+         +--------+
      |        |     |  ISPA  |   |  ISPA  |   |  ISPB  |         |        |
      |  Host  |-----| Router |---| Router |---| Router |---------|  Dest  |
      |        |     |   1    |   |   2    |   |   3    |         |        |
      +--------+     +--------+   +--------+   +--------+         +--------+
                         |
                         |   +--------+            +--------+
                         |   |        |            |        |
                         +---| Policy |------------| Policy |
                             |   A    |            |   B    |
                             +--------+            +--------+




Calhoun, Peirce          expires November 1998                 [Page 28]


INTERNET DRAFT                                                  May 1998


   The above diagram depicts an example where the said packet needs to
   be forwarded from ISPA to ISPB's network in order to reach its
   ultimate destination. When the ISPA Router-1 receives the packet it
   sends the BRQ to Policy-A.

   Server Policy-A ensures that the user has both authorization to
   request bandwidth and the amount of bandwidth already reserved falls
   within the policy. The Policy-A Server then modifies the TOS-DS-Value
   in the request to represent the value that will be used within the
   local network and proxies the request to Policy-B.

   Upon receipt of the BRQ, Policy-B performs the required steps to
   ensure that the source/destination pair is authorized to request
   bandwidth and compares the amount of allocated bandwidth from ISPA
   with the policy.

   If the BRQ is successful, Policy-B sends a message (TDB) to ISPB
   Router-3 to inform of the TOS mapping from ISP-A to ISP-B (inbound
   packets). Policy-B then formulates the BRP it back to Policy-A, which
   ensures that the response is successful and then sends a message
   (TDB) to Policy-A Router-2 to notify it of the proper mapping for
   inbound packets with ISP-B's TOS value.

   Policy-A then sends the BRP back to ISPA Router-1 with the local TOS
   value to be used within the network. Knowing the TOS value that was
   received from the Host's original network (if different from ISPA)
   the router will know the mapping of the TOS value from the host's
   network to the local value to the be used within ISPA's network.


5.0  Security Considerations

   This draft relies heavily on the existing security mechanism built
   into the DIAMETER protocol [2]. The base protocol provides support
   for HMAC-MD5-96 using a shared secret, public key cryptography or no
   security in the case where IPSEC is used.


6.0  References

    [1] Rigney, et alia, "RADIUS", RFC 2138, Livingston, January 1997
    [2] Calhoun, Rubens, "DIAMETER", Internet-Draft, April 1998.
    [3] Calhoun, "DIAMETER Resource Management Extensions", Internet-
        Draft, April 1998.
    [4] Boyle et alia, "Protocol for Exchange of PoliCy Information
        (PEPCI)", January 1998.
    [5] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
    [6] Yavatkar, Guerin, "A Framework for Policy-based Admission



Calhoun, Peirce          expires November 1998                 [Page 29]


INTERNET DRAFT                                                  May 1998


        Control", Internet-Draft, November 1997.
    [7] Braden, Zhang, Berson, Herzog, Jamin, "Resource ReSerVation
        Protocol (RSVP)", RFC2205, September 1997.
    [8] Wroclawski, "The Use of RSVP with IETF Integrated Services",
        RFC2210, September 1997.


7.0  Acknowledgements

   The authors would like to note that the content of this draft as it
   applies to RSVP message handling is largely based on the PEPCI[4]
   protocol, a work in progress. The main intent of this draft is to
   encourage the re-use of the well established and freely available
   DIAMETER code with some simple modifications. The authors would like
   to thank the developers of PEPCI for their efforts:

        Jim Boyle, MCI
        Ron Cohen, Class Data Systems
        Laura Cunningham, MCI
        David Durham, Intel
        Arun Sastry, Cisco
        Raj Yavatkar, Intel


8.0  Author's Address

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Technology Development
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-650-786-7733
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@eng.sun.com

      Michael Speer
      Technology Development
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-650-786-6368
         Fax:  1-650-786-6445



Calhoun, Peirce          expires November 1998                 [Page 30]


INTERNET DRAFT                                                  May 1998


      E-mail:  speer@eng.sun.com

      Ken Peirce
      3Com Corporation
      1800 W. Central Ave.
      Mount Prospect, Il, 60031
      USA

       Phone:  1-847-342-6894
         Fax:  1-847-222-2424
      E-Mail:  kenneth_Peirce@mw.3com.com








































Calhoun, Peirce          expires November 1998                 [Page 31]