1. Field of the Invention
The present invention relates generally to the field of Internet multimedia communication, and, more particularly, to a method for combining Internet protocols for session setup, teardown, authorization, and accounting in a Internet Protocol (IP) network, which uses the DiffSERV (Differentiated Services) model in order to guarantee Quality of Service (QoS).
2. Description of the Related Art
The invention of the telephone opened an unprecedented era in personal communication. At the present time, the Internet is opening up another era in personal communication, allowing a level of interactivity previously unknown between computers and groups of computers. In the future, these two services will be combined into one seamless communication medium.
However, the concepts underlying the telephone system and the Internet are fundamentally different. The telephone system is circuit-based; meaning that, for example, when a call is set up between caller and caller, a dedicated line, or circuit, is maintained between the two, and, when the call is over, the dedicated line is taken down. The Internet is packet-based; meaning that, for example, when a user downloads a web page, or receives an e-mail, the data that comprises the web page or e-mail is broken down into packets before being transmitted. The individual packets, although they form one web page or one e-mail message, may take entirely different routes between the sender and the destination. The destination computer puts all the packets together to form the web page.
A fundamental problem lies in providing a circuit-based service, such as a telephone call or videoconferencing, over a packet-based network. While the answer may appear simple-digitize and packetize the audio or visual information—the situation is more complicated than it appears. For one thing, an application such as a telephone call requires a constant transmission rate; something the current Internet cannot guarantee. An application such as videoconferencing using MPEG has stringent real-time requirements in order to avoid the displayed motion appearing jerky. These requirements include a variable transmission rate and very little jitter in the packet arrival times. Once again, at present the Internet cannot guarantee these requirements will be met.
One system for addressing these Quality of Service (QoS) issues on the Internet is the DiffServ model or Differentiated Services architecture (RFC 2475). In DiffServ, packet traffic shaping is implemented by network routers. In order to specify the transmission requirements, DiffServ uses the Type of Service (ToS) bits in the Internet Protocol (IP) packet header (see FIG. 1). Although the ToS field exists in the current protocol IPv4 (Internet Protocol, version 4), most routers do not use or read the bits in the ToS field. DiffServ uses these bits to tell the router the priority of the packet. Because of this, the ToS field in the IP header is referred to as the DS field.
DiffServ is implemented in the following manner: when packet traffic enters a DiffServ network, the packets are classified and possibly conditioned at the network boundary, most likely in an edge router. The DS field will be filled in with the appropriate bits for that type of traffic, which may depend on customer usage, media specification, general policy, etc. The network nodes inside the DiffServ network will read the DS field to determine how to manage incoming packets. For instance, if an edge router recognizes incoming packets as being high priority, the router will classify those packets as high priority in the DS field, and then send those packets inside the network. When those high priority packets reach a network node, the node will forward them before other packets, because the DS field indicates that they are high priority. This example is somewhat of a simplification, for the DS field classification scheme is more complicated than merely high or low priority, and takes into account throughput, delay, jitter, packet loss, and other traffic characteristics. Taken together, these traffic characteristics make up Quality of Service (QoS).
Because DiffServ classifies these packets into different categories, it works only upon “flow aggregates,” which refers to a collection of packet flows. In other words, an interior network node does not know what a packet contains or if that packet is part of a series of packets; the interior node merely treats it as a member of a certain classification of traffic characteristics. This is in contrast to another method of assuring QoS over a network, the Resource ReSerVation Protocol (RSVP). RSVP sets up a path from network node to network node for a particular packet flow. For example, if an end client device wishes to establish a telephone call over the network, the device would use RSVP to establish a path to the callee's end client device through one or more network nodes. The individual network nodes on the path would then know that a particular identified packet flow will require certain traffic conditions, and resources will be reserved for them. When a node receives one of the packets in the series of packets, the node will recognize it and behave accordingly. While DiffServ looks at flow aggregates, RSVP looks at individual “micro-flows.”
For the rest of this description; a DiffServ environment will be assumed. This means that the QoS requirements will be handled by edge routers which will tag individual packets appropriately, while interior network nodes will act upon packets based merely on their DS field.
Even assuming the QoS problems are being handled by DiffServ, there are other services automatically handled in a circuit-based environment which are problematic in an IP-based network. A call has to be set up, establishing a connection between the two end devices, and the resources used in an individual call or session must be tracked, for accounting purposes. In addition, there needs to be the capability to have only authorized sessions or calls from authenticated users. In the Internet framework, these issues are resolved by different protocols that do different things. Although these individual protocols have been developed in detail, there is at present known method that sets forth how to use them together in a consistent way across the Internet.
Thus, there is a need for linking these protocols together in a consistent and workable way. In particular, there is a need for a method providing an interchange of parameters among protocols between session setup, authorization, policy, and usage reporting that will support IP communications between Internet Service Providers (ISPs), enterprise networks, and individual clients.
The present invention provides a method for providing an interchange of parameters among protocols for session setup, teardown, authorization, policy, and usage reporting that will support IP communications in a Differentiated Services model environment.
The present invention provides a method for session or call setup, teardown, authorization, policy and usage reporting in a common way of usage, thereby supporting IP communications across the Internet.
The present invention also provides a method to link together the Session Initiation Protocol (SIP), Common Open Policy Service (COPS), and Open Settlement Policy (OSP) in a Differentiated Services model environment.
These and other objects are achieved by the preferred embodiment of the present invention. In the preferred embodiment, the messages from the Session Initiation Protocol (SIP), Common Open Policy Service (COPS), and Open Settlement Policy (OSP) are interwoven so that session setup, authorization, policy, and usage reporting are all performed concurrently, in one unified sequence of messages. Likewise, the messages from the Session Initiation Protocol (SIP), Common Open Policy Service (COPS), and Open Settlement Policy (OSP) are interwoven so that session teardown, authorization, policy, and usage reporting are all performed concurrently, in one unified sequence of messages.
The above and other objects, features and advantages of the present invention will become more apparent from the following detailed description when taken in conjunction with the accompanying drawing in which:
As stated above, in the prior art there has been no linkage between the individual protocols that provide for call setup, authorization, accounting, and authentication. These steps are taken care of by the following protocols:
These protocols will be discussed in detail below. In these discussions, the terms “client” and “server” will be used in their abstract functional sense, as process that may be implemented in any sort of device. This means, of course, that some servers and clients may be running in the same device.
a) Session Initiation Protocol (SIP)
SIP is a signaling protocol that allows for initiating and tearing down connections. There are two components in a SIP system: network servers and user agents. A user agent is an end system that acts on behalf of someone who wants to participate in calls. In general, the user agent contains both a protocol client (a user agent client UAC) which initiates a call and a protocol server (user agent server UAS) which responds to a call (see
The steps in initiating a session are fairly simple: as shown in
The steps in terminating a session, or teardown, are even more simple: the UAC sends a BYE message, and the UAS sends a message indicating receipt of the BYE message. In SIP, either the UAC or the UAS may send the BYE message terminating a session.
b) Common Open Policy Service (COPS)
COPS is a simple query and response protocol that can be used to exchange information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs), as shown in
When particular events occur at a PEP, such as the initiation of a session, the PEP will send a REQ to the PDP to determine the policy regarding the session. The REQ may be an Authentication, Authorization Accounting (AAA) REQ, which is asking that the session be authorized, authenticated, and track of for accounting purposes. If the PDP determines the session fits the AAA policy, the PDP will send its decision DEC to the PEP, thus allowing the PEP to allocate the needed resources. The RPT message is used by the PEP to communicate to the PDP its success or failure in carrying out the PDP's decision, or to report an accounting related change in state.
c) Open Settlement Protocol (OSP)
OSP is used when there is a central clearinghouse for certain policy decisions. As shown in
As stated above, these protocols have been extensively defined and implemented, but to date there has been no common way of usage for combining them. A preferred embodiment of the present invention, as described below, combines these protocols in order to provide a consistent and common manner of usage for IP-based networks using the Differentiated Services model. In the description below of
Referring to
In general, the call setup request, authorization and policy installation occur as follows:
The actual sequence of messages is divided between the three protocols: message steps 1, 6, 11, 12, 17, and 22-9 are SIP messages; message steps 2, 5, 7, 10, 13-16, 18-21 are COPS messages; and message steps 3-4 and 8-9 are OSP messages. In this manner, the preferred embodiment of the present invention links the three protocols for call setup, authorization, and accounting. Although the above sequence has been described with a clearinghouse server, the preferred embodiment can work in a system without a clearinghouse. In such a network, the policy server handles most of the clearinghouse tasks, and message steps 3-4 and 8-9 would take place inside the policy server.
As with the setup message sequence described above, the actual sequence of messages is divided between the three protocols: message steps 1, 6, 11, 12, 17, and 22-9 are SIP messages; message steps 2, 5, 7, 10, 13-16, 18-21 are COPS messages; and message steps 3-4 and 8-9 are OSP messages. In this manner, the preferred embodiment of the present invention links the three protocols for call tear-down and usage reporting. Although this has been described with a clearinghouse server, the preferred embodiment can work in a system without a clearinghouse. In such a network, the policy server handles most of the clearinghouse tasks, and message steps 3-4 and 8-9 would take place inside the policy server.
While an embodiment of the present invention has been shown and described, it is to be understood that many changes and modifications may be made thereunto without departing from the spirit and scope of the invention as defined in the appended claims.
The present application is a continuation of U.S. Pat. application Ser. No. 09/435,540 filed on Nov. 8, 1999, which claims the benefit of U.S. Provisional Patent Application Ser. No. 60/163,913 filed on Nov. 5, 1999; the entireties of which are hereby incorporated by reference.
Number | Name | Date | Kind |
---|---|---|---|
5130983 | Heffner | Jul 1992 | A |
5315586 | Charvillat | May 1994 | A |
5586121 | Moura et al. | Dec 1996 | A |
5634012 | Stefik et al. | May 1997 | A |
5680116 | Hashimoto et al. | Oct 1997 | A |
5745694 | Egawa et al. | Apr 1998 | A |
5825772 | Dobbins et al. | Oct 1998 | A |
5867571 | Borchering | Feb 1999 | A |
5883894 | Patel et al. | Mar 1999 | A |
5889777 | Miyao et al. | Mar 1999 | A |
5903559 | Acharya et al. | May 1999 | A |
5903735 | Kidder et al. | May 1999 | A |
5909430 | Reaves | Jun 1999 | A |
5930348 | Regnier et al. | Jul 1999 | A |
5933412 | Choudhury et al. | Aug 1999 | A |
5953338 | Ma et al. | Sep 1999 | A |
5960416 | Block | Sep 1999 | A |
5991292 | Focsaneanu et al. | Nov 1999 | A |
6058113 | Chang | May 2000 | A |
6073160 | Grantham et al. | Jun 2000 | A |
6088358 | Tomita et al. | Jul 2000 | A |
6097722 | Graham et al. | Aug 2000 | A |
6108314 | Jones et al. | Aug 2000 | A |
6137777 | Vaid et al. | Oct 2000 | A |
6141686 | Jackowski et al. | Oct 2000 | A |
6151319 | Dommety et al. | Nov 2000 | A |
6157648 | Voit et al. | Dec 2000 | A |
6195355 | Demizu | Feb 2001 | B1 |
6205148 | Takahashi et al. | Mar 2001 | B1 |
6216006 | Scholefield et al. | Apr 2001 | B1 |
6295532 | Hawkinson | Sep 2001 | B1 |
6298383 | Gutman et al. | Oct 2001 | B1 |
6324279 | Kalmanek et al. | Nov 2001 | B1 |
6343326 | Acharya et al. | Jan 2002 | B2 |
6366577 | Donovan | Apr 2002 | B1 |
6385203 | McHale et al. | May 2002 | B2 |
6426955 | Gossett Dalton et al. | Jul 2002 | B1 |
6434153 | Yazaki et al. | Aug 2002 | B1 |
6473404 | Kaplan et al. | Oct 2002 | B1 |
6487170 | Chen et al. | Nov 2002 | B1 |
6578076 | Putzolu | Jun 2003 | B1 |
6581102 | Amini et al. | Jun 2003 | B1 |
6584093 | Salama et al. | Jun 2003 | B1 |
6594277 | Chiang et al. | Jul 2003 | B1 |
6678264 | Gibson | Jan 2004 | B1 |
6678835 | Shah et al. | Jan 2004 | B1 |
6714515 | Marchand | Mar 2004 | B1 |
6714987 | Amin et al. | Mar 2004 | B1 |
6728365 | Li et al. | Apr 2004 | B1 |
6735630 | Gelvin et al. | May 2004 | B1 |
6745207 | Reuter et al. | Jun 2004 | B2 |
6765927 | Martin et al. | Jul 2004 | B1 |
6775701 | Pan et al. | Aug 2004 | B1 |
6801542 | Subbiah | Oct 2004 | B1 |
6801940 | Moran et al. | Oct 2004 | B1 |
6823385 | McKinnon et al. | Nov 2004 | B2 |
6826613 | Wang et al. | Nov 2004 | B1 |
6845106 | McKinnon et al. | Jan 2005 | B2 |
6854014 | Amin et al. | Feb 2005 | B1 |
6857012 | Sim et al. | Feb 2005 | B2 |
6914883 | Dharanikota | Jul 2005 | B2 |
6973035 | Seddigh et al. | Dec 2005 | B2 |
7046680 | McDysan | May 2006 | B1 |
7069337 | Rawlins et al. | Jun 2006 | B2 |
7146425 | Oottamakorn et al. | Dec 2006 | B2 |
7212495 | Karri et a | May 2007 | B2 |
7307954 | Strandberg et al. | Dec 2007 | B1 |
20010025310 | Krishnamurthy et al. | Sep 2001 | A1 |
20010027490 | Fodor et al. | Oct 2001 | A1 |
20010048682 | Fichou et al. | Dec 2001 | A1 |
20020016839 | Smith et al. | Feb 2002 | A1 |
20020026513 | Hoglund et al. | Feb 2002 | A1 |
20040022191 | Bernet et al. | Feb 2004 | A1 |
Number | Date | Country | |
---|---|---|---|
20050213584 A1 | Sep 2005 | US |
Number | Date | Country | |
---|---|---|---|
60163913 | Nov 1999 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 09435540 | Nov 1999 | US |
Child | 11130317 | US |