WO2000067444A2

WO2000067444A2 - Method and apparatus for protocol conversion

Info

Publication number: WO2000067444A2
Application number: PCT/US2000/010563
Authority: WO
Inventors: Robert Charles Booth
Original assignee: General Instrument Corporation
Priority date: 1999-04-30
Filing date: 2000-04-19
Publication date: 2000-11-09
Also published as: AU4472600A; CA2371624A1; TW529259B; WO2000067444A3; EP1175764A2

Abstract

A protocol agent (135, 160) for a broadband communication network accommodates data that is provided using different protocols. Data is received from protocol handlers (130, 165) at a client (115) or server (105). An identifier (565, 682) is attached (240, 315) to the data (570, 684), to identify the protocol thereof, whether encoding was applied and, if so, which type, and whether encryption/signing was applied and, if so, which type. The data with the attached identifier is communicated, e.g., from a client (115) to a server (105), or from a server (105) to a client (115). Available communication paths include one-way, e.g., broadcast or multicast (462, 465, 470), or dedicated upstream path (475), and two-way, e.g., an interactive path such as a computer network or telephone link (485) using TCP or UDP, or a cable television upstream path (480). At the receiving end, the protocol identifier (565, 682) is filtered (215, 340) to apply decryption/signature verification, and/or decoding, and to forward the data to an appropriate counterpart protocol handler (130, 165).

Description

METHOD AND APPARATUS FOR COORDINATING AND FILTERING ON INTERACTIVE AND BROADCAST PROTOCOLS IN BROADBAND NETWORK ENVIRONMENTS

BACKGROUND OF THE INVENTION

This application claims the benefit of U.S.

Provisional Application No. 60/131,807, filed April 30, 1999.

The present invention relates to broadcast and interactive multimedia and secure E- commerce, and particularly to such features provided by cable television set-top terminals and systems.

The following acronyms and terms are used: ASIC - Application Specific Integrated Circuit ATM - Asynchronous Transfer Mode CD - Compact Disc

CMTS - Cable Modem Termination System CPS - Cable Proxy Server CRC - Cyclic Redundancy Check DES - Data Encryption Standard DOCSIS - Data-Over-Cable Service Interface Specifications

DSL - Digital Subscriber Loop DVD - Digital Video Disk E - Encrypted EPG - Electronic Program Guide

GIF - Graphical Interchange Format HMTP - Hypermedia Transfer Protocol HTML - Hyper Text Markup Language HTTP - Hyper Text Transport Protocol HVML - Hyper Video Markup Language

ID - Identifier

IP - Internet protocol

IRD - Integrated Receiver-Decoder IRT - Integrated Receiver Transcoder

ITXP - Interactive Transport Protocol

JPEG - Joint Photographic Experts Group

MAC - Medium Access Control

MPEG - Moving Picture Experts Group MPS - Modular Processing System

NC - Network Controller

OM - Out-of-band Modulator

PC - Personal Computer

PID - Packet Identifier PDU - Protocol Data Unit

RF - Radio Frequency

RPD - Return Path Demodulator

TCP - Transmission Control Protocol

TELCO - Telephone Company UDP - User Datagram Protocol

UHTTP - Unidirectional HyperText Transport Protocol

VBI - Vertical Blanking Interval

VCR - Video Cassette Recorders VOD - Video On Demand

VRL - Virtual Resource Locator

WWW - World Wide Web

A set-top terminal, also referred to as an IRD or a subscriber terminal, is a device that receives and decodes television signals for presentation by a television. The signals can be delivered over a satellite, through a cable plant, by means of terrestrial broadcast, and/or via a computer network such as the Internet .

Recently, there has been a trend to incorporate additional features and capabilities into conventional broadband networks. These features include VOD, pay- per-view, interactive shopping, electronic commerce,

