Internet DRAFT - draft-lior-radius-bandwidth-capability

draft-lior-radius-bandwidth-capability







Network Working Group                                            A. Lior
Internet-Draft                                       Bridgewater Systems
Expires: January 18, 2006                                     F. Adrangi
                                                                   Intel
                                                              P. Congdon
                                                                C. Black
                                            ProCurve Networking Business
                                                                 F. Bari
                                                                    AT&T
                                                           July 17, 2005


  Network Bandwidth Parameters for Remote Authentication Dial In User
                           Service (RADIUS).
               draft-lior-radius-bandwidth-capability-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes bandwidth profile parameters and a protocol



Lior, et al.            Expires January 18, 2006                [Page 1]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


   framework that enables an AAA server to specify the parameters that
   should be allocated by the access network for duration of an
   authorized user session.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Requirements language  . . . . . . . . . . . . . . . . . .  4
   2.  Attributes . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Ingress Bandwidth  . . . . . . . . . . . . . . . . . . . .  4
     2.2   Egress Bandwidth . . . . . . . . . . . . . . . . . . . . .  5
     2.3   Bandwidth Profile Id . . . . . . . . . . . . . . . . . . .  6
   3.  Table of Attributes  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Diameter RADIUS Interoperability . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1   Normative references . . . . . . . . . . . . . . . . . . . 10
     8.2   Informative references . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
   A.  Issue Resolution . . . . . . . . . . . . . . . . . . . . . . . 12
   B.  Example: Static Bandwidth Allocation . . . . . . . . . . . . . 12
   C.  Example: Mid-Session Bandwidth Allocation  . . . . . . . . . . 14
     C.1   Push Method  . . . . . . . . . . . . . . . . . . . . . . . 15
     C.2   Pull Method  . . . . . . . . . . . . . . . . . . . . . . . 16
       Intellectual Property and Copyright Statements . . . . . . . . 18
























Lior, et al.            Expires January 18, 2006                [Page 2]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


1.  Introduction

   The bandwidth that a user is authorized within an access network can
   be a result of the access network capabilities based on its
   architecture and access technology, and the type of user subscription
   to the home network (e.g., gold, silver, bronze user types).

   This document describes a simple protocol framework that enables an
   access network to advertise the network bandwidth capabilities that
   it can allocate for a given user session in the Access Network.  And,
   it enables the Home Network to indicate the desired bandwidth to be
   allocated for the user session within the access network.


    +--------+                   +------+                     +--------+
    |        | Data Ingress flow |      | Bandwidth Attributes| Home   |
    |  User  |   <-----------    |      +<------------------->+ AAA    |
    | Device +<----------------->+  NAS |      AAA Protocol   | Server |
    |        |   ----------->    |      +<------+             +--------+
    |        |   Egress flow     |      | Data  |
    +--------+                   +------+       V
                                               ---
                                            --     ---
                                        ---  Internet--
                                          --       -
                                           --     ---
                                             ----


   Session bandwidth can be allocated during initial authentication
   authorization of the session.  It is also desirable to change the
   bandwidth mid-session.  For example, the user may want to purchase
   additional bandwidth to download a large file.  This document enables
   operators to modify the bandwidth allocation for a user during mid-
   session.

   In certain conditions bandwidth can be allocated to a user session by
   assigning a preconfigured bandwidth profile to the user session.  In
   this case, the home network and the access network could pre-arrange
   bandwidth profiles such as "gold", "silver", and "bronze" in the NAS.
   The AAA servers, would then communicate which bandwidth profile to
   apply to the user.  The advantage of this scheme is that it allows
   for complex bandwidth profiles to be provisioned for the user
   session.  A single bandwidth profile could be provisioned to handle
   different bandwidth treatments for different flows.  Such as
   bandwidth for best effort traffic and bandwidth for VoIP traffic.
   The disadvantage of communicating just a bandwidth profile id to the
   NAS is in roaming situations where this does not scale well.



Lior, et al.            Expires January 18, 2006                [Page 3]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


   To address these needs, this document defines new AAA attributes that
   can be used for the following:
   o  Conveying to the home network the available bandwidth at the
      access network that may be allocate to a given user session.
   o  Conveying the access network the desired bandwidth that should be
      allocated by the access network for the duration of the user
      session.

   These attributes are also used for reporting the allocated bandwidth
   in RADIUS accounting packets [RFC2866].  The attributes are described
   for the RADIUS protocol[RFC2865] , but will work as is in Diameter
   [RFC3588] , and through the translation rules defined in [Diameter
   NASREQ].

