An Open Service Platform for Deploying and Managing Services at Network Edges

B.FalchukA, J.Chiang, A.Hafid, Y.-H.Cheng, N.Natarajan, F.J.Lin, H.Cheng Telcordia Technologies, Inc.

445 South Street, Morristown, NJ 07960

Abstract - Over the past several years, in response to demands from users that access to networked information and services be both customized and rapid, services and content have increasingly been ‘pushed’ towards network edges by Providers. In turn, this has resulted in an increased need for a software framework that provides an open and systematic way for Providers to deploy and manage such network edge services. We have implemented and tested such a framework in our Lab, called the Telcordia Edge Services Node. Inspired by the foundations built in the IETF OPES-related drafts, it is beneficial to Access, Service, and Content Providers alike. This paper reports on the design, implementation, and lessons- learned from our edge service node framework and management tools.

I. INTRODUCTION

Edge services are content delivery and communication services that are deployed at the “edges” of networks such as Internet. The location of the edge may be an Internet Service Frfivider’s (ISP) Point of Presence (POP), an access network (wireline or wireless network) provider’s POP, Intemet gateway of an enterprise, or the front-end of a content provider site (including enterprise intra and extranets). Examples of content delivery edge services are caching (e.g. Akumui) and content filtering (e.g. Web Wusher). Examples of communication edge services are on-demand delivery of multimedia information, instant messaging, web- casting, and directory services for peer-to-peer information sharing. Figure 1 illustrates the concept of edge services and three different possible deployments (numbered 1 to 3 - the implementation described in this paper is of type 1). In principle, any Internet based service that is traditionally offered using a single “source” site can be deployed in multiple edge locations. In practice, such distributed deployments require careful analysis of network and business-level factors. Note that a subscriber is a paying customer of an Access Provider’s services (e.g. xDSL, dialup). Once “online”, a subscriber becomes a consumer of Content Provider (CP) content.

The edge services concept represents the evolution of Intemet based communication and information services, offering several benefits to the different stakeholders: Subscribers, Access Providers (e.g. UUNET, SBC, Earthlink), Content Providers (e.g.

CNN, MSNBC), and 31d-party Service Developers (e.g. Microsoft, Google), as shown in Table 1.

In part from our business relationships with Service Providers, we understand the problems they face: Access Providers in particular seek new revenue streams to supplement those from their basic services (dialuplxDSL Internet access), while leveraging their existing relationships with customers and their access networks. However: 0 It is expensive and risky to create and manage new

edge services, and few edge service management tools exist

0 There are no systematic approaches nor stable standards for this purpose

This paper describes our solution to the above problems in the form of our edge services platform, which extends the state-of-the-art and has the following innovations: 0 Open and extensible formats and management tools,

enabling openness on the service, business and subscriber planes

0 Leverages “emerging” IETF standards 0 Easily managed rule-based platform 0 Automatically generates and validates XML rules

Local Central Office ____-_-___________r-________.

‘ 0 @ @

Edge Service in (Layer 2) Access Provider Pop Edge Service in ISP POP Edge Service in Content Provider site

Figure 1. Edge Services deployments

’Contact author: bfalchuk@research.telcordia.com

0-7803-7764-8/03/$17.00 02003 IEEE. 77 IEEE OPENARCH 2003

0 Integrated interfaces for, and management of, rules from all Content Provider’s, Access Provider’s, and Subscribers

0 Enables Providers to easily add and manage revenue- creating services to their portfolios

TABLE 1 BENEFITS OF EWE SERVICE NODE To BUSINESS ENTITIES

Access Value-adding (revenue-creating) services created on top

enterprise markets. APs strengthen customer ‘ownership’ by acting as a trusted agent for- personalization. Access

Fast service (data access) response time. Single point of

Telcordia Edge Service Node (ESN) protocols are built upon emerging standards such as IETF Open Pluggable Edge Service (OPES) Architecture and Intermediary Rule Markup Language (JRML) [ 1][2], IETF OPES Meta Markup Language (OMML) [3], and Internet Content Adaptation Protocol (ICAP) [4].

The remainder of this paper lays out the technical architecture of our Edge Services Node, describes its customization and management capabilities, and presents a mathematical model for its response time.

11. FRAMEWORK DESIGN AND IMPLEMENTATION

Edge Services Node (ESN) consists of a rule-based edge service execution platform and a suite of management services supporting edge services configuration, edge services usage monitoring, subscription management, and subscriber profile management. Depending on the scalability and performance requirements of access providers, ESN can be distributed across multiple machines. The edge services may be executed either in the same machine that hosts the service execution platform or in a remote machine, called a callout server. ESN and callout servers are linked via an Intranet or the public Internet.

