RSVP transmitter proxy

A Resource reSerVation Protocol (RSVP) transmitter proxy reserves network resources on behalf of a multimedia server that lacks RSVP facilities. The RSVP transmitter proxy is preferably disposed in an intermediate network device that is proximate to (e.g., one hop away from) the respective server, and includes a classification engine configured to identify network traffic passing through the network device, and a media session manager for maintaining state and other information for streams and/or sessions being provided by the server. The classification engine may snoop messages exchanged between the server and a client to identify the traffic flow characteristics and bandwidth of a stream. The RSVP transmitter uses the snooped information to generate and send RSVP Path messages on behalf of the server and to terminate RSVP Reservation messages sent to the server, thereby causing network resources to be reserved for the stream.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to computer networks, and more specifically, to a network protocol proxy.

2. Background Information

Computer networks typically comprise a plurality of interconnected entities. An entity may consist of any device, such as a computer or end station, that “sources” (i.e., transmits) or “sinks” (i.e., receives) datagrams (e.g., packets and/or frames). A common type of computer network is a local area network (“LAN”) which typically refers to a privately owned network within a single building or campus. LANs typically employ a data communication protocol (LAN standard), such as Ethernet, FDDI or token ring, that defines the functions performed by the data link and physical layers of a communications architecture (i.e., a protocol stack). In many instances, several LANs may be interconnected by point-to-point links, microwave transceivers, satellite hook-ups, etc. to form a wide area network (“WAN”) or intranet that may span an entire country or continent.

One or more intermediate network devices are often used to couple LANs together and allow the corresponding entities to exchange information. For example, a bridge may be used to provide a “bridging” function between two or more LANs. Alternatively, a switch may be utilized to provide a “switching” function for transferring information between a plurality of LANs or end stations. Bridges and switches may operate at various levels of the communication protocol stack. For example, a switch may operate at layer2which, in the Open Systems Interconnection (OSI) Reference Model, is called the data link layer and includes the Logical Link Control (LLC) and Media Access Control (MAC) sub-layers. Data frames at the data link layer typically include a header containing the MAC address of the entity sourcing the message, referred to as the source address, and the MAC address of the entity to whom the message is being sent, referred to as the destination address. To perform the switching function, layer2switches examine the MAC destination address of each data frame received on a source port. The frame is then switched onto the destination port(s) associated with that MAC destination address.

Other network devices, commonly referred to as routers, may operate at higher communication layers, such as layer3of the OSI Reference Model, which in TCP/IP networks corresponds to the Internet Protocol (IP) layer. Data frames at the IP layer also include a header which contains an IP source address and an IP destination address. Routers or layer3switches may re-assemble or convert received data frames from one LAN standard (e.g., Ethernet) to another (e.g. token ring). Thus, layer3devices are often used to interconnect dissimilar subnetworks.

Multimedia Applications

Increasingly, computer networks are being called upon to support time-sensitive traffic, such as the transmission of audio and/or video files in real-time. More specifically, technology has recently been developed to support streaming multimedia applications. With streaming, a user can begin playing or listening to the corresponding content as it is being received at his or her computer. That is, the user does not have to wait until the entire file is downloaded before playing the content as was previously the case. Sources of data for streaming can include both live feeds, such as videoconferences, concerts, etc., and stored clips or files.

To support streaming multimedia traffic, a number of real-time oriented network protocols have been developed and/or proposed. The Real-time Transport Protocol (RTP), for example, provides end-to-end delivery services to support applications transmitting real-time data. RTP typically runs on top of the User Datagram Protocol (UDP) to utilize its multiplexing and checksum services, although other transport protocols besides UDP may also be used. RTP is a proposed standard from a working group of the Internet Engineering Task Force (IETF), which is an independent standards organization, and is described at Request for Comments (RFC) 1889. RTP defines several messages that specify the type of audio encoding being used, e.g., pulse code modulation (PCM). RTP messages also contain timestamps and sequence numbers which are used by a receiver to reconstruct the timing produced by the source.

The Real-Time Control Protocol (RTCP) works in conjunction with RTP, and is responsible for the management of the real-time session between the source and the receiver. During an RTP session, RTCP reports are periodically sent back-and-forth between the receiver and the source. These reports provide feedback regarding reception quality and are also used to control the session and provide diagnostic services. The feedback may include the number of packets sent, the number of packets lost, jitter, etc. This information can then be used by the source to modify its transmission so as to eliminate or at least reduce identified problems. The Session Description Protocol (SDP) is used to announce multimedia sessions. It specifies a short, structured textual file format for describing sessions, including the name and purpose of the session, the media, protocols, bandwidth requirements, timing and transport information. In particular, it provides the information needed to join and thus receive a multimedia session including streaming media sessions. SDP was developed by the Multiparty Multimedia Session Control (MMSC) working group of the IETF, and is found at RFC 2327.

