Application influenced policy

Details Application influenced policy Application influenced policy

2001-05-21

2003-09-16

Yao, Kwang Bin (Department: 2664)

Multiplex communications

Data flow congestion prevention or control

Control of data admission to the network

C370S352000, C370S401000

Reexamination Certificate

active

06621793

ABSTRACT:

BACKGROUND
This application generally relates to packet data networks, and more specifically to filtering and gating data in packet data networks using policy mechanisms.
Originally, packet data networks, such as Internet Protocol (“IP”) networks, were designed to carry “best effort” traffic. That is, the network did not guarantee that a user packet would arrive at the destination. Because of the market success of IP networks, there is today a clear requirement for mechanisms that allow IP networks to support various types of applications. Some of these applications have quality-of-service (“QoS”) requirements. Examples of such applications include various real time applications (IP Telephony, video conferencing), streaming services (audio or video), or high quality data services (browsing with bounded download delays). Recognizing these requirements, the Internet Engineering Task Force (“IETF”), which is the main standards body for IP networking, recently standardized a set of protocols and mechanisms that enable IP network operators to build QoS-enabled IP networks.
FIG. 1
depicts a simplified high-level model of an IP network which may be useful in explaining QoS provisioning. As can be appreciated, the model includes two users, but could easily be expanded to include more users without changing the basic functionality of the network.
In
FIG. 1
, User-A
101
may communicate with User-B
102
or with an application server
103
. For example, in the case of an IP telephony session, User-A
101
may communicate with User-B
102
. Similarly, in the case of streaming services, User-A
101
may communicate with the application server
103
, which may be configured as a video server. In either case, User-A
101
accesses an IP backbone network
104
through a local access network
105
, such as a telephone, Global System for Mobile Communications (“GSM”), or Universal Mobile Telecommunication System (“UMTS”) network. User-B
102
is similarly connected to the IP network
104
through local access network
106
. It will be appreciated that User-A and User-B need not use the same type of access network, however.
As is generally known, the IP network
104
may include a number of IP routers and interconnecting links that together provide connectivity between the IP network's ingress and egress points and thereby make two party communication possible.
As far as the users are concerned, the perceived QoS depends on the mechanisms both in the access networks
105
,
106
and on the IP backbone network
104
. Of particular interest is the specific case where at least one of the access networks is a UMTS network.
When users access IP based services, they typically use a device that runs an application program that provides the interface for the user to access the particular service. For instance, in
FIG. 1
, User-A may use a laptop computer running a conferencing application program to attend an IP network based meeting, where participants of the meeting collaborate using various programs. Such programs are well known in the art.
Various applications may access network services through an application programming interface (“API”). An API provides application programmers with a uniform interface to access underlying system resources. For instance, an API may be used to configure the network resource manager to require that a particular IP packet originating from a given application receive a certain treatment from the network, such as a particular QoS. For example, if the IP network is a Differentiated Services IP network, then an application program may request that all of its IP packets receive the “Expedited Forwarding” treatment.
Note that the User (and the API in the user's equipment) may not be aware of the different technologies that various access networks and IP backbone networks employ in order to provide end-to-end QoS. For instance, the user may use an RSVP/IntServ based API and the end-to-end embodiment in which the user is involved may include a UMTS access network and a non-RSVP enabled IP network. In such cases, some interworking mechanisms between the various technologies may be needed to make sure that QoS is provided end-to-end.
Integrated Services (“IntServ”) provide the ability for applications to choose among multiple, controlled levels of delivery service for their data packets. To support this capability, two things are required. First, individual network elements, such as subnets and IP routers, along the path followed by an application's data packets must support mechanisms to control the QoS delivered to those packets. Second, a way to communicate the application's requirements to network elements along the path and to convey QoS management information between network elements and the application must be provided.
IntServ defines a number of services such as Controlled-Load (defined in IETF RFC
2211
) and Guaranteed (defined in IETF RFC
2212
). The service definition defines the required characteristics of the network equipment in order to deliver the service. For example, guaranteed service provides firm, mathematically-provable bounds on end-to-end datagram queuing delays and makes it possible to provide a service that guarantees both delay and bandwidth. Controlled-load service provides the client data flow with a QoS closely approximating the QoS that the same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded. The individual network elements (subnets and IP routers) that support the service must comply with the definitions defined for the service.
The service definition also defines the information that must be provided across the network in order to establish the service. This function may be provided in a number of ways, but is frequently implemented by a resource reservation setup protocol such as RSVP (defined in IETF RFC
2205
).
RSVP (Resource reSerVation Protocol) is a resource reservation setup protocol designed for an IntServ Internet (defined in IETF RFC
1633
,
2205
, and
2210
). The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver QoS requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path.
FIG. 2
shows the End-to-End Integrated Service between the hosts. The service is provided using routers and hosts that support the service definition defined for the required service and through signaling of the relevant information between the nodes.
Since RSVP is a protocol that is primarily designed to be end-to-end, some extra functionality is required in a situation where the sender would like to use RSVP for resource reservation in only some portion of the end-to-end path. This may arise if RSVP is used in an access network and over-provisioning is used in the backbone network. In such situations the concept of the RSVP Proxy is useful.
The RSVP Proxy is a functionality provided by a network device, such as a router or a switch, in which the network device originates the RESV message in response to an incoming PATH message on behalf of one or more receivers identified by the PATH message. In other words, the RSVP Proxy acts on behalf of the remote host and thereby facilitates resource reservation between the originating host and the RSVP Proxy. This is shown in FIG.
3
. The RSVP Proxy may use knowledge of network conditions between the RSVP Proxy and the non-RSVP host.
Differentiated Services (“DiffServ”) enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may b

Affiliated with

Also associated with

Rating

Application influenced policy does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Application influenced policy, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Application influenced policy will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3082135