1.1  Requirements language

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

2.  Attributes

   The following subsections describe the format and syntax of the
   Bandwidth parameters.

2.1  Ingress Bandwidth

   Ingress Bandwidth attribute is available for use in Access-Request,
   Accept-Accept, COA and Accounting packets.

   If used in an Access-Request packet the Ingress Bandwidth attribute
   is a hint indicating the data rate that the NAS has available to
   allocate for traffic flowing to the user's device for that session.
   NASs that support only symmetric bandwidth allocation MUST only
   include Ingress Bandwidth attribute which is a hint to the available
   bandwidth in both ingress and egress direction.

   If used in an Access-Accept packet the Ingress Bandwidth attribute
   indicates the desired data rate for traffic flowing to the user's
   device for the session.  The value expressed SHOULD NOT exceed the
   value specified by the Ingress Bandwidth attribute in the Access-
   Request packet (if any).  If the value specified in Access-Accept is
   less then the value specified in an Access-Request then the NAS
   SHOULD allocate the ingress bandwidth specified in the Access-Accept
   for that user session.  If the value requested in the Access-Accept
   is greater then the value indicated in the Access-Request then the



Lior, et al.            Expires January 18, 2006                [Page 4]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


   NAS MAY allocate bandwidth up to the bandwidth requested in the
   Access-Accept.  A value of '0' for this attribute in an Access-Accept
   implies I don't care.

   If the NAS is receives an Ingress Bandwidth attribute that it
   understands, the NAS MUST include the Ingress Bandwidth attribute in
   the Accounting packets to indicate the actual bandwidth allocated by
   the NAS for traffic flowing to the user's device.  In the case where
   the NAS is only capable of symmetric bandwidth allocation, the
   Ingress Bandwidth SHALL indicate the bandwidth allocated in both
   direction.



       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |     Value                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Value             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type

              TBD - Ingress-Bandwidth

      Length  6

      Value
              An Integer value representing the ingress bandwidth
              (traffic to the user device) rate in Kilo-bits per second.



2.2  Egress Bandwidth

   Egress Bandwidth attribute is available for use in Access-Request,
   Accept-Accept, COA and Accounting packets.

   If used in an Access-Request packet the Egress Bandwidth attribute is
   a hint indicating the data rate that the NAS has available to
   allocate for traffic flowing from the user's device for that session.

   If used in an Access-Accept packet the Egress Bandwidth attribute
   indicates the desired data rate for traffic flowing from the user's
   device for the session.  The value expressed SHOULD NOT exceed the
   value specified by the Egress Bandwidth attribute in the Access-
   Request packet (if any).  If the value specified in Access-Accept is



Lior, et al.            Expires January 18, 2006                [Page 5]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


   less then the value specified in an Access-Request then the NAS
   SHOULD allocate the egress bandwidth specified in the Access-Accept
   for that user session.  If the value requested in the Access-Accept
   is greater then the value indicated in the Access-Request then the
   NAS MAY allocate bandwidth up to the bandwidth requested in the
   Access-Accept.  A value of '0' for this attribute in an Access-Accept
   implies I don't care.

   If the NAS is allocating bandwidth then the NAS MUST include the
   Egress Bandwidth attribute in the Accounting packets to indicates the
   actual bandwidth allocated by the NAS for traffic flowing from the
   user's device.  If the NAS is only capable of symmetric bandwidth
   allocation the NAS MUST NOT include the Egress Bandwidth attribute in
   the Accounting packets.



       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |     Value                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Value             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type

              TBD - Egress-Bandwidth

      Length  6

      Value
              An Integer value representing the egress bandwidth
              (traffic from the user device) in Kilo-bits per second




2.3  Bandwidth Profile Id

   The Bandwidth Profile Id attribute is available in an Access-Accept,
   COA and Accounting Packets and indicates which bandwidth profile to
   assign to the user session.  Use of this attribute requires apriori
   configuration of the NAS and therefore does not scale well in large
   roaming scenarios.






Lior, et al.            Expires January 18, 2006                [Page 6]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |     Text .......
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Type

          TBD Bandwidth-Profile-Id


      Length   >= 3


      Text

         The Text field is one or more octets, and its contents are
         implementation dependent.  It is intended to be human readable and
         MUST NOT affect operation of the protocol.  It is recommended that
         the message contain UTF-8 encoded 10646 [7] characters.