The Real-Time Streaming Protocol (RTSP) is an application-level protocol for use in controlling streaming sessions. It typically works on top of RTP to both control and deliver real-time content. RTSP provides receivers of streams with “VCR-style” control functionality, such as pause, fast forward, reverse, etc. It is set forth at RFC 2326.

Allocation of Network Resources

Computer networks include numerous services and resources for use in forwarding network traffic, e.g., packets and frames, throughout the network. For example, different network links, such as Fast Ethernet, Asynchronous Transfer Mode (ATM) channels, network tunnels, satellite links, etc., offer unique speed and bandwidth capabilities. Particular intermediate devices also include specific resources or services, such as priority queues, filter settings, queue selection strategies, congestion control algorithms, etc. Depending on the selection or allocation of such resources or services, network traffic can be forwarded at different speeds or rates. To take advantage of these services and resources, individual frames or packets can be marked so that intermediate devices will treat them in a predetermined manner.

More specifically, the Institute of Electrical and Electronics Engineers (IEEE), in an appendix (802.1p) to the 802.1D bridge specification standard, describes additional information that can be loaded into the MAC header of Data Link Layer frames.FIG. 1Ais a partial block diagram of a Data Link frame100which includes a MAC destination address (DA) field102, a MAC source address (SA) field104and a data field106. In accordance with the 802.1p standard, a user_priority field108, among others, is inserted after the MAC SA field104. The user_priority field108may be loaded with a predetermined value (e.g., 0-7) that is associated with a particular treatment. Possible treatments include background, best effort, excellent effort, etc. Network devices examine the user_priority field108of received frames100and apply the corresponding treatment to the frames. For example, an intermediate device may have a plurality of transmission priority queues per port, and may assign frames to different queues of a destination port on the basis of the frame's user priority value.

FIG. 1Bis a partial block diagram of a Network Layer packet120corresponding to the Internet Protocol (IP), such as IPv4. Packet120includes a one octet differentiated services (DS) field122that can be loaded with a differentiated services codepoint (DSCP) value. Currently, DSCP values are 6-bits, leaving 2-bits of the DS field122unused. Packet120further includes a protocol field124, an IP source address (SA) field126, an IP destination address (DA) field128and a data field130. The ToS field122was intended to be used to specify a particular service to be applied to the packet120, but it is rarely used. The protocol field124is used to identify the next higher protocol that is to receive the packet. Version 6 of the Internet Protocol (IPv6) similarly includes a DS field, formerly known as the traffic class field.

Layer 3 devices that are DS compliant apply a particular per-hop forwarding behavior to packets based on the contents of their DS fields122. Examples of per-hop forwarding behaviors include expedited forwarding and assured forwarding. By setting the DS field122with the DSCP value associated with the expedited forwarding PHB, the packet is forwarded with minimal delay or loss. By setting the DS field122with the DSCP value associated with the assured forwarding PHB, the packet receives better forwarding reliability than the traditional best efforts service. DS-compliant nodes typically establish special queues and/or employ queue selection strategies, such as Random Early Detection (RED), Random Early Detection with In and Out (RIO), etc., to achieve the forwarding requirements of the various PHBs.

The DS field122is typically loaded by DS compliant intermediate devices located at the border of a DS domain, which is a set of DS compliant intermediate devices under common network administration. Thereafter, interior DS compliant devices along the path examine the DS field122of received packets and apply the corresponding forwarding behavior to them.

FIG. 1Cis a partial block diagram of a Transport Layer packet150. In the TCP/IP Reference Model, the transport layer corresponds to the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). The transport layer packet150preferably includes a source port field152, a destination port field154and a data field156, among others. Fields152and154are preferably loaded with the predefined or dynamically agreed-upon TCP or UDP port numbers being utilized by the corresponding network entities. A TCP or UDP packet150is typically encapsulated within an IP packet120by placing it in the data portion130of the IP packet120. The IP packet120, in turn, is encapsulated in the data portion106of a Data Link frame100for transmission across a computer link.

The Resource Reservation Protocol

As set forth above, to support streaming multimedia applications, the corresponding content must typically be delivered within specific, fixed time constraints and without jitter. Although many computer networks have the resources and services to meet the delivery requirements of streaming multimedia, these resources and services must be allocated, preferably in advance, to the correct network traffic. The Resource reSerVation Protocol (RSVP), which is set forth at RFC 2205, was developed so that entities (typically referred to as receivers) could reserve bandwidth within their computer networks to receive a desired traffic flow from one or more sourcing entities. Pursuant to RSVP, sources send RSVP Path messages identifying themselves and indicating the bandwidth needed to receive their programming or content. If a receiver is interested in the programming or content offered by a particular source, it responds with a RSVP Reservation (Resv) message, which travels hop-by-hop back to the source. At each hop, the corresponding intermediate device establishes a session for the receiver and sets aside the requested bandwidth for the desired traffic flow. With RSVP, traffic corresponding to streaming multimedia content can be accorded the resources and services it needs to ensure timely, jitter-free delivery.