Internet connectivity and Internet-based telephony. In particular, the development of cable modems has enabled computer network resources, such as Internet resources, to be integrated into television networks . However, the provision of both interactive and broadcast data in a broadband network raises various issues, including the need for compatibility with different communication protocols, and the need to optimize available bandwidth. Accordingly, it would be desirable to provide a system that addresses the above and other issues .

The system should be usable, e.g., in wireless, satellite, cable, or any telecommunication system. More particularly, the system should be usable with all digital set-top terminals, or any device that supports video, audio, or WWW content (e.g., a personal computer, network computers, VCRs , DVD players, CD players, IP telephones, video phones, web phones, etc.) . Such devices may be connected, either directly or indirectly, to a broadband network.

The system should provide a common mechanism for coordinating and routing interactive and broadcast protocol data using all available data pipes within a network. This includes analog VBI data channels, Out- of-Band and In-band downstream data channels, such as those using the MPEG or similar DigiCipher II standard, proprietary to the assignee hereof, upstream channels, such as those using a random access contention protocol such as ALOHA, and two-way communications, such as those using DOCSIS (for cable modems) or a telephone link (for elco modems) .

The system should coordinate broadcast and interactive data, such as video data, and Internet data such as WWW content, on devices connected to a network.

The system should ensure the privacy of end user data requests and responses between end-user terminals, proxy servers, and origin servers. The system should optimize the use of a cable operator's upstream and downstream network bandwidth.

The system should reduce the cost of supporting new services in set-top terminals.

The system should improve upon existing solutions that use currently defined industry standard TCP/IP protocols and HTTP message formats for handling server requests and responses on broadband networks.

The present invention provides a system having the above and other advantages .

SUMMARY OF THE INVENTION

In accordance with the present invention, an Interactive Transport Protocol (ITXP) is provided to establish a baseline framework for message handling in communication networks, e.g., such as broadband networks. For example, the invention can be used in connection with set-top terminals for cable television, satellite television, wireless, Ethernet, Firewire, twisted pair, infrared, or ATM/xDSL services. A common mechanism is disclosed for coordinating and routing interactive and broadcast protocol data using existing data pipes within broadband networks, including out-of- band and in-band downstream data channels, upstream channels, cable modem two-way communications, and analog VBI data.

Currently there is a need to coordinate broadcast and interactive video and internet data on devices connected to broadband networks . Examples of such devices include: 1) broadcast only digital set-top terminals using MPEG-2 transport or 2) interactive digital set-top terminals authorized to use DOCSIS cable modems, ALOHA upstream capabilities, or a telephone modem, in addition to using MPEG-2 transport. The present invention allows existing broadcast only or interactive digital set-top terminals to support web protocols, such as HTTP.

In addition, the invention provides the flexibility to enable new or future protocol definitions to meet the demands of the broadband networks. One such example is the Hypermedia Transfer Protocol (HMTP) , proprietary to the assignee hereof. HMTP more effectively handles the coordination of broadcast and interactive video content on broadband networks than existing protocols such as HTTP.

The invention also addresses the current need in broadband cable network environments to ensure the privacy of end user data requests and responses between end-user terminals, proxy servers, and origin servers. The present invention allows various encryption mechanisms to be applied to data content protocols such as HTTP and HMTP and the content that is carried within those protocols. For example, the well known DES, as well as public, private and single key systems can be used for such encryption.

Additionally, the invention optimizes the use of a cable operator's upstream and downstream network bandwidth by providing a mechanism for allowing various encoding schemes to be applied to application level protocols (i.e., data content protocols) such as HTTP and HMTP.

Moreover, the invention reduces the cost of supporting new services in set-top terminals. Current plans for enhanced digital set-tops generally include cable modem hardware chips, an additional tuner, and TCP/IP software consuming memory in the terminal. The present invention provides a mechanism wherein, if the required functionality is to support the HTTP protocol in the terminal (or a more efficient protocol producing the same results) , additional hardware as listed above is not required in the terminal . This reduces the cost of deploying such systems. The system improves upon existing solutions that are all using currently defined industry standard TCP/IP protocols and HTTP message formats for handling server requests and responses on broadband networks. The novel approach of the present invention provides a more efficient and flexible mechanism for supporting the HTTP protocol, or other data content protocols such as HMTP. The invention: 1. Provides the framework for a new, very scaleable broadband proxy server, such as, for example, a headend Cable Proxy Server (CPS) ;

