Network traffic admission control

Description

This application claims the benefit of Provisional Application No. 60/537,277, filed Jan. 15, 2004, the entirety of which is hereby incorporated herein by reference for all purposes. The present application is a Continuation-in-Part of U.S. patent application Ser. No. 09/634,035, now U.S. Pat. No. 7,013,338, filed Aug. 8, 2000 and entitled “Multiplexing Several Individual Application Sessions Over a Pre-Allocated Reservation Protocol Session”, the entirety of which is hereby incorporated herein by reference for all purposes. U.S. Pat. No. 7,013,338 claims the benefit of U.S. Provisional Application No. 60/221,571, filed Jul. 28, 2000. The present application is also a Continuation-in-Part of U.S. patent application Ser. No. 10/206,402, now U.S. Pat. No. 7,266,683, filed Jul. 27, 2002 and entitled “Selective Encryption of Application Session Packets”, the entirety of which is hereby incorporated herein by reference for all purposes. U.S. Pat. No. 7,266,683 claims the benefit of U.S. Provisional Application No. 60/308,421, filed Jul. 27, 2001. The present application is also a Continuation-in-Part of U.S. patent application Ser. No. 10/701,017, filed Nov. 3, 2003 and entitled “End-to-End Service Quality for Latency-Intensive Internet Protocol (IP) Applications in a Heterogeneous, Multi-Vendor Environment”, the entirety of which is hereby incorporated herein by reference for all purposes. U.S. patent application Ser. No. 10/701,017 claims the benefit of U.S. Provisional Application No. 60/423,189, filed Nov. 1, 2002.

COPYRIGHT NOTICE

Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever. Copyright© 2000-2005 Prominence Networks, Inc.

BACKGROUND

1. Field

Embodiments of the present invention relate generally to a traffic admission control methodology for a Differentiated Services (DiffServ) network environment. More particularly, embodiments of the present invention relate to a scalable model for determining whether to grant admission to a voice, video and/or data traffic session using a combination of global path admission control and local traffic session admission control.

2. Description of the Related Art

Edge devices cannot currently obtain visibility into available bandwidth in all intermediate routers in a path to another edge device in a DiffServ network environment. Internet Protocol (IP) networks do not offer any mechanism to query the available bandwidth on a certain path through the network. Consequently, there is no available model for performing strict session admission control for new sessions desiring access to a path between two edge boxes in a DiffServ network environment.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1 conceptually illustrates an exemplary topology and network environment in which one embodiment of the present invention may be employed.

FIG. 2 is an example of a network device in which one embodiment of the present invention may be implemented.

FIG. 3 is a high-level block diagram of a media aggregation manager according to one embodiment of the present invention.

FIG. 4 is a simplified, high-level flow diagram illustrating application session processing according to one embodiment of the present invention.

FIG. 5 is a simplified, high-level flow diagram illustrating application session establishment processing according to one embodiment of the present invention.

FIG. 6 illustrates interactions among local and remote media aggregation manager functional units according to one embodiment of the present invention.

FIG. 7 is a high-level block diagram of a media director according to one embodiment of the present invention.

FIG. 8 is a simplified, high-level flow diagram illustrating application path provisioning/processing according to one embodiment of the present invention.

SUMMARY

Methods and apparatus are described for performing traffic admission control in a Differentiated Services (DiffServ) network environment. According to one embodiment, a predetermined portion of available bandwidth between a first network device and a second network device is reserved as a real-time bandwidth pool for real-time communication sessions among users of a first group of terminals associated with the first network device and a second group of terminals associated with the second network device, the real-time bandwidth pool corresponding to estimated bandwidth remaining available on a path through a Differentiated Services (DiffServ) network interposed between the first group of terminals and the second group of terminals. Thereafter, the real-time bandwidth pool is shared among multiple real-time communication sessions involving terminals of the first and second groups of terminals by selectively admitting application sessions based upon currently available resources in the real-time bandwidth pool.

Other features of embodiments of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.

DETAILED DESCRIPTION

