JP2003008636A - Method and apparatus for configuring and controlling network resources in quality of service content transfer - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method and apparatus for controlling and configuring network resources in an intermediate network element for transferring content having quality of service (QoS). An input data packet is passed to step 201 to extract QoS statistics, and then the packet is forwarded to step 202 to inspect the content and match the content against a pool of input rules. If the rule is met, the data is passed to the gateway module 101 in step 203 for processing. After this processing, the data is passed to the rule engine 102 in step 204 so as to match the output rule pool. Next, the output data packet is passed to the QoS module 103 in step 205 to extract the output QoS statistics.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION The present invention relates to the field of content transfer in data communication networks. More particularly, the present invention relates to controlling a data packet stream flowing through an intermediate network element and controlling and configuring network resources in the intermediate element. The main intended use of the present invention is for content streaming,
It is intended to serve as a proxy that provides content adaptation services based on quality of service (QoS) parameters and policies.

[0002]

BACKGROUND OF THE INVENTION Over the past decade, the Internet, and more specifically the Internet Protocol (IP) based network, has seen significant growth. The proliferation of the Internet and the increase in the number of Internet users have created application expansion and scaling problems.
This is especially true for applications designed for end users such as the World Wide Web (WWW) and audiovisual streaming. Increasing network bandwidth and processing power can barely keep up with the increasing demand of Internet users. As a result, the load time required for a WWW page request becomes longer, and the quality of real-time audio / video reproduction on the Internet is degraded. Efforts to reduce such undesired effects have led to the widespread deployment of intelligent network elements at the network edge (ie, the edge closer to the end user).

The most common use of such intermediate network elements is the document 1 (Fielding, R., Ge.
ttys, J .; Mogul, J .; , Frystyk,
H. , Masinter, L .; Leach, P .; , And T. Berners-Lee's "Hyptertext Transfe
r Protocol-HTTP / 1.1 ", IETF RFC
2616, June 1999) and acts as a caching proxy, such as a hypertext transfer protocol (HTTP) proxy and / or a cache. They have been successful in reducing the network load on WWW servers and speeding up WWW content transfers to end users. But,
As the number of end users increases, the variety of web browser configurations and platforms expands. Similarly, the range of web contents is expanded. Merely replicating static web content cannot hope to withstand the ever-increasing demands of end users.

Furthermore, the development of multimedia streaming on the Internet has also increased significantly. These are usually described in Ref. 2 (Schulzrine, H., Casn.
er, S.E. Frederick, R .; , And Jabc
Obson, V.I. , “RTP: A Transport Protocol
for Real-Time Applications ”, IETF RFC1
889, January 1996), using a real-time transfer protocol and a real-time control protocol (RTP / RTCP). Due to the versatility of Internet traffic, adapting multimedia streams to changing traffic conditions requires ensuring a smooth presentation to the end user. Although RTCP provides a means for end users to report their communication status back to the sender, the action taken by the sender based on the receiver report is that the network between the receiver and sender (network It is almost ineffective because the distance is often long (in the sense of the word). Most end-users connect to the Internet via an intermediary of the kind, for example a firewall gateway, a network address translator (NAT) or a proxy, so the intermediary gives a good choice and fits on behalf of the content originator. Do the service.

[0005] Many International Standards Organizations recognize the need to provide services that should be available only at the network core (where the server is located) to the network edge (where the end user is located). For example, the Internet Engineering Task Force (IETF) has recently established several working groups that focus on providing services at the edge of the network. The Open Pluggable Extensible Services (OPES) Working Group is one such effort. The OPES Working Group focuses on performing simple caching tasks for the entire set of conforming services to extensions of current HTTP proxies. The framework of OPES is document 3 (T
Omlison, G .; Orman, H .; , Condr
y, M. , And Kemf, J .; `` Extensible Proxy S
ervices Framework ", IETF Internet Draft, Work in Progress, http: // www. iet
f. org / internet-drafts / dra
ft-tomlinson-epsfw-00. tx
t, July 2000). Another IETF
Working Group, Middlebox Communications (MI
The DCOM) working group focuses on communication between end users and intermediaries at the edge of the network.

[0006] Efforts have been made to integrate services at the edge of the network, but such work is sufficient to meet the increasing end-user demand if the quality of service (QoS) issue is not addressed. is not. This is particularly important with the widespread deployment of broadband wireless networks and the proliferation of wireless portable devices available on the Internet. The channel condition of wireless communication is more fluctuating than that of wired communication. Therefore, QoS is an important consideration in order to provide a smooth presentation of content to the end user.

[0007]

The current use of intermediate means in content transfer is often limited to providing simple functionality such as HTTP caching and proxies. This is not able to maintain the required service level due to the increase in the number of end users as the different system configurations and hence the different sets of requirements increase. With the proliferation of multimedia streaming over the Internet, such shortcomings of the current deployment of intermediate network elements are particularly significant.

Various international organizations recognize the above problems and are trying to solve them.
Ignore the need to address the issue of oS. The content adaptation done at the edge cannot be effectively performed without paying attention to the QoS issue. In particular, the OPES framework described in reference 3 ignores the increasing demand for multimedia streaming over the Internet,
Focusing on TP content transfer. Furthermore,
The OPES framework has a rule-based content adaptation mechanism, but does not consider the rules to be specified during transfer.

At present, most of the enforcement of the QoS policy on the Internet is described in Reference 4 (Blake, S., Blac).
k, D. Carlson, M .; , Davies,
E. , Wang, Z. , W. , Weiss's "An Archi
tecture for Diffentiated Sevice ", UETF RF
C2475, December 1998), which is performed using the differentiated service (DiffServ) architecture, and QoS is performed within the DiffServ domain.
It can only guarantee implementation. In addition, DiffServ
Marking is done at the IP layer, which is difficult to access and control at the application layer (performing content transfer).