A. Interfacing with Content & Service Providers As described in OPES [ 13 and [2], an “intermediary”

(e.g. Edge Service Node operator) depends on input from its business partners. In addition to their own subscribers, such partners may include Content Providers (CP), and 3‘d Party Edge Service Developers.

Content Provider’s may provide revenue to ESN operators if ESNs are able to attract subscribers’ eyeballs to Content Provider content through value added services (such as multiple language formats). Similarly, 31d Party Edge Service Developers may get revenue from ESN operators whose subscribers demand the ‘latest and greatest’ edge services. Communication mechanisms between Content Provider’s and ESN, and 31d Party Service Developers and ESN are not discussed fiather here. Their protocols are at the OS1 application level (such as OMML, likely over HTTP or SOAP) over TCP/IP networks. While Content Provider’s and 31d Party Service Developers were simulated in our lab, we focus here on the ESN core and management features.

The OPES architecture defines, “how participating transit intermediaries can be extended to incorporate services executed on application data. The services are written to an openstandard for use with the intermediaries.. .’, [ 1][2]. OPES allows services to be located either locally or remotely (a powerful mechanism); furthermore, the ICAP protocol can be used to ‘call out’ to remote servers offering edge services. OPES is caching-centric (the protocol has been influenced by cache vendors), so although incoming requests may be diverted through a chain of local and remote callout services, caching is an assumed part of that. The ‘four processing point’ model is built around a cache.

B. Service & Protocols Types Accommodated As subscribers utilize HTTP-based browsers atop access

provider networks, edge services - such as caching and language translation - are generally triggered in real-time and without subscriber intervention (though they see the value-added). Alternatively, some services deployed on edges, such as Web-casting, may need explicit requests for startup. Via ESN, Access Provider’s are also able to give subscribers the ability to subscribe to and customize (e.g. select a “preferred language”) some edge services, while other services such as caching may be implicitly subscribed to and not configurable. See Figure 2. Telcordia ESN is able to accommodate services of all of the above types, including those that support ICAP and those that do not. Some that we have deployed on ESN include (see also Figure 3): 0 Symantec Virus Scanning Service 0 Web Washer Content Filtering Service 0 Squid Cache service 0 Telcordia Ad-Insertion Service 0 Telcordia Language-Translation Service 0 Telcordia URL-Redirection (Load Balancing) Service

0-7803-7764-8/03/$17.00 Q2003 IEEE. 78 IEEE OPENARCH 2003

Cschlng service deployed U a ”true” callout

Figure 3 ESN Sofhvare Architecture

i Figure 4 illustrates the simplest system flow involving service subscription and subsequent real-time callouts.

D.

J t - - - - - - - - - - - _ - - - - - - - - - - _ - - - - - , - - - - - - - - - - - - - - - - - - - - l

Figure 2 ESN Functional Architecture Software Architecture -Engine and Compiler

C. System Functional Components

Telcordia ESN. Central to ESN design is the notion of n-Processing Point (PP) model.

In OPES (and our prototype - see discussion later), n is four, and the PPs represent instances in the Engine flow at which services may be triggered. Point 1 is immediately upon user message receipt. Point 2 is after a cache-miss and before the request to the origin server for the content. Point 3 is after origin server response but before re-caching, and Point 4 is after the cache- update and just before the response is relayed to the user (see [2] for details). The following summarizes ESN component functionality:

Figure 3 shows the five main software components in its Figure 2 shows the hct ional architecture of the deployment: (i) Profile Manager; (ii) Edge Service

Manager; (iii) Call-out servers on which edge services are - deployed; (iv) Rule Compiler; (v) Edge Service Engine. This section describes Rule Compiler and the Edge Sewices Engine. Section 3 presents details of the other components.

0 Edge Service Node Core (Engine and Compiler) - d for Subscriber Converts rule modules to a database format for high- speed access, and interprets subscriber traffic in-real- time, callingout to edge services as necessary at each intemal “processing point”. Also plays proxy-role. Edge Services - Deployed on Access Provider intranets or Intemet, services add value to customer experiences or to provider operations (e.g. caching). Rule Compiler - Rules control the triggering of the edge Databases - High-speed repositories for efficient services in ESN; users, service providers, andor access storage and management of metdata related to the providers define the rules. IRML, an XML-based rule edge services, business partners, and subscribers. language for so-called ‘intermediaries’, is used to specify

0 Management Services - Performs automatic creation these A well-defined I ~ L document consists of and Of XML-based and one or more rule modules each containing an owner, a set provides administrators access to tools and GUIs for ofrules and conditions under which they should ‘trigger’. service and subscriber management. The role of the rule compiler is to transform the IRML-

0 Business Partners - Though not a Part Of the based rules into data structures that can be easily and framework “Per se”, inputted rules from business efficiently parsed by the Engine’s rule interpreter. The Partners (e.g. Content Provider’s) affect system flow. aim of rule compilation then, is to optimize future real-

time rule access. In the Telcordia ESN, the rule compiler

Figure 4. One of several fundamental use-cases of the ESN

0-7803-7764-8/03/$17.00 02003 IEEE. IEEE OPENARCH 2003 79

maps the IFWL-based rules into tables, then stores them in an Oracle& database, accessible later by the rule interpreter. We use a table to represent the set of content provider rules in the DB; the URL (rule owner) is used as the principal key. A table entry contains 4 lists of rules: list-1 contains the rules that apply to processing-point 1, list-2 contains rules that apply to processing-point 2, etc. A rule contains two lists: list-1 contains a list of broperty, value) and list-2 a list actions (URLs); property will assume values 0, 1, etc. (e.g., 0: content-type, 1: User-Agent, etc.). Value is a string. Caching techniques are used to cache URL-rules for the most requested URLs instead of connecting to the DB each time a user request has the “host” property equal to the URL. A similar format is used to represent the rules for a given user; for example, upon demand the profile manager returns a user-rule object that contains the rules associated with the user in question. An example of an ICAP action in URL form is: icap:llwww.company.com/ icaplvirusScanning.