Many network servers, including multimedia servers, however, do not include RSVP facilities. As a result, the bandwidth needed to support the content residing on these servers cannot be reserved in the computer networks which connect these servers to potential receivers. The quality of the presentations of this content may thus be substantially degraded.

SUMMARY OF THE INVENTION

Briefly, the invention relates to a Resource reSerVation Protocol (RSVP) transmitter proxy for use on behalf of a network entity, such as a multimedia server, that lacks RSVP facilities of its own. The RSVP transmitter proxy is preferably disposed in an intermediate network device that is proximate to (e.g., one hop away from) the respective server. In addition to the RSVP transmitter proxy, the network device further includes a classification engine configured to identify network traffic passing through the network device, and a media session manager for maintaining state and other information for sessions being provided by the server. The network device may also include an admission control engine.

In accordance with the invention, the classification engine examines the network traffic destined for the multimedia server and identifies client requests seeking to initiate a multimedia session. These requests may be in the form of Real Time Streaming Protocol (RTSP) messages containing Session Description Protocol (SDP) files, and the classification engine is specially configured to snoop such messages. Traffic flow information for the session, such as source and destination addresses and ports and a description of the traffic characteristics of the expected multimedia stream from the server, is passed to the RSVP transmitter proxy. Using this snooped information, the RSVP transmitter proxy, on behalf of the server, generates and sends an RSVP Path message to the client. The Path message is specifically configured by the RSVP transmitter proxy to appear as though it had been generated and sent by the multimedia server. The Path message traverses the same route through the computer network that the data packets will follow and is received by the client. At each intermediate node, the information from the Path message is used to establish path state should a subsequent reservation be made.

Assuming it is interested in the session, the client responds to the “server” with an RSVP Resv message that contains admission control and traffic flow parameters based upon those contained in the Path message from the RSVP transmitter proxy. Based on the previously established path state at each node, the RSVP Resv message follows the same route through the computer network as the Path message although in the opposite direction. The intermediate network devices disposed along the route examine the traffic flow parameters contained within the RSVP Resv message and reserve sufficient local resources to support the session. The Resv message is intercepted by the RSVP transmitter proxy before reaching the multimedia server, which would be unable to process it. The intermediate device containing the RSVP transmitter proxy similarly reserves sufficient resources for the anticipated flow. As a result, bandwidth in the computer network can be reserved for streaming sessions originating from the multimedia server, even though the server itself does not support the RSVP protocol.

In a further embodiment of the present invention, the RSVP transmitter proxy may also select one or more admission control parameters, such as a Differentiated Services Codepoint (DSCP) that is to be applied to a session originating from the multimedia server. The selected DSCP is preferably inserted into the RSVP Path message generated and sent by the RSVP transmitter proxy. Intermediate devices along the route to the client examine the DSCP assigned by the RSVP transmitter proxy and may use it to perform local admission control decisions to determine whether the resources and/or services necessary to satisfy the treatment specified by the DSCP can be allocated.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

FIG. 2is a highly schematic block diagram of a computer network200. The network200includes a multimedia server202and a client entity204that are interconnected by a plurality of intermediate network devices. More specifically, server202is coupled to a first hop network device, such as router206, which, in turn, is coupled to a network cloud208. The network cloud208may consist of a plurality of network devices, local area networks (LANs), and end stations. Client entity204is similarly coupled to a first hop network device, such as router210, which, in turn, is coupled to network cloud208. More specifically, router210is coupled to an edge or border device of network cloud208, such as edge router212. Edge router212represents an ingress/egress point for network cloud208.

Multimedia server202preferably has a plurality of accessible files, including one or more continuous media files that can be streamed to clients, such as client204. Alternatively, multimedia server202may be configured to support videoconferencing, white board applications and/or live “webcasts”. The continuous media files, videoconferences or webcasts are all time-sensitive and must be reproduced at the client204within the same timing relationship that existed at the server202. The continuous media files, videoconferences or webcasts may each include one or more audio and/or video streams, which either alone or together with other media streams represent a complete presentation. Multimedia server202preferably includes facilities, such as software, hardware and/or firmware, for operating in accordance with the Real-time Transport Protocol (RTP) as set forth at Request for Comments (RFC) 1889, the Real-Time Streaming Protocol (RTSP) as set forth at RFC 2326, and the Session Description Protocol (SDP) as set forth at RFC 2327, which are each hereby incorporated by reference in their entirety.

Network cloud208preferably represents the infrastructure and facilities of an Internet Services Provider (ISP). ISPs are enterprises who have built sophisticated communication infrastructures and facilities, which are then used by other organizations, such as corporations, educational institutions, and governmental entities, for connecting to the well-known Internet. The infrastructures and facilities of one or more ISPs may also be used to provide connectivity between geographically remote facilities of an organization so as to form a virtual private network (VPN) or intranet for that organization. These organizations typically enter into service level agreements (SLAS) with the ISPs, which include one or more traffic specifiers. The traffic specifiers typically place limits on the amount of resources that the subscribing organization will consume for a given charge. For example, an organization, which typically includes many network entities or end stations, such as client204, may agree not to send and/or receive traffic that exceeds a certain bandwidth (e.g., 1 Mb/s).