3.  Table of Attributes

   The following table provides a guide to which attribute(s) may be
   found in which kinds of packets, and in what quantity.


   Request Accept Reject Challenge Accounting  #  Attribute
                                   Request
   0-1      0-1   0      0         0-1      TBD Ingress-Bandwidth [Note 1,3]

   0-1      0-1   0      0         0-1      TBD Egress-Bandwidth [Note 1,3,5]

   0        0-1   0      0         0-1      TBD Bandwidth-Profile-Id [Note 2]

   1        0     0      0         0         80 Message-Authenticator [Note 4]


   Note 1 :  If Ingress-Bandwidth appears alone in an Access-Request
      packet then the NAS is indicating that it only supports symmetric
      bandwidth allocation.  Therefore, Egress bandwidth SHOULD NOT
      appear in the corresponding Access-Accept packet.





Lior, et al.            Expires January 18, 2006                [Page 7]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


   Note 2 :  Bandwidth-Profile-Id MUST NOT appear in a RADIUS packet
      that contains either or both of Ingress-Bandwidth or Egress-
      Bandwidth attributes.
   Note 3 : If the NAS only supports symmetric bandwidth allocation then
      it signals its support for symmetric bandwidth allocation by not
      sending the Egress-Bandwidth attribute in an Access-Request.  The
      NAS SHALL ignore any Egress-Bandwidth attribute received in the
      Access-Accept.  If the NAS only sends the Ingress-Bandwidth
      attribute in an Access-Request then the RADIUS server SHOULD NOT
      send the Egress-Bandwidth attribute in an Access-Accept.
   Note 4 : An Access-Request message that contains Ingress-Bandwidth
      attribute and/or Egress-Bandwidth attribute MUST be integrity
      protected by including the Message-Authenticator (80) attribute.
      RADIUS clients and servers MUST compute and validate the Message-
      Authenticator as described in [RFC2869].
   Note 5 : A RADIUS server that receives an Access-Request packet
      containing only an Egress Bandwidth attribute and a Message-
      Authenticator (80) SHOULD ignore the Egress Bandwidth Attribute.

   For Change-of-Authorization packets


      Request  ACK    NAK      #   Attribute

       0-1      0      0      TBD      Ingress-Bandwidth [Note 1,3]
       0-1      0      0      TBD      Egress-Bandwidth [Note 1,3]
       0-1      0      0      TBD      Bandwidth-Profile-Id [Note 2]


   Note 1 :  If the COA packet contains any bandwidth attributes then
      all the bandwidth attributes received for this session are
      overwritten.  If the COA packet does not contain any bandwidth
      attributes then, the previously received bandwidth attributes
      remain in effect.
   Note 2 :  Bandwidth-Profile-Id MUST NOT appear in a COA packet that
      contains either or both of Ingress-Bandwidth or Egress-Bandwidth
      attributes.
   Note 3 : If the NAS only supports symmetric bandwidth allocation then
      it signals its support for symmetric bandwidth allocation by not
      sending the Egress-Bandwidth attribute in an Access-Request.  In
      this case the NAS SHALL ignore Egress-Bandwidth attribute received
      in the COA.  If the NAS only sends the Ingress-Bandwidth attribute
      in an Access-Request then the RADIUS server SHOULD NOT send the
      Egress-Bandwidth attribute in a COA packet.

4.  Diameter RADIUS Interoperability

   The attributes specified in this document may be used in Diameter



Lior, et al.            Expires January 18, 2006                [Page 8]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


   NASREQ application.

   In DIAMETER the Ingress and Egress Bandwidth Attribute are of type
   Unsigned32 Integer (which corresponds to RADIUS Integer type).  The
   Bandwidth Profile Id attribute is defined as UTF8String (which
   corresponds to a RADIUS Text type).

   RADIUS Access-Request packets corresponds to AA-Request messages in
   Diameter applications based on NASREQ .  RADIUS Access-Accept packet
   correspond to AA-Answer messages in Diameter applications based on
   NASREQ.  RADIUS accounting packets correspond to Diameter Accounting-
   Request ACR messages as defined by [RFC3588].  The RADIUS rules
   defined for these attributes in RADIUS packets SHALL also apply to
   their inclusion in the aforementioned Diameter messages.

   Diameter applications based on NASREQ do not support COA "PUSH"
   method of changing bandwidth dynamically (see the appendix at the end
   of this document).  If a RADIUS to Diameter translating agent
   receives a COA message containing an Ingress Bandwidth attribute,
   and/or Egress Bandwidth attribute or a Bandwidth Profile Attribute
   then the RADIUS to Diameter translating agent SHALL engage the
   Diameter server by sending a Diameter Re-Auth-Request RAR as defined
   by [RFC3588] which forces a Diameter Re-authentication.