Apparatus and methods are described for performing admission control in a DiffServ network environment. Broadly stated, embodiments of the present invention seek to provide a scalable model for determining whether to grant admission to a media session onto a path between edge devices of a DiffServ network environment. According to one embodiment, the unique model employs a combination of global path admission control and local traffic session admission control. For example, in the context of a Voice over IP (VoIP) implementation, a media director may maintain an up-to-date table of available bandwidth on every interface in the network and perform global path admission control (e.g., allocate bandwidth along a path through one or more DiffServ network domains) on behalf of local media aggregation managers. The local media aggregation managers then need only concern themselves with performing local call admission control based upon the pre-allocated bandwidth provided by the media director. Advantageously, in this matter, a scalable method is provided for determining whether to grant admission to calls onto an aggregate pipe while assuring the newly admitted call/session that it will receive required end-to-end bandwidth. The proposed method of call admission control improves the jitter and delay characteristics of voice flows. Additionally, the local media aggregation managers need not query the media director for available bandwidth upon initiation of every call/session. Rather, the local media aggregation managers may perform local call admission control without the overhead of interactions with the media director so long as they operate within the pre-allocated bandwidth they have been granted for a particular path.

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. It will be apparent, however, to one skilled in the art that embodiments of the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.

Embodiments of the present invention include various steps, which will be described below. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software, and/or firmware.

Embodiments of the present invention may be provided as a computer program product which may include a machine-readable medium having stored thereon instructions which may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, ROMs, random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions. Moreover, embodiments of the present invention may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).

While, for convenience, embodiments of the present invention are described with reference to a VoIP implementation, the present invention is equally applicable to various other network applications or services that are latency intensive (e.g., affected by jitter and/or transmission delays) and/or that require real-time performance, such as applications based on human interactions (e.g., collaborative software, online/Web collaboration, voice conferencing, and video conferencing), and real-time data communication and/or exchange, such as market data applications, financial transactions, and the like.

Additionally, for sake of brevity, embodiments of the present invention are described with reference to particular existing signaling, control, and communications protocol standards, such as International Telecommunication Union Telecommunication Standardization Section (ITU-T) Recommendation H.225.0 entitled “Call Signalling Protocols and Media Stream Packetization for Packet-based Multimedia Communication Systems,” published February 1998 (hereinafter H.225.0); and ITU-T Recommendation H.245 entitled “Control Protocol for Multimedia Communication,” published May 1999 (hereinafter H.245); ITU-T Recommendation H.323 entitled “Packet-based Multimedia Communications Systems,” published September 1999 (hereinafter H.323), the present invention is equally applicable to various other signaling, control, and communications protocols. For example, Session Initiation Protocol (SIP) may be employed to create, modify, and terminate application sessions with one or more participants. SIP is described in M. Handley et al., “SIP: Session Initiation Protocol,” RFC 2543, Network Working Group, March 1999, which is hereby incorporated by reference. Furthermore, it is contemplated that embodiments of the present invention will be applicable to various proprietary signaling and media transport protocols.

TERMINOLOGY

Brief definitions of terms used throughout this application are given below.

An “application” or “endpoint” generally refers to a software program that is designed to assist in the performance of a specific task, such as Internet telephony, online collaboration, or video conferencing.

An “application flow” generally refers to the data associated with an application session. An example of an application flow is a media stream, such as a continuous sequence of packetized voice and/or voice-band data transmitted over a network.

“Application session” generally refers to a session established and maintained between two or more end points or terminals. According to embodiments of the present invention, one or more application sessions may be multiplexed onto a path through a DiffServ network environment. In the context of VoIP, a call from one user community to another is an example of an application session.

The phrase “communication network” or term “network” generally refers to a group of interconnected devices capable of exchanging information. A communication network may be as few as several personal computers on a Local Area Network (LAN) or as large as the Internet, a worldwide network of computers. As used herein “communication network” is intended to encompass any network capable of transmitting information from one entity to another. In one particular case, a communication network is a Voice over Internet Protocol (VoIP) network. In some cases, a communication network may be comprised of multiple networks, even multiple heterogeneous networks, such as one or more border networks, voice networks, broadband networks, service provider networks, Internet Service Provider (ISP) networks, and/or Public Switched Telephone Networks (PSTNs), interconnected via gateways operable to facilitate communications between and among the various networks.

The terms “connected” or “coupled” and related terms are used in an operational sense and are not necessarily limited to a direct or physical connection or coupling.

The phrases “in one embodiment,” “according to one embodiment,” and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one embodiment of the present invention, and may be included in more than one embodiment of the present invention. Importantly, such phases do not necessarily refer to the same embodiment.

If the specification states a component or feature “may”, “can”, “could”, or “might” be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.