2. Defines an efficient mechanism for allowing the encryption and decryption of interactive and broadcast protocol data in various broadband networks, thereby allowing cable operators to deploy secure interactive and broadcast data solutions, such as encrypted broadcast web pages, secure e-commerce transactions, and secure e-mail on their broadband networks. A per- transaction licensing fee for use of the secure e- commerce transaction mechanism can be provided;

3. Defines a mechanism that allows interactive and broadcast messages, such as Hypertext Transfer Protocol

(HTTP) , to be encoded in a manner that preserves network bandwidth. In addition, this mechanism reduces the processing power and memory required in end-user terminals/devices, proxy servers, and origin data servers to handle such messages. This, in turn, provides more attractive and cost effective solutions to cable operators; and

4. Defines a mechanism that can be implemented in either software or in an efficient and cost effective hardware application specific integrated circuit (ASIC) to handle the processing of this novel functionality in client and server devices.

In a specific embodiment, a sending client or server agent receives input data and processes it in some manner to provide output data. As a minimum, the agent attaches an identifier to the output data to designate the protocol in which it is provided. The protocol of the output data may be unchanged from that of the input data. Or, the agent may encode the input data to change its protocol, in which case the identifier designates the encoding that was applied. The agent may also apply encryption/signing to the input data, in which case the identifier designates the encryption/signing that was applied. At a receiving client or agent server, the attached information is examined to determine which counterpart operations should be performed to recover the data in the same condition in which it was input to the sending client or server agent. The recovered data can then be routed to the appropriate protocol handler.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high level overview of the ITXP framework used within a digital network in accordance with the present invention. FIG. 2 illustrates the ITXP client agent functional elements in accordance with the present invention.

FIG. 3 illustrates the ITXP server agent functional elements in accordance with the present invention. FIG. 4 illustrates an example broadband cable configuration capable of supporting ITXP in accordance with the present invention.

FIG. 5 illustrates an example of how ITXP messages can be delivered over an MPEG-2 private data stream in accordance with the present invention. FIG. 6 illustrates an example of how ITXP messages can be delivered over a DOCSIS-based TCP/IP socket connection in accordance with the present invention. FIG. 7 illustrates example data paths within an ITXP enabled client connected to a broadband cable network in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to an Interactive Transport Protocol (ITXP) for message handling in communication networks . Since the invention is network independent, as new mechanisms for transporting data across cable plants are deployed, the content developed using the invention can simply be re-directed over any new digital data paths established. The invention can be implemented using software written for existing hardware, or an ASIC for handling the processing of this novel functionality in client and server devices, which may be a more efficient and cost-effective approach.

Moreover, as mentioned, a DOCSIS cable modem, additional tuner, and/or TCP/IP software stack are not required to implement the invention. However, additional tuners, MPEG packet processors, and cable modems make the invention much more flexible. Enhancements to both hardware and software can improve the performance of this functionality, e.g., such as building a dedicated hardware ASIC to support the ITXP protocol format may result in a more efficient and cost effective solution.

The invention can be used as a standard to define how a browser on a PC can access video and audio content via a cable television network (or other information network) through the use of a digital video PC card, a cable modem or any in-home network connected to a set- top terminal. Likewise, any device can use the invention to more efficiently process HTTP (or HMTP) requests and responses. For example, a video phone can use the invention to send a request to establish a video conferencing session through a cable network via a physical connection to a set-top terminal or a cable modem. Other examples include VCRs, DVD players, stereo tuners, CD players, flat panel televisions, etc., that can all use the invention for more efficiently processing HTTP (or HMTP) requests and responses.