[0010]

SUMMARY OF THE INVENTION To solve the problem described in section 3.3, the present invention provides a content provider, an access provider, and / or an end user for the content transfer performed on an intermediate network element. Allows you to specify rules that determine behavior. In the present invention, these rules can be constructed based on QoS parameters, and thus more efficiently match content based on changing network conditions. Furthermore, the rules
It can be dynamically specified by remote parties, disabled, or re-enabled. Thus, the invention provides maximum flexibility in adapting content.

By allowing the QoS parameters to be specified in the rule, the invention also relies on a lower layer mechanism (eg DiffServ) which may be particularly impossible if the content should move multiple DiffServs. Instead, it provides a more abstract, high-level way to enforce QoS policies at the application level.

The present invention involves the operation of intermediate network elements to perform content transfer and adaptation between end users and content providers. The intermediate network element (also known as an intermediate means) parses each data packet transferred between the end user and a content provider. If the data packet meets certain criteria specified by the set of rules registered in the intermediate means, the action specified in the rule is performed and the data packet is typically modified. Rules can be dynamically inserted, disabled, and / or reenabled.

Since the intermediate network element monitors the traffic conditions of the data stream flowing through it, the specified rules can use the traffic information to implement and improve the quality of service policy. Further, the above-mentioned intermediate means also uses the Q of the end user or the content provider.
It has a mechanism to query the oS status.

[0014]

DETAILED DESCRIPTION OF THE INVENTION An apparatus for controlling network resources in an intermediate network element is disclosed herein. To help understanding of the invention, the following definitions are used. A "packet" is a self-contained unit of data in any available format that can be transferred over a data network. -"Intermediate means" and "intermediate network elements" are equivalent and are used interchangeably unless otherwise specified. These refer to gateways, routers or intelligent network hubs to which the invention applies. -The term "QoS" (Quality of Service) refers to quality of service.

In the following, for purposes of explanation, specific numbers, times, structures and other parameters are given in order to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details.

The intermediate network element to which the present invention is applied has a functional architecture as shown in FIG. The intermediate means is the gateway module (101),
Rule engine (102), QoS module (103)
And a rule insertion module (104) (see claim 1).

The gateway module (101) is a group of functional blocks for implementing a gateway or proxy function. These are HTT as described in Reference 1.
It may include, but is not limited to, a P proxy and / or cache, an RTP / RTCP mixer and / or converter as described in [2], and an application level gateway (ALG).

The rules engine (102) parses all data packets and matches them with a set of criteria specified by the rule or rules. These rules are rule-specific
specified in logical units known as on). The rule specification includes one or more rules. If a match is found, the action specified by the rule and corresponding to that rule is triggered. This is known as the "firing of rule." The acts performed may include, but are not limited to, inserting content into the data packet, removing certain content from the data packet, modifying the content within the data packet. These insertions, removals or modifications of the packet content can be performed on the intermediary or on another remote machine dedicated to performing the packet transformation.

The QoS module (103) inspects incoming data packets and extracts communication statistics about remote hosts. It also provides an interface with a rules engine that queries QoS information about communications between the intermediary and remote hosts. Furthermore, as described below,
The module (103) implements a mechanism for inquiring communication statistics from a remote party to a remote host.

The rule insertion module (104) is the module that dynamically loads and unloads rules into and out of the rules engine (102). The rule insertion module (104) also provides a remote party interface for dynamically registering, enabling or disabling rules that define the decision making process of the rules engine (102) (claim 5,
See 6, 7, or 8).