The phrases, terms, and acronyms “media aggregation manager,” “MAM,” “media controller,” and “MC” generally refer to one or more or a combination of physical and/or logical network devices, such as an edge device at the ingress/egress edges of a user community, or a group of one or more software processes running on a network device that provides application/protocol specific multiplexing/demultiplexing of media traffic over a pre-allocated path (potentially through one or more tunnels).

The phrase/acronym “media director”/“MD” generally refers to one or more or a combination of physical and/or logical network devices or a group of one or more software processes running on a network device that has a global view of the DiffServ network and provides core router visibility. According to one embodiment, the MD is separate and remote from MCs. However, in other embodiments, the MD functionality may be colocated with MC functionality.

The term “responsive” includes completely or partially responsive.

A “tag,” in the context of the described embodiment, generally refers to information that is appended to application generated packets, such as Real-time Transport Protocol (RTP) packets or Real-time Transport Control Protocol (RTCP) packets, that allows the proxy endpoints of the communication session to transmit encapsulated packets to the appropriate remote application/endpoint (RA). According to one embodiment of the present invention, a tag includes address information, such as the destination network address of the terminal upon which the destination application/endpoint resides. When a media aggregation manager is employed in connection with a transport protocol and control protocol (such as RTP and RTCP) that use different channels or ports for control and data, control and data packets may be multiplexed onto the pre-established path by including protocol dependent control information. Then, the remote media aggregation manager may strip the tag from the encapsulated packet and determine the appropriate channel/port of the remote application/endpoint on which to forward the resulting packet based upon the additional protocol dependent control information within the tag. In this manner, two layers of multiplexing may be achieved, (1) a first layer that allows identification of the appropriate application at the remote media aggregation manager; and (2) a second layer that specifies a subclass/subprocess within an application.

A “terminal” generally refers to a LAN-based endpoint for media transmission, such as voice and/or voice-based data transmission. Terminals may be capable of executing one or more networked applications programs. In the context of VoIP, an example of a terminal would be a computer system running an Internet telephony application, such as CoolTalk or NetMeeting.

A “tunnel” generally refers to a logical transmission medium through which packets of one protocol encapsulated or wrapped in a packet of another protocol are transmitted via the protocol of the wrapper. According to one embodiment, voice and/or voice-band data packets are encrypted proximate to the source for secure transmission over one or more public internetworks, such as the Internet, and then decrypted proximate to the destination.

A “user community” generally refers to a group of users residing on a common network. For example, employees on an enterprise network at a given location or users of a particular Internet service provider (ISP) at a given location may represent a user community.

In the exemplary topology depicted in FIG. 1, media controller or media aggregation manager A (“MC-A”) and media controller or media aggregation manager B (“MC-B”) comprise edge boxes/session controllers that aggregate voice, video and/or data traffic for H323, SIP, and Skinny phones and endpoint units. The centralized media director (MD) provisions a path through the router topology between MC-A and MC-B.

When the MD is introduced into the network, it acts as a bandwidth broker and discovers the entire topology. The MD keeps track of the available bandwidth of PQ on every interface in the network. MC forwards its aggregate voice traffic through the PQ.

The MD performs Path Admission control and is the strict owner of bandwidth for the priority queue. The MCs request bandwidth from the MD. Since MD has visibility into the total available bandwidth in network, it has enough information to accept or deny the request. Once bandwidth is allocated to an MC for a path, the MC then keeps track of the available bandwidth in the path, to perform local Call admission control.

In this example, the route for the path is edge box MC-A, routers UT1, T1, T3, UT2 and edge box MC-B. The path is allocated a certain bandwidth, for example 500 Kb/s.

When MC-A gets an incoming voice call or request for a new session, it determines the aggregate path through which the call must be forwarded to the remote edge box. MC-A then determines if there is enough bandwidth available in the routers along the path to fit this call. This process (called Call Admission Control) validates that there is room to fit one session, the source MC marks all incoming packets from the session with a DiffServ marking appropriate to the nature of traffic, and forwards it to the remote MC. In the above case, if Phone A calls Phone B, PhoneA's traffic is first sent to MC-A; which determines that it should be forwarded over the aggregate path to MC-B. MC-B then de-aggregates PhoneA's traffic and forwards it to PhoneB.

Necessary policies are configured into the routers so that the packets with the DiffServ marking are given the Expedited Forwarding Per-Hop-Behavior (PHB) treatment. Such packets are channeled into the priority queue, (PQ) so that voice flows do not suffer delays, jitters of best effort traffic.