Since the invention is network independent, it allows more efficient use of network bandwidth via telephone modem connections, xDSL connections, IEEE 802.3 (Ethernet) networks, etc.

In addition, existing Internet Proxy and Origin Servers can be updated to support the ITXP protocol on a well-defined IP port number. This, in turn, enables the servers to support 1) any efficient encoded formats of application protocols, such as encoded HTTP or encoded HMTP, resulting in the support of more end users, or 2) any encryption and decryption mechanisms that can be applied to the application protocols and/or the data encapsulated within these protocols. ITXP provides a baseline framework for message handling in broadcast and interactive environments. The figures illustrate how ITXP can be used in digital networks, specifically broadband digital cable networks. In addition, diagrams are included showing the internal functional elements within the ITXP layers.

FIG. 1 provides a high level overview of the ITXP framework used within a digital network. The ITXP functional model 100 consists of three major network components that distribute content between content providers and content users. The network components include digital network servers 105, a digital network 110, and digital network clients 115.

The server component 105 includes an example content provider 120, a content handler 125, protocol handlers 130 -that are compatible with different communication protocols, an ITXP server agent 135, a path 132, and a broadcast data streaming function 140. The network component 110 includes a broadcast path

145 for broadcast network data, and a two-way path 150 for interactive network connections.

The client component 115 includes a broadcast data stream handler 155, an ITXP client agent 160, protocol handlers 165, a path 162, content handlers 170, and a content user 175.

The ITXP client agent 160 can receive data from either the broadcast network connections 145, the interactive network connections 150, or client-side protocol handlers 165.

FIG. 2 shows the functional elements of the ITXP client agent 160 of FIG. 1.

Like-numbered elements correspond to one another in the figures. The ITXP client agent 160 includes a decrypt and/or verify signature functions 205 with a bypass path 210, a filter protocol ID function 215, and a decode data function 225 with a bypass path 225. An encrypt and/or sign data function 230 with a bypass path 235, attach protocol ID function 240, and an encode data function 245 with bypass path 250 are also provided.

If data is received from either the broadcast path 145 or the interactive network connections 150 via a mux 147, the filter protocol ID function 215 filters on a protocol identifier within the ITXP header in the data to determine which protocol handler 165 must be used to process the data. In addition, the ITXP client 160 may decode encoding formats at decoder function 220, or decrypt encryption schemes and/or verify any digital signatures applied to some or all of the data at decrypt/verify function 205 before handing the data off for processing by an appropriate protocol handler 165. Analogously, if data is received from a protocol handler via path 162, the ITXP client agent 160 identifies the protocol handler that passed the data to it by attaching a protocol identifier within an ITXP header at attach protocol ID function 240 before transmitting the data across the interactive network connection 150. Optionally, the ITXP client 160 may encode the data at encode function 245, or encrypt and/or apply a digital signature to some or all of the data at encrypt/sign function 230 before continuing with transmission across the interactive network 150. Appropriate control techniques, including switches and the like, can be used to route the data via the bypass paths 210, 225, 235 and 250.

FIG. 3 shows the functional elements of the ITXP server agent 135 of FIG. 1. The ITXP server agent 135 includes a decrypt and/or verify signature functions 345 with a bypass path 350, a filter protocol ID function 340, and a decode data function 330 with a bypass path 335. An encrypt and/or sign data function 320 with a bypass path 325, attach protocol ID function 315, and an encoder data function 305 with bypass path 310 are also provided.

The ITXP server agent 135 can send data to the broadcast network connections 145, interactive network connections 150, or server-side protocol handlers 130. The ITXP server agent 135 can also receive data from interactive network connections 150 or from the server- side protocol handlers 130 via path 132.

If data is received from the interactive network connection 150, the filter protocol ID function 340 filters on a protocol identifier (ID) within the ITXP header of the data to determine which protocol handler 130 must be used to process the data. In addition, the ITXP server agent 135 may decode encoding formats at the decode data function 330, or decrypt encryption schemes and/or verify any digital signatures applied to some or all of the data at the decrypt/verify function 345 before handing the data off for processing by a server- side protocol handler.

