WO2002013023A1 - Multiplexage de plusieurs sessions individuelles d'applications sur une session de protocole de reservation pre-allouee dans un systeme vocal sur internet (voip) - Google Patents

Multiplexage de plusieurs sessions individuelles d'applications sur une session de protocole de reservation pre-allouee dans un systeme vocal sur internet (voip) Download PDF

Info

Publication number
WO2002013023A1
WO2002013023A1 PCT/US2001/024878 US0124878W WO0213023A1 WO 2002013023 A1 WO2002013023 A1 WO 2002013023A1 US 0124878 W US0124878 W US 0124878W WO 0213023 A1 WO0213023 A1 WO 0213023A1
Authority
WO
WIPO (PCT)
Prior art keywords
media
session
media aggregation
reservation protocol
application
Prior art date
Application number
PCT/US2001/024878
Other languages
English (en)
Inventor
Shiddharta Nag
Alfred D'souza
Naveed Alam
Rakesh Patel
Original Assignee
Prominence Networks, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/689,222 external-priority patent/US7886054B1/en
Application filed by Prominence Networks, Inc. filed Critical Prominence Networks, Inc.
Priority to AU2001290525A priority Critical patent/AU2001290525A1/en
Publication of WO2002013023A1 publication Critical patent/WO2002013023A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/745—Reaction in network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/822—Collecting or measuring resource availability data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/828—Allocation of resources per group of connections, e.g. per group of users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/83—Admission control; Resource allocation based on usage prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer

Definitions

  • the invention relates generally to managing flows for a reservation protocol. More particularly, the invention relates to a technique for pre-allocating an aggregated reservation protocol session and thereafter sharing the reservation protocol session among multiple individual application sessions by multiplexing the multiple individual application flows thereon.
  • the present invention also relates to management of a Voice Over Internet Protocol (VoIP) network via a novel Graphical User Interface (GUI) that enables a system manager to initialize, based on predicted link utilization, a plurality of routers and media aggregation managers existing on a selected communication path. The initialization provides the media aggregation managers with reservation protocol session parameters and bandwidth allocation requirements for a predetermined schedule of usage over the VoIP network.
  • VoIP Voice Over Internet Protocol
  • GUI Graphical User Interface
  • VoIP voice over Internet Protocol
  • VoIP voice over Internet Protocol
  • bandwidth reservation protocols require per-flow state information to be maintained at each intermediate node between the initiator and the prospective recipient.
  • RSVP Resource Reservation Protocol
  • IP Internet Protocol-
  • RSVP Internet Protocol-
  • the Path message causes state information, such as information regarding the reverse path to the imtiator, to be stored in each node along the way.
  • the prospective recipient of the VoIP call initiates resource reservation setup by communicating its requirements to an adjacent router via an upstream Resv message.
  • the prospective recipient may communicate a desired quality of service (QoS), e.g., peak/average bandwidth and delay bounds, and a description of the data flow to all intervening routers between the call participants.
  • QoS quality of service
  • participating routers must continue to exchange periodic status and control messages to maintain the reservation. Consequently, processing and storage overhead associated with reservation establishment and maintenance increases linearly as a function of the number of calls.
  • RSVP Resource Reservation Protocol
  • a pre-allocated reservation protocol session is shared by one or more individual application sessions.
  • the reservation protocol session is preallocated over a path between a first network device associated with a first user community and a second network device associated with a second user community based upon an estimated usage of the path for individual application sessions between users of the first and second user communities.
  • the one or more individual application sessions are dynamically aggregated by multiplexing application flows associated with the one or more individual application sessions onto the pre-allocated reservation protocol session at the first network device and demultiplexing at the second network device.
  • a network device enables multiple applications to share an aggregated reservation protocol session.
  • the network device includes a storage device having stored therein one or more routines for establishing and managing the aggregated reservation protocol session.
  • a processor coupled to the storage device executes the one or more routines to pre-allocate the aggregated reservation protocol session and thereafter share the aggregated reservation protocol session among multiple application sessions of individual application sessions.
  • the aggregated reservation protocol session is pre-allocated based upon an estimate of the bandwidth requirements to accommodate the multiple application sessions.
  • the aggregated reservation protocol session is shared by multiplexing, onto the aggregated reservation protocol session, outbound media packets originated by local application endpoints associated with the application sessions, and demultiplexing, from the aggregated reservation protocol session, inbound media packets originated by remote application/endpoints.
  • a method of conveying information about a VoIP network to a user comprises: discovering a plurality of nodes on a VoIP network wherein the plurality of nodes includes a media aggregation manager that provides application/protocol specific multiplexing/demultiplexing of media traffic onto a pre-allocated reservation protocol session; and graphically depicting representations of the plurality of nodes and their interconnections on a network map, wherein the representations of the plurality of media aggregation managers are visually distinguishable from the remainder of the plurality of nodes.
  • a graphical user interface displays graphical representations of a first media aggregation manager and second media aggregation manager.
  • the first and second media aggregation managers serve as reservation session aggregation points between a first user community and a second user community and have a plurality of physical paths through which media packets may be exchanged by way of one or more packet forwarding devices.
  • the GUI displays a first projected link utilization based upon an indication that a first path of the plurality of physical paths will be used to convey media packets between the first and second media aggregation managers.
  • the GUI also displays a second projected link utilization based upon an indication that a second path of the plurality of physical paths will be used to convey media packets between the first and second media aggregation managers.
  • a method comprising: in response to a discovery request, discovering nodes on a network; identifying and graphically displaying the nodes and their interconnections on a map; receiving inputs including a first node, a second node and projected bandwidth traffic requirement between the first node and the second node; and displaying the projected bandwidth traffic requirement for the nodes.
  • a graphical user interface comprising: a display portion that graphically depicts and identifies a plurality of nodes on a network, wherein the plurality of nodes includes a plurality of media aggregation managers that provide application/protocol specific multiplexing/demultiplexing of media traffic onto a pre-allocated reservation protocol session, and wherein the plurality of media aggregation managers are distinguishable from other nodes on the network.
  • a method comprising: receiving a first input indicating a first media aggregation manager; receiving a second input indicating a second media aggregation manager; receiving a third input indicating a projected utilization between the first media aggregation manager and the second media aggregation manager; displaying a prioritized plurality of paths between the first media aggregation manager and the second media aggregation manager that satisfy the projected utilization; and receiving a fourth input indicating a selected path of the plurality of paths.
  • Figure 1 conceptually illustrates interactions between two media aggregation managers according to one embodiment of the present invention.
  • Figure 2 is an example of a network device in which one embodiment of the present invention may be implemented.
  • Figure 3 is a high-level block diagram of a media aggregation manager according to one embodiment of the present invention.
  • Figure 4 is a simplified, high-level flow diagram illustrating media aggregation 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.
  • Figure 6 illustrates interactions among local and remote media aggregation manager functional units according to one embodiment of the present invention.
  • FIG. 7 is a flow diagram illustrating Registration, Admission, Status (RAS) signaling processing according to one embodiment of the present invention.
  • RAS Registration, Admission, Status
  • Figure 8 is a flow diagram illustrating call signaling processing according to one embodiment of the present invention.
  • Figure 9 is a flow diagram illustrating control signaling processing according to one embodiment of the present invention.
  • Figure 10 is a flow diagram illustrating media control transmission multiplexing processing according to one embodiment of the present invention.
  • Figure 11 is a flow diagram illustrating media/control reception demultiplexing processing according to one embodiment of the present invention.
  • Figure 12 conceptually illustrates application session establishment in an H.323 environment according to one embodiment of the present invention.
  • Figure 13 A illustrates the encapsulated ("MUX") packet format according to one embodiment of the present invention in which address replacement is performed by the LMAM.
  • Figure 13B illustrates media transmission in both directions according to the encapsulated packet format of Figure 13 A.
  • Figure 14A illustrates the encapsulated ("MUX") packet format according to another embodiment of the present invention in which address replacement is performed by the RMAM.
  • Figure 14B illustrates media transmission in both directions according to the encapsulated packet format of Figure 14A.
  • Figure 15 illustrates an initialization control GUI in communication with a plurality of media aggregation Managers according to one embodiment of the present invention.
  • Figure 16 is a menu of available screens for the initialization GUI according to one embodiment of the present invention.
  • Figure 17 is a flow diagram illustrating a typical user navigation flow through the initialization process according to one embodiment of the present invention.
  • Figures 18 is a screen used for de-allocation of the media aggregation managers according to one embodiment of the present invention.
  • Figure 19 illustrates a network map interface according to one embodiment of the present invention.
  • Figure 20 illustrates a property window associated with a node according to one embodiment of the present invention.
  • Figure 21 illustrates a bandwidth allocation screen according to one embodiment of the present invention.
  • Figure 22 illustrates a BW on Link screen showing a utilization schedule for a selected node on the discovered network according to one embodiment of the present invention.
  • Figure 23 is a flow chart indicating the process of analysis for a selected path according to one embodiment of the present invention.
  • Figure 24 is a flow chart indicating the process of initializing the selected media aggregation managers according to one embodiment of the present invention.
  • Apparatus and methods are described for multiplexing application flows over a preallocated bandwidth reservation protocol session and initializing, allocating and deallocating reservation protocol sessions between a plurality of media aggregation managers.
  • embodiments of the present invention seek to provide a scalable architecture that enables efficient provisioning of reserved bandwidth for multiple application flows by multiplexing individual application flows over a pre-allocated reservation protocol session.
  • embodiments of the present invention seek to provide a graphical user interface (GUT) that enables a user to allocate and de-allocate bandwidth and reservation protocol sessions between a plurality of media aggregation managers along a path containing a plurality of routers.
  • GUT graphical user interface
  • the pre-allocated reservation protocol session 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. Additionally, the pre-allocated reservation protocol session may be dynamically adjusted to account for actual usage that surpasses the estimated usage or actual usage that falls below the estimated usage.
  • Allocation and de-allocation of bandwidth and reservation protocol sessions between a plurality of media aggregation managers along a path containing a plurality of routers is facilitated by allowing the user to analyze various repercussions of increasing/decreasing the user demand over various paths on a Voice over Internet Protocol (VoIP) network and viewing the bandwidth effects at all nodes on the path for a schedule that varies based on usage variations at various times of the day, week, month or year.
  • VoIP Voice over Internet Protocol
  • a more intelligent approach is employed in connection with initiation and maintenance of a large number of reservations.
  • a single reservation protocol session may be pre-allocated and subsequently dynamically shared among the application flows by aggregating the associated media packets and transmitting them over a multiplexed media stream.
  • VoIP services may be provided between many different user communities using pre-allocated RS VP sessions between pairs of distributed media aggregation managers.
  • the media aggregation managers multiplex outbound voice packets onto the pre-allocated RSVP session and demultiplex inbound voice packet received over the pre-allocated RSVP session, thereby sharing a common RSVP session and reducing the computational resources required by the network to provide real-time response for multiple application flows.
  • reservation protocols such as RSVP
  • One benefit of the graphical user interface of the present invention is that it allows a system administrator to adjust bandwidth allocation requirements for a plurality of users communicating between a plurality of locations based on historical and current utilization demands by allowing allocation and de- allocation of bandwidth reservations between a plurality of media aggregation managers. Additionally, another advantage of the present invention is that the GUI allows a user, by selecting a path, to initialize multiple routers along the path simultaneously without having to individually provision each router.
  • the present invention addresses the inadequacy of current network management tools by providing a GUI for discovering a VoIP network, including the media aggregations managers residing on the VoIP network and allowing a user, based on predicted usage requirements, to initialize the media aggregation managers and the routers included on a selected path for a predetermined schedule.
  • a VoIP network containing a plurality of media aggregation managers is discovered and then displayed.
  • the user may review individual properties for each of the nodes displayed on a network map. For example, the user may select two media aggregation managers for inter-communication analysis along with a predicted community demand of resources between the two selected media aggregation managers.
  • the GUI displays a prioritized list of potential paths between the selected media aggregation managers including one or more routers for the communities to use in communicating between the media aggregation managers. Additionally, the user may select a path for an analysis of the effect of allocating the predicted bandwidth to a reservation protocol session between the selected media aggregation managers.
  • the graphical user interface displays a predicted schedule of bandwidth traffic for any node on the network incorporating the predicted pre-allocated bandwidth that is being considered for allocation between the media aggregation managers. Based on the displayed data, the user may decide to allocate the bandwidth for all of the routers and media aggregation managers along the selected path, change paths, de-allocate bandwidth between these or other media aggregation managers or reduce/restrict the predicted community usage on a selected path.
  • the present invention includes various steps, which will be described below.
  • the steps of the present invention 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.
  • the steps may be performed by a combination of hardware and software.
  • 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 according to the present invention.
  • the machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnet Or optical cards, flash memory, or other type of media / machine-readable medium suitable for storing electronic instructions.
  • 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).
  • a communication link e.g., a modem or network connection
  • Session Initiation Protocol may be employed to create, modify, and terminate application sessions with one or more participants.
  • SIP Session Initiation Protocol
  • M. Handley et al. "SIP: Session Initiation Protocol," RFC 2543, Network Working Group, March 1999, which is hereby incorporated by reference.
  • embodiments of the present invention are described with reference to a specific application (i.e., VoIP) in which individual flows may be multiplexed over a pre-allocated bandwidth reservation protocol session.
  • VoIP Voice over IP
  • present invention is equally applicable to various other applications 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 the like.
  • a "media aggregation manager” may generally be thought of as a network device, 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 onto a pre-allocated reservation protocol session.
  • a “reservation protocol” generally refers to a protocol that may be employed to communicate information regarding a desired level of service for a particular application flow.
  • An example of an existing bandwidth reservation protocol is RSVP.
  • a “community” or “user community” generally refers to a group of users/residents residing on a common network at a given location. 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.
  • ISP Internet service provider
  • a "reservation protocol session” generally refers to a set of reserved network resources established and maintained between two or more network devices that serve as proxies for application endpoints residing behind the proxies.
  • An example, of a reservation protocol session is an RSVP session between two media aggregation managers.
  • an "application session” generally refers to a session established and maintained between two or more terminals.
  • one or more application sessions may be multiplexed onto a single reservation protocol session thereby reducing the overhead for establishing and maintaining multiple application sessions.
  • Total available bandwidth refers to the amount of bandwidth accessible for any given router or could refer to the maximum available bandwidth of the most limiting node on a path between two selected nodes and their intervening nodes.
  • the "available communication bandwidth” encompasses the amount of bandwidth accessible for the desired type of communication to be reserved in any reservation protocol session. For instance, in one embodiment, the user may wish to allocate reservation protocol sessions for VoIP communication. In one case, 75% of the total available bandwidth may be the available communication bandwidth for VoIP type communications and a reservation protocol session initialized for 100 users between two media aggregation managers may only require 10% of the available communication bandwidth.
  • a “terminal” generally refers to a LAN-based endpoint for media transmission, such as voice transmission. Terminals may be capable of executing one or more networked applications programs. An example of a terminal would be a computer system running an Internet telephony apphcation, such as CoolTalk or NetMeeting.
  • an “apphcation” 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 “apphcation 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 data transmitted over a network.
  • 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 reservation protocol session to transmit encapsulated packets to the appropriate remote application/endpoint (RA).
  • a tag includes address information, such as the destination network address of the terminal upon which the destination application/endpoint resides.
  • 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 reservation protocol session as well by including protocol dependent control information.
  • 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.
  • two layers of multiplexing maybe 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.
  • FIG. 1 conceptually illustrates interactions between two media aggregation managers 110 and 120 according to one embodiment of the present invention.
  • the media aggregation managers 110 and 120 act as reservation protocol proxies on behalf of the terminals 111, 112, 121, and 122.
  • the media aggregation managers 110 and 120 establish and maintain a reservation session, such as an RSVP session, between each other by exchanging reservation signaling messages 160.
  • the media aggregation managers 110 and 120 respond to reservation requests from the terminals 111, 112, 121, and 122 by dynamically allocating the reserved resources, such as bandwidth, associated with the reservation protocol session to corresponding application sessions. In this manner, multiple application sessions may share the reservation session by multiplexing media packets onto the reservation session as described further below.
  • a multiplexed media/control stream 170 is established using admission control signaling messages 130.
  • the multiplexed media/control stream 170 is carried over the pre-allocated reservation session between media aggregation manager 110 and media aggregation manager 120.
  • the multiplexed media/control stream 170 represents one way to handle certain transport and control protocol combinations, such as RTP and RTCP, that use different channels or ports for control and data.
  • the reservation protocol session 160 may not need to distinguish between control and data..
  • the media aggregation managers 110 and 120 are discussed as if they are autonomous network edge devices, it should be kept in mind that 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 only a single aggregated reservation protocol session between two media aggregation managers 110 and 120 is described in connection with the present example, it should be appreciated that each media aggregation manager 110 and 120 may support multiple, heterogeneous reservation protocol sessions capable of providing heterogeneous application flows among multiple user communities. Importantly, according to embodiments of the present invention, regardless of the number of terminals or application/endpoints, application flows may be provided with reserved bandwidth between any and all pairs of terminals of N user communities by establishing and sharing no more than N 2 reservation protocol sessions.
  • the network device 200 comprises a bus or other communication means 201 for communicating information, and a processing means such as one or more processors 202 coupled with bus 201 for processing information.
  • Networking device 200 further comprises a random access memory (RAM) or other dynamic storage device 204 (referred to as main memory), coupled to bus 201 for storing information and instructions to be executed by ⁇ rocessor(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.
  • Network device 200 also comprises a read only memory (ROM) and/or other static storage device 206 coupled to bus 201 for storing static information and instructions for processor 202.
  • ROM read only memory
  • static storage device 206 coupled to bus 201 for storing static information and instructions for processor 202.
  • a data sto ⁇ age device (not shown), such as a magnetic disk or optical disc and its corresponding drive, may also be coupled to bus 201 for storing information and instructions.
  • One or more communication ports 225 may also be coupled to bus 201 for allowing various local terminals, remote terminals and/or other network devices to exchange information with the network device 200 by way of a Local Area Network (LAN), Wide Area Network (AN), Metropolitan Area Network (MAN), the Internet, or the public switched telephone network (PSTN), for example.
  • the communication ports 225 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 interfaces, such as Asynchronous Transfer Mode (ATM) ports and other interfaces commonly used in existing LAN, WAN, MAN network environments.
  • ATM Asynchronous Transfer Mode
  • FIG. 3 is a high-level block diagram of a media aggregation manager according to one embodiment of the present invention.
  • a media aggregation manager By interconnecting a plurality of distributed media aggregation managers, such as media aggregation manger 300, an architecture is provided for multiplexing several apphcation flows (e.g., VoIP calls) over a pre-allocated reservation protocol session, such as a pre-allocated RSVP pipe.
  • the multiplexing of application flows reduces the computational resources required by the network to provide reserved bandwidth, e.g., guaranteed bandwidth, for multiple application flows.
  • the source media aggregation manager receives media packets from its local terminals and transmits multiplexed media to the destination aggregation manager.
  • the destination aggregation manager receives the multiplexed media and routes media packets to the appropriate terminal(s) of its local terminals.
  • the media aggregation manger 300 includes an application/protocol specific media multiplexor 350, an application protocol specific media demultiplexor 360, an admission control manager 315, a generic resource manager 340, and a resource pool 345.
  • 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.
  • the particular partitioning of functionality described with reference to this example is merely illustrative of one or many possible allocations of functionality.
  • the resource manager 340 establishes and maintains one or more pre-allocated reservation protocol sessions between the local media aggregation manager and one or more remote media aggregation managers.
  • the resource manager 340 optionally interfaces with a centralized entity (not shown) that provides information relating to the characteristics and estimated amount of resources for the preallocated reservation protocol sessions.
  • a network administrator may provide information to the resource manager 340 relating to desired characteristics of the pre-allocated reservation protocol sessions.
  • the resource manager 340 also tracks active application sessions for each reservation protocol session and the current availability of resources for each reservation protocol session in the resource pool 345.
  • 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 hides the details of how reserved resources are internally allocated and managed, thereby allowing the local terminals to use existing reservation protocols, such as RSVP, without change.
  • the media multiplexor 350 receives media packets from the local terminals and appropriately translates/encapsulates the packets in accordance with the aggregation technique described further below.
  • the admission control manager 315 interfaces with the resource manager 340 to allocate and deallocate resources, respectively.
  • the media demultiplexor 360 interfaces with the local terminals to supply with media packets by demultiplexing their respective application flows from the pre-allocated reservation protocol session.
  • 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 the media multiplexor 350 after an application session has been established with a remote media aggregation manager.
  • the admission control manager 315 may include RAS, call control, and call signaling processing.
  • two resource managers cooperate to establish a pre-allocated reservation protocol session between a local media aggregation manager (LMAM) and a remote media aggregation manager (RMAM).
  • the resource managers make a reservation that is large enough to accommodate the anticipated load offered by applications that need to communicate over the reservation protocol session.
  • a local media multiplexor (LMM) 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, such as bandwidth, are available over the pre-allocated reservation protocol session, then the local media multiplexor multiplexes the application flows over the pre-allocated reservation protocol session.
  • the remote media demultiplexor demultiplexes the application flows and sends them to their intended destinations.
  • 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 LMM and remote media multiplexor (RMM).
  • the application/endpoints may use a transport protocol and/or a control protocol, such as RTP and or RTCP to exchange media packets between them.
  • the media packets may carry various types of real-time data, such as voice, video, multimedia, or other data for human interactions or collaboration.
  • Media packets from a data source are tagged by the local media multiplexor 350 and sent over the reserved path to one or more media demultiplexers 360 corresponding to the data destination. As illustrated below, the media demultiplexor 360 strips the tag before the media packets are forwarded and uses the tag information to determine the eventual destination of the data packet.
  • the media aggregation manger 300 shares the pre-allocated reservation protocol session among multiple application flows.
  • 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 to reside.
  • 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 network 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.
  • FIG. 4 is a simplified, high-level flow diagram illustrating media aggregation processing according to one embodiment of the present invention.
  • the processing blocks described below may be performed under the control of a programmed processor, such as processor 202.
  • the processing blocks may be fully or partially implemented by any programmable or hard-coded logic, such as Field Programmable Gate Arrays (FPGAs), TTL logic, or Application Specific Integrated Circuits (ASICs), for example.
  • FPGAs Field Programmable Gate Arrays
  • TTL logic TTL logic
  • ASICs Application Specific Integrated Circuits
  • the pre-allocated reservation protocol session 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.
  • the media aggregation manager 300 determines the type of event that has occurred. If the event represents the receipt of an application session establishment request from a local terminal, then processing proceeds to decision block 420. If the event represents the receipt of media packets from a local application/endpoint, then processing continues with decision block 450. If the event represents the receipt of a media packet from a remote application/endpoint, then control passes to processing block 460. If the event represents the receipt of an application session termination request, then processing continues with processing block 470.
  • media packets received from a local apphcation/endpoint are tagged and sent over the network to the destination using the previously reserved resources (e.g., the pre-allocated reservation protocol session).
  • the previously reserved resources e.g., the pre-allocated reservation protocol session.
  • media packets received from a remote application endpoint are forwarded to the appropriate local application/endpoint.
  • the packets maybe sent to the appropriate local apphcation/endpoint based upon an examination of the tag information added by the remote media aggregation manager.
  • resources allocated to this application session are relinquished and made available for other application sessions.
  • the resource manager 340 may update an indication of available resources in the resource pool 345 for the pre-allocated reservation protocol session associated with the terminated application session.
  • FIG. 5 is a simplified, high-level flow diagram illustrating apphcation session establishment processing according to one embodiment of the present invention.
  • application session establishment processing begins with processing block 510.
  • the requested resources are allocated to the application session.
  • 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.
  • decision block 520 a determination is made whether the desired remote application/endpoint is available to participate in the apphcation session. If so, processing proceeds to processing block 530; otherwise, processing branches to processing block 560.
  • 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.
  • the local and remote media multiplexors and demultiplexors are configured in accordance with the apphcation 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.
  • Figure 6 illustrates interactions among local and remote media aggregation manager functional units according to one embodiment of the present invention.
  • 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.
  • LA local application/endpoint
  • RA remote apphcation/endpoint
  • LMAM local media aggregation manager
  • RMAM remote media aggregation manager
  • 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).
  • the LACM asks the RACM if the RA is available (676).
  • 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).
  • the RACM communicates the RA's availability to the LACM (682).
  • the LACM directs the RACM to proceed with establishment of a connection between the LA and RA.
  • 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 (RMD) (686).
  • the LACM further configures the local media demultiplexor (LMD) to forward media packets that are received from the RMM and tagged as being associated with the LA-RA connection to the LA (690).
  • the RACM configures the remote media demultiplexor (RMD) 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 (LMD) (692).
  • RMD remote media demultiplexor
  • LMD local media demultiplexor
  • the LACM and the RACM inform their application/endpoints to commence transmission of media to the LMM and the RMM, respectively.
  • 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.
  • media packets originated by the LA are sent 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 pre-allocated reservation protocol session 690 to the RMD.
  • the RMD determines the RA is the intended destination based upon the tag, removes the tag, and forwards the media packet to the RA.
  • Media packets originated by the RA are sent to the RMM, which encapsulates the media packets by appending a tag appropriate for the LARA connection and forwards the encapsulated packets over the pre-allocated reservation protocol session 690 to the LMD.
  • the LMD determines the LA is the intended destination based upon the tag, removes the tag, and forwards the media packet to the LA.
  • H.323 is basically an umbrella that covers several existing protocols, including but not limited to H.225.0, and H.245.
  • the later two protocols are used to establish call connection, and capability information between two endpoints. Once this information is exchanged, the endpoints may use RTP and RTCP to exchange voice (and multi-media) information between them.
  • H.323 suggests that RTP/RTCP should be established between two endpoints (caller/receiver) for each call. Consequently, in order to provide Quahty Of Service (QoS) for each call using a protocol like RSVP would mean that every endpoint pair (caller/receiver) for every H.323 call would need to establish RSVP between one another. This would create a huge amount of overhead on the endpoint and adversely affect network resources as RSVP "soft states" must be maintained for the life of the call. This quickly becomes a tremendous scalability issue, since as number of simultaneous calls increase, so do the RSVP "soft state” maintenance messages between endpoints, and every router involved in the transmitting RTP/RTCP data stream.
  • QoS Quahty Of Service
  • the media aggregation manager 300 described herein seeks to provide a clean, and scalable solution for this problem, while providing the same QoS as if two individual endpoints had used a reservation protocol session, such as RSVP, between them.
  • a reservation protocol session such as RSVP
  • the H.323 endpoints callers/receivers
  • the media aggregation managers establish one or more RSVP "pipes" between them that can accommodate several (expected) voice calls.
  • RSVP pipes are created as the media aggregation managers are started and the RSVP pipes are maintained between them. This immediately reduces the amount of RSVP state processing in the network.
  • the RSVP pipes between media aggregation managers may be created based upon an educated estimate of the number of calls that are expected between user communities being managed by these media aggregation managers. Since RSVP by nature is established between a specific IP address/port pair and since the pipes are pre-created between media aggregation managers, all voice traffic (RTP/RTCP) originates and terminates between media aggregation managers at the media multiplexor 350 and the media demultiplexor 360, respectively.
  • the "local" media aggregation manager appears to an H.323 voice application caller as its intended receiver.
  • the H.323 endpoints make calls to the media multiplexors of the local media aggregation managers without realizing the local media aggregation managers are not really the final destination.
  • the local media aggregation manager calls the remote media aggregation manager and passes the RTP RTCP voice data to it.
  • the remote media aggregation manager receives the voice data and sends it the "real" receiver while hiding all mutiplexing details from both the caller and the receiver.
  • this solution serves as a surrogate to route calls over the pre- created RSVP pipes elirninating QoS processing by endpoints, without any deviations from each involved standard protocol.
  • FIG. 7 a flow diagram illustrating exemplary Registration, Admission, Status (RAS) signaling processing will now be described.
  • the appropriate processing path is determined based upon the triggering event. If the event is a request for a terminal's signaling address then processing proceeds to decision block 720. If the event represents a signaling address response, then control flow branches to processing block 750. However, if the event is a new call request, then processing continues with decision block 760.
  • RAS Registration, Admission, Status
  • the media aggregation manager 300 requests the call signaling address from an appropriate remote media aggregation manager.
  • the local media aggregation manager may transmit a multicast message or a directed broadcast to locate the appropriate remote media aggregation manager that services the desired terminal.
  • the media aggregation manager 300 returns its own signaling address rather than the signaling address of the locally serviced terminal. In this manner, subsequent call signaling and control signaling is routed through the local media aggregation manager rather than letting the locally service terminal handle this signaling directly.
  • the media aggregation manager 300 in response to a signaling address response, returns its signaling address in place of the signaling address of the locally serviced terminal to abstract call and control signaling from the locally serviced terminal.
  • the media aggregation manager 300 returns an indication that the new call can be accepted.
  • the media aggregation manager 300 returns direction to reject the new call.
  • Figure 8 is a flow diagram illustrating call signaling processing according to one embodiment of the present invention.
  • the appropriate processing path is determined based upon the event that has triggered the call signaling processing tread. If the event is a local call connect request, the processing proceeds to processing block 820. If the event represents a remote call connect request, then control flow branches to processing block 830. If the event is a local alerting call or proceeding connect message, then processing continues with processing block 840. However, if the event is a remote alerting/call or proceeding/connect message, the processing proceeds with processing block 850.
  • the media aggregation manager 300 accepts the call from the local terminal and calls the remote media aggregation manager that services the destination terminal. In this manner, the local media ag regation manager poses as the intended receiver to its local terminals that are callers.
  • the media aggregation manager 300 accepts the call from the remote media aggregation manager and calls the intended recipient, e.g., on of the terminals serviced by the local media aggregation manager. In this manner, the local media aggregation manager poses a caller to its local terminals that are receivers.
  • the local media aggregation manager relays the message to the appropriate remote media aggregation manager(s).
  • the local media aggregation manager relays the message to the appropriate local terminal(s).
  • call signaling is complete and control protocol signaling (e.g., H.245) can begin.
  • Figure 9 is a flow diagram illustrating control signaling processing according to one embodiment of the present invention.
  • the appropriate processing path is determined based upon the event that has triggered the control signaling processing tread. If the event is receipt of a master/slave and capability exchange from a local application/endpoint, the processing proceeds to processing block 920. If the event represents receipt of a master/slave and capability exchange from a remote media aggregation manager, then control flow branches to processing block 930. If the event is receipt of logical channel information from a local application/endpoint, then processing continues with processing block 940. However, if the event is reception of logical channel information from a remote media aggregation manager, the processing proceeds with processing block 950.
  • the master/slave and capability exchange is transmitted to the remote media aggregation manager.
  • the master/slave and capability exchange is transmitted to the local application/endpoint.
  • the logical channel information from the local application/endpoint is stored in anticipation of making a connection with the media and/or control channels of the local application/endpoint.
  • the LMAM forwards its own logical channel information to the RMAM. Additionally, the network address of the LA is sent to the RMAM.
  • the network address of the RA is stored in a lookup table for address translation and the logical channel information of the LMAM is forwarded to the LA.
  • Figure 10 is a flow diagram illustrating media/control transmission multiplexing processing according to one embodiment of the present invention.
  • the local media multiplexor reports the resources being consumed by the local application/endpoint to the local resource manager.
  • the media aggregation manager 300 connects to the media and/or control channels of the local apphcation/endpoint.
  • media and control data packets are generated by the local application/endpoint and received by the local media multiplexor.
  • the media multiplexor 350 takes packets coming from either the control or media channels of the local apphcation/endpoint and sends them to the appropriate remote media aggregation manager(s).
  • the media multiplexor 350 marks the outbound packets with appropriate address information (referred to as a "tag") for demultiplexing at the remote media aggregation manager.
  • the tag is typically appended to transport protocol packets, such as TCP or RTP packets, to allow the media multiplexor 350 to direct packets to the appropriate remote application/endpoint.
  • the tag includes address information, such as the destination network address associated with the remote application/endpoint.
  • the destination network address may be determined with reference to a lookup table that allows translation between the source network address associated with the local application/endpoint and the destination network address associated with the remote application/endpoint.
  • a lookup table may be maintained on the media demultiplexor 360 and the tag would include the source network address associated with the local application/endpoint. Then, the source network address would be used by the remote media demultiplexor to determine how to route the inbound packet to the appropriate remote application/endpoint.
  • each outbound packet may additionally be marked as control or data to allow the remote media aggregation manager to detennine the appropriate channel/port of the remote application/endpoint on which to forward the packet.
  • the marked packet is transmitted to the appropriate remote media aggregation manager(s).
  • FIG. 11 is a flow diagram illustrating media/control reception demultiplexing processing according to one embodiment of the present invention.
  • a packet is received from a remote media aggregation manager.
  • the demultiplexing information e.g., the tag
  • the demultiplexing information is stripped from the packet and examined at processing block 1120.
  • processing block 1130 if control and data packets are being multiplexed onto the reservation protocol session, a determination is made whether the packet is a media packet or a control packet based upon the tag.
  • the appropriate the local application(s)/endpoint(s) to which the packet is destined is/are determined.
  • the media multiplexor 350 may perform address translation from a source network address to a destination network address.
  • the media demultiplexor 360 determines the appropriate local application(s)/endpoint(s) that are to receive the packet by examining the address portion of the tag.
  • the media demultiplexor 360 determines the appropriate local application(s)/endpoint(s) by first translating the address portion using a local lookup table, for example.
  • the media demultiplexor 360 transmits the packet to those of the local application(s)/endpoint(s) identified in processing block 1140. If, according to the particular transport and/or control protocols employed, the application(s)/endpoint(s) receive media packets and control packets on different channels/ports, then the packet is forwarded onto the appropriate channel/port of the local application s)/er ⁇ dpoints(s) based on the packet classification performed at processing block 1130.
  • Figure 12 conceptually illustrates application session establishment in an H.323 environment according to one embodiment of the present invention.
  • 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 signaling messages originating from their respective local applications/endpoints and modifying the signaling messages to make themselves appear as the actual callers/recipients.
  • LA local application/endpoint
  • RA remote application/endpoint
  • LMAM local media aggregation manager
  • RMAM remote media aggregation manager
  • RAS signaling 1210 begins with a request for the RA signaling address 1211 by the LA to the LMAM.
  • the LMAM transmits the request 1211 via the reservation protocol session 1290 to the RMAM.
  • the RMAM decides it wants to route H.225/H.245 signaling through it instead of letting the RA do it directly. Therefore, the RMAM replies with a packet 1212 containing RMAM's signaling address.
  • the LMAM decides it wants to route H.225/H.245 signaling through it instead of letting the LA do it directly. Therefore, the LMAM substitutes its signaling address for that of the RMAM and forwards packet 1213 to the LA.
  • RAS signaling continues with the RA asking the RMAM (on its RAS channel) if it is okay to accept a new call by sending the RMAM a new call request 1231.
  • the RMAM authorizes the new call by responding with a packet 1231 giving the RA permission to accept the new call.
  • H.225 signaling comprises the RA sending H.225 alerting/call proceeding/connect messages 1241 to the RMAM.
  • the RMAM sends the same to the LMAM; and the LMAM sends the same to the LA.
  • the LA determines that H.225 call signaling is complete and starts H.245 signaling.
  • H.245 signaling begins with the LA sending master/slave and capability exchange messages 1251 to the LMAM, which are relayed to the RMAM and from the RMAM to the RA. Then, the RA sends master/slave and capability exchange messages 1252 to the RMAM. The RMAM transmits these messages to the LMAM; and the LMAM forwards them to the LA.
  • the LA initiates an exchange of logical channel information by sending logical channel information packets 1253 to the LMAM.
  • the logical channel information identifies the network address (e.g., IP address) and port numbers where RTP/RTCP connections will be accepted.
  • the LMAM stores the LA's logical channel information and passes its own connection information 1254 to the RMAM. Additionally, the LMAM provides the network address of the LA to the RMAM for later use in address translation lookups. As mentioned above, the network address of the LA may be used by the RMM or the RMD depending upon where the address translation lookup is performed.
  • the RMAM remembers the information provided by the LMAM and generates its own RTP RTCP information 1255 and passes it to the RA.
  • the RA After receiving logical channel information thought to be associated with the LA, the RA sends its logical channel information 1256 to the RMAM (thinking it is being directed to the LA).
  • the RMAM stores the RA's logical channel information and passes its own connection information 1257 to the LMAM. Additionally, the RMAM provides the network address of the RA to the LMAM.
  • the LMAM remembers the logical channel information provided by the RMAM and generates its own RTP/RTCP information 1258 and passes it to the LA.
  • the LA sends an AC message 1259 to the LMAM to acknowledge receipt of what it thinks to be the RA's logical channel information.
  • the acknowledgement is relayed to the RA by the LMAM and the RMAM.
  • the RA also sends an ACK message 1260 to the RMAM to acknowledge receipt of what it thinks to be the LA's logical channel information.
  • the acknowledgement is related to the LA by the RMAM and the LMAM.
  • the LMAM and the RMAM each use the logical channel information intercepted from the LA and the RA, respectively, to connect to the media and/or control channels of the LA and RA.
  • FIG. 13A illustrates the encapsulated ("MUX") packet format 1300 according to one embodiment of the present invention in which address replacement is performed by the LMAM.
  • the payload of the encapsulated packet 1300 includes a destination network address field 1310, a variable length transport or control protocol packet portion 1315, and a packet type indication 1320.
  • the destination network address 1310 is typically the IP address of the true recipient (e.g., the apphcation/endpoint to which the packet is destined).
  • the variable length portion 1315 may include either a transport protocol packet (e.g., a RTP packet) or a control protocol packet (e.g., a RTCP packet) as indicated by the packet type indication 1320.
  • variable length portion 1315 would still include either control or data, but the packet type indication 1320 would no longer be necessary.
  • Figure 13B illustrates media transmission in both directions according to the encapsulated packet format of Figure 13 A.
  • the LA originates a media packet, it generates a packet 1340 including media 1342.
  • the LMAM encapsulates the media 1342 in the encapsulated packet format 1300 by generating an encapsulated packet 1350 that includes the RA's network address 1351, the media 1342, and a packet type indicator 1353.
  • the LMAM may append the network address of the RA and a packet type indicator 1353 based upon the channel/port upon which the packet 1340 was received.
  • the RMAM strips the information added by the LMAM and forwards a packet 1360 comprising the media 1342 to the RA.
  • the RA When the RA originates a media packet, it generates a packet 1390 including media 1392.
  • the RMAM encapsulates the media 1392 in the encapsulated packet format 1300 by generating an encapsulated packet 1380 that includes the LA's network address 1341, the media 1392, and a packet type indicator 1383. For example, upon receipt of packet 1390, the RMAM may append the network address of the LA and a packet type indicator 1383 based upon the channel/port upon which the packet 1390 was received.
  • the encapsulated packet 1380 When the encapsulated packet 1380 is received by the LMAM, it strips the information added by the RMAM and forwards a packet 1370 comprising the media 1392 to the LA.
  • FIG. 1 A illustrates the encapsulated ("MUX") packet format according to another embodiment of the present invention in which address replacement is performed by the RMAM.
  • the payload of the encapsulated packet 1400 includes a source network address field 1410, a variable length transport or control protocol packet portion 1415, and a packet type indication 1420.
  • the source network address 1410 is typically the IP address of the true caller (e.g., the application/endpoint from which the packet is originated).
  • the variable length portion 1415 may include either a transport protocol packet (e.g., a RTP packet) or a control protocol packet (e.g., a RTCP packet) as indicated by the packet type indication 1420.
  • FIG. 14B illustrates media transmission in both directions according to the encapsulated packet format of Figure 14 A.
  • the LA originates a media packet, it generates a packet 1440 including media 1442.
  • the LMAM encapsulates the media 1442 in the encapsulated packet format 1400 by generating an encapsulated packet 1450 that includes the LA's network address 1441, the media 1442, and a packet type indicator 1453.
  • the LMAM may append the network address of the LA and a packet type indicator 1453 based upon the channel/port upon which the packet 1440 was received.
  • the RMAM strips the information added by the LMAM and forwards a packet 1460 comprising the media 1442 to the RA by looking up the network address of the RA based upon the LA's network address 1441.
  • the RA When the RA originates a media packet, it generates a packet 1490 including media 1492.
  • the RMAM encapsulates the media 1492 in the encapsulated packet format 1400 by generating an encapsulated packet 1480 that includes the RA's network address 1451, the media 1492, and a packet type indicator 1483. For example, upon receipt of packet 1480, the RMAM may append the network address of the RA and a packet type indicator 1483 based upon the channel/port upon which the packet 1480 was received.
  • the encapsulated packet 1480 When the encapsulated packet 1480 is received by the LMAM, it strips the information added by the RMAM and forwards a packet 1470 comprising the media 1492 to the RA by looking up the network address of the LA based upon the RA's network address 1451.
  • FIG. 15 conceptually illustrates interactions between two media aggregation managers 1530 and 1540 according to one embodiment of the present invention.
  • the media aggregation managers 1530 and 1540 act as reservation protocol proxies on behalf of the communities 1550 and 1560 where a plurality of residents wish to communicate with each other. For example, resident 1551 may wish to communicate with resident 1561 while resident 1552 wishes to communicate with resident 1562.
  • the media aggregation managers pre-allocate bandwidth and establish a reservation protocol session capable of handling multiple communications between residents in Community 1550 and residents in Community 1560. Having media aggregation managers controlling a single reservation protocol session for multiple communication for residents between a plurality of communities allows for packets of communication data to be efficiently multiplexed and reduces protocol overhead as individual pairs of residents need not maintain their own application sessions.
  • the reservations may apply to various paths.
  • the bandwidth reservation may lay over path 1510 containing one intermediary router 1511 or may be allocated over path 1520 containing two intermediary routers 1521 and 1522.
  • the reservation for communications between community 1550 and community 1560 may also be split over the various paths 1510 and 1520 depending on the historical and current bandwidth burden on individual routers 1511, 1521 and 1522.
  • the media aggregation managers reserve a protocol session and then multiplex the plurality of data packets for a plurality of communication links to be communicated.
  • prior technologies required each resident in a community to request an individual reservation session to establish a link between Community 1550 and Community 1560 media aggregation managers and the apparatuses and methods required for initializing/controlling the media aggregation managers have been developed.
  • the present invention focuses on the graphical user interface 1500 that enables a user to interactively discover, analyze and initialize the media aggregation managers to handle a schedule of community communications.
  • the administration GUI tool used for initializing the routers and media aggregation managers is illustrated as designator 1500 in Figure 15.
  • the instructions for the GUI may reside in any combination of hardware or software and likewise may reside on any system configured to interact with other nodes on the network.
  • Figure 16 demonstrates one embodiment of a navigation tool for accessing various screens of the graphical user interface.
  • a user may choose from one of the listed options, for instance, a user may select Network Discovery 1601 to discover the network to be initialized or may choose Bandwidth Allocation 1603 to allocate bandwidth to or establish a reservation protocol session between selected media aggregation managers as will become apparent in the following description,
  • FIG. 17 An example of how a user may navigate through the menu to administer to a network is depicted in Figure 17. Beginning with the menu depicted in Figure 16, a user may select Network Discovery 1601 in processing block 1710. Once the Network Discovery 1710 is complete, the user may select to display the network map by selecting Network Map 1602 from the menu. After viewing the network map that displays all or a subset of the communities, nodes and media aggregation managers currently on the system, the user may choose to go directly to the Bandwidth Allocation screen 1603 by selecting the menu link or may choose to right-click on a graphical representation of one of the media aggregation managers and select from a pop-up menu to allocate bandwidth for that particular media aggregation manager.
  • a Bandwidth Allocation screen presents itself to the user enabling him to select two media aggregation managers and indicate the number of users capable of communicating via the selected media aggregation managers 1730.
  • the user indicates which media aggregation managers are to be allocated and how many users are predicted to utilize the session, one or more potential paths between the two media aggregation managers are displayed on the bandwidth allocation interface.
  • the user may select a path for analysis and, through the graphical user interface, indicate that the selected path is to be analyzed.
  • the selected path is analyzed to determine projected bandwidth utilization for each link of the selected path.
  • a user may select BW on Link 1606 from the menu or the BW on Link screen may automatically appear after analysis has completed.
  • the user may select any node on the network, specifically of interest would be those altered by the predicted increase in usage.
  • the screen displays a schedule of usage for that node and optionally a projection indicating if the predicted usage increase is within an acceptable range 1750.
  • the media aggregation managers may be initialized.
  • the user selects Bandwidth Allocation 1603 from the menu and, based on the nodes all falling within an acceptable range, the bandwidth for the selected media aggregation managers 1760 and the routers along the path is allocated.
  • the user can then decide if more media aggregation managers need to be allocated 1770 (for instance, if a pre-existing plurality of communities are experiencing an increase of residents in the near future). When no more media aggregation managers need to be initialized, then the initialization is complete 1780. On the other hand, when more media aggregation managers need to be initialized, the user may return to the network map interface through the Network Map menu item 1602 or may return directly to the Bandwidth Allocation Interface through the Bandwidth Allocation menu item 1603 and repeat the media aggregation selection process just described.
  • the user may choose to select a different path for analysis or select to de-allocate a previously allocated session between two other media aggregation managers 1790. In either case, the user may return to the Bandwidth allocation page to select a different path through the bandwidth allocation menu item 1603 or the user may select a different combination of media aggregation managers to analyze or de-allocate.
  • the user may simply select the media aggregation managers 1800 and then click on the menu option Bandwidth Deallocation 1604 which brings up a dialog box 1820 and de-allocate screen 1830, shown in Figure 18, allowing the user to de-allocate the current session between the selected media aggregation managers 1810.
  • Figure 19 shows the network map interface according to one embodiment of the invention.
  • a graphical representation of a plurality of nodes on the discovered network is shown.
  • links between each of the nodes and the administration GUI 1950 are shown.
  • the network map screen indicates commumty nodes 1910, router nodes 1920 and media aggregation managers 1930.
  • Each of the nodes or media aggregation nodes are visually distinct via a graphical representation indicative of the type of node. The user is able to readily identify whether a node is a community, router, media aggregation manager, & etc. simply by looking at its graphical representation.
  • the community nodes 1910 may have a plurality of residents, including but not limited to computers, routers, phones, printers, scanners and the like.
  • Each of the nodes and the media aggregation managers have properties associated with it that may be accessed by positioning the cursor over the graphical representation for the node and clicking on a mouse button assigned for property retrieval, in this embodiment, although not shown, the right mouse button is assigned for property retrieval.
  • a properties window immediately appears as shown in Figure 20 indicating information about the node such as the manufacturer 2010, the interface addresses 2020 or a name 2030. Additionally, the properties window may indicate other information about the characteristics of the current configuration of the node. For instance, the property window for a media aggregation manager may indicate how many reservation protocol sessions it is maintaining and with which other media aggregation managers each of the reservation protocol sessions are concerning.
  • the property window may also indicate the available bandwidth for a given node and for what type of communication the bandwidth is available, such as voice or data communication and the amount of bandwidth that is currently allocated for reservation protocol sessions utilizing this particular media aggregation manager as a proxy or gate-keeper.
  • Other properties may include interface command options, such as allocate bandwidth 1940, de-allocate bandwidth (not shown), or other interface command options that take the user to various interface screens and option windows.
  • Figure 21 is a snapshot of one embodiment of the bandwidth allocation screen.
  • the user may select two community gate-keepers or media aggregation managers 2110 for analysis or initialization.
  • the present embodiment allows the user to select a source media aggregation manager 2120, in this case "reddog" from a menu listing all media aggregation managers that were discovered on the network (not shown) and a destination media aggregation manager 2130, in this case "rossini”.
  • the user may also designate the number of users 2140 capable of communicating from each of the selected media aggregation managers.
  • 100 users are capable of simultaneously communicating through the media aggregation manager reddog to residents whose gate-keeper or media aggregation manager is Rossini and likewise, 100 users are capable of communicating from Rossini to residents of reddog.
  • the number of users for this example is 100 for both media aggregation managers, they need not be the same number of users.
  • the user may select "OK" 2150 to indicate to the graphical user interface's processing algorithms to evaluate all available paths between the two media aggregation managers.
  • the user may also decide to "abort" the path evaluation process by selecting the "abort" button 2160.
  • the graphical user interface displays the paths graphically depicting all intervening communities, routers or other nodes that lie between the selected media aggregation managers.
  • the graphical user interface may display the list in a prioritized fashion utilizing factors such as the number of nodes between the media aggregation managers, the physical length of travel between nodes, the total available bandwidth on the nodes between the media aggregation managers, the available co munication bandwidth, or the propagation speed between the various nodes that make up the path. For each factor or combination of weighted factors, the most limiting of the intervening nodes may be utilized for the computation as would be readily apparent to one skilled in the art.
  • the user may then select a path 2170 to analyze.
  • the user may default to the highest prioritized path that in this case defaults to the first position on the graphical user interface but may be configured by the user to appear where desired.
  • the user may see that a node in the prioritized path is going to ultimately be extremely burdened by other allocations that the user needs to initialize or has already been initiahzed and instead may opt for a lower prioritized path.
  • the bandwidth allocation screen allows the user to abort the analysis at any time if so desired by selecting the "abort" button 2160.
  • Figure 23 demonstrates what happens when the analyze button 2190 is selected.
  • a schedule of bandwidth allocation is determined for the selected path.
  • the schedule of increased bandwidth allocation is overlaid on top of the schedule that accounts for bandwidth previously reserved to the nodes on the path via other media aggregation managers utilizing those nodes.
  • the combined schedule of usage is optionally displayed to the user.
  • the graphical user interface may automatically switch to the BW on Link screen shown in Figure 22 or the user may select BW on Link from the menu on the left and previously discussed with regard to Figure 16.
  • the BW on Link screen displays the predicted utilization results of reserving the session as indicated on the Bandwidth allocation interface. As previously indicated, the displayed schedule incorporates all previously allocated sessions and bandwidth reservations burdening the intervening nodes as well as the predicted increase as a result of the analyzed path if it were to be allocated.
  • the results of the analysis may be viewed for each of the nodes displayed in the network map, primarily of interest would be the nodes along the selected path so that a determination can be made as to whether the protocol session to be reserved will exceed the available communication bandwidth for any node at any time in the predicted schedule.
  • the media aggregation managers that have been analyzed are displayed 2210.
  • the user may indicate a time range for display by changing the offset for each router 2220.
  • Another segment of the display 2230 indicates to the user all available and analyzed nodes between the selected media aggregation managers byway of a scrollable list of intervening nodes.
  • the user may then select a node on the path and a schedule of utilization for that node appears 2240.
  • the schedule depicts a time frame including a Start Time 2250 and End time 2260 and indicates the bandwidth utilized during that time frame 2270 and the amount of the available communication bandwidth 2280 that would remain available after the analyzed path has been allocated.
  • the schedule covers various segments of the day as determined by the offsets selected 2220 and also indicates a schedule of usage for the node for various days of the week.
  • the bandwidth for the media aggregation managers are allocated as shown in the flow chart in Figure 24.
  • each and every router on the selected path where RSVP is not currently utilized RSVP is enabled.
  • each router on the selected path is provisioned to force all communication media between the residents communicating between selected source and destination media aggregation managers to travel across the media aggregation managers and routers of the selected path.
  • the media aggregation managers are initialized with all scheduling information necessary to reserve protocol sessions for the plurality of residents at anytime within the schedule.
  • the reservation protocol sessions manage the protocol sessions for multiple communication links in order to reduce the overhead and delay times occurring when individual links must be maintained as in previous technologies.
  • the necessary scheduling information may include information such as how much bandwidth needs to be allocated for each session, expected increases and decreases in utilization based on time and other information necessary to manage a reservation protocol session.
  • the media aggregation managers begin reserving protocol sessions according to the information schedule provided in step 2430.
  • the user may select another path for analysis, select another pair of allocated media aggregation nodes for de-allocation or restrict the number of users allowed to communicate over the selected media aggregation managers. Should the user decide to de-allocate a previously allocated protocol session, he selects the media aggregation managers and then selects Bandwidth Deallocation 1604 from the menu.
  • Figure 18 indicates a bandwidth deallocation screen and allows the user to select "deallocate bandwidth”.
  • the graphical user interface provides a warning and confirmation dialog box. The user may then confirm the deallocation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un appareil et des procédés permettant de multiplexer des flux d'applications sur une session de protocole de réservation de bande passante pré-allouée. L'invention concerne également une interface utilisateur graphique (GUI) permettant à un utilisateur d'identifier routeurs, communautés, résidents et gestionnaires d'agrégation de supports (110, 120) présents sur un réseau. Selon un mode de réalisation, une session de protocole de réservation pré-allouée, telle qu'une session RSVP, est partagée par une ou plusieurs sessions d'applications. La session de protocole de réservation est pré-allouée sur un chemin entre un premier appareil réseau (111, 112), associé à une première communauté d'utilisateurs, et un deuxième appareil réseau (121, 122), associé à une deuxième communauté d'utilisateurs, en fonction d'un taux d'utilisation estimé dudit chemin pour des sessions d'applications entre utilisateurs des première et deuxième communautés. Les sessions d'applications sont ensuite agrégées de façon dynamique par multiplexage de flux d'applications associés aux sessions individuelles d'applications sur la session de protocole de réservation pré-allouée au niveau du premier appareil réseau (111, 112) et démultiplexage au niveau du deuxième appareil réseau (121, 122).