FIG. 2 shows the processing steps involved when a data packet is received by an intermediate network element (see claims 2, 3 or 4). When an input data packet is received by the low network protocol layer, the data packet is passed to the QoS module (103) to extract the QoS statistics, as noted at 201. The QoS statistics may be as simple as incrementing a byte or packet reception counter, or parsing the QoS information embedded in the data packet, eg inspecting the QoS report in RTCP packets (ref. 2) or different. It may be complicated such as extracting jitter and delay information of the priority stream from the audio / video stream. The packet is then forwarded to the rules engine (102),
Inspect the content and attempt to match it against a pool of validation rules, as noted at 202. Whenever the conditions specified in the rule are met, the specified action is performed. The data packet is then passed to the gateway module (101) for processing, as noted at 203.

The application of the data packet calls the appropriate protocol stack to process the data packet. This is HTTP request / response, RTP
It may be streaming content or other content. Since the intermediate means basically works as a proxy,
The general reaction is one of the following: (A) Generate a response packet to be returned and forwarded to the originator, as indicated by the branch labeled 215 (eg,
If the HTTP request results in a cache hit, the requested page from the cache is sent back to the requester), or (b) a data packet to be forwarded to the actual intended recipient, as shown in the branch labeled 214. (Eg, if the HTTP request results in a cache miss, the request is forwarded to the actual requesting web server).

In either case, an output packet is generated. This output packet is passed to the rules engine (102) to match the pool of output rules, as indicated by the step labeled 204. Similarly, the contents of the output data packet are matched against the conditions specified in the rules, and the specified action is invoked when a match is found. The output data packet is then passed to the QoS module (103) and the relevant QoS information is extracted, as indicated by the step labeled 205. As shown at step 201, these QoS statistics may be as simple as incrementing a byte or packet reception counter, or as complex as parsing the QoS information embedded in the data packet. . The data packet is then sent to the lower network interface to be sent.

The rules that define the rules engine (102) are:
Specified in one or more rule specifications. A rule specification is a logical collection of rules specified by the same person, organization or group. With respect to claim 10, data format 1 indicates the format of the rule specification structure.

The next pointer is used to connect different rule specifications to the linked list. If the intermediary has no packages, the rules pointer points to the merger structure. It is a rule or operation as shown in the data format 2.

In the case of the RuleAction structure, type
The e column is used to identify whether it is a rule or action (see claim 11). The package column is used to indicate whether the rule or action requires a special package / plug-in product to exist. If the intermediary finds a rule or action that requires a package it does not have, it ignores the rule or action and parses the next rule or action. The next column is used to connect the independent rule or action to the linked list. For rules, use the rules part of the merger. property specifies the type of variable to be checked, value specifies what the specified value should be, and op specifies the conditional operator. For example, op can be set to indicate that the operation is "less than or equal to". In this case, the variable designated by property is checked to see if its value is less than or equal to the value designated by value. If it is less than or equal to the value, it can be said that the condition specified by the rule is satisfied. Other possible values of op are "less than", "equal", "not equal",
May contain a value that indicates a "greater than", "greater than or equal to" Boolean operation, or a column comparison operation that is "is a substring,""is not a substring,""includes a substring," or "does not include a substring." Yes, but not limited to. The embed column is Rule
Used to point to a nested linked list of Action structures, each of which may be a rule or action. These structures in the embed linked list are: property, va
It is only parsed if the conditions specified by lue and op are met.

FIG. 3 shows an example of a rule specification format for implementing the following rules. if ((x <= 1) and (y> 2)) then do (action-1 and actio
n-2}

The logical "product" (and) relation of (x <= 1) and (y> 2) is expressed using the incorporation of one rule into another, as shown at 301 and 302. To be done. The two operations to be performed are denoted by reference numeral 303.
And 304, represented as a linked list embedded in the second rule structure.

FIG. 4 shows the first RuleAc of rules.
RuleSpecificat that starts from the action structure
The process of parsing the ion structure is shown (see claim 12 or claim 19). Pack required by rule or action
age first checks if it is available, as indicated by the step labeled 401. If the required package is not available, the current structure is ignored and the next structure in the linked list is examined, as indicated by the steps labeled 404 and 405. If the package is available, the RuleAction type indicates that it is an action, as indicated by the steps labeled 402-405, and performs the specified action to execute the next action.
Parses the next RuleAction structure if is empty. The step labeled 406 further performs an additional task of checking if the additional property field is supported by the intermediary. Parses and evaluates the next property if the property name is not supported. If no property is supported, use the default, or if no default is found, use the behavior of the first property as the default. If the RuleAction type indicates that it is an action, then it evaluates the specified condition to see if there is a match, as indicated by the steps noted 406 and 407. If there is a match, the symbols 408 and 409
If it is not empty, then embe
Parse d's RuleAction structure.