If data is received from a server-side protocol handler, the attached protocol ID function 315 identifies the protocol handler that passed the data to the ITXP server agent 135 by attaching a protocol ID within an ITXP header of the data before transmitting the data across the broadcast path 145 or interactive network connections 160 to the client. In addition, the ITXP server agent 135 may encode the data at the encode data function 305, or encrypt and/or apply a digital signature to some or all of the data at the encrypt/sign function 320 before continuing with transmission across the broadcast path 145 or interactive network connections 150 via a demux 327.

Appropriate control techniques, including switches and the like, can be used to route the data via the bypass paths 310, 325, 335 and 350.

FIG. 4 shows a broadband cable network configuration 400 that is capable of supporting ITXP. The configuration 400 includes a CPS 425 that communicates, for example, with a controller 405, an EPG data function 410, WWW and other Internet servers 415, and other ITXP-capable servers 420.

The CPS 425 also communicates with example headend components, including, for example, a VBI data insertion function 427, an IRT 430, a MPS 435, an OM 440, a NC 445, an RPD 450, a CMTS 455, and a modem bank 460. The VBI data insertion function 427 provides VBI data 462 downstream. The IRT 430 and MPS 435 provide downstream in-band MPEG data streams 465 to an example digital cable terminal 490 in a terminal population, and optionally to other in-home network devices 495. The MPS 435 is also known as a broadcast data router or in- band data router. The ITXP client agent 160 can be provided in the terminal 490. The OM 440 provides downstream out-of-band MPEG data streams 470 to the terminal 490.

For upstream communications, the RPD 450 receives ALOHA upstream data 475 from the terminal 490.

For bi-directional communications, the CMTS sends/receives DOCSIS data 480, and the modem bank 460 sends/receives telco data 485, e.g., in a conventional telephone link. Within a broadband cable environment, the ITXP server agent 135 may exist within the CPS 425, and the ITXP client agent 160 may be present within the digital cable terminals 490. However, the digital cable terminals 490 may also include an ITXP server agent to support other ITXP- capable in-home network client devices. The term "digital cable terminal" or the like in this context represents any device that can be connected to a cable head-end via a RF connection. In a typical mode of operation, the CPS 425, containing the ITXP server agent 135, delivers ITXP messages to digital cable terminals via MPEG-2 transport streams (e.g., streams 465 and 470), UDP/IP socket connections, or TCP/IP socket connections. FIG. 5 shows an example of how ITXP messages can be delivered over an MPEG-2 private data stream.

An example 188 -byte MPEG packet 500 includes a sync field 505, a PID 510, scrambling, adaptation and continuity fields 515, and a payload 520. A number of transport packets 530 are shown including packets 535, 540 and 545. An MPEG-2 private data stream 550 is constructed from the number of transport packets 530 and includes a HYPER MEDIA Message type 555, a first field 560 for private message information, an ITXP message field 565, a field 570 for HTTP/HMTP/UHTTP, etc., a field 575 for data, graphics, audio, video, etc., another field for private information 580, and a CRC field 585. The example uses a new HYPER MEDIA message type

(field 555) that indicates that the following data (field 565) may include an ITXP message, such as an ITXP header that specifies a protocol ID of the application protocol that follows in the message, and/or a type of encoding applied by an ITXP server agent or client agent, and/or a type of encryption/signing applied by an ITXP server agent or client agent, as discussed previously. For example, the ITXP message 565 identifies one of several supported application level data protocols 570 (e.g. HTTP, HMTP, UHTTP or any other application protocol) . In this case, A HYPER MEDIA message can be sent to a terminal via any device capable of delivering MPEG-2 transport packets, either in-band or out-of-band. For example, HYPER MEDIA messages can be sent from the CPS 425 of FIG. 4 to the OM 440, IRT