PCT/US2001/024878 2000-08-08 2001-08-08 Multiplexage de plusieurs sessions individuelles d'applications sur une session de protocole de reservation pre-allouee dans un systeme vocal sur internet (voip) WO2002013023A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001290525A AU2001290525A1 (en) 2000-08-08 2001-08-08 Multiplexing several individual application sessions over a pre-allocated reservation protocol session in a voice over internet protocol (voip)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US64303500A 2000-08-08 2000-08-08
US09/643,035 2000-08-21
US09/689,222 2000-10-11
US09/689,222 US7886054B1 (en) 2000-10-11 2000-10-11 Graphical user interface (GUI) for administering a network implementing media aggregation

Publications (1)

Publication Number Publication Date
WO2002013023A1 true WO2002013023A1 (fr) 2002-02-14

Family

ID=27094170

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/024878 WO2002013023A1 (fr) 2000-08-08 2001-08-08 Multiplexage de plusieurs sessions individuelles d'applications sur une session de protocole de reservation pre-allouee dans un systeme vocal sur internet (voip)

Country Status (2)

Country Link
AU (1) AU2001290525A1 (fr)
WO (1) WO2002013023A1 (fr)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1443733A2 (fr) * 2003-01-30 2004-08-04 Avaya, Inc. Identification de flux de données par paquets pour multiplexage
US7013338B1 (en) 2000-07-28 2006-03-14 Prominence Networks, Inc. Multiplexing several individual application sessions over a pre-allocated reservation protocol session
US7083230B2 (en) 2002-04-19 2006-08-01 Adam Aircraft Industries Hybrid composite-metal energy absorbing seat
US7107354B2 (en) 2003-02-07 2006-09-12 Avaya Technology Corp. Multiplexer discovery and parameter exchange
EP1723810A1 (fr) * 2004-03-08 2006-11-22 Nortel Networks Limited Pre-attribution des ressources d'un reseau sans fil pour des communications a commutation par paquets en temps reel, interactives
US7266683B1 (en) 2001-07-27 2007-09-04 Siddhartha Nag Selective encryption of application session packets
US7447211B1 (en) 2004-03-23 2008-11-04 Avaya Inc. Method and apparatus of establishing a communication channel using protected network resources
FR2917937A1 (fr) * 2007-06-25 2008-12-26 Alcatel Lucent Sas Procede de communication avec interception de messages de controle
WO2009135981A1 (fr) * 2008-05-07 2009-11-12 Nokia Corporation Procédé, appareil et produit de programme d'ordinateur pour assurer un routage dans un réseau
US7680100B1 (en) 2004-09-30 2010-03-16 Avaya Inc. Internet protocol appliance manager
US7774468B1 (en) 2000-07-28 2010-08-10 Siddhartha Nag Network traffic admission control
GB2491431A (en) * 2011-03-25 2012-12-05 Exelis Inc Enabling multiple terminals to transmit data within a single communication session
US8918523B2 (en) 2000-10-11 2014-12-23 Prom Ks Mgmt Limited Liability Company Graphical user interface (GUI) for administering a network implementing media aggregation
US8929394B2 (en) 2000-07-28 2015-01-06 Prom Ks Mgmt Limited Liability Company End-to-end service quality for latency-intensive internet protocol (IP) applications in a heterogeneous, multi-vendor environment

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6009469A (en) * 1995-09-25 1999-12-28 Netspeak Corporation Graphic user interface for internet telephony application
US6208638B1 (en) * 1997-04-01 2001-03-27 J 2 Global Communications, Inc. Method and apparatus for transmission and retrieval of facsimile and audio messages over a circuit or packet switched network
US6226678B1 (en) * 1995-09-25 2001-05-01 Netspeak Corporation Method and apparatus for dynamically defining data communication utilities
US6243376B1 (en) * 1997-08-13 2001-06-05 Mediaring.Com Ltd. Method and apparatus for making a phone call connection over the internet connection
US6243759B1 (en) * 1998-05-08 2001-06-05 International Business Machines Corporation Method and system for configuring dynamic interfaces
US6259771B1 (en) * 1998-04-03 2001-07-10 Nortel Networks Limited Web based voice response system
US6298120B1 (en) * 1996-06-28 2001-10-02 At&T Corp. Intelligent processing for establishing communication over the internet

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6009469A (en) * 1995-09-25 1999-12-28 Netspeak Corporation Graphic user interface for internet telephony application
US6226678B1 (en) * 1995-09-25 2001-05-01 Netspeak Corporation Method and apparatus for dynamically defining data communication utilities
US6298120B1 (en) * 1996-06-28 2001-10-02 At&T Corp. Intelligent processing for establishing communication over the internet
US6208638B1 (en) * 1997-04-01 2001-03-27 J 2 Global Communications, Inc. Method and apparatus for transmission and retrieval of facsimile and audio messages over a circuit or packet switched network
US6243376B1 (en) * 1997-08-13 2001-06-05 Mediaring.Com Ltd. Method and apparatus for making a phone call connection over the internet connection
US6259771B1 (en) * 1998-04-03 2001-07-10 Nortel Networks Limited Web based voice response system
US6243759B1 (en) * 1998-05-08 2001-06-05 International Business Machines Corporation Method and system for configuring dynamic interfaces

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7013338B1 (en) 2000-07-28 2006-03-14 Prominence Networks, Inc. Multiplexing several individual application sessions over a pre-allocated reservation protocol session
US8929394B2 (en) 2000-07-28 2015-01-06 Prom Ks Mgmt Limited Liability Company End-to-end service quality for latency-intensive internet protocol (IP) applications in a heterogeneous, multi-vendor environment
US7774468B1 (en) 2000-07-28 2010-08-10 Siddhartha Nag Network traffic admission control
US8918523B2 (en) 2000-10-11 2014-12-23 Prom Ks Mgmt Limited Liability Company Graphical user interface (GUI) for administering a network implementing media aggregation
US7266683B1 (en) 2001-07-27 2007-09-04 Siddhartha Nag Selective encryption of application session packets
US7083230B2 (en) 2002-04-19 2006-08-01 Adam Aircraft Industries Hybrid composite-metal energy absorbing seat
US7525994B2 (en) 2003-01-30 2009-04-28 Avaya Inc. Packet data flow identification for multiplexing
EP1443733A3 (fr) * 2003-01-30 2004-11-17 Avaya, Inc. Identification de flux de données par paquets pour multiplexage
EP1443733A2 (fr) * 2003-01-30 2004-08-04 Avaya, Inc. Identification de flux de données par paquets pour multiplexage
EP2259549A1 (fr) * 2003-01-30 2010-12-08 Avaya Inc. Identification de flux de données par paquets pour multiplexage
EP1445901B1 (fr) * 2003-02-07 2006-10-04 Avaya Technology Corp. Reconnaissance de multiplexeurs et échange de paramètres
US7107354B2 (en) 2003-02-07 2006-09-12 Avaya Technology Corp. Multiplexer discovery and parameter exchange
EP1723810A4 (fr) * 2004-03-08 2010-12-22 Nortel Networks Ltd Pre-attribution des ressources d'un reseau sans fil pour des communications a commutation par paquets en temps reel, interactives
EP1723810A1 (fr) * 2004-03-08 2006-11-22 Nortel Networks Limited Pre-attribution des ressources d'un reseau sans fil pour des communications a commutation par paquets en temps reel, interactives
US7447211B1 (en) 2004-03-23 2008-11-04 Avaya Inc. Method and apparatus of establishing a communication channel using protected network resources
US7680100B1 (en) 2004-09-30 2010-03-16 Avaya Inc. Internet protocol appliance manager
EP2009871A1 (fr) * 2007-06-25 2008-12-31 Alcatel, Lucent Procédé de communication avec interception de messages de controle.
FR2917937A1 (fr) * 2007-06-25 2008-12-26 Alcatel Lucent Sas Procede de communication avec interception de messages de controle
WO2009135981A1 (fr) * 2008-05-07 2009-11-12 Nokia Corporation Procédé, appareil et produit de programme d'ordinateur pour assurer un routage dans un réseau
GB2491431A (en) * 2011-03-25 2012-12-05 Exelis Inc Enabling multiple terminals to transmit data within a single communication session
US8681690B2 (en) 2011-03-25 2014-03-25 Exelis Inc. Technique for enabling multiple terminals to simulate traffic of a single virtual terminal
GB2491431B (en) * 2011-03-25 2017-12-13 Exelis Inc Technique for enabling multiple terminals to simutate traffic of a single virtual terminal