Traffic exiting and entering the ISP's network to and from the organization's network is monitored (i.e., “policed”) to ensure that it complies with the relevant traffic specifiers, and is thus “in-profile”. Traffic that exceeds a traffic specifier (i.e., traffic that is “out-of-profile”) may be dropped or shaped by the ISP or it may result in an accounting change (i.e., causing the subscribing organization to be charged a higher rate). Alternatively, out-of-profile traffic can be marked as exceeding one or more traffic specifiers, but nonetheless allow it to proceed through the network. If there is congestion, the ISP may drop such “marked” traffic first in an effort to relieve the congestion. The policing, shaping, dropping and marking of network traffic may be performed by one or more intermediate network devices under the ISP's control, such as edge router212.

FIG. 3is a highly schematic, partial, functional block diagram of a router in accordance with the present invention, such as router206, which is the first hop router from multimedia server202. Router206preferably includes a packet/frame receiver transmitter object302, a packet/frame classification engine304, and a traffic scheduler306. The traffic scheduler306includes a plurality of resources or services that are used by router206to forward packets. For example, scheduler306may include one or more metering entities308, one or more marker entities310, one or more shaper/dropper entities312, and one or more queue selector entities314. The queue selector entity314, moreover, includes or has access to a plurality of queues316a-dwhich store packets for the interfaces and/or ports that have been configured at router206. The packet/frame receiver transmitter object302is configured to receive and send network messages for router206. The packet/frame receiver transmitter object302, the packet frame classification engine304and the traffic control engine306are all in communicating relationship with each other so that network messages as well as commands may be exchanged among them.

In accordance with the present invention, router206further includes a Resource reSerVation Protocol (RSVP) transmitter proxy318. The RSVP transmitter proxy318includes an RSVP message generator320and an RSVP state machine engine322. Router206also includes an admission control entity324, a policy control entity326, and a media session manager328having a session table600and a plurality of state machine engines330that can be configured to store information and maintain state for various media sessions with which the RSVP transmitter proxy318is involved. Router206may further include a differentiated services (DiffServ) entity332having one or more tables, such as table334, for mapping the bandwidth requirements of network traffic sessions to the differentiated services codepoints (DSCPs) established in accordance with one or more service level agreements (SLAs). The RSVP transmitter proxy318operates substantially in accordance with at least part of the RSVP specification standard, which is set forth at RFC 2205 and is hereby incorporated by reference in its entirety.

A suitable platform for router206is the 7100 and 7200 series of routers from Cisco Systems, Inc. of San Jose, Calif. A suitable packet/frame classification engine304, moreover, is the Network-Based Application Recognition (NBAR) facility of the Internetwork Operating System (IOS) from Cisco Systems, Inc.

FIGS. 4A-Bare a flow diagram of the method of the present invention. First, the RSVP transmitter proxy318obtains sufficient information regarding a proposed stream between multimedia server202and a client, such as client204, to identify the traffic flow, as indicated at block402. Preferably, the RSVP transmitter proxy318determines the source and destination IP addresses, the source and destination transport layer port numbers, and the transport layer protocol, e.g., TCP, UDP, etc. for the traffic flow. The RSVP transmitter proxy318also obtains and the bandwidth of the stream, as indicated at block404.

In a preferred embodiment, the traffic flow and bandwidth information is obtained by snooping on RTSP traffic between the server202and the client204. More specifically, a client, such as client204, may generate and send an RTSP Describe Request message to the multimedia server202in order to obtain information about a particular stream or session that is supported by server202and of interest to client204. RTSP uses a message format that is similar to the Hypertext Transport Protocol (HTTP), which is wellknown to those skilled in the art. First, the client204may establish a transport layer, e.g., TCP, connection with the multimedia server202in a conventional manner. Once the TCP connection is established, the client204sends the RTSP Describe Request message, which typically contains the Uniform Resource Identifier (URI) for the session or stream of interest to the client204.

FIG. 5Aillustrates an exemplary RTSP Describe Request message500. Like HTTP, RTSP messages, including message500, are organized as a series of lines separated by carriage returns (CRs). In particular, RTSP messages typically include an initial line, zero, one or more header lines, a blank line, i.e., a carriage return/line feed (CRLF) by itself, and an optional message body. In an initial line502, message500specifies the respective RTSP message type, e.g., DESCRIBE. The initial line502also contains the URI of the presentation or of the individual stream or streams that make up or are part of the presentation of interest. Message500further includes a second header line504that specifies a CSeq value. As provided in the RTSP specification standard, a CSeq value is a sequence number used to match RTSP request-response message pairs. Message500also includes a blank line506. The RTSP Describe Request message500does not have a message body. Message500travels through routers210and212, which sends the message500through network cloud208. Message500is forwarded to router206, which, in turn, passes it to multimedia server202.