430, or MPS 435 as MPEG-2 packets. Each device (OM, IRT, or MPS) inserts the MPEG-2 packets that make up the HYPER MEDIA message into the particular broadband multiplex managed by that device.

FIG. 6 shows an example of how ITXP messages can be delivered over a DOCSIS-based TCP/IP socket connection. A 188-byte MPEG packet 600 includes the fields 505, 515 and 520 discussed previously, along with a DOCSIS PID (with the value OxlFFE) field 510. A number of transport packets 630 are shown including packets 632, 634 and 636. A DOCSIS MAC frame 640 includes a header 642 and a packet PDU 644. An Ethernet- type PDU 650 includes a destination address 652, a source address

654, a type/length field 656, and a user data field 658, which may be from, e.g., 0 to 1500 bytes. An IP layer 660 includes an IP header 662 and IP data 664, such as a TCP segment . A TCP layer 670 includes a TCP header 672 and TCP data 674. Lastly, the TCP data 674 includes an ITXP field 682, such as an ITXP header that includes information for designating the protocol ID, encoding, and/or encryption/signing status of the protocol data present in field 684 (i.e. HTTP, HMTP, or UHTTP), a HTTP/HMTP/UHTTP field 684, and a field 688 for data, graphics, audio, video, etc. The ITXP message 682 thus identifies the data 684 as being provided according to an HTTP, HMTP, UHTTP or other protocol. The ITXP message may further designate, if applicable, what type of encoding and encryption/signing was applied to the data that is input to a client or server agent. FIG. 7 shows example data paths within an ITXP enabled client agent 760 connected to a broadband cable network. The agent 760 includes a VBI data processor 762, in-band MPEG packet processors 765, out-of-band MPEG packet processors 770, ALOHA upstream data processors, a DOCSIS cable modem 780, and a Telco Modem 785. An ITXP processor/switch 715 communicates with a HYPER MEDIA message function 705 and a TCP/IP function 710. The ITXP processor/switch 715 routes data to, and receives data from any one or more of a number of protocol functions, such as an HTTP function 720, an E-HTTP function 722, an HMTP function 724, an E-HMTP function 726, a UHTTP function 728, and a reserved function 730 for future needs. UHTTP refers to uni-directional (downstream) HTTP. The TCP/IP function 710 can also communicate with any one of these functions 720-730 directly .

The functions 720-730, in turn, can communicate with any one or more of applications functions, including an HTML function 732, an E-HTML function 734, an HVML function 736, an E-HVML function 738, a JPEG function 740, a GIF function 742, Java Applets 744, and any other desired functions 746.

Accordingly, it can be seen that the present invention provides a mechanism for coordinating and routing interactive (two-way), broadcast (downstream), and upstream protocol data. The interactive data may be provided, e.g., via a cable modem or a telephone company modem. The cable modem may operate according to the DOCSIS protocol. Moreover, both the cable modem and telco modem may communicate using the TCP/IP protocol, such as is commonly used to communicate Internet data. The broadcast data may be provided, e.g., as in-band and/or out-of-band MPEG data streams, or as analog VBI data. The upstream data may be provided, e.g., using the ALOHA network contention protocol.

Furthermore, the invention uses existing data paths within broadband networks.

Optionally, the invention can be used in transferring data, e.g., via a data queue between two processes on the same device or machine.

Although the invention has been described in connection with various specific embodiments, those skilled in the art will appreciate that numerous adaptations and modifications may be made thereto without departing from the spirit and scope of the invention as set forth in the claims .

Claims

What is claimed is:

1. A protocol agent apparatus in a communication system, comprising: means for receiving input data from at least one protocol handler,- means for processing the input data to provide corresponding output data according to a desired data protocol ; wherein said processing means comprises means for attaching at least one identifier to the output data to identify the desired data protocol thereof; and means for providing the output data with the at least one attached identifier to at least one client or server via the system.