These rules can be converted to any rule format as described above, in any text format,
Or reference 5 (Beck, A. and Hofmann, M .;
"IRML: Rule Specification Language for Intermediary Service", I
ETF internet draft, work in progress, http
p: // www. ietf. org / internet
-Drafts / draft-beck-opes-i
rml-00. txt, February 2001) and may be specified using the Intermediary Rule Markup Language (IRML). In such cases, Rule
The Specification structure is generated by parsing the rules specified in the IRML text. These rules can be specified by any stakeholder, such as an end user, access provider or content provider. The present invention allows these parties to insert a rule specification in the rule insertion module (104) via an active connection. For purposes of explanation, the party that inserts the rule is hereinafter referred to as the remote party.

FIG. 5 shows a state diagram of a remote party and an intermediate network element when the remote party is trying to insert a rule specification (see claim 5). First, the remote party has established a reliable communication link (eg, TCP) with an intermediate network element at a predesignated port. Once the communication is established, both the remote party and the intermediary are able to use the COMMS-, as shown at 501 and 511.
Enter the ESTAB state. Next, the remote person, the transition mark 5
21, the host identification code and the rule specification are transmitted to the intermediate means so that the next state (reference numeral 502) is sent.
RULES_SENT), as described in. When the intermediate network element receives the host identification and rule, it sends the RU, as noted at 531.
Transition to the next temporary state of LES-RECV (512). From here, another state transition, as noted by numeral 532, is by sending the rule's identification code (uniquely assigned by the intermediary) to the remote party, as indicated by reference numeral 532.
D-SENT (513) to the network element. Upon receiving the rule identification code, the remote party receives the ID-RECV status (50) as noted by reference numeral 522.
Go to 3). From here, the remote party is designated by reference numeral 523.
Send a notification back to the intermediate network element and transition to the EXIT state (504), as noted at. Upon receiving the notification, the intermediary means, as noted at 533,
Store the rule specification in the rules engine (102) and
Transition to the T state (514).

A remote party can dynamically invalidate a pre-registered rule specification or re-validate a pre-invalidated rule specification. Referring to FIG. 6, if a remote party wishes to override a pre-registered rule specification, it establishes a secure communication link with an intermediate network element, as noted at 601 (see claim 6). ). Next, the remote party transmits the host identification code and the rule identification code of the rule specification to be invalidated to the intermediate means, as shown in the process indicated by reference numeral 602. If the host identification code and the rule identification code are valid and match (that is, the rule specification is registered in advance by the remote party), reference numeral 6
The intermediate means removes the rule specification from the rule engine (102), as indicated by the steps marked 03-604,
Send notifications to remote parties. If the host and rule identification codes are invalid and do not match, the intermediate means sends an error signal to the remote party, as indicated by the step noted 606.

Referring to FIG. 7, if a remote party wants to re-enable a pre-invalidated rule specification, it is labeled 701.
Establishing a reliable communication link with the intermediate network element, as described in (7). The remote party then sends the host identification code and the rule identification code of the rule specification to be revalidated to the intermediary, as indicated by the step noted 702. If the host identification code and the rule identification code are invalid, reference numerals 703 and 70
The intermediate network element replies with an error indication, as shown in the process noted at 4. If the code is valid, the intermediary checks whether the specified rule specification is still available (eg, in auxiliary storage), as indicated by the step noted 705. If the rule specification is not available, the intermediate network element sends an error indication to the remote party, as indicated by the step noted 706.
Otherwise, the network element inserts the rule specification into the rules engine (102) and responds with a notification, as indicated by the steps labeled 707 and 708.

Since the rule is sending data packets via the intermediate network element, the remote party can insert or override the rule (see claims 8 or 9). This allows remote parties to build rules that apply only to certain data packets and send data packets that are exempt from certain sets of general rules.

Dynamic insertion of rules during execution requires remote parties to incorporate rule specifications into data packets. In the case of HTTP packets, this can be done by having a special header field and incorporating the rule specification into a separate chunk. For RTP packets, this can be done by having a special RTP extension that follows the standard RTP header. The RTP extension contains a rule specification. Those skilled in the art will appreciate that similar measures can be taken for other protocols to incorporate the rule specification into the data packet.

The rules engine (102) parses the data packet and detects the inclusion of rule specifications. The rules engine (102) will then pass the data packet to the rules insertion module (104) to build a rules specification containing built-in rules. In addition, the rule insertion module (104) adds two additional rules to the rule specification. The rule specification can only be applied to data packets containing built-in rules (hereinafter known as "carrier" packets) and all other data packets in response to "carrier" packets.・ Regulation specifications are "carrier" packet and "carrier"
Invalidated when forwarding all data packets responsive to the packet from the intermediate network element.

Next, the rule insertion module (104)
Insert the rule specification into the rules engine (102). In the above description, the term data packet in response to a "carrier" packet refers to any data packet that is a duplicate of a "carrier" packet, any response generated by an intermediate means (eg, a response to a cache hit), and Note that it includes any responses generated by other hosts (eg, responses from servers for cache misses).