According to one embodiment, the MC notifies the MD of any changes to bandwidth for a path. Requests for additional bandwidth from MCs may occur during path creation. Furthermore, such requests may be due to unpredicted call load volumes. Relinquishment of bandwidth may occur during path deletion and/or voluntary bandwidth relinquishment from an MC.

According to one embodiment, the MD maintains an up-to-date table of available bandwidth on every interface in the DiffServ network environment called an AvailableBandwidth table. For every bandwidth request from an MC for a path, the MD performs “Path admission control (PAC).” PAC verifies the AvailableBandwidthTable to ensure that for every interface in the path, there is enough available bandwidth to accommodate the bandwidth request. If there is, then the request is granted. If not, the request is denied. The MD then adjusts the ReservedBandwidth table to subtract the available bandwidth by the amount granted along all the interfaces in the path.

Once a portion of bandwidth on an interface is granted to a path, the MD will not allocate it for any other paths that are also provisioned over that interface.

Once the MC is granted a chunk of bandwidth, the MC is assured of the requested bandwidth in the path, end-to-end to the remote MC. For its part, the MC keeps track of the available bandwidth on its aggregate path. When MC gets an incoming call, or a new session, it computes the bandwidth requirements for the new call or session. The MC also knows the exact size of its aggregate path to the remote MC. MC performs Call Admission Control (CAC) locally for the request. It determines if there is room in the path for the requested bandwidth. If there is room, the new session is admitted into the path. The available bandwidth on the path is reduced by the bandwidth occupied by the session on the local MC.

If the local MC determines that it needs more bandwidth on the path to the remote MC, it again requests the MD to readjust the bandwidth size of its path. The MD performs Path Admission Control and grants or denies the request (see e.g., FIG. 8).

While in some embodiments described herein, the media aggregation managers 110 and 120 are discussed as if they are autonomous network edge devices, according to various embodiments of the present invention some or all of the functionality of a media aggregation manager might be integrated with existing network devices, such as bridges, routers, switches, and the like.

Additionally, while the media director is discussed as if it were an autonomous network device, according to one embodiment of the present invention some or all of the functionality of a media director might be integrated within existing network devices or distributed among one or more media aggregation managers.

Furthermore, in some embodiments the determination regarding bandwidth requirements between the local and remote MCs is described as being performed by the local (or originating) MC; however, such determination may be performed on behalf of the local MC or by or on behalf of the remote MC in alternative embodiments.

Moreover, while according to one embodiment, Path Admission Control is performed by a centralized entity, e.g., a MD, in alternative embodiments the Path Admission Control functionality may be distributed. Similarly, while Call Admission Control is described above as being performed local to a call originating MC, in alternative embodiments, such Call Admission Control may be performed on behalf of the MC by the remote MC or by the MD, for example.

Network Device Overview

An exemplary machine in the form of a network device 200, representing an exemplary media aggregation manager or media director, in which features of the present invention may be implemented will now be described with reference to FIG. 2. In this simplified example, the computer system 200 comprises a bus 201 or other communication means for communicating data and control information, and one or more processors 202, such as Intel® Itanium® or Itanium 2 processors or Sun® UltraSPARC-IIi® processors, coupled with bus 201.

Computer system 200 further comprises a random access memory (RAM) or other dynamic storage device (referred to as main memory 204), coupled to bus 201 for storing information and instructions to be executed by processor(s) 202. Main memory 204 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor(s) 202.

Computer system 200 also comprises a read only memory (ROM) 206 and/or other static storage device coupled to bus 201 for storing static information and instructions for processor(s) 202.

A mass storage device 207, such as a magnetic disk or optical disc and its corresponding drive, may also be coupled to bus 201 for storing instructions and information.

One or more communication ports 203 may also be coupled to bus 201 for supporting network connections and communication of information to/from the computer system 200 by way of a communication network, such as a Local Area Network (LAN), Wide Area Network (WAN), the Internet, or PSTNs, for example. The communication ports 203 may include various combinations of well-known interfaces, such as one or more modems to provide dial up capability, one or more 10/100 Ethernet ports, one or more Gigabit Ethernet ports (fiber and/or copper), or other well-known network interfaces commonly used in internetwork environments. In any event, in this manner, the computer system 200 may be coupled to a number of other network devices, communication devices, clients, and/or servers via a conventional communication network infrastructure.