2. The apparatus of claim 1, wherein: said processing means comprises means for encoding the input data to provide it in the desired data protocol ; wherein the desired data protocol differs from a protocol in which the input data is provided from the protocol handler.

3. The apparatus of claim 2, wherein: said processing means comprises means for bypassing said encoding means when the desired data protocol corresponds to the protocol in which the input data is provided from the protocol handler.

4. The apparatus of claim 2, wherein: the at least one attached identifier further designates the protocol in which the input data is provided from the protocol handler.

5. The apparatus of claim 1, wherein said processing means comprises: means for encrypting and/or signing the input data; wherein the attaching means attaches at least one identifier to the output data to identify the encryption and/or signing that was applied.

6. The apparatus of claim 5, wherein: said processing means comprises means for bypassing said encrypting and/or signing means .

7. The apparatus of claim 1, wherein: the protocol handler is provided at a server; and the output data with the at least one attached identifier is provided to at least one client.

8. The apparatus of claim 7, wherein-. the output data with the at least one attached identifier is provided to the at least one client using at least one of a unidirectional protocol and a bidirectional protocol .

9. The apparatus of claim 8, wherein: the at least one of a unidirectional protocol and a bi-directional protocol is provided via an out-of-band downstream data channel of a network.

10. The apparatus of claim 8, wherein: the at least one of a unidirectional protocol and a bi-directional protocol is provided via an in-band downstream data channel of a network.

11. The apparatus of claim 7, wherein: the output data with the attached identifier is provided to the at least one client using one of broadcast, multicast, and single-cast communication.

12. The apparatus of claim 11, wherein: the protocol of the broadcast, multicast, or single-cast communication uses a packetized transport stream standard.

13. The apparatus of claim 11, wherein: the protocol of the broadcast, multicast, or single-cast communication uses an analog vertical blanking interval of a television signal to carry the output data.

14. The apparatus of claim 11, wherein: the protocol of the broadcast, multicast, or single-cast communication carries the output data using at least one of: a User Datagram Protocol (UDP) , a Transmission Control Protocol (TCP) , and an Internet Protocol (IP) .

15. The apparatus of claim 1, wherein: the protocol handler is provided at a client; and the the output data with the at least one attached identifier is provided to at least one server.

16. The apparatus of claim 15, wherein: the output data with the at least one attached identifier is provided to the server using at least one of a unidirectional protocol and a bi-directional protocol .

17. The apparatus of claim 15, wherein: the output data with the at least one attached identifier is provided to the server using one of broadcast, multicast, and single-cast communication.

18. The apparatus of claim 17, wherein: the broadcast, multicast, or single-cast communication carries the output data using at least one of: a User Datagram Protocol (UDP), a Transmission Control Protocol (TCP), and an Internet Protocol (IP) .

19. The apparatus of claim 15, wherein: the output data is provided according to at least one of a cable modem standard and a telephone system standard .

20. The apparatus of claim 15, wherein: the output data is provided according to a random network contention standard.

21. The apparatus of claim 15, wherein: the client comprises a subscriber terminal.

22. The apparatus of claim 1, wherein: the system comprises at least one of a broadband cable, satellite, wireless, Asynchronous Transfer Mode (ATM) , and a Digital Subscriber Loop (DSL) communication network.

23. The apparatus of claim 1, wherein: the attaching means provides the at least one attached identifier in a header associated with the output data .

24. The apparatus of claim 1, wherein: the attaching means provides the at least one attached identifier in a header associated with packets of the output data.

25. A protocol agent apparatus in a communication system, comprising: means for receiving input data with at least one attached identifier via the system from at least one client or server; wherein the at least one attached identifier identifies a protocol of the received input data; means for processing the input data to provide corresponding output data according to a desired data protocol ; wherein said processing means comprises means for filtering the input data according to the at least one attached identifier to route the input data to a protocol handler for processing thereat in accordance with the desired data protocol .

26. The apparatus of claim 25, wherein: said processing means comprises means for decoding the input data to provide it according to the desired data protocol ; wherein the desired data protocol differs from the protocol in which the input data is provided.