Also Published As

Publication number Publication date
AU2001290525A1 (en) 2002-02-18

Similar Documents

Publication Publication Date Title
US8032646B2 (en) Administering a communication network
US7013338B1 (en) Multiplexing several individual application sessions over a pre-allocated reservation protocol session
US8929394B2 (en) End-to-end service quality for latency-intensive internet protocol (IP) applications in a heterogeneous, multi-vendor environment
EP1921813B1 (fr) Procédé et dispositif de fourniture de qualité/classe de service garantie dans et par l'intermédiaire de réseaux en utilisant des protocoles de réservation et des formats de paquets existants
US6449251B1 (en) Packet mapper for dynamic data packet prioritization
US7266683B1 (en) Selective encryption of application session packets
DE69916747T2 (de) Verfahren zur Bereitstellung von Dienstgüte in IP-Netzwerken für verzögerungsempfindliche Verkehr
JP4376457B2 (ja) 構内または広域ネットワークのサービスの保証された品質を与える方法および装置
US7774468B1 (en) Network traffic admission control
US20020091810A1 (en) Method and system for resource reservations in a multicasting network
JP2003521199A (ja) 通信ネットワークの方法、サーバ及び構成
JP2004236332A (ja) 多重化のためのパケット・データ・フローの識別
WO2002013023A1 (fr) Multiplexage de plusieurs sessions individuelles d'applications sur une session de protocole de reservation pre-allouee dans un systeme vocal sur internet (voip)
US7856025B2 (en) Method and system for intercommunicating between private network user and network with QoS guarantee
WO2004042533A2 (fr) Qualite de service de bout en bout pour des applications ip a forte intensite de temps d'attente dans un environnement multiconstructeur heterogene
EP1195075A1 (fr) Ameliorations en matiere de prestation de services de telecommunication
CN100396050C (zh) 一种跨独立运营网络的路由选路方法
Zainal Abidin QoS SOLUTIONS FORVIDEOCONFERENCING
Micom et al. Sample Products

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP