INTERNET-DRAFT C. W. Ng Document: draft-ng—opes-irmlsubsys-00.txt P. Y. Tan Expires: January 2002 H. Cheng Panasonic Singapore Labs July 2001 Sub-System Extension to IRML Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Intermediary Rule Markup Language (IRML) [2] is an XML-based language that can be used to describe service-specific execution rules for network edge intermediaries under the Open Pluggable Edge Services (OPES) framework, as described in [3] and [4]. This memo discusses the need for OPES framework to have different sub-systems in different deployment scenario, and proposes additions to IRML for a more flexible approach to supporting different sub-systems. Ng, Tan, Cheng Expires January 2002 [Page 1] INTERNET-DRAFT Sub-System Extension to IRML July 2001 Table of Contents 1. Introduction....................................................2 2. Motivation for Different Sub-Systems............................2 3. Proposal to IRML Sub-Systems....................................3 3.1. The “sub-system” Attribute....................................3 3.2. The “no-sub-system” Attribute.................................3 3.3. Proposed IRML DTD.............................................4 3.4. Proposed Architecture.........................................4 4. Example.........................................................5 4.1. Scenario Overview.............................................5 4.2. IRML Examples.................................................6 5. References......................................................7 6. Author's Address................................................8 1. Introduction The Intermediary Rule Markup Language (IRML) [2] is an XML-based language that can be used to describe service-specific execution rules for network edge intermediaries under the Open Pluggable Edge Services (OPES) framework, as described in [3] and [4]. This memo discusses the need for OPES framework to have different sub-systems in different deployment scenario, and proposes additions to IRML for a more flexible approach to supporting different sub-systems. This memo begins in Section 2 by presenting the motivation behind having sub-systems support in IRML. Section 3 proposed a set of QoS extension to the "property" element defined in the IRML, and Section 4 presents some examples illustrating possible use of these extensions. 2. Motivation for Different Sub-Systems In [4], various different examples services that the OPES intermediary can provide are presented. These services cover a wide application range, including data insertion into HTML pages, web or AV content adaptation, and user profiles creation. These different services would have different set of requirements. The current set of IRML properties, in its initial drafting, has been focused to the Hyper Text Transfer Protocol (HTTP). These lead to difficulty in constructing rules for other applications. For instance, limited client bandwidth adaptation and streaming media adaptation requires a whole set of quality of services properties, such as bandwidth allocated and the packet lost rate, which is absent from the IRML framework. Creation of user profiles needs user specific parameters, such as the user identification, current IP address of the user, etc. Ng, Tan, Cheng Expires January 2002 [Page 2] INTERNET-DRAFT Sub-System Extension to IRML July 2001 Since the required set of property parameters is different for different services, it would be much more manageable to classify these parameters into different sub-systems. Furthermore, this allows a specific implementation of the OPES intermediary to incorporate only the parameters in the sub-systems that it needs for the services it provides, and not the entire range of properties that is defined. In addition, since the development of the OPES framework is still in its infancy stage, the sub-systems concept in IRML allows researchers to create new sub-systems to experiment with new properties, and still maintain conformance to the standard OPES framework. For example, some implementations may desire the “matches” attributes of the “property” element to have arithmetic support, instead of restricting to regular expression. They can implement such support using new sub-systems. 3. Proposal to IRML Sub-Systems This memo proposed two new attributes to the “property” element of the current IRML specifications: “sub-system” and “no-sub-system”. 3.1. The “sub-system” Attribute The “sub-system” attribute is used to specify the sub-system where the value of the property specified by the “name” attribute can be derived. In order to maintain compatibility with the current IRML specification, the “sub-system” attribute is optional. When it is omitted, the default value of “Standard” is assumed, which implies that the property belongs to the set of parameters currently defined in [2]. 3.2. The “no-sub-system” Attribute The “no-sub-system” attribute complements the “sub-system” attribute, and is used to specify the default matching result when the sub-system required (as specified by the “sub-system” attribute) is not supported by the IRML engine. It can have a value of “match” or “no-match”. A value of “match” implies that if the required sub-system is not supported, the IRML engine should treat it as if the “property” condition is met. Conversely, a value of “no-match” implies that if the requires sub-system is not supported, the rule engine should treat it as if the “property” condition is not met. Ng, Tan, Cheng Expires January 2002 [Page 3] INTERNET-DRAFT Sub-System Extension to IRML July 2001 In order to maintain compatibility with the current IRML specification, the “no-sub-system” attribute is optional. When it is omitted, the default value of “no-match” is assumed. 3.3. Proposed IRML DTD The proposed IRML DTD (Document Type Definition) with the two proposed attributes for the “property” element is shown below. 3.4. Proposed Architecture The proposed architecture with sub-systems is shown in Figure 1 below. Here the entire IRML rule engine consists of three parts: the rule parser, the “Standard” sub-system, and any other additional sub-systems. The rule parser and the “Standard” sub-system are mandatory. Together, they implements all the standard IRML rule engine functionality specified in [2]. Any other additional sub-systems are optional. These additional sub-systems either provide enhance functionality, or is for experimental purposes. Ng, Tan, Cheng Expires January 2002 [Page 4] INTERNET-DRAFT Sub-System Extension to IRML July 2001 +---------------+ +---------------+ | | | | Mandatory | Rule |<---->| Standard | | Parser | | Sub-System | | | | | +---------------+ +---------------+ ^ | | v +---------------+ | | Optional | Additional | | Sub-system(s) | | | +---------------+ Figure 1 Architecture of Rule Engine With such an implementation, the rule parser will parse each property and see what kind of sub-system the property uses. If the required sub-system is supported, the property is then passed to the corresponding sub-system for evaluation (i.e. check if the condition specified is met). In the event that the required sub-system is absent, the rule parser will then assume the condition to be met or not according to the “no-sub-system” attribute of the property. In this modular approach, implementation becomes easier. In addition, because conditions are evaluated by the sub-systems, each sub-system can choose to support arithmetic comparison, bolean expressions, etc, instead of being limited to regex, which may be sufficient for matching HTTP headers, but are at best awkward for evaluating conditions which involve QoS or System parameters. 4. Example 4.1. Scenario Overview Figure 2 below depicts a scenario, which illustrates the concept of sub-system. In this figure, three sub-systems are shown interfacing with the OPES rule engine. These are: “Standard” sub-system, “QoS” sub-system, and the “System” sub-system. The “Standard” sub-system uses the standard HTTP properties as defined by [2]. The “QoS” sub- system provides the rule engine an interface with the QoS control Ng, Tan, Cheng Expires January 2002 [Page 5] INTERNET-DRAFT Sub-System Extension to IRML July 2001 and monitoring modules, such as Traffic Engineering Module. This enables rules to construct condition involving QoS parameters. The “System” sub-system provides the rule engine an interface to the operating system. This enables rules to be constructed using conditions involving system parameters, such as the system load, the number of TCP/UDP connections the system is currently handling, etc. +---------------+ +---------------+ | | | | | Rule |<---->| Standard | | Parser | | Sub-System | | | | | +---------------+ +---------------+ ^ ^ | | | | v v +---------------+ +---------------+ | | | | | System | | QoS | | Sub-System | | Sub-System | | | | | +---------------+ +---------------+ Figure 2 Sub-Systems interfaces with rule engine. 4.2. IRML Examples The first example below illustrates the case where a HTML page is adapted to suit the allocated bandwidth of the client. Here we assume that there is a “QoS” sub-system which defined the property name of “allocated-bandwidth” to give the value of bandwidth allocated to the client in bits per second. In addition, the “QoS” sub-system also overloads the “matches” attributes to support arithmetic comparison (i.e. greater than, smaller than). In this example, the bandwidth of client is used to determine how the HTML page is translated to WML page. If the bandwidth allocated is large than 9.6 kbps, the translated WML page will contain some bitmaps. If it is smaller, bitmaps are replaced by alternate text. When the “QoS” sub-system is not supported, the rule-engine should assume that the client has a tight bandwidth. Ng, Tan, Cheng Expires January 2002 [Page 6] INTERNET-DRAFT Sub-System Extension to IRML July 2001 proxylet://localhost/html2wml?image=no proxylet://localhost/html2wml?image=yes The second example illustrates the scenario where the access provider wishes to re-direct the client request periodically to a remote proxy for logging purposes. Here, we assume that there is a “System” sub-system that provides support for the property name “request-count”. This gives the accumulated number of requests the proxy has serviced. In addition, the “System” sub-system also overloads the “matches” attribute to support arithmetic expressions. In this example, the “matches” attribute is “($%400)==0”. The “$” is a token to be replaced by the value of the parameter specified by the “name” attribute. icap://log.server/log 5. References [1] Bradner, S., "The Internet Standard Process – Revision 3", BCP 9, RFC 2026, October 1996. [2] Beck, A., Hoffman, M., "IRML: A Rule Specification Language for Intermediary Services", Work In Progress, draft-beck-opes-irml- 00.txt, February 2001. Ng, Tan, Cheng Expires January 2002 [Page 7] INTERNET-DRAFT Sub-System Extension to IRML July 2001 [3] Tomlinson, G., Orman, H., Condry, M., Kempf, J., "Extensible Proxy Services Framework", Work In Progress, draft-tomlinson-epsfw- 00.txt, 2000. [4] Beck, A., Hoffman, M., Condry, M., "Example Services for Network Edge Proxies", Work In Progress, draft-beck-opes-esfnep-01.txt, November 2000. 6. Author's Address Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Send Ave #04-3530 Tai Seng Industrial Estate Singapore 534415 Phone: (+65) 381 5420 Email: cwng(_at_)psl(_dot_)com(_dot_)sg Pek-Yew Tan Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Send Ave #04-3530 Tai Seng Industrial Estate Singapore 534415 Phone: (+65) 381 5470 Email: pytan(_at_)psl(_dot_)com(_dot_)sg Cheng Hong Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Send Ave #04-3530 Tai Seng Industrial Estate Singapore 534415 Phone: (+65) 381 5477 Email: hcheng(_at_)psl(_dot_)com(_dot_)sg Ng, Tan, Cheng Expires January 2002 [Page 8]