5.  IANA Considerations

   This document requires the assignment of four new RADIUS attribute
   numbers for the following attribute(s):
   1.  Ingress-Bandwidth
   2.  Egress-Bandwidth
   3.  Bandwidth-Profile-Id

   Please See section 3 for the registered list of numbers.

6.  Security Considerations

   The protocol extension to RADIUS described herein is susceptible to
   all the security threats described for RADIUS in [RFC2865],
   [RFC2866], [RFC2869] and [RFC3576].  Mitigation of these security
   threats are provided in those document.

   However, specific to this document, since RADIUS Access-Request
   messages are not integrity protected, it would be possible for a Man-
   In-The-Middle to modify Access-Requests packets and reduce the
   advertized bandwidth by the NAS for the Access-Network.  This would
   result in user getting lower bandwidth response.  To mitigate this
   atack, in this document we mandate the use of the RADIUS Message-
   Authenticator (80) attribute which provides for integrity protection.



Lior, et al.            Expires January 18, 2006                [Page 9]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


   Message-Authenticator is widely supported due to its required use
   when transporting EAP payloads in RADIUS messages.

7.  Acknowledgements

   The authors would specially like to thank Jari Arkko (of Ericsson)
   for his through review of the draft, providing feedback/comments and
   proposing text.

   The authors would like to thank Bernard Aboba (of Microsoft), Parviz
   Yegani (of Cisco), Stefan De_cnodder (of alcatel) for their feedback
   and guidance.

8.  References

8.1  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC2869]  Rigney, C., Willats, W., and P. Calhoun, "RADIUS
              Extensions", RFC 2869, June 2000.

   [RFC3576]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 3576,
              July 2003.

8.2  Informative references

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.













Lior, et al.            Expires January 18, 2006               [Page 10]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


Authors' Addresses

   Avi Lior
   Bridgewater Systems Corporation
   303 Terry Fox Drive
   Ottawa, Ontario  K2K 3J1
   Canada

   Phone: +1 613-591-6655
   Email: avi@bridgewatersystems.com


   Farid Adrangi
   Intel Corporation
   2111 N.E. 25th Avenue
   Hillsboro, OR  97124
   USA

   Phone: +1 503-712-1791
   Email: farid.adrangi@intel.com


   Paul Congdon
   ProCurve Networking Business
   8000 Foothills Blvd
   Roseville, CA  95747
   USA

   Phone: +1 916 785 5753
   Email: paul.congdon@hp.com


   Chuck Black
   ProCurve Networking Business
   8000 Foothills Blvd
   Roseville, CA  95747
   USA

   Phone: +1 916 785 9713
   Email: chuck.black@hp.com











Lior, et al.            Expires January 18, 2006               [Page 11]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


   Farooq Bari
   AT&T Wireless
   7277 164th Avenue N.E.
   Redmond, WA
   USA

   Phone: +1 425-580-5526
   Email: farooq.bari@attws.com

Appendix A.  Issue Resolution

   The following have been addressed by this version of the document:
      Attribute Scale: Use of Integer and units of Kilobits gives us
      2**35 bits per second.  As per Bernard, today we are at 10 Gbps
      (or 2*30).  At an increase of one order of magnitude every 3 years
      will gives us headroom for the next 15 years or so.  Bernard
      suggested to use a 64-bit attribute.  We think that this is
      wasteful now.  As well, RADIUS only supports Integer type.  We
      could gain 2-3 years by using Kilo Octets instead of Kilobits.
      Re-organized the contents.  Moved text into the attribute section
      and added text into an appendix.  The text in the appendix is
      INFORMATIVE.
      Strengthened the Diameter Section
      Removed new Acct-Terminate-Cause value introduced in the last
      version.  This are nice to have but if we add them it should be
      added to the 3576bis version (if ever).

Appendix B.  Example: Static Bandwidth Allocation

   Static bandwidth allocation is performed during the initial session
   authentication / authorization.

   The following diagram shows the protocol interaction between the NAS
   and the home RADIUS server for determining network bandwidth rates
   that an access network needs to allocate for a user session within
   the access network.















