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]