Abstract:
A method of accounting for policy decision in access requests is disclosed. The method includes receiving a pre-authentication request for a call and applying at least one policy to determine a policy decision for the request. At least one message is then transmitted to indicate a manner in which the call is resolved and the policy decision.

Description:
BACKGROUND 
     1. Field 
     This disclosure relates to policy systems, more particularly to policy systems using Remote Access Dial-In User Services (RADIUS). 
     2. Background 
     Policy systems are typically a server or servers deployed in conjunction with a wholesale network to monitor and control traffic on the network in accordance with various policies. Policies that may impact the traffic control include service level agreements between wholesalers and their customers, and port management policies. The policy system generally enforces policies to ensure that the network is operating within pre-defined limits. At the core of policy enforcement is the establishment, enforcement and reporting of policy that affects a particular call. 
     RADIUS provides a means to monitor and control services across the wholesale dial, Voice over Internet Protocol (VoIP), and Any Service Any Port (ASAP) networks. The parameters and protocols for RADIUS messaging is set forth in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2865. One aspect of RADIUS is a pre-authentication request and response that allows the network to accept or reject messages prior to commitment of resources, such as by reservation. This increases network efficiency, as the resources are not committed while waiting for a policy system to accept or reject a call. 
     A problem that arises is when a pre-authentication request is rejected. This is generally accomplished in RADIUS using an “Access Reject” message. Under the terms of the IEFT&#39;s RFC 2865, the Access Reject message only needs to contain a text message that gives some indication of the reason for call rejection. This message is not well defined and may only be sent to the remote client that had the call rejected. This is not helpful for a policy system that has policy processors, gateways and accounting systems on separate hosts. 
     Similarly, there is no requirement that the RADIUS client receiving the Access Reject message as part of a pre-authentication transaction issue any form of accounting information. Remote reporting systems that should report on every call rejection have no guaranteed means to receiving accounting information for policy rejection criteria. 
     For calls that are accepted, there is no current way to indicate under which policies the call was accepted. Further there are no current means by which an accepted call is identified with a ‘standard use’ policy, or whether the call is part of an ‘over-subscription’ pool for which the customer is charged a premium. 
     SUMMARY 
     One embodiment of the invention comprises a method to account for policy decision in access requests is disclosed. The method includes receiving a pre-authentication request for a call and applying at least one policy to determine a policy decision for the request. A message is then transmitted to indicate a manner in which the call is resolved and the policy decision. The messages may be RADIUS Access Accept or Access Reject messages, and may include a vendor specific RADIUS attribute that accounts for policy decisions. 
     Another embodiment of the invention is a network device capable of transmitting the messages in such a manner as to allow for accounting of the policy decision. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention may be best understood by reading the disclosure with reference to the drawings, wherein: 
         FIG. 1  shows an embodiment of a network and its associated policy processors. 
         FIG. 2  shows a call flow for a pre-authentication request, according to the prior art. 
         FIG. 3  shows an embodiment of a call flow for a pre-authentication request. 
         FIG. 4  shows a diagram of a RADIUS Access Accept or Access Reject message. 
         FIG. 5  shows a diagram of a RADIUS Vendor Specific Attribute. 
         FIG. 6  shows a flowchart of an embodiment of a method to account for policy decisions in response to pre-authentication requests. 
         FIG. 7  shows a diagram of an embodiment of a network device. 
     
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
       FIG. 1  shows a wholesale network  18  with an associated policy system. Network Access Servers (NAS)  10   a - n  receive calls from users. The NASes then determine if the call can be connected to the network. Somewhere in the network lies the (RADIUS) server  14  or servers to which the user is trying to connect. A relatively new implementation of a RADIUS proxy devices, referred to as a RASER may also be used. 
     Several different factors affect the connection of a call. A user typically enters a user name and password, which must be verified. Similarly, the network must be able to handle the call. Typically the factors affecting the network handling of a call are directed towards traffic considerations and network capacity. If the traffic level is too high, or network resources are tied up, the call will be rejected. 
     Recently, however, wholesalers have begun implementing policy systems to control their networks. Policy systems, which contain one or more dedicated devices that process policy considerations and are referred to here a policy processors, make decisions to accept or reject calls based on other factors than the capabilities and capacity of the network. For example, a user dialing into the network through NAS  10   a  may be a user of a particular ISP, ISP1. ISP1 is a customer of the wholesaler that owns the network  18 , and has an agreement, referred to here as a Service Level Agreement (SLA) that sets for the provision of service by the wholesaler to ISP1 and the associated costs. 
     A service level agreement may guarantee a predetermined number of users on the network for ISP1, at a set level of service. The SLA may also set forth another number of users for which there is no guaranteed level of service, but for which there will be made best efforts to connect. For example, ISP1 may have 25,000 users are a particular level of service, with a ‘best-efforts’ pool of 10,000 users. These numbers may also be manipulated based upon the time of day, and may be spread over a number of POPs. For example, ISP1 may be allowed 15,000 users between 6 and 8 am at the first level of service, going up or down after 8 am. 
     This type of agreement is implemented in the policy system as a set of constraints that are used to determine whether or not a call can be accepted. Generally, it is desirable for the results of the applications of policies to be reported and provided to the wholesaler and the customer. If, for example, ISP1 has had several users call in to their customer service center complaining that are not getting connected, ISP1 may then turn around and call the wholesaler to complain. If the wholesaler can show that the rejected calls were because they were over the SLA, then ISP1 may become aware that it needs to renegotiate the contract, or that it was just a random occurrence and will be adjusted accordingly. However, current systems have no accounting requirements for calls rejected prior to access request, those calls rejected based upon a pre-authentication request. 
     In the call flow for a pre-authentication request, the pre-authentication request is followed by an authentication request, followed by an accounting start and then an accounting stop. There is no place in the call flow for any accounting between pre-authentication and authentication. When a call is rejected after an authentication request, the call flow would start with the pre-authentication request, then the authentication request, followed by an accounting stop, where the accounting stop has a reject reason associated with it. 
     However, problems arise in the current implementations of policy services in that this information may not be recorded at all, recorded in such a way that it is cumbersome for the wholesale network reporting systems to access the information, or it may not provide enough information. For example, current policy systems may write a Call Detail Record, documenting the resolution of a call, such as accepted or rejected, and is associated accounting information. These are typically stored as local files by the servers, as there are no effective requirements on how to pass this information to other systems. 
     Similarly, if the call is outside the first level of service, the user may be connected as part of the ‘best efforts’ pool, which may also be referred to as the over-flow pool or the over subscription pool. These slots for calls are allocated on a first-come, first-serve basis and may involve a premium pricing structure, as they are ‘extra’ service being provided. 
     NAS  10   a  sends the request to the policy processor or processors  16   a - c . The policy processor applies the appropriate policies, as will be discussed in more detail later, and either accepts or rejects the call. It must be noted that the call request in a RADIUS system is actually a pre-authentication request. A pre-authentication allows the system to determine if a call is going to be accepted prior to any resource reservations or allocations that might decrease the network efficiencies if the call were to be rejected. Making reservations and allocations, even temporarily, for calls that will not be connected reduces the amount of traffic a network can handle. 
     As can be seen in  FIG. 2 , this scenario may result in a call accept or a call reject message. In RADIUS systems, as documented in IETF&#39;s RFC 2865, a pre-authentication request is granted with an Access Accept message and denied with an Access Reject message. Currently, the client  20 , which may be a NAS or a gateway, sends a pre-authentication request to the policy processor  22 . The policy processor then returns a response. In the case of an Access Reject message, the traffic ends there and there is no accounting required of the rejection or the reasons for the rejection. 
     In the case of an Access Accept message, there are some requirements that allow the accounting systems and procedures of the network to have access to the necessary information. For example, the RADIUS specification (IEFT RFC 2865) requires that an attribute, discussed in more detail below, called a Class attribute can be sent by the server, in this case the policy processor, to the client. The client is to send it unmodified to the accounting server as part of an accounting request response packet. This can be used to ensure that the accounting and reporting system  24  ‘knows’ that the call has been accepted. This solves the problem of identifying accepted calls but is somewhat awkward in that there is no way to indicated under which policy the call was accepted, the agreed upon service level or as part of an over subscription service. 
     A more detailed view of an Access Accept or Access Reject message is shown in  FIG. 4 . It must be noted that these are actually two different messages and have different aspects to them. However, the overall structure of these messages is the same. The first 8 bits is the CODE field, in which the type of message is defined, such as 2 for Access Accept and 3 for Access Reject. The Identifier field is an octet that identifies the Access Request or pre-authentication request that caused the response. The length field is two octets that define how long the message is. The Response Authenticator is a calculated value that allows the system to maintain security and is beyond the scope of this disclosure. The rest of the message is Attributes. Attributes are the pieces of the message that is necessary to provide information to the other party to the transaction. Examples include user name, client ID, port ID, etc. An example of such an Attribute is the Class Attribute defined above. 
     A specific Attribute that may be used is a Vendor Specific Attribute (VSA) the format of which is shown in  FIG. 5 , which will be referred to here as the Policy Description Attribute. It is possible to define a VSA that documents the policy under which a call was rejected or a call was accepted as an over subscription call. This VSA could take many forms. The string portion could point to a file name into which the Call Detail Record was written, allowing other portions of the policy system to access the file, or it could actually include the documented information itself, as examples. The use of such a VSA would then allow the policy system to track and report on rejected calls and over subscription calls in addition to the regularly accepted calls. Alternatively, the Policy Description could become a new RADIUS Attribute. 
     Referring to  FIG. 3 , it can be seen that the use of either a VSA or a new RADIUS Attribute of Policy Description would allow the policy processor to document the relevant policy applied and the request resolution and then require the client to return that information to the accounting and reporting system as part of the response to an accounting request. This would overcome both the problems of undocumented rejected calls as well as identifying over subscription calls that are priced differently than ‘regular’ calls. While this information may be supplied to the accounting system from the client, it is the policy processor that actually generates and documents that information based upon the policies applied to the request. 
     An embodiment of a method to account for policy decisions in response to pre-authentication requests is shown in  FIG. 5 . At  60  the policy processor receives a pre-authentication request from a client, which could be one of several different entities, including a NAS, a RADIUS server, a RADIUS proxy server referred to as a RASER, where the latter two entities are typically forwarding the request generated by the NAS. At  62 , the policy processor applies a policy. As some policy systems are distributed, this may involve the policy processor receiving the request accessing other policy processors that have information relevant to the request, or the policy processor may be able to apply policies local to that processor. 
     At  64  the policy processor determines whether or not the call is within policy. Note that ‘within policy’ may include being outside of an SLA but within the over subscription pool. If the call is within policy, the policy processor then transmits the Access Accept message with the Policy Decision Attribute, either a VSA or a standard RADIUS Attribute. If the call is outside of policy, the processor transmits an Access Reject message with the included Attribute such that the reporting system will receive the Reject message as well. 
     In actuality, there will more than likely be two response packets. The first is returned to the client making the pre-authentication request as an Access Reject or Accept. The second is either an Accounting Start or an Accounting Stop packet, depending up the acceptance or rejection of the pre-authentication request, addressed to the accounting system or the AAA (Authentication, Authorization and Accounting) server. This allows the AAA server or other accounting system to have access to the necessary information thereby allowing the wholesaler to track the impact of policy decisions on customer traffic. If the Policy Decision Attribute were to be defined as a standardized RADIUS Attribute, it could be defines similar to the Class Attribute for Access Accept messages, where the policy process would be required to provide it to the reporting system. However it is possible that in further refinements to the RADIUS service specification, one message could be sent to the two different entities in a multi-cast format. 
     An example of a network device capable of operating as a policy processor with the Policy Description Attribute is shown in  FIG. 7 . The policy processor  70  has a port  74  allowing it to receive pre-authentication requests. It may have another port  76  that allows it to communicate with other policy processors as necessary, as discussed above. The processor  72  applies the relevant policies and transmits the requisite response with the Policy Description attribute. A memory  78  would act as the storage for the various parameters associated with a customer, such as a call limit, an oversubscription limit, etc. 
     As policy processors are currently resident on wholesale systems that have policy systems, the implementation of embodiments of the invention could be the form of executable code contained on an article of machine-readable media. The code, when executed, would cause the machine to perform the processes of the invention. 
     Thus, although there has been described to this point a particular embodiment for a method and apparatus for policy system load balancing and throttling in data networks, it is not intended that such specific references be considered as limitations upon the scope of this invention except in-so-far as set forth in the following claims.