idnits 2.17.00 (12 Aug 2021) /tmp/idnits38835/draft-adrangi-radius-bandwidth-capability-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 13 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 26 has weird spacing: '... The list ...' == Line 34 has weird spacing: '... This docum...' == Line 145 has weird spacing: '...US, and the A...' == Line 463 has weird spacing: '... An integ...' == Line 503 has weird spacing: '... An integ...' == (1 more instance...) -- 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.) -- The document date (July 16, 2004) is 6518 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC 3588' on line 94 -- Looks like a reference, but probably isn't: 'Diameter NASREQ' on line 146 -- Looks like a reference, but probably isn't: 'RFC2119' on line 105 -- Looks like a reference, but probably isn't: 'Diameter EAP' on line 146 == Unused Reference: '2' is defined on line 570, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3576 (ref. '3') (Obsoleted by RFC 5176) ** Obsolete normative reference: RFC 3588 (ref. '4') (Obsoleted by RFC 6733) Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group F. Adrangi, Intel 2 INTERNET DRAFT P. Congdon, C. Black, Hewlett Packard 3 Category: Informational A. Lior, Bridgewater Systems 4 Expires: Dec 2004 F. Bari, AT&T Wireless 5 July 16, 2004 7 Network Bandwidth Parameters 8 draft-adrangi-radius-bandwidth-capability-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes bandwidth profile parameters and a 35 protocol framework that enables an AAA server to specify the 36 parameters that should be allocated by the access network for 37 duration of an authorized user session. 39 Table of Contents 41 1. Introduction....................................................2 42 1.2 Requirements language..........................................3 43 2. Overview........................................................3 44 2.1 Bandwidth Parameters...........................................3 45 2.1.1 Minimum Bandwidth for ingress and egress.....................3 46 2.1.2 Maximum Bandwidth for ingress and egress.....................3 47 2.2 Protocol.......................................................3 48 2.2.1 Static Bandwidth Allocation..................................5 49 2.2.2 Dynamic Bandwidth Allocation.................................6 50 2.2.2.1 Push Method................................................6 51 2.2.2.2 Pull Method................................................8 52 2.3 Diameter RADIUS Interoperability...............................9 53 3. Attribute Format/Syntax.........................................9 54 4. Table of Attribute(s)..........................................11 55 5. IANA Considerations............................................12 56 6. Security Considerations........................................12 57 7. Acknowledgements...............................................13 58 8. References.....................................................13 59 AuthorsÆ Addresses................................................13 61 1. Introduction 63 The bandwidth that a user is authorized within an access network 64 can be a result of the access network capabilities based on its 65 architecture and access technology, and the type of user 66 subscription to the home network (e.g., gold, silver, bronze user 67 types). 69 This document describes a simple protocol framework that enables 70 an access network to advertise its network bandwidth capabilities 71 that it can allocate for a given client connection. And, it 72 enables the home network to indicate the desired network bandwidth 73 capabilities for the user connection within the access network. 75 User bandwidth can be determined during initial authentication 76 authorization of the session. It is also desirable to change the 77 bandwidth mid-session. For example, the user may want to purchase 78 additional bandwidth to download a large file. This document 79 enables operators to dynamically modify the bandwidth allocation 80 for a session. 82 This document defines new AAA attributes that can optionally be 83 used for the following; 85 . Conveying bandwidth parameters to the home network that an 86 access network can allocate for a given user session 88 . Conveying the desired bandwidth parameters from the home 89 network that should be allocated by the access network for 90 the duration of the user session. 92 These attributes are also used for reporting the allocated 93 bandwidth in accounting records. The attributes are described for 94 RADIUS [1], but works as is also in Diameter [RFC 3588], and 95 through the translation rules defined in [Diameter NASREQ]. 97 1.2 Requirements language 99 In this document, several words are used to signify the 100 requirements of the specification. These words are often 101 capitalized. The key words "MUST", "MUST NOT", "REQUIRED", 102 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 103 "MAY", and "OPTIONAL" in this document are to be interpreted as 104 described in [RFC2119]. 106 2. Overview 108 This section describes the bandwidth parameters and the protocol 109 by which these parameters can be exchanged between a NAS and the 110 AAA server to help the access network determine the bandwidth 111 parameters that should be allocated for the userÆs connection by 112 the access. 114 2.1 Bandwidth Parameters 116 Bandwidth Profile parameters consists of four parameters: minimum 117 bandwidth, and maximum bandwidth specified both for ingress and 118 egress. The following subsections describe these parameters. 120 2.1.1 Minimum Bandwidth for ingress and egress 122 It indicates the minimum peak ingress/egress data rate that the 123 authorized user should get within the access network. This 124 value is a target, rather than a guarantee. 126 2.1.2 Maximum Bandwidth for ingress and egress 128 It indicates the average maximum ingress/egress data rate that 129 an access network can allow to an authorized user. 131 2.2 Protocol 133 Two protocols are described. One protocol is used to allocate 134 bandwidth when a service is initiated (referred to as Static 135 Bandwidth Allocation); the other protocol describes how to change 136 bandwidth attribute dynamically that is, mid-session (also 137 referred to as Dynamic Bandwidth Allocation). 139 Both protocols exchange bandwidth parameters using the various 140 AAA messages, and they are comprised of three phases: bandwidth 141 Advertisement, Selection, and Confirmation. 143 Bandwidth Advertisement: 145 MAY be sent in Access-Request packet in RADIUS, and the AAR 146 and DER commands in Diameter [Diameter NASREQ, Diameter EAP], 147 from the NAS to the home AAA server. The attributes convey 148 possible/available bandwidth parameters that can be allocated 149 for the access network client connection to the AAA server by 150 the NAS. 152 Bandwidth Selection: 154 MAY be sent in Access-Accept packet and Change of 155 Authorization (COA) messages in RADIUS. MAY also be sent in 156 RAR command in Diameter [4]. Selection conveys the desired 157 bandwidth parameters for an access network client connection 158 to the NAS by the home AAA server. 160 Bandwidth Confirmation: 162 If Bandwidth Selection is received and enforced, the 163 attributes MUST be sent in Accounting-Request packets in 164 RADIUS and in ACR command in Diameter. Confirmation indicates 165 that the desired bandwidth parameters specified by a home 166 network are being enforced by the access network. 168 The Bandwidth Attributes, defined in section 3, are used to carry 169 the Bandwidth Advertisement, Selection, Confirmation in various 170 RADIUS packets and Diameter commands. 172 An Advertisement, Selection, Confirmation is said to be valid if 173 it contains the four aforementioned bandwidth parameters. For a 174 valid Advertisement, Selection or Confirmation, the minimum 175 bandwidth rate values for ingress and egress traffic MUST be 176 equal or less than their corresponding maximum bandwidth rate 177 values. 179 If a Selection is sent in response to an Advertisement, for the 180 Selection to be considered valid, the bandwidth parameters in the 181 Selection MUST NOT exceed the corresponding bandwidth parameters 182 in the Advertisement. A bandwidth rate value of zero in 183 Selection should be interpreted as a ödonÆt careö value. 185 The following subsections describe static and dynamic bandwidth 186 allocation. 188 2.2.1 Static Bandwidth Allocation 190 Static bandwidth allocation is performed during the initial 191 session authentication / authorization. 193 The following diagram shows the protocol interaction between 194 the NAS and the home RADIUS server for determining network 195 bandwidth rates that an access network needs to allocate for a 196 client connection within the access network. 198 Client NAS home RADIUS server 200 | | | 201 | | | 202 | Authentication | | 203 | Phase Begin | | 204 |----------------->| Access-Request | 205 | | + | 206 | | BA for Advertisement | 207 | |----------------------------->| 208 | | | 209 |<> | 210 | | | 211 | | | 212 | |<-----------------------------| 213 | | Access-Accept | 214 | Authentication | + | 215 | Accept | BA for Selection | 216 |<-----------------| | 217 | | | 218 | | | 219 | | Accounting Request | 220 | | + | 221 | | BA for Confirmation | 222 | |----------------------------->| 223 | | | 225 The NAS MAY send an Advertisement in an Access-Request message. 226 If the home RADIUS server receives an invalid Advertisement, 227 then the RADIUS server MUST silently discard the Access- 228 Request. 230 A home RADIUS server MAY send the Selection after receiving a 231 valid Advertisement. It MAY also send the Selection in the 232 absence of an Advertisement, based on local policies such as 233 the clientÆs subscription profile. When the NAS receives an 234 invalid Selection, it MUST treat the Access-Accept message as 235 an Access Reject. 237 If the NAS receives a valid Selection in response to an Access- 238 Request that did not contain an Advertisement, then the NAS MAY 239 honor the Selection. 241 If the NAS receives a valid Selection in response to an Access- 242 Request that contained a valid Advertisement, then the NAS MUST 243 honor the Selection. 245 In the absence of a Selection after sending a valid 246 Advertisement, in accordance with local policy, the access 247 network MAY enforce its default bandwidth rate values or it MAY 248 use öbest effortö bandwidth for that client connection. 250 2.2.2 Dynamic Bandwidth Allocation 252 Dynamic bandwidth allocation uses the Change of Authorization 253 (COA) RADIUS message as defined in [3], and the Diameter RAR 254 message as defined in [4]. These messages are referred to as 255 the re-authorization messages in this specification. 257 In accordance with [3] there are two methods for dynamically 258 changing authorization attributes of a session. These two 259 methods are described in this section. 261 At anytime during the session the home AAA server may send the 262 NAS a re-authorization message containing session 263 identification attributes (see [3] for the possible options). 264 The re-authorization message may include authorization 265 attributes in which case it is "pushing" the bandwidth 266 attributes to the NAS. Or, it may instruct the NAS to generate 267 an authorize-only AAA exchange to "pull" the bandwidth 268 attributes. In RADIUS this exchange is an Access-Request with 269 Service-Type set to "Authorize-Only". In Diameter it is the AAR 270 command with the Auth-Request-Type AVP set to AUTHORIZE_ONLY. 272 In either "push" or "pull" method, upon successful acceptance 273 of the new bandwidth parameters for the session, the NAS MUST 274 generate an Accouting-Stop record that contains the old 275 bandwidth attributes followed by an Accounting-Start message 276 that contains the new bandwidth attributes. 278 In order to allow for downstream correlation of the accounting 279 records, an NAS that supports dynamic bandwidth allocation MUST 280 include Acct-Multi-Session-Id when writing accounting records. 282 2.2.2.1 Push Method 283 In the Push Method, to effect a dynamic bandwidth change the 284 home RADIUS server sends a re-authorization message and 285 includes a valid Selection. The RADIUS server MAY also 286 include other attributes in the re-authorization message. 288 NAS Home RADIUS Server 289 | | 290 | | 291 |re-authorization + BAs for Selection | 292 |<---------------------------------------------| 293 | | 294 | | 295 | re-authorization ACK | 296 |--------------------------------------------->| 297 | | 298 | | 299 | Accounting-Stop + old BAs for Confirmation | 300 |--------------------------------------------->| 301 | | 302 | Accounting-Start + new bandwidth | 303 |--------------------------------------------->| 304 | | 305 | | 307 Upon the successful reception of the re-authorization message 308 (see [3] for details) by the NAS, if the re-authorization 309 message contains an invalid Selection, the NAS MUST respond 310 with a re-authorization NAK with Error Cause (101) set to 311 öInvalid Requestö (404). 313 If the NAS is able to offer the requested bandwidth to the 314 specified session, the NAS MUST reply with a re-authorization 315 ACK and it MUST generate an Accounting-Stop record containing 316 the old bandwidth attributes followed by an Accounting-Start 317 record containing the new bandwidth attributes. If the NAS 318 can not comply with the request for new bandwidth it MUST 319 reply with re-authorization NAK with Error Cause (101) set to 320 "Resources Unavailable"(506). 322 If the NAS receives a re-authorization message that does not 323 include Bandwidth attributes then the NAS must not alter the 324 bandwidth already allocated to the session. 326 2.2.2.2 Pull Method 328 Alternatively, in the pull method, to effect a dynamic 329 bandwidth change, as per [3], the home network sends a re- 330 authorization message to instruct the AN to generate an 331 Authorize-Only request (Access-Request with Service-Type set 332 to Authorize-Only). 334 NAS Home RADIUS server 335 | | 336 | re-authorization + Service-Type = öAuthorize Onlyö | 337 |<-----------------------------------------------------| 338 | | 339 |re-authorization NAK + Service-Type = öAuthorize Onlyö| 340 | + Error-Cause "Request Initiated" | 341 |----------------------------------------------------->| 342 | | 343 | Access-Request + Service-Type öAuthorize Onlyö | 344 | + BAs for Advertisement | 345 |----------------------------------------------------->| 346 | | 347 | Access-Accept + BAs for Selection | 348 |<-----------------------------------------------------| 349 | | 350 | Accounting-Stop + old BAs for Confirmation | 351 |----------------------------------------------------->| 352 | | 353 | Accounting-Start + new BAs for Confirmation | 354 |----------------------------------------------------->| 355 | | 356 | | 358 As with the static bandwidth allocation (described earlier), 359 the AN MAY Advertise the currently available bandwidth in the 360 Authorize-Only message. 362 Upon receiving the Authorize-Only message from the AN, the 363 RADIUS server MUST respond with either an Access-Accept 364 message or an Access-Reject message. 366 When responding with an Access-Accept message, the RADIUS 367 server MAY include the BAs for Selection. If the Authorize- 368 Only message included an Advertisement, the bandwidth 369 parameters in Selection MUST be within the bounds of 370 bandwidth parameters in the Advertisement received in the 371 Authorize-Only message. 373 Upon receiving an Access-Reject in response to the Authorize- 374 Only, the AN will terminate the session and send an 375 Accounting-Stop record. 377 Upon receiving an Access-Accept in response to an Authorize- 378 Only request that does not contain bandwidth Selection, the 379 access network MUST allocate its default bandwidth rate 380 values, and then the NAS MUST generate an Accouting-Stop 381 record that contains the old bandwidth attributes followed by 382 an Accounting-Start message that contains the new bandwidth 383 attributes. 385 Upon receiving an Access-Accept packet that contains an 386 invalid Bandwidth Selection, the AN MUST treat the response 387 as an Access-Reject and immediately terminate the session. 389 Upon receiving an Access-Accept message in response to an 390 Authorize-Only message that contained the Bandwidth 391 Advertisement, then providing the bandwidth selections are 392 within the bounds of the Advertisement, then AN MUST honor 393 the requested bandwidth and generate an Accounting-Stop 394 message that contains the old bandwidth attributes followed 395 by an Account-Start message that contains the new bandwidth 396 attributes. If the bandwidth Selection were outside the 397 bounds of the Advertisement, then the AN MUST treat the 398 Access-Accept as an Access-Reject and immediately terminate 399 the session. 401 Upon receiving an Access-Accept message that contains a valid 402 Selection in response to an Authorize-Only that did not 403 contain the Advertisement, the AN MAY honor the Selection or 404 it MAY continue to honor the previously agreed to bandwidth. 405 In the former case, the AN must generate an Accounting Stop 406 message containing the old bandwidth attributes followed by 407 an Accounting-Start message containing the current bandwidth 408 attributes. 410 2.3 Diameter RADIUS Interoperability 412 In deployments where both RADIUS clients talking with Diameter 413 Servers or Diameter Client talking with RADIUS server then a 414 translation agent will be deployed and operate in accordance to 415 the NASREQ specification. 417 3. Attribute Format/Syntax 419 This section describes format and syntax for the attributes that 420 carry the network bandwidth parameters. The attributes are used 421 for bandwidth parameters Advertisement, Selection, and 422 Confirmation. 424 A summary of the AN Bandwidth Parameter Attributes is shown below. 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type | Length | Value | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Value | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Type 435 TBD - Ingress Average Minimum Bandwidth Rate 437 Length 439 6 441 Value 443 An integer value representing the ingress average minimum 444 bandwidth rate in bytes per second. 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Type | Length | Value | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Value | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Type 455 TBD - Ingress Average Maximum Bandwidth Rate 457 Length 459 6 461 Value 463 An integer value representing the egress average minimum 464 bandwidth rate in bytes per second 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Type | Length | Value | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Value | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Type 475 TBD Egress Average Minimum Bandwidth Rate 477 Length 479 6 481 Value 483 An integer value representing the ingress average maximum 484 bandwidth rate in bytes per second 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Type | Length | Value | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Value | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Type 495 TBD Egress Average Maximum Bandwidth Rate 497 Length 499 6 501 Value 503 An integer value representing the egress average maximum 504 bandwidth Rate in bytes per second 506 4. Table of Attribute(s) 507 The following table provides a guide to which attribute(s) may be 508 found in which kinds of packets, and in what quantity. 510 Request Accept Reject Challenge Accounting # Attribute 511 Request 512 0-1 0-1 0 0 0-1 TBD Ingress Minimum Band. 514 0-1 0-1 0 0 0-1 TBD Ingress Maximum Band. 516 0-1 0-1 0 0 0-1 TBD Egress Minimum Band. 518 0-1 0-1 0 0 0-1 TBD Egress Minimum Band. 520 For Change-of-Authorization Messages 522 Request ACK NAK # Attribute 524 0-1 0 0 TBD Ingress Minimum Bandwidth 525 0-1 0 0 TBD Ingress Maximum Bandwidth 526 0-1 0 0 TBD Egress Minimum Bandwidth 527 0-1 0 0 TBD Egress Maximum Bandwidth 529 Note 1 : if the Change-of-Authorization message contains any 530 bandwidth attributes then all the bandwidth attributes received for 531 this session are overwritten. If the Change-of-Authorization 532 message does not contain any bandwidth attributes then, the 533 previously received bandwidth attributes remain in effect. 535 Note 2: if one of the attribute is included in a qualified RADIUS 536 packet, then all the three attributes MUST be included. 538 5. IANA Considerations 540 This document requires the assignment of four new RADIUS attribute 541 numbers for the following attribute(s): 543 1) Ingress Average Minimum Bandwidth Rate 544 2) Ingress Average Maximum Bandwidth Rate 545 3) Egress Average Minimum Bandwidth Rate 546 4) Egress Average Maximum Bandwidth Rate 548 Please See section 3 for the registered list of numbers. 550 6. Security Considerations 551 The attributes in this document have no additional security 552 considerations beyond those already identified in [1]. 554 7. Acknowledgements 556 The authors would specially like to thank Jari Arkko (of Ericsson) 557 for his through review of the draft, providing feedback/comments 558 and proposing text. 560 The authors would like to thank Bernard Aboba (of Microsoft), 561 Parviz Yegani (of Cisco), Stefan De_cnodder (of alcatel) for their 562 feedback and guidance. 564 8. References 566 [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 567 Authentication Dial In User Server (RADIUS)", RFC 2865, June 568 2000. 570 [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 572 [3] Chiba, M., Dommety, G., Eklud, M., Mitton, D., Aboba, B., 573 öDynamic Authorization Extensions to Remote Authentication 574 Dial In User Service (RADIUS)ö, RFC 3576, July 2003. 576 [4] Calhoun, et al., ö Diameter Base Protocolö, RFC 3588, 577 September 2003. 579 AuthorsÆ Addresses 581 Farid Adrangi 582 Intel Corporation 583 2111 N.E. 25th Avenue 584 Hillsboro OR 585 USA 587 Chuck Black 588 ProCurve Networking Business 589 Hewlett-Packard Company 590 8000 Foothills Blvd 591 Roseville, CA 95747 593 Phone: +1 916 785 9713 594 Fax: +1 916 785 1199 595 Email: chuck.black@hp.com 597 Paul Congdon 598 ProCurve Networking Business 599 Hewlett-Packard Company 600 8000 Foothills Blvd - MS 5662 601 Roseville, CA 95747 603 Phone: +1 916 785 5753 604 Fax: +1 916 785 8478 605 Email: paul.congdon@hp.com 607 Avi Lior 608 Bridgewater Systems Corporation 609 303 Terry Fox Drive 610 Suite 100 611 Ottawa, Ontario K2K 3J1 612 Canada 614 Farooq Bari 615 AT&T Wireless 616 7277 164th Avenue N.E. 617 Redmond WA 618 USA 620 Phone: +1 425-580-5526 621 EMail: farooq.bari@attws.com 623 Full Copyright Statement 625 Copyright (C) The Internet Society (2002). All Rights 626 Reserved. 628 This document and translations of it may be copied and 629 furnished to others, and derivative works that comment on or 630 otherwise explain it or assist in its implementation may be 631 prepared, copied, published and distributed, in whole or in 632 part, without restriction of any kind, provided that the above 633 copyright notice and this paragraph are included on all such 634 copies and derivative works. However, this document itself may 635 not be modified in any way, such as by removing the copyright 636 notice or references to the Internet Society or other Internet 637 organizations, except as needed for the purpose of developing 638 Internet standards in which case the procedures for copyrights 639 defined in the Internet Standards process must be followed, or 640 as required to translate it into languages other than English. 642 The limited permissions granted above are perpetual and will 643 not be revoked by the Internet Society or its successors or 644 assigns. 646 This document and the information contained herein is provided 647 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 648 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 649 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 650 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 651 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 652 PARTICULAR PURPOSE. 654 Acknowledgement 656 Funding for the RFC Editor function is currently provided by 657 the Internet Society.