Multimedia server202, which includes RTSP facilities, examines the message500and searches its files for the specified presentation or stream. Assuming the presentation or stream identified by the Describe Request message's URI is at the multimedia server202, it responds with an RTSP Describe Response message.FIG. 5Billustrates an exemplary RTSP Describe Response message510. Message510includes a header512and a message body514. The header512includes an initial response line516that, like HTTP, is a status line, where the value “200” indicates that the request succeeded. A second header line518contains the same CSeq value as the request message500so that this response510can be matched up with request message500. A third header line520contains the date. A fourth header line522specifies the format type of the stream or session description included in the message body514. In this case, the description is in Session Description Protocol (SDP) format. A fifth header line524specifies the length of the attached presentation description, and a blank line526separates the header512from the message body514.

The message body514contains a description of the specified presentation in SDP format. An SDP description file consists of a series of lines of text of the form: <type>=<value>. Three required types “v”, “o” and “s” specify the protocol version, the owner and the session's name, respectively. The remaining types are optional. The “i” type specifies session information. The “u” type specifies a URL where more information about the session may be obtained, the “e” type specifies the email address of a contact person, the “c” type specifies connection information, e.g., a multicast IP address and time-to-live (TTL), the “b” type specifies bandwidth information for the respective presentation or stream, the “t” type specifies the time the respective presentation or stream is active, such as a start time and stop time. For each media stream (e.g., first audio, second audio, first video, second video, etc.) that makes up the corresponding session or presentation, there is typically a “m” type, which specifies the respective media name, and one or more optional fields, including the “a” type, which specifies some attribute, such as receive only, of the respective media stream.

Here, the RTSP Describe Response message510specifies a bandwidth of “CT:128” which indicates that a bandwidth of 128 Kb/s is to assumed for the entire multimedia session, i.e., both the audio and the video streams.

Message510is sent by multimedia server202to the client204. More specifically, the message510is forwarded to router206which sends it through network cloud208. Message510is received at edge router212which forwards it to router210. From here, the message510is passed to the client204.

In accordance with the present invention, router206is configured to snoop RTSP messages sent to and originating from the multimedia server202. More specifically, since router206is the last hop router for server202, messages from client204that are addressed to the multimedia server206pass through router206. These messages are examined by the packet/frame classification engine304before being forwarded on to server202. Similarly, messages from multimedia server206that are addressed to client204(whether by unicast or multicast addresses) pass through router206and are also examined by the packet/frame classification engine304before being forwarded on their way to client204.

More specifically, the TCP message150(FIG. 1C) containing the RTSP Describe Response message510is examined by the packet/frame classification engine304. The classification engine304determines that the TCP message150is carrying an RTSP Describe Response message. The classification engine304examines the session description contained in the message body514. It retrieves the IP address of the originating host, which is specified by the type “o” field, the session name, which is specified by the type “s” field, and the bandwidth for each media stream, which is specified by the type “b” field(s). This information is then passed to the RSVP transmitter proxy318. The RSVP transmitter proxy318preferably passes the information to the media session manager328which creates an entry for the session in its session table600and activates at least one state machine engine330for the session.

FIG. 6is a highly schematic block diagram of a session table600maintained by the media session manager328. Table600is preferably configured as an array having a plurality of columns602-622and rows630-634whose intersections define corresponding records or cells. Each row630-634contains information corresponding to a respective stream. In particular, a first column602lists the name of the corresponding session. A second column604contains the identifier (ID) for the session, while a third column606lists the IP address of the source of the session, e.g., the IP address of multimedia server202. A fourth column608lists the source port of the session. A fifth column610lists the destination IP address for the session, which may be the client's unicast IP address or it may be a multicast address that has been assigned to the session. A sixth column612lists the destination port, while a seventh column614lists the transport layer protocol being used by the session, e.g., TCP, UDP, etc. An eighth column616lists the URI for the session, and a ninth column618identifies the media transport protocol, e.g. RTP. A tenth column620lists the session's bandwidth as provided in the RTSP Describe Response message. Tenth column620may be sub-divided into a plurality of sub-columns, such as sub-columns620a,620band620cfor storing token bucket rate [r], token bucket size [b], and peak data rate [p] information. Tenth column620may be further configured to store additional information, such as minimum policed packet size [m], maximum packet size [M], etc. An eleventh column622lists the current RTSP state of the session as described below.