27. The apparatus of claim 26, wherein: said processing means comprises means for bypassing said decoding means when the desired data protocol corresponds to the protocol in which the input data is provided .

28. The apparatus of claim 25, wherein: at least one further identifier is attached to the input data to identify encryption and/or signing that was applied thereto; and said processing means further comprises means for decrypting and/or verifying a signature of the input data according to the at least one further identifier.

29. The apparatus of claim 28, wherein: said processing means comprises means for bypassing said means for decrypting and/or verifying a signature means .

30. The apparatus of claim 25, wherein: the protocol handler is provided at a client; and the input data with the at least one attached identifier is received from a server.

31. The apparatus of claim 30, wherein: the input data with the at least one attached identifier is received from the server using at least one of a unidirectional protocol and a bi-directional protocol .

32. The apparatus of claim 31, wherein: the at least one of a unidirectional protocol and a bi-directional protocol is provided via an out-of-band downstream data channel of a network.

33. The apparatus of claim 31, wherein: the at least one of a unidirectional protocol and a bi-directional protocol is provided via an in-band downstream data channel of a network.

34. The apparatus of claim 30, wherein: the input data with the at least one attached identifier is received from the server using one of broadcast, multicast, and single- cast communication.

35. The apparatus of claim 34, wherein: the broadcast, multicast, or single-cast communication uses a packetized transport stream standard.

36. The apparatus of claim 34, wherein: the broadcast, multicast, or single-cast communication uses an analog vertical blanking interval of a television signal to carry the input data.

37. The apparatus of claim 34, wherein: the protocol of the broadcast, multicast, or single-cast communication carries the at least one attached identifier using at least one of: a User Datagram Protocol (UDP) , a Transmission Control Protocol (TCP), and an Internet Protocol (IP).

38. The apparatus of claim 25, wherein: the protocol handler is provided at a server; and the input data with the at least one attached identifier is received from a client.

39. The apparatus of claim 38, wherein: the input data with the at least one attached identifier is received from the client using at least one of a unidirectional protocol and a bi-directional protocol .

40. The apparatus of claim 38, wherein: the input data with the at least one attached identifier is received from the client using one of broadcast, multicast, and single-cast communication.

41. The apparatus of claim 40, wherein: the broadcast, multicast, or single-cast communication carries the input data using at least one of: a User Datagram Protocol (UDP), a Transmission Control Protocol (TCP), and an Internet Protocol (IP) .

42. The apparatus of claim 38, wherein: the input data is provided according to at least one of a cable modem standard and a telephone system standard .

43. The apparatus of claim 38, wherein: the input data is provided according to a random network contention standard.

44. The apparatus of claim 25, wherein: the client comprises a subscriber terminal .

45. The apparatus of claim 25, wherein: the system comprises at least one of a broadband cable, satellite, wireless, Asynchronous Transfer Mode (ATM) , and a Digital Subscriber Loop (DSL) communication network .

46. The apparatus of claim 25, wherein: the at least one attached identifier is provided in a header associated with the input data.

47. The apparatus of claim 25, wherein: the at least one attached identifier is provided in a header associated with packets of the input data.

48. A method for providing a protocol agent in a communication system, comprising the steps of: receiving input data from at least one protocol handler; processing the input data to provide corresponding output data according to a desired data protocol; wherein the processing comprises attaching at least one identifier to the output data to identify the desired data protocol thereof; and providing the output data with the at least one attached identifier to at least one client or server via the system.

49. A method for providing a protocol agent in a communication system, comprising the steps of: receiving input data with at least one attached identifier via the system from at least one client or server; wherein the at least one attached identifier identifies a protocol of the received input data; processing the input data to provide corresponding output data according to a desired data protocol; wherein the processing comprises filtering the input data according to the at least one attached identifier to route the input data to a protocol handler for processing thereat in accordance with the desired data protocol .