If a remote party does not want to apply some of the rules on a particular data packet that would otherwise apply,
The remote party may incorporate into the data packet the rule identification code of the rule specification that it is desired to temporarily disable. As mentioned above, the rule identification code is HTTP.
Special header fields and separate chunks for RTP, special extensions for RTP, or other similar methods for other protocols. When detecting such a code, the rule engine (102) ignores the rule specification identified by the rule identification code when parsing the data packet regardless of whether the condition of the rule specification is satisfied.

The present invention provides QoS in content transfer.
It aims at the composition and control of. Thus, the rule specification used by the rules engine (102) can specify conditions based on the current QoS state of the connection between the intermediate network element and the end user or content server. The QoS module (103) provides an interface to the rules engine (102) to query QoS statistics for communication connections. The interface format is shown in the following interface format 1 (see claim 13).

For interface format 1, s
rcAddr and srcPort are the IP address and port number of the sender (remote party who initiated the connection), and dstAddr and dstPort are
These are the IP address and port number of the recipient (remote person who responded to the connection). These four parameters completely identify the connection as to which QoS parameter to query. The QoSParam identifies the QoS parameter to query, and the QoSvalue is the Q
Points to the memory location used to store the value of the oS parameter.

[0041]

[Table 1]

Table 1 shows the possible QoS parameters. QoS parameters are divided into four categories (static, dynamic, dynamic parameter difference, and system).
Static QoS parameters are parameters that do not change once a connection is established. These are usually the values set by the QoS policy. The dynamic QoS parameters are
Content transfer statistics that reflect current network conditions. These are updated at known specific intervals. The dynamic QoS parameter difference is the difference between the current value of the dynamic QoS parameters and the value before they were last updated. The difference in dynamic QoS parameters allows the rules engine (102) to perform stateless enforcement. Although not strictly a QoS parameter, system parameters are provided to the rules engine to query the system load that affects the QoS of the transferred content.

The following is an example of how various QoS parameters can be used for various categories (claims 14, 15).
16, 17 or 18). The following shows the case where the HTML page is adapted to the allocated bandwidth of the client. For illustration purposes, the following example does not represent a real world application, but rather provides a way to generate rules for the search of particular content. Now suppose there is a subsystem that looks at the allocated bandwidth and classifies it into associated tags of "low,""medium," or "high."<rule processing-point = “4”><!-invoke local services to insert label-><action> checkBandwidth </ action><!-check the allocated bandwidth and adapts accordingly-><property name = “ allocated-bandwidth ”matches =“ low ”><!-Bandwidth is low, use tiny WML-><action> proxylet: // localhost / html2wml? target = tiny </ action></property><property name = “Allocated-bandwidth” matches = “medium”><!-Bandwidth is moderate, use small WML-><action> proxylet: // localhost / html2wml? Target = small </ action></property><property name = “Allocated-bandwidth” matches = “high”><!-Bandwidth is high, use large WML-><action> proxylet: // localhost / html2wml? Target = large </ action></property><property> name = “r-jitter” matches = “high”><! receiver jitter is high, adapt to use still pictures-><action> proxylet: //stillimage.server/jpeg-only </ action></property><property name = “r-jitter-diff” matches = “low”><! jitter difference is low, resume previous content format-><action> proxylet: //content.server/resume </ action></property><property name = “system-processing-load” matches = “High”><! system load is high, suggest using remote server-><action> icap: //video.adapt.server/video-adapt </ action></property><property name = “r-fraction-lost” matches = “High”><! receiver accumulated loss is high, suggest using Forward error correction coded content-><action> proxlet: //videoFEC.correct.server/video-FEC </ action></property></rule>

To collect these parameters, Q
The oS module (103) has two main components: a local component (80) as shown in FIG.
1) and a remote component (claim 20)
reference). The local component (801) collects information about intermediary transfer and reception statistics. The remote component (802) collects these statistics from remote machines. In addition, the remote component (80
2) consists of four components: an upper layer interface abstraction component (803), a remote query interface component (804), a network interface component (805) and a packet parsing interface component (806). The Upper Interface Abstraction Component (803) provides a unified abstraction to other modules to query remote QoS statistics. It does the job of choosing which of the actual remote interface components to use. If nothing is available, the upper-layer interface abstraction component (803) returns to the local component (80
Evaluation of remote statistics is given from the local statistics obtained from 1). In some situations, the low network protocol layer has a mechanism for obtaining remote statistics about links. In these cases, the network interface component (80
5) is chosen to collect such information via the interface provided by the lower network layer. Instead, some transport protocol, such as RTP / R
TCP has built-in statistics that report functionality. In this case, the packet parsing interface component (806) is used to directly extract such information from the data packets when parsing these data packets. For other transport protocols that do not have state reporting functionality, the remote interface component (804) uses a separate communication channel to provide such information. However, this can only be used if the remote party provides a similar mechanism.