Optionally, operator and administrative interfaces (not shown), such as a display, keyboard, and a cursor control device, may also be coupled to bus 201 to support direct operator interaction with computer system 200. Other operator and administrative interfaces can be provided through network connections connected through communication ports 203.

Finally, removable storage media (not shown), such as one or more external or removable hard drives, tapes, floppy disks, magneto-optical discs, compact disk-read-only memories (CD-ROMs), compact disk writable memories (CD-R, CD-RW), digital versatile discs or digital video discs (DVDs) (e.g., DVD-ROMs and DVD+RW), Zip disks, or USB memory devices, e.g., thumb drives or flash cards, may be coupled to bus 201 via corresponding drives, ports or slots.

Media Aggregation Manager

FIG. 3 is a high-level block diagram of a media controller/media aggregation manager according to one embodiment of the present invention. By interconnecting a plurality of distributed media aggregation managers, such as media aggregation manger 300, an architecture is provided for multiplexing several application flows (e.g., VoIP calls) and optionally additionally selectively encrypting such flows over a pre-established path. In a VoIP environment, the logical positioning of the media aggregation managers 300 relative to the terminals enables encryption to be performed only on voice related packets rather than every packet that hits the router as would be the case in a RBE solution.

In the example depicted, the source media aggregation manager receives media packets from its local terminals and transmits encrypted multiplexed media to the destination aggregation manager. The destination aggregation manager receives the encrypted multiplexed media and routes media packets to the appropriate terminal(s) of its local terminals by performing demultiplexing and decryption.

In this example, the media aggregation manger 300 includes an application/protocol specific media multiplexor 350, an application/protocol specific media demultiplexor 360, a media encryptor 355, a media decryptor 365, an admission control manager 315, a tunneling control manager 320, a generic resource manager 340, and a resource pool 345. In a software implementation, instances of the media multiplexor 350, media demultiplexor 360, and admission control manager 315 may be created for each particular application/protocol needed to allow communications between terminals of the geographically diverse user communities. Importantly, it should be appreciated that the particular partitioning of functionality described with reference to this example is merely illustrative of one or many possible allocations of functionality.

According to the embodiment depicted, the resource manager 340 establishes and maintains one or more pre-established paths between the local media aggregation manager and one or more remote media aggregation managers. The resource manager 340 optionally interfaces with a centralized entity, e.g., the media director, to obtain pre-allocated bandwidth. The media director may also provide information relating to the characteristics and estimated amount of resources needed for the pre-allocated path. Alternatively, a network administrator may provide information to the resource manager 340 relating to desired characteristics of the pre-allocated path. The resource manager 340 also tracks active application sessions for each pre-established path and the current availability of resources for each path in the resource pool 345.

The tunneling control manager 320 interfaces with the media encryptor 350 and one or more other remote tunneling control managers (RTCMs) associated with other user communities to agree upon encryption, such as Message Digest 5 (MD5), RSA Data Encryption Standard (DES) or other encryption standard, key management, and/or a tunneling protocol to be employed for a particular application session, such as existing or future versions of the IP Security (IPSec) Protocol, generic routing encapsulation (GRE), Layer 2 Forwarding (L2F), Layer 2 Tunneling Protocol (L2TP), or the Point-to-Point Tunneling Protocol (PPTP).

The media encryptor 355 receives media packets from the local terminals (not shown) and selectively encrypts the media packets for exchange with the media decryptor 365 of the remote media aggregation manger as previously agreed upon by the participating tunneling control managers based upon the application session with which the media packets are associated. In this manner, security may be configured on an application session basis (e.g., a call-by-call basis).

The admission control manager 315 interfaces with local terminals (not shown) associated with a particular user community, the media multiplexor 350, the resource manager 340, and one or more other remote media aggregation managers associated with other user communities.

The media multiplexor 350 receives selectively encrypted media packets from the media encryptor 355 and appropriately translates/encapsulates the packets for communication with the media demultiplexor 360 of the remote media aggregation manger in accordance with the aggregation technique described further below. When application flows are established and terminated, the admission control manager 315 interfaces with the resource manager 340 to allocate and deallocate resources, respectively.

The media demultiplexor 360 interfaces with the media decryptor 365 to supply the media decryptor 365 with the selectively encrypted media packets by demultiplexing the respective application flows from the pre-established path. The media decryptor 365 then decrypts the media packets, if necessary, and forwards them to the appropriate local terminals (not shown).