Edge Services Engine - The Engine is the heart of the edge service node. It consists of two components: (a) rule interpreter and (b) proxy server. The latter’s presence helps us break the cache-centric limitations of, for example, the OPES model (see discussion later).

The role of the rule interpreter is to identify the rules that are applicable for a given user request and then call the corresponding services (i.e., rule actions). More specifically, upon the receipt of a HTTP request, the rule interpreter parses the request and calls the profile manager to get the user identifier associated with the source IP address of the request. To optimize this process a cache is used to store (IP address, user identifier); the cache is carefully managed to reflect the changes in IP addresses for a given user (e.g., a user may be assigned different IP addresses during one session). The rule interpreter checks this cache first before calling the profile manager. With the knowledge of the user identifier, the rule interpreter accesses the (compiled) rules associated with the user, the rules associated with the requested URL (i.e., content provider rules), and the rules associated with the access provider; here also, we use a cache to store the rules: the rule interpreter access the database to get rules only when they are not in the cache. It then determines the applicable rules (i.e., rules for which conditions are true), and calls the corresponding services (local services or call-out ICAP-based services) in the corresponding order. For example, services at PP-2 are called before services at PP-4.

0-7803-7764-8/03/$17.00 Q2003 IEEE. 80

D. I Using a Proxy to “Break Free ” of the OPES Cache- Centric view

In the OPES framework, there is an assumption that the device used to realize the edge node functionality is a web cache server (e.g., NetCache [ 5 ] ) . In our design, caching is “just another edge service”, and we don’t assume ESN is primarily a cache. However, having said that, caching is a slightly different type of edge service than Language Translation, for example. For one thing, caching is not likely ‘subscribed’ to or otherwise explicitly chosen by end users. Rather, caching is likely deployed by the access or content provider, to reduce network traffic or improve access times. Secondly, caching is typically ‘fired’ for every subscriber (e.g. the provider has a cache and is using it). Thus it is not clear whether it warrants an explicit rule for each user in the rule database (the approach we take for now.)

Our proxy is responsible for processing user requests and for thread creation. The use of both a proxy and dual threads per user ‘transaction’ is necessitated by the design and implementations of most cache software.

Upon receipt of the user request, the proxy creates a thread that handles the processing at PP-1 and eventually calls the cache server. If the requested document is stored in the cache, it is returned to the first thread and then to the user. Otherwise, the cache server makes a request to the origin server, which is again handled by the proxy. A second thread is created to handle PP-2 and PP-3 processing and it sends back the processed document to the cache server. The latter caches the document and sends back the response to the awaiting first thread, which handles processing at PP-4 and sends back the response to the user. The somewhat complicated series of events arises because cache access to origin servers is via the ESN’s proxy and so that PP-2 and PP-3 rules can be evaluated as prescribed.

E. Example 4-PP System Flow In general, for incoming requests towards the content

server, services are called in the following order: (1) services associated with client rules; (2) services associated with access provider rules; and (3) services associated with content provider rules.

