idnits 2.17.1 draft-calhoun-diameter-qos-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 118: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 122: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 125: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 131: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 133: '...hich does not include this option MUST...' (59 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 1340, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1343, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2139 (ref. '5') (Obsoleted by RFC 2866) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAP Working Group Pat Calhoun 3 INTERNET DRAFT Michael Speer 4 Category: Internet Draft Sun Microsystems, Inc. 5 Title: draft-calhoun-diameter-qos-00.txt Ken Peirce 6 Date: May 1998 3Com Corporation 8 DIAMETER 9 QOS Extension 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet- 22 Drafts as reference material or to cite them other than as a 23 ``working draft'' or ``work in progress.'' 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 30 (US West Coast). 32 Abstract 34 This document describes a simple client/server model for supporting 35 QOS policies. A router that supports RSVP or one of the proposed 36 differentiated service schemes will require a policy database and a 37 means to access it. This document describes the extensions to a 38 protocol based originally on RADIUS [1] called DIAMETER[2]. This 39 document does not describe the policy database or policy enforcement. 41 Table of Contents 42 1.0 Introduction 43 1.1 Definitions 44 2.0 Command Codes 45 2.1 Bandwidth-Request (BRQ) 46 2.2 Bandwidth-Response (BRP) 47 3.0 DIAMETER AVPs 48 3.1 Source-Address 49 3.2 Destination-Address 50 3.3 Source-Port 51 3.4 Destination-Port 52 3.5 Protocol 53 3.6 RSVP-Service-Type 54 3.7 Token-Bucket-Rate 55 3.8 Token-Bucket-Size 56 3.9 Peak-Data-Rate 57 3.10 Minimum-Policed-Unit 58 3.11 Maximum-Packet-Size 59 3.12 QOS-Rate 60 3.13 Slack-Term 61 3.14 Inbound-Interface 62 3.15 Outbound-Interface 63 3.16 QOS-Service-Type 64 3.17 Inbound-TOS-Value 65 3.18 Outbound-TOS-Value 66 3.19 Session-Timeout 67 4.0 Client Server interaction examples 68 4.1 Bandwidth-Request (BRQ) Client -> Policy Server 69 4.1.1 Bandwidth-Request with Differentiated Services 70 4.1.2 Bandwidth-Request with Integrated Services 71 4.2 Bandwidth-Response (BRP) Policy Server -> Client 72 4.2.1 Bandwidth-Response with Differentiated Services 73 4.1.2 Bandwidth-Response with Integrated Services 74 4.3 Integration with Resource-Management 75 4.3.1 Session-Reclaim-Request (SRR) Policy Server -> Client 76 4.3.2 Session-Reclaim-Response (SRP) Policy Server -> Client 77 4.3.3 Session-Free-Request (SFR) Client -> Policy Server 78 4.3.4 Session-Free-Response (SFP) Policy Server -> Client 79 4.3.5 Query-Resource-Request (QRR) Policy Server -> Client 80 4.3.6 Query-Resource-Response (QRS) Client -> Policy Server 81 4.4 Cross-domain Integrated-Services with DIAMETER 82 5.0 Security Considerations 83 6.0 References 84 7.0 Acknowledgements 85 8.0 Author's Address 87 1.0 Introduction 89 This document describes extensions to DIAMETER, a protocol superset 90 of RADIUS and a work in progress. RADIUS is based on a client/server 91 model and was originally used for authentication and accounting 92 purposes. RADIUS in itself is not an extensible protocol largely due 93 to its very limited command and attribute address space. In addition, 94 the RADIUS protocol assumes that there cannot be any unsolicited 95 messages from a server to a client. In order to support new services, 96 such as RSVP or differentiated services policy, it is imperative that 97 a policy server be able to send unsolicited messages to clients on a 98 network, and this is one of the two primary motivations of the 99 DIAMETER protocol. 101 The other primary motivation for DIAMETER is that its implementation 102 represents a small modification to a RADIUS server. RADIUS servers 103 are used to control the authentication and accounting of millions of 104 internet users each day. The RADIUS source code is freely available 105 and these servers are resident at the "edges" of the network. Current 106 trends in the area of quality of service(qos) and differentiated 107 services indicate that overhead intensive protocols, like RSVP, will 108 be used at the edges of the internet, while more scaleable 109 differentiated services solutions will be employed within the 110 backbone fabric. This places the DIAMETER server at the correct 111 location within the network to service RSVP/Diff-Serv requests. 113 1.1 Definitions 115 In this document, several words are used to signify the requirements 116 of the specification. These words are often capitalized. 118 MUST This word, or the adjective "required", means that the 119 definition is an absolute requirement of the 120 specification. 122 MUST NOT This phrase means that the definition is an absolute 123 prohibition of the specification. 125 SHOULD This word, or the adjective "recommended", means that 126 there may exist valid reasons in particular circumstances 127 to ignore this item, but the full implications must be 128 understood and carefully weighed before choosing a 129 different course. 131 MAY This word, or the adjective "optional", means that this 132 item is one of an allowed set of alternatives. An 133 implementation which does not include this option MUST 134 be prepared to interoperate with another implementation 135 which does include the option. 137 2.0 Command Codes 139 This document defines the following DIAMETER Commands. All DIAMETER 140 implementations supporting this extension MUST support all of the 141 following commands: 143 Command Name Command Code 144 ----------------------------------- 145 Bandwidth-Request 300 146 Bandwidth-Response 301 148 2.1 Bandwidth-Request (BRQ) 150 Description 152 A Bandwidth-Request message is sent by the client to the server 153 and is used to request that the server examine the proposed QOS 154 flow against the current policy and available bandwidth for the 155 policy. 157 The Session-Id MUST accompany this command. 159 A summary of the Bandwidth-Request packet format is shown below. 160 The fields are transmitted from left to right. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | AVP Code | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | AVP Length | AVP Flags | Reserved | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Command Code | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Code 174 256 DIAMETER Command 176 AVP Length 178 The length of this attribute MUST be 12. 180 AVP Flags 182 The AVP Flags field MUST have bit one (Mandatory Support) set. 184 Command Type 186 The Command Type field MUST be set to 300 (Bandwidth-Request). 188 2.2 Bandwidth-Response (BRP) 190 Description 192 Bandwidth-Response packets are sent by the server to the client to 193 in response to an Bandwidth-Request message. This packet follows 194 the DIAMETER rules and include the attributes that accompanied the 195 request in addition to other attributes appropriate for the 196 corresponding request. 198 The Session-Id AVP MUST accompany this command. 200 A summary of the Bandwidth-Response packet format is shown below. 201 The fields are transmitted from left to right. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | AVP Code | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | AVP Length | AVP Flags | Reserved | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Command Code | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Code 215 256 DIAMETER Command 217 AVP Length 219 The length of this attribute MUST be 12. 221 AVP Flags 223 The AVP Flags field MUST have bit one (Mandatory Support) set. 225 Command Type 226 The Command Type field MUST be set to 301 (Bandwidth-Response). 228 3.0 DIAMETER AVPs 230 This section will define the mandatory AVPs which MUST be recognized 231 by all DIAMETER implementations supporting this extension. The 232 following AVPs are defined in this document: 234 Attribute Name Attribute Code 235 ----------------------------------- 236 Source-Address 300 237 Destination-Address 301 238 Source-Port 302 239 Destination-Port 303 240 Protocol 304 241 RSVP-Service-Type 305 242 Token-Bucket-Rate 306 243 Token-Bucket-Size 307 244 Peak-Data-Rate 308 245 Minimum-Policed-Unit 309 246 Maximum-Packet-Size 310 247 QOS-Rate 311 248 Slack-Term 312 249 Inbound-Interface 313 250 Outbound-Interface 314 251 QOS-Service-Type 315 252 Inbound-TOS-Value 316 253 Outboud-TOS-Value 317 254 Session-Timeout 27 256 3.1 Source-Address 258 Description 260 This attribute contains the source address of the proposed QOS 261 flow. The absence of this AVP or the presence of this AVP with a 262 value of 0 represents a wildcard filter. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | AVP Code | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | AVP Length | AVP Flags | Reserved | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Address | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 AVP Code 276 300 Source-Address 278 AVP Length 280 The length of this attribute MUST be at least 12. 282 AVP Flags 284 The flag field MUST have bit one (Mandatory Support) set. 286 Address 288 The Address field contains the source address of the QOS flow. 290 3.2 Destination-Address 292 Description 294 This attribute contains the destination address of the proposed 295 QOS flow. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | AVP Code | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | AVP Length | AVP Flags | Reserved | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Address | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 AVP Code 309 301 Destination-Address 311 AVP Length 313 The length of this attribute MUST be at least 9. 315 AVP Flags 317 The flag field MUST have bit one (Mandatory Support) set. 319 Address 321 The Address field contains the destination address of the QOS 322 flow. 324 3.3 Source-Port 326 Description 328 This attribute contains the source port of the proposed QOS flow. 329 The absence of this AVP or the presence of this AVP with a value 330 of 0 represents a wildcard filter. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | AVP Code | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | AVP Length | AVP Flags | Reserved | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Integer32 | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 AVP Code 344 302 Source-Port 346 AVP Length 348 The length of this attribute MUST be at least 12. 350 AVP Flags 352 The flag field MUST have bit one (Mandatory Support) set. 354 Integer32 356 The Integer32 field contains the source port of the QOS flow. 357 Regardless of the size of the field, the value MUST be between 0 358 and 65535. 360 3.4 Destination-Port 362 Description 364 This attribute contains the destination port of the proposed QOS 365 flow. 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | AVP Code | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | AVP Length | AVP Flags | Reserved | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Integer32 | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 AVP Code 379 303 Destination-Port 381 AVP Length 383 The length of this attribute MUST be at least 9. 385 AVP Flags 387 The flag field MUST have bit one (Mandatory Support) set. 389 Integer32 391 The Integer32 field contains the destination port of the QOS flow. 392 Regardless of the size of the field, the value MUST be between 0 393 and 65535. 395 3.5 Protocol 397 Description 399 This attribute contains the protocol of the proposed QOS flow. 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | AVP Code | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | AVP Length | AVP Flags | Reserved | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Integer32 | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 AVP Code 412 304 Protocol 414 AVP Length 416 The length of this attribute MUST be at least 9. 418 AVP Flags 420 The flag field MUST have bit one (Mandatory Support) set. 422 Integer32 424 The Integer32 field contains the IP protocol. 426 3.6 RSVP-Service-Type 428 Description 430 The RSVP-Service-Type AVP contains the reservation type. 432 When present in the BRQ, the value of this AVP was copied from the 433 RESV TSpec [8]. When present in the BRP, the value returned is to 434 be used within the RESV TSpec. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | AVP Code | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | AVP Length | AVP Flags | Reserved | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Integer32 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 AVP Code 448 305 RSVP-Service-Type 450 AVP Length 452 The length of this attribute MUST be 12. 454 AVP Flags 456 The flag field MUST have bit one (Mandatory Support) set. 458 Integer32 459 The Integer32 field contains the RSVP-Service-Type. The following 460 values have been defined: 462 RSVP-Controlled-Load 1 RSVP-Guaranteed 2 464 Implementation Note: When the RSVP-Service-Type value is set to 465 RSVP-Guaranteed, the QOS-Rate and the Slack-Term AVPs MUST be 466 present. 468 3.7 Token-Bucket-Rate 470 Description 472 The Token-Bucket-Rate AVP contains the token bucket rate. 474 When present in the BRQ, the value of this AVP was copied from the 475 RESV TSpec [8]. 477 When present in the BRP for integrated services, the value 478 returned is to be used within the RESV TSpec. When present in the 479 BRP for differentiated services the value returned contains 480 information pretinent for the router on how to handle the TOS 481 returned. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | AVP Code | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | AVP Length | AVP Flags | Reserved | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Integer32 | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 AVP Code 495 306 Token-Bucket-Rate 497 AVP Length 499 The length of this attribute MUST be 12. 501 AVP Flags 503 The flag field MUST have bit one (Mandatory Support) set. 505 Integer32 506 The Integer32 field contains the Token-Bucket-Rate. 508 3.8 Token-Bucket-Size 510 Description 512 The Token-Bucket-Size AVP contains the token bucket size. 514 When present in the BRQ, the value of this AVP was copied from the 515 RESV TSpec [8]. 517 When present in the BRP for integrated services, the value 518 returned is to be used within the RESV TSpec. When present in the 519 BRP for differentiated services the value returned contains 520 information pretinent for the router on how to handle the TOS 521 returned. 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | AVP Code | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | AVP Length | AVP Flags | Reserved | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Integer32 | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 AVP Code 535 307 Token-Bucket-Size 537 AVP Length 539 The length of this attribute MUST be 12. 541 AVP Flags 543 The flag field MUST have bit one (Mandatory Support) set. 545 Integer32 547 The Integer32 field contains the Token-Bucket-Size. 549 3.9 Peak-Data-Rate 551 Description 552 The Peak-Data-Rate AVP contains the peak data rate. 554 When present in the BRQ, the value of this AVP was copied from the 555 RESV TSpec [8]. 557 When present in the BRP for integrated services, the value 558 returned is to be used within the RESV TSpec. When present in the 559 BRP for differentiated services the value returned contains 560 information pretinent for the router on how to handle the TOS 561 returned. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | AVP Code | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | AVP Length | AVP Flags | Reserved | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Integer32 | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 AVP Code 575 308 Peak-Data-Rate 577 AVP Length 579 The length of this attribute MUST be 12. 581 AVP Flags 583 The flag field MUST have bit one (Mandatory Support) set. 585 Integer32 587 The Integer32 field contains the Peak-Data-Rate. 589 3.10 Minimum-Policed-Unit 591 Description 593 The Minimum-Policed-Unit AVP contains the minimum policed unit. 595 When present in the BRQ, the value of this AVP was copied from the 596 RESV TSpec [8]. 598 When present in the BRP for integrated services, the value 599 returned is to be used within the RESV TSpec. When present in the 600 BRP for differentiated services the value returned contains 601 information pretinent for the router on how to handle the TOS 602 returned. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | AVP Code | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | AVP Length | AVP Flags | Reserved | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Integer32 | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 AVP Code 616 309 Minimum-Policed-Unit 618 AVP Length 620 The length of this attribute MUST be 12. 622 AVP Flags 624 The flag field MUST have bit one (Mandatory Support) set. 626 Integer32 628 The Integer32 field contains the Minimum-Policed-Unit. 630 3.11 Maximum-Packet-Size 632 Description 634 The Maximum-Packet-Size AVP contains the MTU size. 636 When present in the BRQ, the value of this AVP was copied from the 637 RESV TSpec [8]. 639 When present in the BRP for integrated services, the value 640 returned is to be used within the RESV TSpec. When present in the 641 BRP for differentiated services the value returned contains 642 information pretinent for the router on how to handle the TOS 643 returned. 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | AVP Code | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | AVP Length | AVP Flags | Reserved | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Integer32 | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 AVP Code 657 310 Maximum-Packet-Size 659 AVP Length 661 The length of this attribute MUST be 12. 663 AVP Flags 665 The flag field MUST have bit one (Mandatory Support) set. 667 Integer32 669 The Integer32 field contains the Maximum-Packet-Size. 671 3.12 QOS-Rate 673 Description 675 The QOS-Rate AVP contains the rate. This AVP MUST be present if 676 the RSVP-Service-Type is set to RSVP-Guaranteed. 678 When present in the BRQ, the value of this AVP was copied from the 679 RESV TSpec [8]. 681 When present in the BRP for integrated services, the value 682 returned is to be used within the RESV TSpec. When present in the 683 BRP for differentiated services the value returned contains 684 information pretinent for the router on how to handle the TOS 685 returned. 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | AVP Code | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | AVP Length | AVP Flags | Reserved | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Integer32 | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 AVP Code 699 311 QOS-Rate 701 AVP Length 703 The length of this attribute MUST be 12. 705 AVP Flags 707 The flag field MUST have bit one (Mandatory Support) set. 709 Integer32 711 The Integer32 field contains the QOS-Rate. 713 3.13 Slack-Term 715 Description 717 The QOS-Rate AVP contains the delay. This AVP MUST be present if 718 the RSVP-Service-Type is set to RSVP-Guaranteed. 720 When present in the BRQ, the value of this AVP was copied from the 721 RESV TSpec [8]. 723 When present in the BRP for integrated services, the value 724 returned is to be used within the RESV TSpec. When present in the 725 BRP for differentiated services the value returned contains 726 information pretinent for the router on how to handle the TOS 727 returned. 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | AVP Code | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | AVP Length | AVP Flags | Reserved | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Integer32 | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 AVP Code 740 312 Slack-Term 742 AVP Length 744 The length of this attribute MUST be 12. 746 AVP Flags 748 The flag field MUST have bit one (Mandatory Support) set. 750 Integer32 752 The Integer32 field contains the Slack-Term. 754 3.14 Inbound-Interface 756 Description 758 This attribute contains the IP Address of the Inbound Interface. 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | AVP Code | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | AVP Length | AVP Flags | Reserved | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Address | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 AVP Code 772 313 Inbound-Interface 774 AVP Length 776 The length of this attribute MUST be 12. 778 AVP Flags 780 The flag field MUST have bit one (Mandatory Support) set. 782 Address 784 The Address field contains the inbound interface address. 786 3.15 Outbound-Interface 788 Description 790 This attribute contains the IP Address of the Outbound Interface. 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | AVP Code | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | AVP Length | AVP Flags | Reserved | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Address | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 AVP Code 804 314 Outbound-Interface 806 AVP Length 808 The length of this attribute MUST be 12. 810 AVP Flags 812 The flag field MUST have bit one (Mandatory Support) set. 814 Address 816 The Address field contains the outbound interface address. 818 3.16 QOS-Service-Type 820 Description 822 This attribute contains the QOS Service Type. When present in the 823 BRQ it contains an indication to the server of the inbound QOS 824 type. When found in a BRP, it contains an indication to the client 825 on the type of QOS to use for the flow. 827 0 1 2 3 828 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 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | AVP Code | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | AVP Length | AVP Flags | Reserved | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Integer32 | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 AVP Code 839 315 QOS-Service-Type 841 AVP Length 843 The length of this attribute MUST be 12. 845 AVP Flags 847 The flag field MUST have bit one (Mandatory Support) set. 849 Integer32 851 The Integer32 field contains the QOS Service Type. The following 852 values values have been defined: 854 RSVP 1 TOS 2 856 3.17 Inbound-TOS-Value 858 Description 860 This attribute contains the value in the IP Header's Type-of- 861 Service field [4] for inbound packets. 863 When present in the BRQ, the value of this AVP was copied from the 864 user's packet that initiated the BRQ. When found in the BRP the 865 value returned contains the TOS to expect for the flow. 867 Caveat: It is still unclear whether a TOS value is a mutable 868 field. This issue is still under debate in the diff-serv working 869 group. 871 0 1 2 3 872 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 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | AVP Code | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | AVP Length | AVP Flags | Reserved | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Octet | 879 +-+-+-+-+-+-+-+-+ 881 AVP Code 883 316 Inbound-TOS-Value 885 AVP Length 887 The length of this attribute MUST be 9. 889 AVP Flags 891 The flag field MUST have bit one (Mandatory Support) set. 893 Octet 895 The Octet field contains the Differentiated Services Type of 896 Service value. 898 3.18 Outbound-TOS-Value 900 Description 902 This attribute contains the value in the IP Header's Type-of- 903 Service field [4] for inbound packets. 905 When present in the BRQ, the value of this AVP is a suggestion by 906 the initiator on the TOS value to use for the flow. When found in 907 the BRP, it contains the TOS value to use for the flow. 909 Caveat: It is still unclear whether a TOS value is a mutable 910 field. This issue is still under debate in the diff-serv working 911 group. 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | AVP Code | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | AVP Length | AVP Flags | Reserved | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Octet | 921 +-+-+-+-+-+-+-+-+ 923 AVP Code 925 317 Outbound-TOS-Value 927 AVP Length 928 The length of this attribute MUST be 9. 930 AVP Flags 932 The flag field MUST have bit one (Mandatory Support) set. 934 Octet 936 The Octet field contains the Differentiated Services Type of 937 Service value. 939 3.19 Session-Timeout 941 Description 943 The Hold Off Timer is used to specify the length of time for which 944 a given policy is valid, or the length of time the client should 945 wait before asking the policy server for a new policy value for a 946 given Session-Id. This timer acts as a simple mechanism to prevent 947 denial of service attacks on a policy server. It also works to 948 ensure that policy information must be renewed periodically. 950 Times are encoded as 32-bit integer values and are in units of 951 seconds. The time value is treated as a delta from the point at 952 which the client receives the message containing the Hold Off 953 Timer. 955 0 1 2 3 956 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 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | AVP Code | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | AVP Length | AVP Flags | Reserved | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Integer32 | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 AVP Code 967 27 Session-Timeout 969 AVP Length 971 The length of this attribute MUST be 12. 973 AVP Flags 974 The flag field MUST have bit one (Mandatory Support) set. 976 Integer32 978 The Integer32 field is 4 octets, containing a 32-bit unsigned 979 integer with the maximum number of seconds the flow is valid. 981 A value of zero means that this flow has an unlimited number of 982 seconds before termination. 984 4.0 Client Server interaction examples 986 The following examples describe possible interactions between the 987 client and server for RAP procedures. The examples below show RSVP as 988 the reservation protocol, but other attributes could easily be 989 defined for handling differentiated services. 991 DIAMETER already has extensions to support IPSEC and other policy 992 entities[3]. 994 Note that it is possible for a router to generate a BRQ for 995 integrated services and receive a BRP that states that differentiated 996 services is to be used. This allows the Policy Router to make the 997 determination on when to bridge from one method to the other. 999 4.1 Bandwidth-Request (BRQ) Client -> Policy Server 1001 4.1.1 Bandwidth-Request with Differentiated Services 1003 When a device receives a packet for a new data stream with a specific 1004 TOS value, the router needs to ensure that the sender/receiver pair 1005 is authorized to allocate bandwidth, and more importantly that there 1006 is enough bandwidth to allocate to the user according to the policy 1007 (where the policy can define the amount of bandwidth a whole network 1008 can allocate at any given time and the user's request must be 1009 evaluated against all existing allocation of other nodes within that 1010 network). 1012 +--------+ +--------+ +--------+ 1013 | | | | | | 1014 | Host |-----| Router |------------| Dest | 1015 | | | | | | 1016 +--------+ +--------+ +--------+ 1017 | 1018 | +--------+ 1019 | | | 1020 +---| Policy | 1021 | | 1022 +--------+ 1024 The router does this by sending a BRQ message to it's local DIAMETER 1025 server and includes such information as the source and destination 1026 address/port numbers and MAY include a prefered Rate and Depth for 1027 the flow. The request MAY also includes the QOS-DS-Value found in the 1028 user's packet. 1030 The Server evaluates the request against the known policy for the 1031 user (or the network the user belongs to) and ensures that the user 1032 is authorized and that the current allocation for the user/network 1033 fits within the policy. If all conditions are true, the Server 1034 formulates an Allocate-Bandwidth-Response message that includes the 1035 Rate, Depth as well as the value to be used in the TOS field of the 1036 IP Header. 1038 The format of a simple Bandwidth-Request message is as follows: 1040 Bandwidth-Request ::= 1041 1042 1043 1044 1045 1046 1047 1048 [] 1049 [] 1050 [] 1051 [] 1052 [] 1054 The mechanism described above can work equally well if the DIAMETER 1055 client is the host that wishes to setup an end-to-end QOS flow. In 1056 this case the client issues an Allocate-Bandwidth-Request message 1057 with the source and destination addresses, but does not need to 1058 include the TOS-DS-Value AVP since that information is not known at 1059 the time of the request. 1061 4.1.2 Bandwidth-Request with Integrated Services 1063 The client sends information found in the RSVP message to the 1064 server.The client provides the server with a unique Session-Id AVP 1065 which is used in subsequent DIAMETER messages as a handle to identify 1066 the particular flow. 1068 Once a session is established any subsequent modifications to the 1069 request can be made using the message with a RRQ using previously 1070 established Session-Id. For example, when a change in a reservation 1071 happens on a refresh, the router will simply supply the new 1072 information in a RRQ message with the existing session associated 1073 with the reservation state. 1075 The format of a simple Bandwidth-Request message is as follows: 1077 Bandwidth-Request ::= 1078 1079 1080 1081 1082 1083 1084 1085 1086 [] 1087 [] 1088 [] 1089 [] 1090 [] 1091 [] 1092 [] 1093 [] 1094 [] 1095 [] 1096 [] 1098 The additional objects are optional and can give more information on 1099 the RSVP state. 1101 4.2 Bandwidth-Response (BRP) Policy Server -> Client 1103 4.2.1 Bandwidth-Response with Differentiated Services 1105 When the policy server determines that a BRW falls within the 1106 parameters of the configured policy, a BRP message is forwarded to 1107 the DIAMETER client. The response contains the information necessary 1108 for the router to understand how to treat the flow. 1110 The format of the Bandwidth-Response message is as follows: 1112 Bandwidth-Response ::= 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 [] 1128 If the TOS value received by the router is different than the one 1129 found in the user's packet upon reception the router MUST translate 1130 all incoming packets with the value received by the server. This 1131 mechanism allows a mapping from the user's network to the local 1132 network. 1134 4.1.2 Bandwidth-Response with Integrated Services 1136 The server responds to the BRQ with a BRP message that includes the 1137 Session-Id AVP and the response. In addition, the response may 1138 include policy information that is different from the request. This 1139 assumes wholesale replacement of a previously received policy 1140 object(s) with appropriate modifications. 1142 Outstanding requests are matched to responses with the identifier 1143 field. 1145 The format of the Bandwidth-Response message is as follows: 1147 Bandwidth-Response ::= 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1161 [] 1163 The additional objects are optional and can give more information on 1164 replacement of policy objects, and can permit the extension of policy 1165 enforcement capabilities. 1167 4.3 Integration with Resource-Management 1169 Document [2] specifies the Resource-Token AVP that is used to carry 1170 information required for a DIAMETER server to rebuild its state 1171 information in the event of a crash or some other event that would 1172 cause the server to loose its state information. 1174 When creating the Resource-Token AVP, the following AVPs MUST be 1175 present, in addition to the AVPs listed in [2]; the Source-Address, 1176 Source-Port, Destination-Address, Destination-Port, QOS-Rate and 1177 QOS-Depth AVPs. Any additional AVP MAY be included if the AVP is a 1178 resource that is being managed. 1180 This document discusses the bandwidth allocation messages which is 1181 analogous to session creation. A message is required for the client 1182 to the server to perform session teardown. This is handled using the 1183 Session-Free-Request/Response messages defined in [2]. 1185 4.3.1 Session-Reclaim-Request (SRR) Policy Server -> Client 1187 The server can send a non-solicited message to request that an 1188 existing session be pre-empted. This is done by sending a SRR to the 1189 client. The client MUST respond with a SRP message. 1191 The format of the SRR with QOS extension attributes is: 1193 ::= 1194 1195 1197 Note that the Session-Id is reconstructed by the Client as the 1198 DIAMETER header will include the correct 16 identifier. 1200 4.3.2 Session-Reclaim-Response (SRP) Policy Server -> Client 1202 This message indicates whether the Session-Reclaim-Request was 1203 successfully processed or not. Upon successful response, the server 1204 must assume that the requested session has been terminated. 1206 The format of the SRP with QOS extension attributes is: 1208 Session-Reclaim-Response ::= 1209 1210 1211 1213 Note that the Session-Id is reconstructed by the Client as the 1214 DIAMETER header will include the correct 16 identifier. 1216 4.3.3 Session-Free-Request (SFR) Client -> Policy Server 1218 This message indicates to the server that the PATH or RESV state has 1219 been deleted. This will be used by the server to initiate appropriate 1220 clean up actions. Reasons may include: PATH_ or RESV_TEAR, pre- 1221 emption, SNMP, loss of soft state. 1223 The format of the SFR message is as follows: 1225 ::= 1226 1227 1229 4.3.4 Session-Free-Response (SFP) Policy Server -> Client 1231 This message indicates to the Client that the corresponding Session- 1232 Free-Request has been acknowledged. This is always a positive 1233 acknowledgement. 1235 The format of the SFR message is as follows: 1237 ::= 1238 1239 1240 1242 4.3.5 Query-Resource-Request (QRR) Policy Server -> Client 1244 The server uses this message to request a list of state that has been 1245 approved and not yet deleted. A case where this would be used is in 1246 server connection startup time. 1248 The format of the QRR with QOS extension attributes is as follows: 1250 ::= 1251 1252 1254 If the Session-Id is recognized, the server is querying about the 1255 state of a particular request. The absence of the Session-Id AVP 1256 indicates that the server wishes to synchronize all the state. 1258 4.3.6 Query-Resource-Response (QRS) Client -> Policy Server 1260 This message from the client includes the original request attributes 1261 and the identifier corresponds to that of the corresponding request. 1263 The format of the QRS message is as follows: 1265 ::= 1266 1267 1268 1269 1270 1272 4.4 Cross-domain Differentiated-Services with DIAMETER 1274 There exists a strong case where the destination of the user's packet 1275 does not belong to the network owning the DIAMETER Server. This is 1276 still an area requiring much research but one could envision the 1277 DIAMETER server communicating with a Route Server in order to 1278 determine the path of the packet. 1280 Note the following is an example only. Research in this area is still 1281 under way in the WG and this document will be revised once a solution 1282 has been proposed. 1284 +--------+ +--------+ +--------+ +--------+ +--------+ 1285 | | | ISPA | | ISPA | | ISPB | | | 1286 | Host |-----| Router |---| Router |---| Router |---------| Dest | 1287 | | | 1 | | 2 | | 3 | | | 1288 +--------+ +--------+ +--------+ +--------+ +--------+ 1289 | 1290 | +--------+ +--------+ 1291 | | | | | 1292 +---| Policy |------------| Policy | 1293 | A | | B | 1294 +--------+ +--------+ 1296 The above diagram depicts an example where the said packet needs to 1297 be forwarded from ISPA to ISPB's network in order to reach its 1298 ultimate destination. When the ISPA Router-1 receives the packet it 1299 sends the BRQ to Policy-A. 1301 Server Policy-A ensures that the user has both authorization to 1302 request bandwidth and the amount of bandwidth already reserved falls 1303 within the policy. The Policy-A Server then modifies the TOS-DS-Value 1304 in the request to represent the value that will be used within the 1305 local network and proxies the request to Policy-B. 1307 Upon receipt of the BRQ, Policy-B performs the required steps to 1308 ensure that the source/destination pair is authorized to request 1309 bandwidth and compares the amount of allocated bandwidth from ISPA 1310 with the policy. 1312 If the BRQ is successful, Policy-B sends a message (TDB) to ISPB 1313 Router-3 to inform of the TOS mapping from ISP-A to ISP-B (inbound 1314 packets). Policy-B then formulates the BRP it back to Policy-A, which 1315 ensures that the response is successful and then sends a message 1316 (TDB) to Policy-A Router-2 to notify it of the proper mapping for 1317 inbound packets with ISP-B's TOS value. 1319 Policy-A then sends the BRP back to ISPA Router-1 with the local TOS 1320 value to be used within the network. Knowing the TOS value that was 1321 received from the Host's original network (if different from ISPA) 1322 the router will know the mapping of the TOS value from the host's 1323 network to the local value to the be used within ISPA's network. 1325 5.0 Security Considerations 1327 This draft relies heavily on the existing security mechanism built 1328 into the DIAMETER protocol [2]. The base protocol provides support 1329 for HMAC-MD5-96 using a shared secret, public key cryptography or no 1330 security in the case where IPSEC is used. 1332 6.0 References 1334 [1] Rigney, et alia, "RADIUS", RFC 2138, Livingston, January 1997 1335 [2] Calhoun, Rubens, "DIAMETER", Internet-Draft, April 1998. 1336 [3] Calhoun, "DIAMETER Resource Management Extensions", Internet- 1337 Draft, April 1998. 1338 [4] Boyle et alia, "Protocol for Exchange of PoliCy Information 1339 (PEPCI)", January 1998. 1340 [5] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 1341 [6] Yavatkar, Guerin, "A Framework for Policy-based Admission 1342 Control", Internet-Draft, November 1997. 1343 [7] Braden, Zhang, Berson, Herzog, Jamin, "Resource ReSerVation 1344 Protocol (RSVP)", RFC2205, September 1997. 1345 [8] Wroclawski, "The Use of RSVP with IETF Integrated Services", 1346 RFC2210, September 1997. 1348 7.0 Acknowledgements 1350 The authors would like to note that the content of this draft as it 1351 applies to RSVP message handling is largely based on the PEPCI[4] 1352 protocol, a work in progress. The main intent of this draft is to 1353 encourage the re-use of the well established and freely available 1354 DIAMETER code with some simple modifications. The authors would like 1355 to thank the developers of PEPCI for their efforts: 1357 Jim Boyle, MCI 1358 Ron Cohen, Class Data Systems 1359 Laura Cunningham, MCI 1360 David Durham, Intel 1361 Arun Sastry, Cisco 1362 Raj Yavatkar, Intel 1364 8.0 Author's Address 1366 Questions about this memo can be directed to: 1368 Pat R. Calhoun 1369 Technology Development 1370 Sun Microsystems, Inc. 1371 15 Network Circle 1372 Menlo Park, California, 94025 1373 USA 1375 Phone: 1-650-786-7733 1376 Fax: 1-650-786-6445 1377 E-mail: pcalhoun@eng.sun.com 1379 Michael Speer 1380 Technology Development 1381 Sun Microsystems, Inc. 1382 15 Network Circle 1383 Menlo Park, California, 94025 1384 USA 1386 Phone: 1-650-786-6368 1387 Fax: 1-650-786-6445 1389 E-mail: speer@eng.sun.com 1391 Ken Peirce 1392 3Com Corporation 1393 1800 W. Central Ave. 1394 Mount Prospect, Il, 60031 1395 USA 1397 Phone: 1-847-342-6894 1398 Fax: 1-847-222-2424 1399 E-Mail: kenneth_Peirce@mw.3com.com