The admission control manager 315 exchanges admission control signaling messages with remote admission control managers and configures the local application/endpoint (LA) to send media to transmitted to the local media aggregation manager after an application session has been established with a remote media aggregation manager. For VoIP using the H.323 protocol, the admission control manager 315 may include RAS, call control, and call signaling processing.

When application flows are established and terminated, the admission control manager 315 interfaces with the resource manager 340 to allocate and deallocate resources, respectively.

In operation, two resource managers cooperate to establish a path between a local media aggregation manager (LMAM) and a remote media aggregation manager (RMAM). The resource managers may interact with the media director to pre-allocate bandwidth sufficient to accommodate the anticipated load offered by applications that need to communicate over the path. Subsequently, a local media encryptor (LME) associated with the LMAM provides admission control for application flows between one or more terminals of the LMAM and the RMAM with the assistance of the local and remote admission control managers and the local and remote resource managers. If sufficient resources are available over the pre-established path, then the LME selectively encrypts the application flows and the local media multiplexor (LMM) multiplexes the application flows for transmission over the path. On the receiving end, the remote media demultiplexor (RMDX) demultiplexes the application flows and sends them to their intended destinations through the remote media decryptor (RMD) which performs any necessary decryption. The typical admission control manager 315 will be a player in the path of the application protocol for setting up the connection between two or more application endpoints; hence, it may be instrumented to modify the path of the media packets to flow through the LME, LMM, the remote media encryptor (RME), and the remote media multiplexor (RMM).

In brief, after an application session has been associated with the pre-established path, the application/endpoints may use a transport protocol and/or a control protocol, such as RTP and/or RTCP to exchange potentially encrypted media packets between them. The media packets may carry various types of real-time data, such as voice, voice-band data, video, multi-media, or other data for human interactions or collaboration. Media packets from a data source are optionally encrypted by the local media encryptor 355, tagged by the local media multiplexor 350, and sent over the pre-established path to one or more media demultiplexors 360 corresponding to the data destination. As illustrated below, the media demultiplexor 360 strips the tag before the media packets are forwarded, the media decryptor 360 performs decryption processing, and then the tag information is used to determine the ultimate destination of the data packet.

A specific example of the use of this architecture is in connection with the use of the H.323 protocol for VoIP calls. Typically, an H.323 Gatekeeper is used by endpoints to help in address resolution, admission control etc. So, for the H.323 protocol, the gatekeeper is a convenient place for the media multiplexor 350 and/or media encryptor 355 to reside.

Note that in this description, in order to facilitate explanation, the media aggregation manager 300 is generally discussed as if it is a single, independent network device or part of single network device. However, it is contemplated that the media aggregation manager 300 may actually comprise multiple physical and/or logical devices connected in a distributed architecture; and the various functions performed may actually be distributed among multiple of such physical and/or logical devices. Additionally, in alternative embodiments, the functions performed by the media aggregation manager 300 may be consolidated and/or distributed differently than as described. For example, any function can be implemented on any number of machines or on a single machine. Also, any process may be divided across multiple machines. Specifically, the media multiplexor 350 and the media encryptor 355 may be combined as a single functional unit or the multiplexing and encrypting processing may be performed in the opposite order than described above. Similarly, the media demultiplexor 360 and the media decryptor 365 may be combined as a single functional unit or the demultiplexing and decrypting processing may be performed in the opposite order than described above, e.g., encryption may be performed before or after multiplexing. Finally, encryption may be performed at various levels of the application flow. For example, encryption may be performed on the media and/or control information directly, the media and/or control packets, or on multiplexed media and/or control packets.

Sharing Pre-Allocated Bandwidth and a Pre-Established Path Through a DiffServ Network Environment

In this example, it is assumed that a path through the DiffServ network environment has been previously established and the media aggregation managers have already requested bandwidth from the media director. The pre-allocated bandwidth preferably takes into consideration current network resources and estimated usage of network resources, such as bandwidth, based upon historical data. For example, the amount of pre-allocated resources may vary due to different loads being offered at different times of day and/or day of week.

FIG. 5 is a simplified, high-level flow diagram illustrating application session establishment processing according to one embodiment of the present invention. In the present example, application session establishment processing begins with processing block 510. At processing block 510, the requested resources are allocated to the application session. According to one embodiment, the local resource manager 340 creates a new application session entry, in the resource pool 345, containing an indication of the resources granted to the application session.

At decision block 520, a determination is made whether the desired remote application/endpoint is available to participate in the application session. If so, processing proceeds to processing block 530; otherwise, processing branches to processing block 560.