A typical processing flow is described as follows, and summarized in Figure 4. First, after some ‘subscription’ phase, a subscriber (owned by an Access Provider with an ESN) accesses Internet data via a web-browser. Each HTTP request becomes an ESN ‘request’. In the ESN (assuming the implicit ‘caching service’ is enabled for this user): (a) proxy receives user request and creates the first thread that calls the rule interpreter to invoke any applicable services at PP-1; if the request is not blocked

IEEE OPENARCH 2003

(e.g., by URL filtering service), it sends the request to the cache server; (b) cache server returns the requested document if it is stored in the cache; otherwise, it makes a request to the origin server. In this case, the request is intercepted and delivered to the proxy again; (c) the proxy creates the second thread to handle the intercepted request; it calls the rule interpreter to invoke any applicable services at PP-2, and then forwards the request to the origin server; (d) upon receipt of the response from the origin server, the second thread calls the rule interpreter to invoke any applicable services at PP-3 and then returns the response to the cache server; (e) the cache server sends back the response to the first thread; and (0 the first thread calls the rule interpreter to invoke any applicable services at PP-4. If the user subscribes to a Language Translation service, for example, it is likely triggered on the content at this point, after which it is returned to the user.

111. MANAGING SERVICES, SUBSCRIBERS, AND METADATA

A. Service Deployments and MetaData The Profile Manager (PM) is the steward of much of

the ESN meta-data, as well as being the customer- facing component for personalization and subscription. It provides a web interface from which users may subscribe, unsubscribe and customize services available at the edge, as well as manage their profiles. Part of PMs processing core is the ability to transform instances of the XML document types we use into an Oracle8i database for rapid and reliable storage and retrieval. We have also had to extend the semantics of the OMML to overcome its limitations (see below).

PM manages the metadata associated with edge services and responds to queries from other ESN components. Recall that ESN services are described using the OMML, deployed on ICAP servers and invoked by the Engine. To enable the customization of services, we had to extend the OMML to introduce conf igurability. This additional XML element enables service developers to specify the customizable service-parameters. For example, Language Translation 's single parameter is Language, which is the preferred delivery language (Mandarin or Korean in our prototype). We incorporated an additional description element to the OMML to allow a brief human-readable description of the service (OMMLs attribute of the same name serves a different purpose). Finally, we needed a service lifecycle status element for service status. Figure 5 illustrates a snippet of the Language Translation service metadata.

0-7803-7764-8/03/$17.00 02003 IEEE.

<service id="IcapLanguageTranslation"> <proxylet>

<owner description="Language Translation"> <name>Telcordia Inc.</name> <id>IcapLanguageTranslation</id> <version>l.O</version>

</owner > <info contact="Mr.System.Admin">

<protocol name="http" > modified-header>accept-language </modified-header>

</protocol <location>icap:// ... /LanguageTranslate</locations <exec-environment>java 2.0</exec-environment>

</info> </proxylet> <description>Delivers Web content in your preferred language, where possible</description> <configurability>

cconf igurable-parm name="Language" type="single"> <value>Mandarin</value> <value>Korean</value>

</configurable-parms </configurability> <status>active</status> </service>

Figure 5. Edge service metadata

Note that the location element describes fully the deployment of this service, including the domain, machine name, and the ICAP format with which it may be called. Note also that the service has a set of selectable language options from which the subscriber can select a "single" one.

B. Subscribers and Customization As subscribers log into the ESN configuration page, PM

parses the service and subscriber meta-data and generates dynamic Java Serve Pages (JSP). The JSPs allow subscribers to modify their profile, subscribe or unsubscribe services, or change service parameters. Figure 7 shows a user called Alice logging in, seeing her currently subscribed-to edge services, and modifying her Language Translation service.

Figure 6 shows a snippet of the user meta data in XML format, showing how the user's personalizations - on a per service basis - are captured in the data. Current IETF documents do not describe how to capture edge service subscriptions and customizations.

<user id="Alice"> < ! - other personal profile info here - > <service location="icap:// JLanguageTranslate?

Language=Mandarin" status="active"> </user>

Figure 6. Subscriber metadata showing service selection and customization

81 IEEE OPENARCH 2003

graph - the administrator can select any individual or combination of PPs. Another view shows a module in an XML editor frame. The former is especially good for rapid customer care, validating, simple editing, and subscriber monitoring, while the latter is best when the administrator must perform a detailed edit of the module

Allceecdlr" (e.g. adding a new condition under which a rule should 'fire'). The underlying representation for modules is the

C Y I I C I S C ~ ~ Virus ssuuuna U"."b.<dbod Subncdbo XML-based Intermediary Rule Markup Language

S"b.sribod Ll"SLlb.C"b" . Per"""., lnf" w c b w m * I I - u € L L Block- ""."b.srmd S"b=cllbr - ,>.*I Scrvi's. l d In.-"" U"."b.Cribod S"b.E"bC - stem-r w"l,\\..n"nlMaFlncr V"."b.Erm.dS"bacdbr

- - (IRML). Figure 8 illustrates both kinds of views.

CI. I . Edge Service Deployment Access Providers, or other ESN deployers, need the

. . - - .. . ma"- W I D SONcnt h P'-fcrrd nl..€?.- ability to deploy and activate/deactivate edge services. For example, new revenue-creating services may be added at any time, uploaded from 3rd party developers; alternatively, old services may need retiring. In either case the ESM plays a role. Using open remote interfaces

proxylets (services) into the ESN. Since it's built upon Java and XML, customizable integration of ESM with

The Edge Service Manager (ESM) component Commercial application servers - such as IBM Websphere encapsulates several important management features. - is possible, enabling further sophistication. In its current Intended for edge-service administrators, ESM enables Prototype stage, ESM Provides administrators With a integrated management of: quick graphical view of service statuses (e.g.

Subscriber, service, and Content Provider meta-data activated I suspended) and their deployments to local and 0 Service deployment and activatioddeactivation remote machines (e.g. deployed I awaiting-deployment). 0 Rule modules, including editing (XML editor, etc.)

C2. Service Sequencing, Global Rules, and Validation Customer Care through visualizations, rule module Service sequencing is important because: validation, and simulated subscriber access Some combinations of services do not make sense, (automatic validation is desirable, but challenging). producing unwanted results. Furthermore, their In the Access Provider-centric deployment of our interactions are beyond what subscribers understand ESN, 31d Party Service Providers and Content Providers 0 Sequencing choices may affect Engine performance (CP) are the collaborating 'business entities', each

requiring a programmatic interface into the ESN. The former for new service uploads (i.e. outsourcing of edge service development), and the latter for rule module uploads describing how service callouts can be applied to specific Content Provider content (e.g. "The page with URL x is available in Spanish at URL y"). The ESM implements these interfaces on behalf of the ESN and serves as a single point-of-entry for administrators into (meta) data repositories.

CI. Module Visualization Rule modules - both Subscriber and Content

Provider - describe what services to fire, at what ESN PP, and under what conditions. To accommodate their range of complexities, ESM offers two main types of

. POlonOllnfo

Figure 7. A subscriber logs into the PM to manage her edge services. PM manages the resulting XML metadata in Oracle databases

based on XML and HTTP, 3rd parties "uploa&' so-called

C. The Edge Service Manager

icap I IocdhWleopFcthr (1)

management views On a simp1e "iconic chain" view in which the combined services

One Figure 8. A subscriber module visualized by Edge Service Manager (back). and the rule module editor Cfroni)

specified in the module are shown as a simple directed

0-7803-7764-8/03/$17.00 Q2003 IEEE. 82 IEEE OPENARCH 2003

<?xml version=’l. 0‘ encoding=“UTF-8“?> <rulemodule>

<owner class=’client‘>

< /owner >

<rule processing-point=‘4’>

clrule7 <rule processing-point=’4’>

</rule>

<name>John Smithc/names<id>jsmith1309l</id>

. . . . .

<action>icap:// ... /ContentAdaptation</action>

<action>icap:// ... /IcapInsertAdc/action>

</rulemodule>

Figure 9. A subscriber’s rule module

The possible sequence of services invoked for a particular subscriber’s access to content is described within subscriber IRML rule modules. Similarly, services allowed on content are described in Content Provider modules. The ESM enables administrators to specify service sequencing at each of the PPs in two ways. One way is to drag, drop, and reconfigure the service graph to include new services. The other way is to directly edit the IRML rule module (both shown in Figure 8). For example, administrators may want to insert and enforce a caching or a monitoring service within subscribers’ modules.

Global sequencing rules in the ESN serve as constraints on service sequencing. ESN stewards rules in the form of (enhanced) IRML, enabling the global sequencing rules themselves to be edited (as above). When modules are to be validated, ESN loops through PPs of the module in question and, with the global rules as a reference, determines if there are any semantic violations. For example, if (a snippet of) of subscriber John Smith’s module is as in Figure 9, and (a snippet of) the global rules are as in Figure 10, then there is a semantic service conflict, as the subscriber’s module specifies the content adaptation service before the ad insertion service at point 4 (but global rules dictate that adaptation should be preceded by ad insertions and it is obvious why - if an ad is inserted after adaptation it remains un-adapted (e.g. possibly un-translated)). Figure 11 illustrates ESM response to a validation query on a subscriber’s rule module. Note that batch validations on many subscribers can also be initiated. In general, the semantics of service interactions and sequencing is difficult, and one of our ongoing efforts.

Telcordia is a leader in feature interaction research for telephony services. Today’s edge services are, in many ways, more complex. Beyond sequencing rules established by a community of edge service players, other approaches for edge services may include having services ‘declare’ their features in a parseable format, exploiting existing tools and languages such as LOTOS or W3C’s Resource Description Format.

0-7803-7764-8/03/$17.00 02003 IEEE.

C3. Customer Care Troubleshooting & Simulation Just as telecommunications services require customer care centers, so too will edge service providers receive complaints from subscribers (e.g. “I don’t get the type of service results I expect”, or “my services don’t work as advertised.”). Therefore, it is important to be able to troubleshoot problems quickly and efficiently. To this end, ESN simulates access to specific content by specific subscribers for a representation of the services that may be triggered for such a real access. We say ‘may’ since beyond the subscriber’s services and the Content Provider’s content rules, the actual service triggering may depend on some or all of:

<?xml version=” 1.0” encoding=”UTF-E”?> <rulemodule>

<owner class=”global”> <name>Global Precedence Rules</name> <ID>administrator</ID>

</owner> ... .

< I - Every service (action) has 0 or more others that have “precedence” over i t - ->

<rule processing-point=”4”> <actionsIcapInsertAd</action>

<rule processing-point=“4”> <action>IcapLanguageTranslation</action> <precedeBy>IcapInsertAdc/precedeBy> </rule> <rule processing-point=“4“> caction>ContentAdaptation</action> cprecedeBy>IcapInsertAd</precedeBy> cprecedeBy>IcapLanguageTranslation</precedeBy> e /rule>

/rule >

I </rulemodule> Figure IO. Apart of some ESMglobal rules.

0 Type of content accessed (e.g. media type, etc.) Subscriber’s current context, such as cookies and

0 Environmental factors such as the time-of-day, browser type, etc.

geographical access point, etc.

Nonetheless, it is useful; at times revealing conflicts or inconsistencies in rule combinations. For example, an administrator may select a subscriber to troubleshoot, and enter a URL into the simulation box (bottom left, Figure 11). In response, ESM loops through the PPs and the subscriber and Content Provider rule modules (as described in previous section) and determines which services will trigger. Services conditional on “run-time” environment variables can be shown with special formatting or omitted. To check for possible discrepancies, the resulting ‘service graph’ can then be validated against the global service rules by the ESM.

83 IEEE OPENARCH 2003

i

Figure 11. Validation of a rule module or simulation sequence. ESMcan alert the administrator of errors or take initiative to repair them

IV. RESULTS Figure 12. The model for edge services node operations

A . Performance and Analysis of Edge Sewices Engine In this section, we present a model that captures the

behaviors of the ESN for analysis purposes. We derive this model to understand the effects that various parameters have on the system performance in terms of response time perceived by the users, system throughput of the edge service node, and load sharing of Web servers. Note that the model below assumes a standalone ESN - that is, without a gateway router and Web switch (as in Figure 1).

A. I Model First, we define the following terminologies to denote a few parameters used in the ensuing discussion. Pi$. the probability that the finite state machine transitions from state i to state j, if i # j; the probability that at least one service is triggered at PPi, if i = j . Tij: the time it takes to exit state i and enter statej

A standalone ESN is modeled by the finite state machine in Figure 12. There are five states in the above figure. State 0 represents the dispatch of user requests and delivery of user responses. Each other state represents a processing point in the edge service node, as discussed in section 11. Once the state reaches either processing points PP-1, 2 or 3, there are three possibilities for the next state transition-triggering the services at this processing point, moving forward to the next state, and making state transition to state 0. At PP4, there are only two possibilities since state 0 is the only possible next state.

0-7803-7764-8/03/$17.00 02003 IEEE.

The rationale behind the above model is as follows. Services at a given processing point would not be triggered unless users have previously "subscribed" or unless an explicit request is made. Consider a request that enters the ESN and that has reached PP-1. If one or multiple services need to be triggered at PP-1, ESN needs to send ICAP request message(s) to the service(s) and wait for the ICAP response(s) and repeat this procedure until either all the subscribed-to services have been invoked or the returned ICAP response demand the encapsulated HTTP response message be delivered to the requesting user. For the simplicity reason of modeling, we represent the invocation(s) by a single loopback arc in Figure 12. So this arc stands for the collective behavior of multiple invocations rather than an individual service that could be invoked at a processing point.

Each time an ICAP response message is received from a service, the edge service node needs to check if the encapsulated HTTP message should be forwarded to the next state or should be directly retumed to the user. To illustrate this, let's suppose content filtering (e.g. denying access to certain URL's) is the only service being subscribed at PP-I. If the accessed URL is on the 'blocked list' the flow passes out of the ESN and is returned to the user. If not, the edge service node pushes the request to the next processing point.

In the process of coming up with the above model, we discovered that, as defined, the ICAP protocol's performance could be improved. In the case of multiple services that need to be invoked, it would be desirable if the first ICAP request message lists all the services to be invoked. The first service can then decide whether it should forward the requests to the next service or the

84 IEEE OPENARCH 2003

ESN, etc. A clear advantage would be reducing network traffic and transmission time by a factor of two.

Now we will use the model to derive the expected service time that a request would experience at an edge service node. Let E(t) denote the expected service time of the edge service node in our model. E(t) can be expressed with the following equation:

Note that f(i) = (i - 1) mod 5 , Po, = 1 and

With the above equation, we can predict the request service time given the stochastic values of the identified parameters (this comprises our ongoing work).

A.2. Implementation Issues Figure 13 illustrates our lab setup which included the

following equipment types: open source Squid Web Proxy Cache on Linux, Windows NT and Linux boxes in ICAP callout server roles, Alteon 180e and Cisco Catalyst web-switches (Layer 3-7 switches), and a Cisco gateway router. Clients were run on Windows 2000 PCs. The ESN was created with Java2 on Windows 2000. Supplemental software included Oracle8i, Tomcat, and Apache.

The model discussed in the previous section is based on the assumption that we have a single standalone ESN on the critical path between users and Web servers. As our ESN, however, employed a Layer 3-7 Web switch to filter and forward requests and responses, one of our main contributions is a technical workaround to allow software-based ESN to work with today’s technology mix. Consider the caching service enforced at PP-1. When cache misses occur, the cache makes a request directed towards the origin content server. If ESN cannot intercept the requests, the request flow would skip the remaining processing points, which violates ESN (and ICAP) semantics. Our solution to this type of problem is to have a single request being serviced by two threads, as described in Section 2.

e,$ = 1 - e.,;+, .

B. Lessons Learned

ESN, we have leamed valuable lessons: Throughout the design and implementation of our

0-7803-7764-8/03/$17.00 Q2003 JEEE.

Edge Services

ESN “subscribers”

Figure 13. Lab setup and ESN deployment (ESN includes Edge Services Manager and Profile Manager)

Limitations of OPES - In OPES model, it is assumed that the intermediary operator is a Content Delivery Network (CDN) entity, whose main service is caching (e.g. Akamai). In our approach, caching is but one of many possible services and the ESN operator may be an Access Provider, CDN, or other 3rd party entity. Incorporating a 3rd-party (i.e. Squid [6] ) cache software in the ESN, and making it a true ‘callout’ service, required us to use two threads for each user ‘transaction’ instead of one (as described in Section 11). Furthermore, OPES assumes a four PP model, relative to a cache. We believe that ultimately this is too restrictive. Though the prototype we described here used 4 PPs, we are investigating a 2 PP model in which edge services (including caching) are sequenced at the “in” and “out” points of the node, without loss of generality or functionality.

Limitations of the OMML - During our work with OMML draft specs we realized that they were insufficient to support the operations of an ESN as ours. Firstly, OMML does not capture service configurability. This is a real problem since most edge services will be customizable. Second, it does not support capturing edge service status, nor does it have a suitable tag for a textual description of the service (e.g. for a subscriber’s benefit). We extended OMML to support all of the above items.

Commercial ICAP Implementations - In the course of deploying commercial, ICAP-compliant, edge services to our callout machines, we discovered that vendors can be inconsistent with their ICAP implementations, and do not necessarily conform to the IETF draft. Some products support NetCache versions of ICAP, while others support older versions of the standard. This complicated the design of ICAP callout clients.

85 EEE OPENARCH 2003

Wrapping Services in ICAP protocol - We discovered that edge services not supporting ICAP could be quite easily made compliant by wrapping them in a Java ICAP proxy (our Cache service approach).

Limitations of non-native Java2 - Although Java’s easy HTTP interfaces and portability made it our initial choice, a more efficient language such as C or C++ may be used going forward (e.g. both [4] and [7] report on their usage of C).

B. I Architectural Tradeofs This sections summarizes architectural tradeoffs that

we had to consider during design and implementation. 0 Choosing a cache-centric ESN or not -- The advantages may have been that the ESN can strictly comply with IETF standards, which use the cache- centric view. The pro is that we have created a more general model by allowing caching to be a (somewhat special) edge service, triggered at any processing point (though it seems to make most sense at only a few). 0 Database representation of rules, etc. -- Since rule triggering is a fundamental issue, further analysis should be done on the efficiency and scalability of the (relatively straightforward) scheme we used. 0 Cache in hardware versus software, inside or out of ESN - While we chose a software cache that was ‘outside’ of the ESN architecture, other choices were possible. Choosing a hardware cache and putting it inside ESN would result in fewer threads during ESN operation and increased efficiency. On the other hand, our software cache outside the ESN gives us a more generic and open architecture at the cost of additional threads and slower response time. 0 ICAP protocol -- using the ICAP callout protocol unchanged has obvious advantages. However, improvements are possible to ICAP, including the ability to chain multiple callouts at a given processing point together , which would increase performance.

V. RELATED WORK A. The OPESModel

The OPES framework and sister specifications, namely OMML and ICAP, are currently Internet drafts, and they serve as the foundations of our ESN work. However, OPES is a caching-centric model while our ESN is not. OPES strictly limits operations to the 4-PP model, while we envision other possibilities worth researching. OMML element tags are not sufficient for edge service customization and management, and have been extended in our ESN. The ICAP [4] protocol is the plumbing technology of edge services, providing a way to vector content between caches and network-based

applications servers. Its non-proprietary specification allows value-adding services to be openly called out to anywhere in the vector (e.g. network path).

B. Other Related Work Bell Labs has created a rule parser in C Language [7],

while the ICAP Forum provides an ICAP server implementation [4]. In our view of ESN, both may be considered ‘components’. Neither proposes an engine implementation nor management features. [8] describes Akamai’s content delivery approach. Akamai uses so- called edge-nodes, but almost exclusively for locating caches upon them. Although they do not claim to use ICAP protocols, our ESN complements Akamai’s infrastructure. In related research we have proposed Agent-based management and aggregation of distributed services [9] for Next-Gen Network Providers, in which intelligent agents - located in distributed services on Service Providers networks - deliver value to subscribers. [ 101 and [ 113 present content services and customization frameworks, however neither proposes sophisticated service management, such as sequencing control.

VI. CONCLUSIONS We have designed and implemented an open architecture for service management and deployment at network edges. Our approach has additional benefits, features, and improvements to both existing IETF drafts and related works. Our design and implementation has yielded innovative approaches to address existing technology limitations. Future work includes stress testing and quantitative analysis of the ESN performance.

REFERENCES [ 11 OPES - Open Pluggable Edge Services, http://www.ietf-opes.org [2] A.Beck, M.Hofinann, “Enabling the Intemet to Deliver Content-Oriented

Services”, Proc. Int ‘I Workshop on Web Caching and Content Distribution, Boston Univ., June 2001.

Rule Specification Language for Intermediary Services, IETF Draft, draft- beck-opes-omml-OO.txt, August 2001.

[3] C.Maciocco, M.Hoffman, OMML: OPES Meta-data Markup Language A

[4] ICAP Forum, http://www.i-cap.org [5] NetworkAppliance, NetCache product documentation. Available at:

[6] Squid Web Proxy Cache, http://www.squid-cache.org [7] Bell Labs, IRML Parser project, available at http://www.belllabs.com/

[SI J.Dilley, B.Maggs, J.Parikh, H.Prokop, R.Sitaraman, B.Weihl, “Globally

http://www.netapp.com/products/netcache/

project/lRML-Parser/

Distributed Content Delivery”, IEEE Computer, 6(5), pp.50-57., Sept.2002. 91 B.Falchuk, K.Cheng, F.J.Lin, V.Jokubaitis, B.Pineiro, “Agent-based

Management and Unification of NGN and Personal Services”, Proc. IASTED Int ’I Con$ on Artificial Intelligence and Soft Computing, July

101 G.Ravindran, M.Jaseemudin, A.Rayhan, “A Management Framework for 2002, pp.19-24.

Service Personalization”, Proc. Int ‘I Con$ on Mgmt. Of Multimedia Networks and Services, Santa Barbara, October 2002.

1 1 1 W.Ma, B.Shen, J.Brassil, “Content Services Network: The Architecture and Protocols”, Proc. Int ‘I Workshop on Web Caching and Content Distribution, Boston Univ., June 2001.

0-7803-7764-8/03/$17.00 02003 IEEE. 86 IEEE OPENARCH 2003