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 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 ::= [] [] [] [] [] 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 ::= [] [] [] [] [] [] [] [] [] [] [] 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 ::= Calhoun, Peirce expires November 1998 [Page 24] INTERNET DRAFT May 1998 [] 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 ::= Calhoun, Peirce expires November 1998 [Page 25] INTERNET DRAFT May 1998 [] 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: ::= 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 ::= 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: ::= 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: ::= 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: ::= Calhoun, Peirce expires November 1998 [Page 27] INTERNET DRAFT May 1998 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: ::= 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]