Lior, et al.            Expires January 18, 2006               [Page 12]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


          Client              NAS                  home RADIUS server

            |                  |                              |
            |                  |                              |
            | Authentication   |                              |
            | Phase Begin      |                              |
            |----------------->|        Access-Request        |
            |                  |            +                 |
            |                  |    BA for Advertisement      |
            |                  |----------------------------->|
            |                  |                              |
            |<<More Authentication/Authorization Exchanges>>  |
            |                  |                              |
            |                  |                              |
            |                  |<-----------------------------|
            |                  |        Access-Accept         |
            | Authentication   |            +                 |
            |    Accept        |      BA for Selection        |
            |<-----------------|                              |
            |                  |                              |
            |                  |                              |
            |                  |       Accounting Request     |
            |                  |             +                |
            |                  |     BA for Confirmation      |
            |                  |----------------------------->|
            |                  |                              |


   The NAS sends "advertizement" in an Access-Request packet.  The
   "advertizement" contains either both Egress and Ingress bandwidth
   attributes or just Ingress attribute indicating that the NAS supports
   symmetric bandwidth only.

   A home RADIUS server could request bandwidth for the session
   regardless of whether it has recieved "advertizement" from the NAS.
   The home RADIUS server SHOULD select bandwidth that is commensurate
   with what was advertized by the NAS.  If the AAA is to respond with a
   Bandwidth Profile Id it SHOULD select the appropriate bandwidth
   profile id as determined by policy, and what is provisioned for the
   user profile.  The policy may or may not take into consideration the
   "advertizement" bandwidth.

   If the NAS receives a bandwidth attributes in an Access-Accept that
   is in response to an Access-Request that did not contain an
   "advertizement", then the NAS could allocate bandwidth up to the
   requested values.

   If the NAS receives a bandwidth attributes in an Access-Accept in



Lior, et al.            Expires January 18, 2006               [Page 13]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


   response to an Access-Request that contained a "advertizement", then
   the NAS SHOULD honor the requested bandwidth.  If it is unable to
   provide the requested bandwidth then it should attempt to provide as
   much bandwidth as possible without excceeding the amound requested.

   In the case where the NAS advertized symmetric bandwidth and it
   received both an Egress and Ingress bandwidth parameters, the NAS
   SHOULD ignore the Egress parameter and allocate symmetric bandwidth
   that matches the received Ingress attribute.

   In the case where the NAS receives a bandwidth profile id, it should
   honor that request or utilize a different profile id as determined by
   the pre-provisioned policies between the two administrative domains.
   Otherwise if the NAS doesnt recognize the profile id, then it could
   treat the Access-Accept as an Access-Reject.

   In the absence of a Selection after sending a valid Advertisement, in
   accordance with local policy, the access network could enforce its
   default bandwidth rate values for that user session.

   During accounting phase, if the NAS received a bandwidth selection,
   then the NAS will report what was provisioned for the user session.
   If the NAS did not receive a bandwidth selection then the NAS SHOULD
   report what bandwidth treatement was provided for the user session.

Appendix C.  Example: Mid-Session Bandwidth Allocation

   Mid-session bandwidth allocation uses the Change of Authorization
   (COA) RADIUS packet as defined in [RFC3576], and the Diameter RAR
   message as defined in [RFC3588].  These packets/messages are referred
   to as the re-authorization messages in this specification.

   In accordance with [RFC3576] there are two methods for changing
   authorization attributes of mid-session.  These two methods are
   described in this section.

   At anytime during the session the home AAA server may send the NAS a
   re-authorization message containing session identification attributes
   (see [RFC3576] for the possible options).  The re-authorization
   message may include authorization attributes in which case it is
   "pushing" the bandwidth attributes to the NAS.  Or, it may instruct
   the NAS to generate an "authorize-only" AAA exchange to "pull" the
   bandwidth attributes.  In RADIUS this exchange is an Access-Request
   with Service-Type set to "Authorize-Only".  In Diameter it is the AAR
   command with the Auth-Request-Type AVP set to "AUTHORIZE_ONLY".

   In either "push" or "pull" method, upon successful acceptance of the
   new bandwidth parameters for the session, the NAS MUST indicate the



