OPES Working Group A. Barbir
Internet Draft N. Bennett
Document: draft-barbir-opes-spcs-03.txt R. Penno
Nortel Networks
H. T. Pham R. Menon
Alcatel Intel
J. Mysore S. Sengodan
Motorola Nokia
March 2003
Requirements for an OPES Service Personalization Callout Server
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document provides the requirements for implementing a Framework
for Service Personalization (FSP) in OPES intermediaries. This
document provides a summary of modifications and required protocols
that need to be supported by OPES intermediaries in order to allow
for the development, deployment, and execution of a Service
Personalization (SP) call-out server.
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Conventions used in this document..................................3
1. Introduction....................................................3
2. Definitions and Terminology.....................................4
3. Overview of Service Personalization............................9
3.1 Subscriber Profile............................................10
3.2 Content Profile...............................................10
3.3 Content Selection.............................................11
3.4 Quality of Delivery (Origin Server Selection).................11
4. OPES Personal Content Services Call-out Server.................12
4.1 Requirements for an OPES SP Call-out Server...................14
4.1.1 Ability to identify a client/subscriber.....................14
4.1.1.1 Subscriber Sessions.......................................14
4.1.2 Protocol to communicate Subscriber Profile..................14
4.1.3 Protocol to communicate Content Profile.....................15
4.1.4 Storage Requirements for Subscriber/Content Profile.........16
4.2 OPES SP Physical Boundary.....................................17
4.3 OPES SP Sequence of Operations................................17
4.4 Content Services..............................................18
4.4.1 Service Characterization....................................19
4.4.2 Service Availability........................................19
4.4.3 In-Path Services............................................19
4.4.4 Out-of-Path Services........................................19
4.4.5 Service Selection...........................................19
4.4.6 Service Reliability/Service Failure.........................19
4.5 Privacy and Security..........................................19
5. Example of a SP Call-out Server................................20
5.1 Personalization Requirements from OPES Framework..............21
5.1.1 User Profile Integrity and Security.........................21
6. Security Considerations........................................21
6.1 Security Considerations for SP Scenario.......................22
7. Acknowledgments................................................22
8. References.....................................................23
9. Authors' Addresses.............................................23
10. Full Copyright Statement......................................25
Barbir, et al. Expires September 2003 [Page 2]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
1. Introduction
In the Internet today, personalization and profiling services are
provided to subscribers by portals. Portals require subscribers to
log on to their sites, which help to identify the subscriber.
Portals perform subscriber profiling by tracking their habits and
preferences. In order to be able to create accurate subscriber
profiles, the portals rely on co-located subscriber identification
and profiling from participating web sites.
Major drawbacks of current personalization schemes are their
reliance on origin web servers to perform the personalization tasks.
The approach requires content providers to store and manage
different content for different subscribers. Current schemes lead to
scalability and optimality issues. This is because the
personalization task is done based on incomplete information about
the subscriber. In particular, content provider may not be aware
about many types of information about the subscriber. Such
information includes: geographic location, QoS policy, device type,
and access rate. The lack of such information could dramatically
decrease the efficiency of any personalization task undertaken on
behalf of the subscriber.
A potential solution to the above problem is to shift the
responsibility for personalizing content to an intermediary device.
This has many advantages over current solutions, and represents an
important value add service that could be provided by network edge
caching proxies or other intermediary devices. In particular,
performing personalization at the edge of the network has the
following advantages:
1) Devices are closer to the edge, whereby better control over
Quality of Service (QOS) can be achieved.
2) Personalization can occur on cached objects thus reducing the
traffic across the network.
3) The subscriber may have better trust when dealing with the local
Internet provider.
4) The same service provider can handle authorization and
accounting.
5) Content transformation and adaptation functions are off-loaded
from the content source, reducing server load.
In [OPES-FSP], a Framework for performing personalization services
(FSP) was introduced. It aims to provide a Framework and Protocols
for the delivery of optimal content variant for a given request
Barbir, et al. Expires September 2003 [Page 3]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
based on subscriber profile and policies, and content profile and
policies. FSP defines the essential components and mechanisms that
are needed in order to provide high quality personalized services to
subscribers in a secure and reliable manner.
This document establishes the requirements for developing an OPES
Service Personalization (SP) call-out server. The document is
organized as follows: section 2 defines the terms used throughout
the document; section 3 provides a summary of SP, while section 4
discusses the implementation of an OPES SP call-out server.
GENERAL NOTES:
- How to get SP to know which services are available/configured for
a given OPES intermediary, and how to invoke them? (rule module
generation)
- Does the user have any say on which services providers are used
for which services? Does the content provider? What are the
security issues if we do allow such configurability?
2. Definitions and Terminology
This section consists of the definitions of a number of terms used
to refer to the roles, participants, and objects potentially
involved in FSP implementations. Although the following uses many
terms used in [RFC-2616] and [RFC-3040], there is no necessary
connection to HTTP or web caching technology. FSP and this
vocabulary are applicable to other protocols and content networks.
Words enveloped within 'single quotes' are defined terms within this
document.
ACTION
An action is a form of a policy action [RFC-3040] that results in
the execution of a 'service module' when 'conditions' of a 'rule'
are met.
AUTHORITATIVE DOMAIN
A logical domain in which the network elements have rights, either
delegated or inherited to act authoritatively on behalf of a party.
This logical domain may be wholly contained within the
administrative domain [ESFNEP] of the party, or it may be a
collection of administrative domains in which the party rights have
been delegated.
CACHE (REFERENCE DEFINITION [RFC-2616])
A program's local store of response messages and the subsystem that
controls its message storage, retrieval, and deletion. A cache
stores cacheable responses in order to reduce the response time and
network bandwidth consumption on future, equivalent requests. Any
client or server may include a cache, though a cache cannot be used
by a server that is acting as a tunnel.
Barbir, et al. Expires September 2003 [Page 4]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
CACHING PROXY (REFERENCE DEFINITION [RFC-3040])
A proxy with a cache, acting as a server to clients, and a client to
servers. Caching proxies are often referred to as "proxy caches" or
simply "caches". The term "proxy" is also frequently misused when
referring to caching proxies.
CLIENT (REFERENCE DEFINITION [RFC-2616])
A program that establishes connections for the purpose of sending
requests.
CONDITION
A form of a policy condition [POLICY] that is an expression, which
is used to determine whether a 'rule' 'action' should be executed.
CONFIGURATION PATH
'Rule modules' and 'OPES service modules' are downloaded into an
'OPES admin server' from 'rule authors' and 'proxylet providers',
respectively, and then distributed to the 'OPES intermediary'. This
flow is referred to as the configuration path, since the data being
transferred along this path is used to provision the 'OPES
intermediaries' for service.
CONTENT CONSUMER
The 'client' that is the final destination of content delivery.
CONTENT PATH
The content path describes the path that content requests and
responses take through the network. Typically, content requests and
responses flow between a client, and/or an 'intermediary', and a
'content server'.
CONTENT PROFILE
A content profile consists of a set of elements that describe
available variants for given content. The profile also includes
policy information about allowable transformations, adaptations, and
Digital Rights Management that are applicable for that content. The
profile can be applicable to a specific piece of content, a set or
class of content, or an aggregation of content from several
locations.
CONTENT SERVER
The server on which content is delivered from. It may be an 'origin
server', replica server, 'surrogate' or parent proxy.
CONTENT SERVICE
A service operating on and providing a value-add to content.
DELEGATE
A 'caching proxy' located near or at the network access point of the
'user agent', delegated the authority to operate on behalf of, and
typically working in close co-operation with a group of 'user
agents'.
Barbir, et al. Expires September 2003 [Page 5]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
EDGE SERVICE NETWORK
An 'overlay network' of 'intermediaries' layered onto an underlying
content network [C-MODEL] that incorporate 'content services' that
operate on messages flowing through the 'content path'.
IN PATH
In-Path Content Services are naturally within the message path of
the application they are associated with. This may be an Application
proxy, gateway, or in the extreme case, one of the end-hosts, that
is party to the application [C-MODEL].
INTERMEDIARY
Intermediaries are application gateway devices located in the
'content path' between 'client' and 'origin server'. 'Caching
proxies' and 'surrogates' are probably the most commonly known and
used intermediaries today.
OPES ADMIN SERVER
An OPES admin server performs authentication, authorization and
accounting (AAA) functions for an OPES 'edge services network'.
These functions include, but are not limited to downloading of
'proxylets' and 'rule modules' from trusted parties, authorization
and authentication of 'OPES services', the collection of accounting
and log data, and other administrative tasks. It must be a member of
the 'authoritative domain' of the parties it is authorizing 'content
services'. It must be a member of the party's 'authoritative domain'
in whose behalf it is provisioning 'content services'.
OPES ENGINE
An OPES engine allows new services to be defined and executed on
'OPES intermediaries' according to the policies set up by an 'OPES
admin server'. OPES Engine contains a message parser, and a rule
processor that reside in the flow of content passing through the
'OPES intermediary' collectively form a 'PEP'. The 'OPES engine'
calls actions, which reside in either the 'proxylet run-time system'
or as 'remote call-out stubs'.
OPES INTERMEDIARY
An "intermediary" device integrating a compliant 'OPES engine'. OPES
intermediaries are typically hosted on 'delegates' or 'surrogates'.
OPES SERVICE
An OPES service is an authorized 'content service' performed on a
message flowing through the 'content path' by a 'OPES service
module'.
OPES SERVICE MODULE
OPES service modules are executable code modules that are executed
ether on the local 'proxylet run-time system' or on the 'remote
call-out server'.
Barbir, et al. Expires September 2003 [Page 6]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
ORIGIN SERVER (REFERENCE DEFINITION [RFC-2616])
The server on which a given resource resides or is to be created.
OUT-OF-PATH
Out-of-Path Content Services are not natively in the transport path
of an application. In other words, they are not necessarily resident
(or co-resident) on entities that are natively in the path of
application flows.
OVERLAY NETWORK A set of connected network elements layered onto
existing underlying networks, and presented as a virtual application
layer to both 'clients' and 'origin servers'.
PCS CALL-OUT SERVER
A 'remote call-out server' that performs the task of generating
dynamic 'rule modules' that are either encoded or could be extracted
from a 'subscriber profile', and which represent a 'subscriber's
personalization preferences and subsequently loading them onto the
appropriate 'OPES admin servers' or 'OPES Engines'.
PDP See 'policy decision point'.
PEP See 'policy enforcement point'.
POLICY DECISION POINT (REFERENCE DEFINITION [POLICY])
A logical entity that makes policy decisions for itself or for other
network elements that request such decisions.
POLICY ENFORCEMENT POINT (REFERENCE DEFINITION [POLICY])
A logical entity that enforces policy decisions.
PROXYLET
A proxylet is 'OPES service module' that runs on the 'OPES
intermediary' within the 'proxylet run-time system' and provides a
service on 'content path' requests or responses.
PROXYLET LIBRARY
Proxylet library is a library provided to support runtime services
in the 'proxylet runtime system'.
PROXYLET META-DATA
Proxylet meta-data describes the characteristics, features and
requirements associated with a proxylet. Examples for such meta-data
are the name of the 'proxylet', its functionality, its version
number, where to get it, license related information, execution
environments, etc. The meta-data can physically be separated from
the 'proxylet' code, but it must be possible to uniquely associate
meta-data with 'proxylets' and vice versa.
PROXYLET PROVIDER
Proxylet provider is the party that provides the 'proxylet' 'OPES
service module' to the 'OPES admin server'.
Barbir, et al. Expires September 2003 [Page 7]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
PROXYLET RUN-TIME SYSTEM
The local execution environment on an 'OPES intermediary'.
'Proxylets' execute as local (as opposed to 'remote call-out')
'actions' within this environment.
REMOTE CALL-OUT
A remote procedure call made via a 'remote call-out protocol" to a
'remote call-out server' that is invoked as the result of an
'action'.
REMOTE CALL-OUT PROTOCOL
The network protocol that encapsulates and transports a 'remote
call-out' between an 'OPES intermediary' and a 'remote call-out
server'.
REMOTE CALL-OUT STUB
A remote procedure call stub running on the 'OPES intermediary' that
binds a 'remote call-out' to the 'OPES engine' as 'actions'. The
stub marshals the 'action' to/from the 'remote call-out protocol'.
REMOTE CALL-OUT SERVER
A cooperating server that runs 'OPES service modules' as the result
of a 'remote call-out'.
RESOURCE
A network data object or service that can be identified by a URI.
Resources may be available in multiple representations ('variants')
(e.g. multiple languages, data formats, size, resolutions) or vary
in other ways.
ROLE (REFERENCE DEFINITION [POLICY])
An administratively specified characteristic of a managed element
(for example, an interface). It is a selector for policy rules and
'rule modules', to determine the applicability of the rule/'rule
module' to a particular managed element.
Note: Provisioning Class has been substituted with 'rule module' in
this definition, as 'rule modules' are instances of Provisioning
Classes within the OPES application domain.
RULE
Rules are forms of policy rules [POLICY] that contain 'conditions'
and 'actions' that are to be executed if the 'conditions' are met.
RULE AUTHOR
The rule author is the party that authors and provides a 'rule
module' to the 'OPES admin server'.
RULE MODULE
A rule module is a form of a policy Provisioning Class [POLICY] that
contains a set of 'rules' and information about the rule module
owner.
Barbir, et al. Expires September 2003 [Page 8]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
SP CALL-OUT SERVER
A 'remote call-out server' that performs the task of generating
dynamic 'rule modules' that are either encoded or could be extracted
from a 'subscriber profile', and which represent a 'subscriber's
personalization preferences and subsequently loading them onto the
appropriate 'OPES admin servers' or 'OPES Engines'.
SUBSCRIBER
A human being, or user, using a 'client' or 'user agent' to connect
to a network in order to make requests for personalized content or
services.
SUBSCRIBER PROFILE
A subscriber profile consists of a set of elements that define a
'subscriber's personalization preferences. This includes, but is not
limited to a description of the device capabilities, Quality of
Service (QOS), access rate, accounting information, content type
preferences, and policies regarding allowable content. A 'subscriber
profile' may also include 'rule modules' that allow an OPES engine
to perform personalization.
SURROGATE (REFERENCE DEFINITION [RFC-3040])
A gateway co-located with an origin server, or at a different point
in the network, delegated the authority to operate on behalf of, and
typically working in close co-operation with, one or more origin
servers. Responses are typically delivered from an internal cache.
Surrogates may derive cache entries from the origin server or from
another of the origin server's delegates. In some cases a surrogate
may tunnel such requests. Where close co-operation between origin
servers and surrogates exists, this enables modifications of some
protocol requirements, including the Cache-Control directives in
[RFC-2616]. Such modifications have yet to be fully specified.
Devices commonly known as "reverse proxies" and "(origin) server
accelerators" are both more properly defined as surrogates.
TRIGGER
See 'condition'.
USER AGENT [RFC-2616]
The client that initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
VARIANT (ALSO: CONTENT VARIANT)
A specific representation of a network data object or service
(resource) identifiable by a URI. A 'variant' is differentiable from
other representations of a resource due to language, data format,
size, resolution or other distinguishing characteristics.
3. Overview of Service Personalization
Barbir, et al. Expires September 2003 [Page 9]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
The details of FSP are given in [OPES-FSP]. In this section a brief
overview of the Framework for Service Personalization (FSP) is
provided.
The end goal of any personalization effort is to enable content
services on network traffic in a personalized manner. Content
services are application-level services that provide added value to
content over simple content delivery. Examples of such services
include: virus scanning, content translation, packet filtering,
content adaptation, and others. What is desired is some means of
allowing subscribers to specify either directly or indirectly which
services should be applied to their traffic stream, and under what
circumstances.
In general, personalization can occur at any point in the network
that has access to the request, the content, the content profile,
and the subscriber profile. Essentially, any point in the content
path is a potential point at which personalization decisions could
be made. The next sub-sections summarize the basic components of
FSP.
3.1 Subscriber Profile
In order for SP to be able to deliver to the subscriber an optimal
content variant for their request based on the subscriber profile
and policies, these profiles and policies must be able to completely
describe a subscriber's personalization preferences. To this end, a
precise definition must be developed that allows for the creation of
a subscriber profile that also includes associated policies. The
subscriber profile must also be able to be stored either in a
centralized location, or be distributed across multiple locations in
the network, including the user agent.
The set of elements that comprise a subscriber's profile includes
among others a description or a reference to device capabilities,
Quality of Service (QoS), access rate, accounting information, and
content type preferences. A subscriber profile also includes
policies that define what constitutes acceptable content (e.g.
topic, explicit content, linked content origin, acceptable
manipulations, filtering policies) that the subscriber is willing to
receive.
3.2 Content Profile
Content profiles and policies, on the other hand, encapsulate
information about the content. This includes information such as
available variants at the content source, encoding method,
dimensions (for graphics), etc. Content profiles and policies also
include information about what is and is not allowed in terms of use
or manipulation of that content (e.g. do not allow legal documents
to be translated into another language). A content provider may
provide hints to a personalization intermediary in choosing the most
Barbir, et al. Expires September 2003 [Page 10]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
suitable transformations to apply in some form (e.g. INFOPYRAMID
provides one such representation).
Content policies are an integral part of the content profile for a
given piece of content. A content profile must encapsulate all of
the information about the content which is needed to make any of the
personalization decisions required for that content, including
whether or not a given personalization transformation is allowed.
3.3 Content Selection
Content selection involves choosing the most appropriate or optimal
available content variant from a content source for transmission
back to the subscriber. The choice of optimal content source in this
context is restricted to the task of identifying the best content
variant that could be adapted to suit the subscriber. This task is
separate and distinct from the process of choosing the content
source that is optimal from a network perspective, based on network
delay, server load, or other such metrics.
There are various criteria that can be used to determine the most
appropriate content variant to retrieve from the content source. The
simplest of these is choosing a variant that completely or most
closely fits the subscriber's preferences. This is, however, only
one possible form of content selection.
In the event that there is no content variant that completely fits
the subscriber's preferences, alternate content selection criteria
may apply [OPES-FSP]. The task of selecting the most appropriate
content variant may be performed as a function of the ease of
translation of the content into the appropriate format provided that
the content policy allows for the needed adaptation.
Editor Note: Expand the notion to the case when there is no content
variant.
3.4 Quality of Delivery (Origin Server Selection)
This criterion only applies in the case where there are multiple
sources from which content can be obtained, and the personalization
framework has some influence over the content source selection. In
this case, it makes some sense to define a Quality of Delivery
(QoD). In the case where there is only one content source from which
content can be obtained, or where the personalization framework has
no influence over which site gets chosen, quality of delivery
reduces to whatever quality the chosen content source can deliver.
Editor Note: This section needs a bit of rewrite. Here, QoD has more
than just availability of a variety of content sources with the same
content represented in different quality levels - example: streaming
media content at different bit rates and encoding quality levels. It
also has to do with other parameters like (1) what is a subscriber's
best access bandwidth (2) is there a cost issue (free vs. paid
content) (3) policies in place by content source/provider vs. those
Barbir, et al. Expires September 2003 [Page 11]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
by the subscriber (4) device characteristics - same subscriber
accessing same content from different user agent devices etc.)
4. OPES Personal Content Services Call-out Server
The Open Pluggable Edge Services (OPES) framework enables the
creation and provisioning of services executed on application data
by participating transit intermediaries. The OPES system
architecture supports the definition of a SP call-out server that
could be responsible for performing personalization tasks.
Such a server would overcome most of the technical challenges
mentioned as barriers in [ESFNEP], and would be able to provide
extensible services such as virus scanning, ad insertion, caching of
personalized web pages, limited client bandwidth adaptation, request
filtering, and creation of subscriber profiles on a per-subscriber
basis.
Figure 1 shows a diagram of the main components of the OPES
framework, with the addition of a SP call-out server. In the
diagram, the SP call-out server is represented as a separate entity.
This arrangement allows a SP call-out server to perform
personalization services for multiple OPES Engines, or for a single
OPES Engine to balance personalization traffic between multiple SP
call-out servers. From an architectural standpoint, it would also be
possible for the OPES Engine and/or the OPES admin server to be
modified to act as a SP call-out server. This option would, however,
severely limit the scalability of the SP call-out server from an
implementation perspective.
Editor note 1:(1) the way components are laid out below, it appears
as if the communications between the user agent and the SP call-out
server is direct (i.e., after initial request made through the OPES
Engine, someone (OPES Engine?) redirects the user agent to the SP
callout server. This may be OK, as the OPES Engine does not need to
be in the "data path" for every user agent after the initial request
is made for content.
Editor note 2: The notion that SP callout server may be implemented
in the same "box" (system) as the OPES Engine is fine with a small
number of subscribers and no other/few other callout services or
proxylets running on the OPES Engine. For scalability, a separate SP
callout server makes sense, depending on the complexity of
personalization processing.
NOTE: We need to clarify this diagram to explicitly show potential
locations for the implementers of the supplementary services, with
examples. Also, we need to modify this and/or add a new diagram
which shows the control path connections between the OPES
engine/admin server and the SP call-out server.
Barbir, et al. Expires September 2003 [Page 12]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
+-----------+ +--------------+
| Rule | | Proxylet |
| Owner | | Vendor |
+-----------+ +--------------+
A | | A
| | | |
| V V |
+--------------------+
| OPES |
| Admin Server |
+--------------------+
UPIF A |
+-----------+ | |
| +-------+ | | V
| | | | +------------------+
| | | V | OPES |
| | +-----------+ | Engine | CPIF +------------+
| | | User |----->|--- --------------|----->| Content |
| | | Agent |<-----| |<-----| Server |
| | +-----------+ | | +------------+
| | | Intermediary |
| | +-----------+ | |
| | | Call-out | | |
| | | Server | | |
| | | | +------------------+
| | +-----------+ A | A |
| | A | | | | |
| | | +------------+ | | |
| | +---------------------+ | V
| | +-------------------------------+
| | | SP Call-out Server |
| | | |
| | | +------------------+ |
| | | | SP Rule | |
| | | | Owner/Generator | |
| | | +------------------+ |
| | +-------------------------------+
| | A |
| +--------------------------+ |
+-------------------------------+
Figure 1 - OPES SP System Architecture Components
NOTE: The components in Figure 1 may belong to different
administrative domains.
Some modifications to the original OPES architecture must be made to
enable support of a SP call-out server. The next sub-sections
summarize the requirements on the OPES framework.
Barbir, et al. Expires September 2003 [Page 13]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
4.1 Requirements for an OPES SP Call-out Server
This section discusses the added features that must be supported by
the OPES framework to support a SP call-out server.
An OPES SP call-out server performs the task of generating dynamic
rules that are either encoded in, or extracted from a subscriber and
content profile. The server must be capable of retrieving a
subscriber profile from centralized or distributed locations across
the Internet. The server must be capable of loading the rules onto
an OPES engine in a dynamic fashion. The server may be capable of
downloading of proxylets and rules from other parties at a higher
trust level. The server must perform authorization and
authentication for services, and other administrative tasks specific
to personalized services on OPES intermediaries.
4.1.1 Ability to identify a client/subscriber
In order for the OPES framework to support personalization, it is
required that an OPES engine be able to identify the beginning of a
traffic stream that is SP-enabled. It is assumed that the
personalization of data streams is performed on a per session basis.
Thus, at the beginning of a session, the OPES engine must recognize
that the traffic is SP-enabled. The rules within the OPES engine
must be able to relate the traffic to a certain subscriber and
assign a special tag that uniquely associates the traffic with the
subscriber. The SP call-out server uses this tag to locate and
retrieve the subscriber profile.
Editor Note: What about Session-less?
The draft by Penno et al. [UID] proposes various schemes for
identifying a subscriber on the Internet. This draft can be used as
a starting point in developing a uniform scheme that can be used by
OPES engines to identify the beginning of a personalized session for
a given subscriber.
The draft entitled "User Profile Information Protocol" [UPIF]
addresses this issue from an implementation perspective. Much of the
work contained in the draft is applicable to the SP effort.
4.1.1.1 Subscriber Sessions
The OPES engine must be able to identify the beginning and end of a
personalized subscriber session. At the session startup and
termination, the OPES engine must inform the SP call-out server
about the subscriber identity. At the termination of the session and
at the command of the SP call-out server, the OPES engines must
delete any dynamic rules related to the subscriber.
4.1.2 Protocol to communicate Subscriber Profile
Barbir, et al. Expires September 2003 [Page 14]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
In order for a SP call-out server to be able to provide
personalization services, a protocol is needed that can retrieve the
subscriber profile in a reliable and secure fashion.
The protocol must meet the following requirements:
1) The protocol must provide several security services - including
user authentication for read/write purposes, integrity of
request/response messages, user non-repudiation for write
purposes, and data confidentiality of request/response messages.
2) The protocol must be reliable.
3) The protocol must be able to retrieve a subscriber profile that
is stored in a distributed fashion across the Internet.
4) The protocol may be able to support accounting services.
In this regard, the draft by Penno et al. [UPIP] proposes a User
Profile Information Protocol (UPIP) that could be used by the OPES
SP call-out server to retrieve the subscriber's profile. The UPIF
protocol could be defined as an extension of RADIUS [RFC-2866] or
Diameter [DIAMETER] in order to provide the needed security,
authorization and accounting capabilities. The work that Penno et
al. have done on the "User Profile Information Protocol" (UPIP) in
[UPIF] represents one possible implementation of these ideas, which
may be applicable to an OPES based personalization call-out server
(SPCS).
4.1.3 Protocol to communicate Content Profile
In order to perform personalization services some content may need
to be adapted to better suit a given subscriber preferences.
However, certain content can exist in various variants. The quality
of the adaptation of the content is highly dependent on the original
format of the content. Additionally, not all content may be adapted
or modified. This is due to the digital rights that are associated
or imposed on the content by the original providers and authors.
NOTE: These remarks are applicable to the underlying OPES framework,
and perhaps are best addressed there, since Digital Rights
Management (DRM) will form an essential part of any architecture
that proposes to perform any modifications or adaptation on original
content.
Editor Note 1: Should DRM issues specific to personalization be
mentioned? For instance, a user A who has viewed some content on one
device type (say, a PC) could have the rights to view it on a
different device type (say, a mobile phone). But, a user B may not
have such privileges. When users are classified into categories,
this can be included in the content profile. I.e., the content
Barbir, et al. Expires September 2003 [Page 15]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
profile could state that if the user is a gold user, some things can
be done. But if the user is a silver user, a more restricted set of
personalization can be done.
Editor Note 2: Need to describe in more detail what Content Profile
(Content Metadata) is; what the various representations of Content
Profile are in use today (little?), which proprietary or standard
forms exist etc.)
In order to perform high quality personalization of the content, the
adaptation process must be able to match the subscriber requirements
or preferences with the availability of various content variants,
and the policies regarding their use. Only then the needed set of
transformations on the content could be fully identified. Therefore,
an OPES engine must support a Content Profile Information Protocol
(CPIF) that is capable of retrieving content profile that
encapsulates this information. Requirements for this protocol are
similar to those for the UPIF protocol.
The support of CPIF by content providers requires changes be made to
the way content is stored on servers. It is most probable that the
rate of adoption of any new content storage scheme by content
providers will be slow. For this reason, the SP framework will
proceed with the assumption that the CPIF protocol for the immediate
future will be non-existent, and that only a limited subset of the
information that could potentially be encoded in a content profile
will be available. It is likely that a large part of this content
information will have to be inferred during the content retrieval
process. On the other hand, it is possible for content providers to
publish content profiles and store them in a unique location on the
Internet. The profiles can then be accessed by the OPES based
personalization call-out server. OPES based authorization schemes
can be used to restrict access to legitimate entities to the content
profiles.
4.1.4 Storage Requirements for Subscriber/Content Profile
The subscriber/content profile may be stored partially or completely
in the terminal or the network. The entity that is responsible for
the storage may be a third-party entity _ especially when the
profile is stored in the network. Some desirable features of such
storage include:
- The entity that owns the storage does not have access to the
subscriber/content profile. This implies that the entity does not
have to be trusted.
- The entity that owns the storage does not have to store the
password (or any shared secret) associated with the
subscriber/content owner. This requirement is automatically
implied when the first requirement is needed. However, this
Barbir, et al. Expires September 2003 [Page 16]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
requirement is desirable even when the first requirement is not
needed, i.e., in the presence of a trusted third party.
4.2 OPES SP Physical Boundary
The OPES admin server, OPES engines and SP call-out servers
represent separate logical components in the SP architecture. The
OPES admin server is off the content path. The involvement of the SP
call-out server in the data flow is limited to the beginning of a
personalized session, with the occasional involvement when the
subscriber preferences are modified within an active session. The SP
call-out server is also involved in the termination of the session,
whereby the subscriber related rules are deleted from the OPES
engine.
There are no assumptions made regarding the physical boundary
between the SP call-out server and other OPES functional components.
In particular, the following physical configurations are possible:
- Appliance Model: The OPES admin server, OPES device and SP call-
out server are built into a single appliance.
- Toolbox Model: The OPES admin server, OPES devices including SP
call-out server are physically separate boxes. In this case, a
few admin servers can administer a large number of OPES devices
and SP engines.
4.3 OPES SP Sequence of Operations
This section describes the sequence of operations that are performed
by the OPES SP framework as described in Figure 1 in order to
support personalization. The process is described in the steps
below:
Editor Note: The current OPES model is not necessarily built on any
"lengthier" notion of a session _ each session is merely an HTTP
request/response sequence; every request from the user agent and
every response from the content source to be delivered to the user
agent are "tracked" and there are associated processing points (4
explicitly defined ones in the current OPES model) where potential
for rule match/actions exist.
1) At the beginning of a session, the user agent must identify
itself as being SP-enabled to the OPES engine. In effect, there
must be some characteristic of a subscriber request which can be
identified by a standard OPES rule as requiring personalization
services (this may be accomplished by some request header
information rule match and associated action).
2) Once a SP-enabled request is identified, the OPES engine must
assign a unique identifier to the subscriber which will be used
Barbir, et al. Expires September 2003 [Page 17]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
to "tag" all subsequent traffic from that subscriber. This may
involve transfer of identifier information back to the user agent
for incorporation into subsequent communications, similar to
existing key-exchange mechanisms.
3) The incoming subscriber request is then routed (using an OPES
rule or rule module) to the SP call-out server for processing.
4) The SP call-out server recognizes the subscriber based on the
identifier that is provided by the OPES engine. The SP call-out
server will establish direct communications using UPIF or a
similar protocol with the user agent to get the appropriate
information on the location of the subscriber profile.
Appropriate authentication schemes between the SP call-out server
and the user agent may be needed. In the event that the
subscriber profile is distributed across various locations on the
Internet, the SP call-out server must be able to authenticate
itself and any entity that is involved in the process.
5) The SP call-out server parses the subscriber's profile to either
extract or derive the appropriate personalization rule module.
6) The SP call-out server then sends the personalization rule module
that is associated with this subscriber to the OPES engine. The
OPES engine dynamically loads and invokes the rules on subsequent
traffic from the subscriber. (To make this happen, subsequent
traffic needs to contain the "SP-enabled" magic word, since there
is no notion of state maintained in the OPES Engine on each user
agent beyond any active request/response pair.)
7) At the end of the session, the OPES engine informs the SP call-
out server about the termination of the session. The SP call-out
server invokes any accounting processing that is needed on the
subscriber profile and then sends a command to the OPES engine to
fully delete any rules that are associated with the subscriber.
Editor Note: How do we exactly know when a session ends? Again,
given the current HTTP request/response model, each
request/response sequence is a session; or, do we unload/delete
the dynamic rules the first request from a user agent that does
NOT contain the "SP_enabled" magic word in the header?
8) NOTE: We haven't mentioned anything about how we know what other
services are available, how we write the rules to route traffic
to them as appropriate, or what happens if the subscriber profile
changes in mid-session. Also, we need to address the security of
the communication between the OPES intermediary and the
Personalization call-out server.
4.4 Content Services
Barbir, et al. Expires September 2003 [Page 18]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
4.4.1 Service Characterization
This is an OPES problem, but we need to know how to characterize
services in general. Perhaps it's enough to merely state that we
need some form of service characterization? Perhaps use the OPES
definition for service characterization wholesale?
4.4.2 Service Availability
How do we know which content services are available for use from a
specific SP platform? Perhaps some of these questions are best
stated here, and discussed in detail within the context of OPES.
4.4.3 In-Path Services
Need to figure out how to route traffic to In-Path services.
4.4.4 Out-of-Path Services
How to route traffic to slower services, and how does this differ
from in path services?
4.4.5 Service Selection
Given one or more content services that perform a specific function,
what are the criteria used to select a specific service? Is this
decision-making process in any way configurable by the subscriber?
Or is it configurable by the content provider? What metrics are used
to make a selection between multiple providers of the same content
service?
4.4.6 Service Reliability/Service Failure
What happens when a service fails? How do we know? What are the
expected actions to be taken by a SP service in light of service
failure? What sorts of reliability guarantees are in place, and how
are they enforced?
4.5 Privacy and Security
Privacy issues are an important component of personalization. In
this regard, the issues of privacy that are related to shopping
habits, the willingness to accept or refuse certain type of
advertisement, and subscriber profiling are already addressed by the
Platform for Privacy Preferences [W3C-P3P] at W3C. It is important
to note that while P3P provides a technical mechanism to ensure that
the subscriber is informed of the privacy policy of a content
source, it does not specify any mechanism for policy enforcement.
This is an area in which SP may play a role in strengthening the
enforcement of privacy policies.
Editor NOTE 1: What I'm thinking here is that through request
anonymization, we may be able to prevent the content source from
Barbir, et al. Expires September 2003 [Page 19]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
gathering metrics that are undesirable to the subscriber. We have to
be careful here, however, because this will not make some content
providers happy. Additionally, anonymization is really more of a
content service than it is core personalization. Maybe what we have
is a selective anonymization based on privacy policy enforcement
during personalization. We may wish to investigate the technical
feasibility of this idea.
Editor Note 2: OPES framework must address the privacy issue from
the point of view of the content provider and the intermediaries.
Basically, the intermediaries must be able to inform to the User
Agent about their policies. This is because the privacy policies of
the intermediaries may be different from the privacy policy of the
content provider. In this case the intermediary must negotiate the
superset.
In performing personalization, there should be a mechanism that
ensures that the transition of a subscriber profile across the
Internet is done in a secure and reliable manner. There should be a
mechanism that authorizes any entity that is interested in accessing
a subscriber profile. The subscriber must be able be informed about
the request to access the profile and must be able to accept or
reject the request.
In general, security considerations for personalization must address
the following issues:
1) Subscriber Profile Integrity: SP must ensure that a subscriber
profile is unadulterated in whole or in part when it reaches a
decision point.
2) Content Profile Integrity: SP must ensure that a content profile
is unadulterated in whole or in part when it reaches a decision
point.
3) Trust Relationships: There must be a proper mechanism that
decides the entity that is authorized to configure, update,
change, and delete a subscriber profile. There must be a proper
mechanism that authorizes any entity that will perform
personalization across the content adaptation chain. This
includes trusted third parties and repositories.
4) Non-repudiation of request: Non-repudiation of any subscriber
profile configuration/update/change/deletion may be required.
5) Data Confidentiality: Preventing eavesdroppers from gaining
access to a subscriber profile is important. Note that this
requirement is different from subscriber privacy.
5. Example of a SP Call-out Server
Barbir, et al. Expires September 2003 [Page 20]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
Here it would be useful to put a real example video on-demand or
anti-virus.
5.1 Personalization Requirements from OPES Framework
OPES architecture must meet the following requirements in order to
support the personalization services as specified by the SP
framework.
1) The OPES admin server must be able to communicate with the SP
call-out server to dynamically load the appropriate rules that
are needed to perform the personalization services.
2) The OPES engine must be able to identify a subscriber.
3) The OPES engine must be able to associate a given rule module
with a unique subscriber.
4) The OPES engine must be able to accept dynamic rules that are
generated by the SP call-out server.
5) The OPES engine must be able to inform the SP call-out server
about changes in the subscriber profile within an active session.
6) The OPES engine must be able to identify the end of a subscriber
session and must be capable of communicating this information to
the SP call-out server.
7) The OPES SP call-out server must be able to instruct the OPES
engine to delete all the rules that are associated with a unique
subscriber.
5.1.1 User Profile Integrity and Security
The SP call-out server is the only owner of the dynamic rules that
are associated with a given subscriber. For this reason, the OPES
admin server must have very limited and secure capabilities for
accessing any information that is related to a particular
subscriber. The rules that are associated with any subscriber on an
OPES engine must be protected and secure from any illegal access by
any entity on the Internet.
6. Security Considerations
All security considerations applicable to the general OPES framework
are applicable here as well.
In the case of SP, the additional component that is introduced is
the subscriber profile. Consequently, certain security
considerations apply in this regard:
Barbir, et al. Expires September 2003 [Page 21]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
1) Subscriber profile configuration/modification/deletion needs
authorization
2) Subscriber profile access needs authorization
3) Non-repudiation needs to be provided for subscriber profile
configuration/modification/deletion
6.1 Security Considerations for SP Scenario
In this section, we consider the OPES SP sequence of operations
described in Section 4.3, and discuss the security considerations
therein. The steps below correspond to the steps in Section 4.3.
1. When the subscriber indicates the need for personalization, this
request may need to be authenticated. Lack of authentication
could result in the successful launching of a denial-of-service
(DOS) attack. For instance, a malicious entity could send several
spurious requests indicating the need for personalization, and
this could consume resources at the OPES engine as well as the SP
call-out server. Rapid authentication schemes are needed in this
case. Such authentication schemes also need to be combined with
integrity - in other words, Message Authentication Codes (MAC)
are preferred. Providing integrity takes care of the case where a
malicious entity tampers with a genuine request in transit.
2. When the unique tag assigned to the subscriber is conveyed to the
subscriber, such notification needs to be authenticated and
integrity protected. Else, a malicious entity could either
generate a spurious response, or could tamper with a genuine
response, e.g. to change the tag to that of a different
subscriber.
3. Authentication and integrity needs to be provided when the
subscriber request is routed from the OPES engine to the SP call
out server.
4. Protocol to communicate between the SP Call-out server and the
subscriber's user agent needs to be secure.
5. Confidentiality may be needed when the rule module is sent back
to the SP Call-Out server.
6. Similarly, confidentiality may be needed here as well.
7. Authentication and integrity are needed here.
7. Acknowledgments
The majority of the definitions contained in this document have been
obtained from the document entitled: "A Model for Open Pluggable
Edge Services", by G. Tomlinson, et al. [O-MODEL]. This contribution
is gratefully acknowledged.
Barbir, et al. Expires September 2003 [Page 22]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
The authors wish to acknowledge the comments and suggestions
contributed by the members of the FSP mailing list. These people
include: Nalin Mistry, Raffi Uddin, Wil Walkoe, Ram Dantu.(Please,
any others that I've missed, add yourselves in...)
8. References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[OPES-FSP] Barbir et al., "A Framework for Service Personalization",
draft-barbir-opes-fsp-03.txt, work in progress, March 2003.
[RFC-2616] Fielding, R., et al., "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[RFC-3040] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001.
[ESFNEP] A. Beck et al, "Example Services for Network Edge
Proxies", draft-beck-opes-esfnep-01.txt (work in progress), June
2001.
[POLICY] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Perry, J., Herzog, S., Huynh, A., Carlson, M. and
S. Waldbusser, "Policy Terminology", RFC 3198, November 2001.
[C-MODEL] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model
for Content Internetworking", draft-ietf-cdi-model-02.txt (work
in progress), May 2002.
[UID] Penno, R., "Identification of Users on the Internet", draft-
penno-uid-00.txt, work in progress, January 2001.
[UPIF] Penno, R., and H. T. Pham, "User Profile Information
Protocol", draft-penno-cdnp-nacct-userid-05.txt. Work in
progress, July 2001.
[UPIP] Penno, R and G. Boissonnard, "Framework User Profile
Information Protocol", draft-framework-upif-00.txt. Work in
progress, June 2001.
[RFC-2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[DIAMETER] Calhoun, P., Rubens, A., Akhtar, H., and Guttman, E.,
"The DIAMETER Base Protocol," draft-calhoun-diameter-17.txt, work
in progress.
[W3C-P3P] Platform for Privacy Preferences (P3P1.0) Specification,
http://www.w3.org/TR/2000/CR-P3P-20001215.
9. Authors' Addresses
Abbie Barbir, Ph.D.
Nortel Networks
3500 Carling Avenue
Nepean Ontario K2H 8E9 Canada
Email: Abbieb@nortelnetworks.com
Nicholas Bennett
Nortel Networks
Barbir, et al. Expires September 2003 [Page 23]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
3500 Carling Avenue
Nepean Ontario K2H 8E9 Canada
Email: nbennett@nortelnetworks.com
Reinaldo Penno
Nortel Networks, Inc.
600 Technology Park Drive
Billerica MA 01821
Email: rpenno@nortelnetworks.com
Rama R. Menon
Intel Corporation
2111 NE 25th Avenue, M/S JF3-206
Hillsboro, OR 97124
Email: rama.r.menon@intel.com
Hien-Thong Pham
Alcatel Bell
Francis Wellesplein 1
B-2018 Antwerp
BELGIUM
Phone: 3-2408630
Email: hien-thong.pham@alcatel.be
Senthil Sengodan, Ph.D.
Nokia Research Center
5 Wayside Road
Burlington, MA 01803
Tel: 781-993-3789
Fax: 781-993-1907
Email: senthil.sengodan@nokia.com
Jayanth P. Mysore
Network and Infrastructure Research Laboratory
Motorola Labs
1301 E. Algonquin Road
Schaumburg, IL 60196
Email: jayanth@labs.mot.com
Editor: (Please send comments to Editor)
Paul Knight
Nortel Networks
600 Technology Park Drive
Billerica, MA USA
Email: paknight-at-nortelnetworks.com
Barbir, et al. Expires September 2003 [Page 24]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server
10. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Barbir, et al. Expires September 2003 [Page 25]