The media session328manager preferably loads the corresponding cells of the entry, e.g., entry630, that has been established for this stream with the information received from the RSVP transmitter proxy318. The conversion of SDP specified information into a format for storing at the session table600depends on the particular flowspec being used. Here, for example, the specified bandwidth, i.e., 128 Kb/s, is preferably used as the token bucket rate [r] value, while default values are utilized for the remaining parameters, e.g., token bucket size [b], peak data rate [p], etc. Manager328may have a store (not shown) of default values, which may vary depending on the type of stream, e.g., audio, video, etc. If the response message510does not include any bandwidth information, manager328may similarly load table600with default information.

Assuming the client204, upon reviewing the session description information contained in the RTSP Describe Response message510, is interested in receiving the corresponding stream or presentation, it next issues an RTSP Setup Request message for each stream that makes up the presentation. The Setup Request message basically contains the transport initialization information for the stream.

FIG. 5Cis an exemplary RTSP Setup Request message530. Message530includes an initial line532that specifies the type of RTSP message, e.g., Setup, and specifies the URI for the media stream to be established. A second header line534specifies the sequence number for use in matching the request message with a response from the server202. It also includes a third header line536containing the transport initialization information. More specifically, header line536specifies a transport protocol, such as the Real-time Transport Protocol (RTP)/Audio Visual Profiles (AVP). It also specifies the transmission mode, such as unicast or multicast, and the client's port number or numbers to which the respective stream is to be directed. The RTSP Setup Request message530is routed to the multimedia server202which determines whether or not the transport initialization information from the client204is acceptable or not and, in either case, responds with an RTSP Setup Response message.

FIG. 5Dis a highly schematic representation of an RTSP Setup Response message540. It has a first header or status line542which may indicate that the RTSP Setup Request message540succeeded, i.e., it may include the code “200”. A second header line544returns the same CSeq number to the client204, and a third header line546may provide the date. A fourth header line548specifies the identifier for the session as selected by the multimedia server202. A fifth header line550specifies the transport initialization information accepted by the server202. More specifically, fifth line550notes that the transport protocol, RTP/AVP, and transmission mode, unicast, as suggested by the client204are acceptable to server202. Fifth line550of message540also returns the client port number(s), e.g.,4588-4589, as a check, and specifies the server's port number(s), i.e.,6256-6257, for the stream or presentation.

Both of these messages530,540are preferably captured by the server's first hop router206and examined by the packet/frame classification engine304which determines what types of messages they are, i.e., RTSP Setup Request and Response messages. From the Setup Request message530, the packet/frame classification engine304extracts a copy of the URI for the session. From the Setup Response message540, the packet/frame classification engine304extracts a copy of the session identifier (ID) and the client and server port numbers. This information is provided to the RSVP transmitter proxy318, which passes it to the media session manager328for loading into the respective cells of the corresponding entry630of session table600.

It should be understood that the packet/frame classification engine304and/or the RSVP transmitter proxy318may store at least temporarily the CSeq values of RTSP messages so that message pairs can be matched together. This allows the URI specified in the Setup Request message530to be matched with the right client and server port numbers, which are specified in the matching Setup Response message540.

It should be further understood that other methods may be used to obtain the description of a stream or presentation, such as another protocol besides RTSP, e.g., HTTP, email applications, etc., or via command line or standard input helper applications.

It should also be understood that the packet/frame classification engine304may send information directly to the media session manager328or that the media session manager328may be incorporated within the RSVP transmitter proxy318.

At this point, the RSVP transmitter proxy318“knows” among other things the “5-tuple traffic flow characteristics” for the stream or session, i.e., the source and destination IP addresses, the source and destination port numbers, and the transport layer protocol, e.g., TCP, UDP, etc. It also knows the URI and the bandwidth for the stream or session, among other things.

Next, the RSVP transmitter proxy318may select or otherwise obtain a Differentiated Services Codepoint (DSCP) for the identified stream or presentation, as indicated at block406. As described below, the DSCP may be used to provide additional granularity in the admission control decision made by intermediate devices along the route to client204. To obtain a DSCP, the RSVP transmitter proxy318may provide some identifying characteristics of the stream, such as the 5-tuple traffic flow characteristics, the bandwidth, whether the stream represents audio and/or video traffic, etc. to the DiffServ entity332. The DiffServ entity322preferably performs a lookup on its DSCP table334to find the DSCP value matching the characteristics specified by the RSVP transmitter proxy318. The matching DSCP is then returned to the RSVP transmitter proxy318.

Using the DSCP value returned by the DiffServ entity332and the 5-tuple traffic characteristics of the stream, the RSVP transmitter proxy318, as indicated at block408, generates an RSVP Path message on behalf of the multimedia server202which, as described above, lacks RSVP facilities. The RSVP Path message preferably includes a plurality of objects, such as a session object, a sender template object, a sender Tspec object, and a DCLASS object. It may also include an adspec object.