Lior, et al.            Expires January 18, 2006               [Page 14]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


   change in bandwidth in the Accounting stream (if accounting is
   available) by using one of two methods:

      The NAS SHOULD indicate the change of bandwidth by issuing a
      RADIUS Accounting-Request(Stop) packet that contains the old
      bandwidth attributes, followed by an RADIUS Accounting-
      Request(Start) packet that contains the new bandwidth attributes.
      In order to allow for correlation of these accounting packets, an
      NAS that supports mid-session bandwidth allocation SHOULD include
      Acct-Multi-Session-Id(51) when writing accounting packets.

      Alternatively, the NAS MAY indicate the change of bandwidth by
      issuing a RADIUS Accounting-Request (Interim) which will contain
      the new bandwidth attributes.

   [EDITORS NOTE: The last case was motivated because at least one
   company reported that their resource management software actually
   released resources when an accounting session stop was received.]

   [EDITORS NOTE: Here the NAS is choosing the method.  Perhaps the home
   network should be controlling how the change is to be reported.  In
   this case we need to introduce an attribute that is sent in the
   Access-Accepts that instructs the NAS how to respond.]

   [EDITORS NOTE: Also note that Accounting Interim may be turned off.
   So does this mean that accounting interim will be generated for this
   case only.]

   [EDITORS NOTE: Finally, does this interfere with the accounting
   interim time.]


C.1  Push Method

   In the Push Method, to effect a mid-session bandwidth change the home
   RADIUS server sends a re-authorization message and includes a valid
   Selection.  The RADIUS server MAY also include other attributes in
   the re-authorization message.













Lior, et al.            Expires January 18, 2006               [Page 15]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


             NAS                                     Home RADIUS Server
                 |                                              |
                 |                                              |
                 |re-authorization + BAs for Selection          |
                 |<---------------------------------------------|
                 |                                              |
                 |                                              |
                 |  re-authorization ACK                        |
                 |--------------------------------------------->|
                 |                                              |
                 |                                              |
                 | Accounting-Stop + old BAs for Confirmation   |
                 |--------------------------------------------->|
                 |                                              |
                 | Accounting-Start + new bandwidth             |
                 |--------------------------------------------->|
                 |                                              |
                 |                                              |


   Upon the reception of the re-authorization message (see [RFC3576] for
   details) by the NAS, if the re-authorization message contains an
   invalid combination of bandwidth attributes (for example only Egress
   Bandwidth attribute or Bandwidth Profile Id or one or both of the
   other Bandwidth attributes), the NAS will respond with a re-
   authorization NAK with Error Cause (101) set to "Invalid Request"
   (404).

   If the NAS is able to offer the requested bandwidth to the specified
   session, the NAS MUST reply with a re-authorization ACK and it will
   report the change in bandwidth in the accounting stream (if
   accounting is available) using one of the two mechanisms described
   above.

   If the NAS receives a re-authorization message that does not include
   Bandwidth attributes then as per [RFC3576] the NAS must not alter the
   bandwidth already allocated to the session.

C.2  Pull Method

   Alternatively, in the pull method, to effect a mid-session bandwidth
   change, as per [RFC3576], the home network sends a re-authorization
   message to instruct the AN to generate an Authorize-Only request
   (Access-Request with Service-Type set to Authorize-Only).







Lior, et al.            Expires January 18, 2006               [Page 16]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


          NAS                                             Home RADIUS server
           |                                                      |
           | re-authorization + Service-Type = Authorize Only     |
           |<-----------------------------------------------------|
           |                                                      |
           |re-authorization NAK + Service-Type = Authorize Only  |
           |          + Error-Cause  "Request Initiated"          |
           |----------------------------------------------------->|
           |                                                      |
           | Access-Request + Service-Type = Authorize Only       |
           |                + BAs for Advertisement               |
           |----------------------------------------------------->|
           |                                                      |
           | Access-Accept + BAs for Selection                    |
           |<-----------------------------------------------------|
           |                                                      |
           | Accounting-Stop + old BAs for Confirmation           |
           |----------------------------------------------------->|
           |                                                      |
           | Accounting-Start + new BAs for Confirmation          |
           |----------------------------------------------------->|
           |                                                      |
           |                                                      |


   Once the NAS issues the Access-Request with Authorize-Only then the
   procedure is identical to the static allocation method.  With the
   following exceptions:

   If accounting is used then the NAS will report the change of
   bandwidth in the accounting stream using one of the two methods
   indicated above.

   Note: If the Access-Accept packet does not contain any bandwidth
   attributes then the NAS must allocate the default bandwidth
   attributes to the session.  That is it would allocate the same
   bandwidth to the session that it would have if it did not receive any
   bandwidth attributes from the home network in the first place.













Lior, et al.            Expires January 18, 2006               [Page 17]

Internet-Draft     Network Bandwidth Param. for RADIUS         July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Lior, et al.            Expires January 18, 2006               [Page 18]