Assuming the desired remote application/endpoint is available to participate in the application session, then at processing block 530, the local application/endpoint and the remote application/endpoint are configured to send media packets associated with the application session to the local and remote media multiplexors, respectively.

At processing block 540, the local and remote media multiplexors and demultiplexors are configured in accordance with the application session. For example, as described further below, a lookup table may be maintained by the media multiplexor 350 or media demultiplexor 360 to translate the source network address of the local application/endpoint to the destination network address of the remote application/endpoint.

Finally, at processing block 550, the local and remote media encryptors 355 and decryptors 365 are configured in accordance with the desired level of security for the application session. Exemplary standards-based encryption options include Message Digest 5 (MD5), RSA Data Encryption Standard (DES), and Triple DES encryption. Exemplary tunneling options include the IP Security (IPSec) Protocol, generic routing encapsulation (GRE), Layer 2 Forwarding (L2F), Layer 2 Tunneling Protocol (L2TP), or the Point-to-Point Tunneling Protocol (PPTP).

FIG. 6 illustrates interactions among local and remote media aggregation manager functional units according to one embodiment of the present invention. In general, the media aggregation managers abstract the true application session endpoints from each other and serve as proxies for their respective local applications/endpoints. The media aggregation managers accomplish this by intercepting messages originating from their respective local applications/endpoints and modifying the messages to make themselves appear as the actual application flow originators/recipients.

In this example, for simplicity, it is assumed that a single local application/endpoint (LA) is establishing an application session with a single remote application/endpoint (RA) over a pre-allocated path between a local media aggregation manager (LMAM) associated with the LA and a remote media aggregation manager (RMAM) associated with the RA.

The LA transmits a request to connect to the RA to the LMAM (670). The LACM inquires of the local resource manager (LRM) whether sufficient resources are currently available to accommodate the LA's request (672). The LRM indicates the availability or inavailability of available resources to the LACM (674).

Assuming sufficient resources are available in the pre-allocated bandwidth provided by the media director to accommodate the resources the LA needs for the requested connection to the RA, then the LACM asks the RACM if the RA is available (676). In response to the LACM's request, the RACM queries the RA to determine its present availability (678). The RA indicates whether or not it is currently available to participate in an application session (680).

Assuming the RA indicates that it is available, then the RACM communicates the RA's availability to the LACM (682). In response to the availability of the RA, the LACM directs the RACM to proceed with establishment of a connection between the LA and RA.

Having determined that a connection is feasible, the LACM and RACM proceed to configure their media multiplexors and media demultiplexors for the LA-RA connection. The LACM configures the local media multiplexor (LMM) to tag media originated from the LA for routing to the RA and to send the resulting encapsulated media packets to the remote media demultiplexor (RMDX) (686). The LACM further configures the local media demultiplexor (LMDX) to forward media packets that are received from the RMM and tagged as being associated with the LA-RA connection to the LA (690).

Similarly, the RACM configures the remote media demultiplexor (RMDX) to forward media packets that are received from the LMM and tagged as being associated with the LA-RA connection to the RA (688). The RACM also configures the remote media multiplexor (RMM) to tag media originated from the RA for routing to the LA and to send the resulting encapsulated media packets to the local media demultiplexor (LMDX) (692).

Once the media multiplexors and media demultiplexors have been appropriately configured for the LA-RA connection, the LACM and the RACM inform their application/endpoints to commence transmission of media to the LME and the RME, respectively 694 and 696. Thus, the media aggregation managers appear to their respective application/endpoints as the actual application flow originators/recipients and subsequently serve as proxies for their respective application/endpoints.

During media transmission between the LA and the RA 698 and 699, media packets originated by the LA are sent to the LME for optional encryption, then to the LMM, which encapsulates the media packets by appending a tag appropriate for the LA-RA connection and forwards the encapsulated packets over the path 697 to the RMDX. The RMDX determines the RA is the intended destination based upon the tag, removes the tag, and forwards the media packet to the RA via the RMD. Media packets originated by the RA are sent to the RME which performs encryption then to the RMM which encapsulates the media packets by appending a tag appropriate for the LA-RA connection and forwards the encapsulated packets over the pre-established path 697 to the LMDX. The LMDX determines the LA is the intended destination based upon the tag, removes the tag, and forwards the media packet to the LA via the local media decryptor (LMD).

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.