FIG. 7is a highly schematic block diagram of the RSVP Path message700generated by the RSVP transmitter proxy on behalf of multimedia server202. The RSVP Path message700includes a header702and, as indicated above, a session object704, a sender template object706, a sender Tspec object708and a DCLASS object710each of which comprises a plurality of fields. More specifically, as provided in RFC 2205, the RSVP header702has a version field712, a flags field714, a message type field716, an RSVP checksum field718, a Send Time To Live (TTL) field720, a reserved field722and an RSVP length field724. Fields712-724are preferably loaded in a conventional manner.

The session object704has a length field730(loaded with the length of the respective object), a class number field (C-Num)731and a class type (C-type) field732. It further includes an IP destination address (DA) field734, an IP protocol identifier field735, a flags field736, and a destination port number field737. The sender template object706has a length field740(loaded with the length of the respective object), a class number field (C-Num)741and a class type (C-type) field742. It further includes an IP source address (SA) field743, a source port number field744and may include one or more un-used fields. The sender Tspec object708also includes length748, class number749and class type750fields. It further includes a token bucket rate field760, a token bucket size field761, a peak data rate field762, a minimum policed unit field763and a maximum packet size field764, among others. The DCLASS object710similarly includes length770, class number771and class type772fields. It also includes one or more DSCP fields, such as first and second DSCP fields773and774, which are each used to carry a DSCP value.

The RSVP transmitter proxy318loads the RSVP Path message700with the 5-tuple traffic characteristics that it identified for the stream. More specifically, the IP destination address and destination port(s) for client204are loaded into fields734and737. The transport layer protocol is loaded into field735. The IP source address and source port(s) for server202are loaded into fields743and744of the sender template object706. The token bucket rate, token bucket size and peak data rate as determined from the SDP file for the stream are loaded into fields760-762of the sender Tspec object708. The DSCP value returned by the DiffServ entity332is loaded into one of the DSCP fields, e.g., first DSCP field773, of the DCLASS object710. The remaining fields of the RSVP Path700message are preferably loaded in a conventional manner.

Router206, on behalf of server202, then sends the RSVP Path message700to client204. The RSVP Path message700, which runs directly over the Internet Protocol, is examined by each intermediate device along the route from router206to client204that supports RSVP, including routers210,212and one or more intermediate devices located in the network cloud208. At each hop, the intermediate device processes the RSVP Path message700by installing RSVP path state information regarding the pending reservation request, as indicated at block410. This information includes the IP address and destination port from session object704and the IP address and source port of the multimedia server202from the sender template object706. In the preferred embodiment, the intermediate device also stores the DSCP value from the DCLASS object710.

The RSVP Path message700is eventually received by client204and/or its proxy. Assuming the client204wants to have resources reserved to support the session, it responds with an RSVP Reservation (Resv) message, as indicated at block412. The RSVP Resv message contains a session object, which is similar to session object704, a filter spec object, which is similar to sender template object706, and a flowspec object, which is similar to the sender Tspec object708. The session object of the Resv message contains the IP destination address and transport layer destination port(s) for client204, as described above in connection with session object704. The filter spec object is loaded with the IP source address and source port(s) for the multimedia server202. The flowspec object specifies the resources, e.g., the bandwidth, that the client204requests to be reserved for the stream from multimedia server202. Specifically, the client204loads the flowspec object with the bandwidth that it requests in support of the stream and/or session with the multimedia server202. Specifically, the client204enters a token bucket rate, a token bucket size and a peak data rate into the flowspec object. The bandwidth requested by the client204is typically the bandwidth that was recommended by the multimedia server202in the sender Tspec object708. However, the client204may request a different bandwidth.

Client204sends the RSVP Resv message to the multimedia server202hop-by-hop. That is, the Resv message is first addressed and sent to router210, which processes it. Router210as well as router212, in addition to having their own RSVP facilities, also include policy control and admission control entities. When the RSVP Resv message is received at router210, it is passed to the router's RSVP facilities for processing. The RSVP facilities first match up the request of the Resv message with the RSVP state that was installed in response to the RSVP Path message700from router206. Then, using the contents of the session and filter spec objects, the RSVP facilities at router210query the policy control entity to determine whether the user, e.g., client204, has administrative permission to make the reservation specified in the RSVP Resv message, as indicated at decision block414. The RSVP facilities also use the contents of the flowspec object to query the admission control entity to determine whether router210has sufficient available resources to support the requested reservation, as also indicated at block414.

In performing the admission control determination, one or more network devices along the route to client204may utilize the DSCP value from DCLASS object710as well as the bandwidth information from the flowspec object, as indicated at decision block416. Suppose, for example, that the network that includes client204and router210has entered into an SLA with network cloud208. Suppose further that this SLA provides that traffic carrying a particular DSCP value is limited to some predefined bandwidth, e.g., 100 Kbps. When the RSVP Resv message is received at edge router212, the admission control entity utilizes not only the bandwidth specified in the reservation request, but also the DSCP value that was specified in the DCLASS object710of the corresponding Path message700to make a decision as to whether the reservation request passes admission control. That is, even though the resources available at the network device, e.g., number of priority queues, queue selection strategy, speed of link, etc., are sufficient to satisfy the reservation request, other streams using the same DSCP value may have already reserved all of the resources that can permissibly be allocated to this DSCP value.