Remote Interface Component (80
The operation of 4) is as follows (see claim 21). The remote interface component establishes a communication link with the remote machine at a predesignated port. The remote interface component (804) then sends a series of blank termination sequences, in which the first four columns are the source IP address, source port number, destination IP address and reception of the connection to be queried. Each must contain a destination port number, and the next column contains the parameter name you want to know about the remote machine. The remote machine then replies with a series of blank termination sequences, in which the first four columns are the source IP address, source port number, destination I of the connection being queried.
It must contain a P-address and a destination port number, respectively, and then an arbitrary number of blank termination sequences contain the parameter name, its value. The parameter name may be any of the parameters listed in Table 1. Unknown parameter names are ignored.

[0046]

With respect to the use of the present invention in an intermediate network element between an end user and a content provider, an efficient use of network resources in said intermediate means can be achieved. The present invention allows content providers, access providers, and / or end users to specify rules that allow content to be efficiently adapted based on the QoS requirements of the network in the vicinity of the end users and intermediaries. In addition, rules can be dynamically inserted, disabled, and / or revalidated, thus providing the greatest flexibility for optimally adapting the transfer of content to changing network conditions through the operation of intermediate means. It is possible. This is especially useful when the end user is on a wireless platform where communication conditions are subject to severe fluctuations.

[Brief description of drawings]

1 is a framework of an intermediate network element and shows the functional architecture of the intermediate network element used in the present invention.

FIG. 2 is a diagram showing the processing steps performed by an intermediate network element when receiving an input data packet.

FIG. 3 is a diagram showing a method of linking rules and actions to express conditions and appropriate actions, which is a rule specification.

FIG. 4 is a diagram showing a process of parsing a rule specification, which is a process of parsing a linked list of rules and actions and matching conditions specified by the rules. If a match is found,
Perform a built-in operation or parse a nesting rule.

FIG. 5 is a state diagram of a remote host and an intermediate means when inserting a rule, the remote host attempting to insert a rule specification into an intermediate network element.

FIG. 6 is a diagram illustrating the invalidation of a rule, the steps performed by an intermediate network element when a remote party requests to invalidate a pre-registered rule specification.

FIG. 7 is a diagram illustrating the revalidation of rules, the steps performed by an intermediate network element when a remote party requests to revalidate a pre-revoked rule specification.

FIG. 8 is a framework of QoS modules,
It is a figure which shows the functional architecture of a QoS module.

   ─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor Chang Oh Nu             Singapore 534415 Singapore, Thailand             Sen Avenue, Block 1022, 04-             No. 3530, Thai Sen Industrial             Estate, Panasonic Singapore             Research Institute Co., Ltd. F term (reference) 5K030 GA12 HA05 HB21 HC01 HD03                       KA06 LB05 LC09 LC11 LC13                       LD20 LE01 MB09 MB15 MC07

Claims (21)