If the requested reservation fails to pass policy and/or admission control at any given intermediate device along the route to server202, the Resv message is dropped and a RSVP Reservation Error (ResvErr) message is returned to the client204, as indicated by No arrow418leading to block420. The ResvErr message informs client204that the reservation request has failed. Client204may then decide whether or not to go forward with the presentation knowing that sufficient resources have not been reserved in advance. Similarly, if the specified DSCP will not support the bandwidth requested by client204, the respective device drops the Resv message and returns a ResvErr message to client, as indicated by No arrow422which also leads to block420.

Assuming the reservation request represented by the RSVP Resv message passes both the policy and admission control entities, and the DSCP value, if tested, passes admission control, the respective intermediate device, e.g., router210, reserves the requested resources, updates the RSVP path state for the anticipated traffic and forwards the RSVP Resv message to the next device on the route toward the server202, as indicated at block424(FIG. 4B). The RSVP Resv message is thus propagated hop-by-hop toward the server202. At router206, the Resv message is intercepted, as indicated at block426. In particular, the packet/frame classification engine304determines that it is an RSVP Resv message and, accordingly, forwards it to the RSVP transmitter proxy318for processing. The RSVP transmitter proxy318parses the Resv message.

Specifically, the RSVP transmitter proxy318examines the session, flowspec and filter spec objects, and performs its own policy and admission control evaluation and passes this information to the RSVP state machine engine322so that it may update the RSVP state established for this session, as indicated at block428. The RSVP transmitter proxy318also programs or directs the packet/frame classification engine304to look for messages matching the traffic flow characteristics for this session. More specifically, it provides the packet/frame classification engine304with the 5-tuple traffic characteristics which are used by the packet/frame classification engine304to search network traffic received at router206. The RSVP transmitter proxy318also directs the traffic scheduler306to apply the resources necessary to provide the bandwidth requested in the flowspec object from the RSVP Resv message to the network traffic matching the specified 5-tuple traffic characteristics. Because the associated RSVP Path message700was issued by router206on behalf of server202, the RSVP transmitter proxy318does not forward the RSVP Resv message to server202. Instead, the RSVP Resv message is terminated at router206, as also indicated by block426.

To start the session, the client204preferably issues an RTSP Play Request message to the multimedia server202. The multimedia server202responds with an RTSP Play Response message and then begins streaming the session to the client204through a plurality of packets generated by the multimedia server202. These packets travel along the route established by the RSVP Path and Resv messages through network100and thus receive the resources reserved for the stream or session by the intermediate devices disposed along this route. Router206may snoop the RTSP Play Request and Play Response messages exchanged between client204and router202, and update the RTSP state stored at column622for this entry630. In particular, it may transition the RTSP state from “ready” to “playing”.

To the extent a DSCP value was obtained by the RSVP transmitter proxy318, this value is preferably loaded into DS field122(FIG. 1B) of packets carrying the stream. DS field122may be loaded by server202or by router206. That is, router202may notify server202of the DSCP value that was obtained, and server202may load this value into DS field122.

The RSVP transmitter proxy318monitors the RTSP state to determine whether resources reserved pursuant to the Path and Resv messages should remain allocated to the stream, as indicated at decision block430. In other words, the router206monitors RTSP messages to see whether the stream or session is still active. Assuming the stream is still active, RSVP transmitter proxy318periodically refreshes the RSVP path state for the stream, as indicated at block432. More specifically, to maintain the reservation of resources allocated to the stream or session, the RSVP transmitter proxy318periodically issues new RSVP Path messages700to client204. As described above, these Path messages are processed by the RSVP-aware intermediate devices as they travel along the route and to the client204. Client204responds with an RSVP Resv message. The Resv message keeps the RSVP path states established by the intermediate devices from timingout which could result in a deallocation of the resources initially reserved for the stream or session.

When the client204has completed viewing and/or listening to the stream or session from multimedia server202, it preferably issues one or more RTSP Teardown Request messages to the server202, and server202responds with an acknowledgement. The packet/frame classification engine304at router206is preferably configured to snoop such messages and to forward copies to the RSVP transmitter proxy318. In response to an RTSP Teardown Request message and an acknowledgement, the RSVP transmitter proxy318changes the RTSP state stored at column622for this entry630, thereby indicating that the stream is no longer active. In response to the stream becoming inactive, the RSVP transmitter proxy318issues an RSVP PathTear message to the client204, as indicated at block426. The client204may respond with an RSVP ResvTear message, thereby causing the intermediate devices along the route to server202to deallocate the resources that had been reserved for the stream. Alternatively, the RSVP transmitter proxy318may simply stop issuing periodic RSVP Path messages, thereby causing the corresponding RSVP path states to time out.