[Claims] 1. i. A gateway module that provides gateway functionality between end users, ii. A quality of service (QoS) module that provides QoS information about the communication network, iii. A rule engine module that makes network resource control decisions based on specified rules, wherein the rules are specified in a rule specification format known as a rule specification; iv. A network control framework device for controlling resources in an intermediate network element connecting two or more communication networks, the rule insertion module inserting a rule specification into the rule engine and removing the rule specification from the rule engine. 2. i. Passing an input data packet through the QoS module and extracting relevant transfer statistics on the input communication channel; ii. Passes an input data packet through the rules engine, determines which protocol stack in the gateway module should be activated to process the input data packet, and which is currently registered with the rules engine. Modifying the input data packet according to applicable rules specified in a rule specification; iii. Passing the input data packet through the gateway module and activating a corresponding protocol stack to process the input data packet, the intermediate network element according to claim 1 being connected between communication networks. A mechanism for processing a stream of content. 3. i. Passing an input data packet through the QoS module and extracting relevant transfer statistics on the input communication channel; ii. Passes an input data packet through the rules engine, determines which protocol stack in the gateway module should be activated to process the input data packet, and which is currently registered with the rules engine. Modifying the input data packet according to applicable rules specified in a rule specification; iii. Passing an input data packet through the gateway module, activating a corresponding protocol stack to process the input data packet, and as a result, generate a data packet according to the input data packet,
Forwarding from the intermediate network element of claim 1, iv. Passing an output data packet through the rules engine, applying specified related rules to the rule specifications currently registered with the rules engine, even if on the output data packet, to produce a modified output data packet. Steps to do, v. Passing an output data packet through the QoS module and extracting relevant transfer statistics on an output communication channel; vi. Sending the output data packet to a suitable communication network via a physical interface, wherein the intermediate network element according to claim 1 or 2 moves from one connection communication network to another connection communication network. A mechanism for processing. 4. i. Passing an input data packet through the QoS module and extracting relevant transfer statistics on the input communication channel; ii. Passes an input data packet through the rules engine, determines which protocol stack in the gateway module should be activated to process the input data packet, and which is currently registered with the rules engine. Modifying the input data packet according to applicable rules specified in a rule specification; iii. An input data packet is passed through the gateway module, a corresponding protocol stack is activated to process the input data packet, the input data packet is duplicated and generated, and transferred from the intermediate network element according to claim 1. Steps to do, iv. Pass the duplicate output data packet through the rules engine, apply the specified related rules to the rule specification currently registered in the rules engine, even if on the output data packet, and modify the output data packet to be modified. Generating step, and v. Passing the duplicate output data packet through the QoS module and extracting relevant transfer statistics on the output communication channel; vi. Sending the duplicate output data packet to a suitable communication network via a physical interface, the intermediate network element of claim 1 or 2 moving data from one connection communication network to another connection communication network. A mechanism for processing packets. 5. i. A remote party establishing a secure communication channel with the rule insertion module in the intermediate network element; ii. Said remote party forwarding the content of the rules in a rule specification along with host identification information to said intermediate network element, iii. Said intermediate network element notifying said remote party of a receipt of said rule and a response containing a rule identification code, iv. The remote party notifying the rule identification code; v. A means for a remote party to register one or more rules with the intermediate network element of claim 1, wherein the intermediate network element inserts the rule specification into the rules engine. 6. i. A remote party establishing a secure communication channel with the rule insertion module in the intermediate network element; ii. Transferring the rule identification code of the rule that the remote party is revoked with host identification information to the intermediate network element; iii. Said intermediate network element checking the validity of said host and rule identification code; iv. If the host and rule identification code are valid,
Said intermediate network element removing said rule specification from said rules engine and sending a notification to said remote party; v. If the host and rule identification code are invalid,
The intermediary network element sending an error indication to the remote party, wherein the remote party overrides one or more rules pre-registered with the intermediary network element according to claim 1 or 5. means. 7. i. A remote party establishing a secure communication channel with the rule insertion module in the intermediate network element; ii. The remote party forwards to the intermediate network element a rule identification code of a rule specification to be revalidated with host identification information; iii. Said intermediate network element checking the validity of said host and rule identification code and checking the availability of the rule specification in auxiliary storage, iv. If the host and rule identification code are valid,
Said intermediate network element inserting said rule specification from said rule engine and sending a notification to said remote party; v. If the host and rule identification code are invalid,
Said intermediate network element sending an error indication to said remote party; vi. Said intermediate network element sending an error indication to said remote party if said rule specification is not available, wherein said intermediate network element is pre-registered and disabled in said intermediate network element according to claim 1 or 5. A means by which remote parties may revalidate one or more rules. 8. i. A remote party sending a data packet with rules embedded therein; ii. Said rules engine of said intermediate network element passing these rules to said rule insertion module upon detection of said embedded rules, constructing a rule specification and including these rules; iii. The rule insertion module ensures that the rule specification can only be applied to data packets used to incorporate these rules and other data packets generated in response to the data packets used to incorporate the rules. Adding a rule to the construction rule specification, iv. Data packets used to incorporate these rules, and other data packets generated in response to the data packets used to incorporate these rules,
Said rule insertion module adding rules to said constructed rule specification so as to invalidate or remove said rule specification from said rules engine when discarding or forwarding from said intermediate means; v. The rule insertion module inserting the build rule specification into the rule engine, wherein the rule allows one or more rules to be registered by a remote party in the intermediate network element of claim 1. A means of incorporating in a data packet. 9. i. A remote party sending a data packet with a signal to invalidate the rules and rule identification codes of the internally disabled rule specification, ii. Upon detection of such an embedded signal, the rule engine of the intermediate network element determines any condition met by the rule of the rule specification identified by the rule identification code specified in the embedded signal in a data packet. Ignoring, wherein disabling of the rules in a data packet enables remote parties to disable one or more rules pre-registered in the intermediate network element according to claim 1 or 5. Means incorporated into. 10. i. A linked list of rules and behavioral data format mergers, ii. 10. The data structure format used in any one of claims 1 to 9, wherein the rule specification is described, which comprises a pointer holding the rule specification data format as a linked list that is independently connected. 11. i. The type of structure that distinguishes between rules and actions, ii. If the structure is a rule, the properties, values, and operations of the conditions within the rule and the actions to be performed or further conditions to be satisfied, iii. An action to be performed if the structure is an action, iv. The data structure format used in any one of claims 1 to 10, which describes a rule or operation, which comprises a pointer holding the rule or operation as a single connected linked list. 12. i. Determining the presence and requirements of special packages in the data structure, ii. Determining whether the data structure is a rule or action, iii. If the data structure is a behavior, performing the described behavior based on the behavior specified in the data structure; iv. If the data structure is a rule and the specified conditions are found to match, then the nesting rule is searched by searching for the next existence and requirement of the special package in the data structure, provided there is a nesting rule or action. Or parsing the action, v. 12. Parsing the rule or action by looking up the next presence and requirement of a special package in the data structure, provided that the elements of the linked list have a rule or action. How to move a linked list of data structures. 13. A rules engine during the processing of input and / or output data packets in the steps of claim 2, 3 or 4 communicates to determine a procedure of operation to comply based on a specified rule. The interface format provided by the QoS module to the rules engine in the intermediate network element according to claim 1, wherein the QoS statistics for the connection can be queried. 14. Enabling different QoS control mechanisms based on content transfer sessions or rules tagged for content so that rule-based content transfer can operate in a stateless or stateful manner. Means for providing a QoS control rule by tagging the rule for one or more content or content transfer sessions with different classifications, the method of classifying comprising: i. Static QoS parameter classification that tags control rules for content transfer only once for rule access of the content; ii. Dynamic QoS parameter classification that tags content transfer control rules based on stored parameter values during a session; iii. Differential QoS parameter classification that tags content transfer control rules based on differences between updated storage parameters; iv. System QoS parameter classification for tagging control rules for content transfer to the rules engine based on the latest QoS parameters giving information about the network node responsible for content transfer. 15. Part (i) comprises i. A fixed amount of allocated network bandwidth for the transfer of content to end terminals, ii. A fixed amount of requested bandwidth for the transfer of content within the content transfer session, iii. A fixed amount of bandwidth available to the end terminals, iv. A set of QoS parameters used as a static control rule according to claim 14, including a required delay limit for the transfer of content. 16. Part (ii) comprises i. The amount of data received by the end user since the start of the content in one session, ii. The amount of accumulated data sent by the access network node to the recipient since the start of the content transfer session, iii. The amount of accumulated data loss registered by the end user since the start of the content transfer session, iv. The amount of accumulated data loss registered by the access network node since the start of the session for content transfer, and v. A set of QoS parameters according to claim 14, comprising: the most recent inter-arrival time of the data package since the last update for valid sessions for content transfer at both the end receiver and the access network node. Used as a dynamic control rule by registering accumulated values of QoS parameters to enable dynamic QoS control rules for one or more transfers of a session as network traffic or QoS control rules tagged to A set of QoS parameters to be set. 17. Part (iii) comprises i. A difference in the amount of accumulated data received by the end user based on the two latest consecutive updates in the QoS parameters of the valid session for content transfer; ii. A difference in the accumulated amount of data sent by the access network node to the recipient based on the two latest consecutive updates in the QoS parameters of the valid session for content transfer; and iii. A difference in accumulated amount of data loss registered by the end user based on two latest consecutive updates in QoS parameters of valid sessions for content transfer; iv. A difference in accumulated amount of data loss registered by the access network node based on two latest consecutive updates in QoS parameters of valid sessions for content transfer; and v. A set of QoS parameters according to claim 14, comprising: a difference between the latest inter-arrival times of data packages since the last update for valid sessions for content transfer at both the end receiver and the access network node, Dynamic control by registering the difference between QoS parameter updates to enable dynamic QoS control rules for one or more transfers of sessions as network traffic tagged as content changes or QoS control rules A set of QoS parameters used as a rule. 18. i. Numerical representative use in measuring the processing load of an access node that transfers valid sessions; ii. As a system control rule, by registering the current load status of the network node that is in charge of the content transfer within the valid session, including the numerical representative use when measuring the number of valid sessions or connections related to the content transfer. The set of QoS parameters used. 19. If the QoS rule processing is disabled or not supported by the intermediary means, said intermediary means masks off or ignores any of the four QoS parameter classifications according to claim 14. Means of providing a valid switch. 20. i. A local component that collects statistics on the local network interface, ii. A framework for a QoS module according to claim 1, comprising: a remote component for collecting statistics of a remote network interface, said remote component providing: (a) a unified remote statistics query interface to other modules. An interface abstraction component, (b) a remote query interface component that queries the remote machine for its QoS statistics, and (c) a network interface component that queries the network interface for remote statistics, given such capabilities. (D) a packet parsing interface component for extracting remote QoS statistics embedded in the data packet, and the framework. 21. A communication format between two network entities in a packet switched communication network, which allows communicating peers to exchange information about collected communication statistics for data packets passing through a network interface.