Internet-Draft H.T. Pham
D. Chantrain
C. Batsleer
File:draft-pham-triggers-and-handles-01.txt Alcatel
Expires: May 2002 November 2001
Triggers and Handles Framework
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 is draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete 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 (2001). All Rights Reserved.
Abstract
This document describes a communication mechanism named "triggers
and handles" between service logic and network elements. The concept
defines a trigger as a notification that a network element sends to
the service logic. A handle is defined as a command that the service
logic sends to a network element. Triggers are bound to network
events and allow network elements to notify service logic of
occurring events in the network whereas handles allow taking control
of network elements. Around these triggers and handles, a framework
architecture is settled that aims at reusing as much as possible
existing protocols supported by network elements. The goal of this
framework is to enable service providers to deploy services in an
independent network vendor manner on top of network elements and to
improve network awareness of services. The targeted network
environment is the broadband access network and its services.
H.T. Pham [Page 1]
Triggers and Handles Framework November 2001
Table of contents
Status of this memo...................................................1
Copyright Notice......................................................1
Abstract..............................................................1
Table of contents.....................................................2
1. Introduction.......................................................3
2. Definitions........................................................4
3. Concepts...........................................................5
3.1. Network configuration............................................5
3.2. Triggers and handles concept.....................................6
3.3. Examples of triggers.............................................8
3.4. Examples of handles..............................................8
4. Requirements.......................................................9
4.1 Framework requirements............................................9
4.2. Transport protocol requirements..................................9
4.3. Semantics requirements..........................................10
4.4. Description syntax requirements.................................10
4.4.1 Examples of triggers and handles syntax........................11
5. Triggers and handles discovery....................................12
6. Security..........................................................12
7. Adaptation to existing network elements...........................13
7.1. Network Interface Adaptation module.............................13
7.2. Protocol interceptor............................................14
7.3. Internal structure of the Network Interface Adaptation module...14
8. Scenarios.........................................................15
8.1. Scenarios for triggers..........................................15
8.1.1. General scenario..............................................15
8.1.2. Scenario for triggers using policies..........................17
8.2. Scenarios for handles...........................................19
9. Architecture......................................................21
10. Example of applications making use of triggers and handles.......23
11. From concept to implementation...................................26
11.1 Networking related view.........................................29
11.1.1 General.......................................................29
11.1.2 Architecture..................................................31
11.1.3 Scenario......................................................33
11.1.4 XML-based interface...........................................34
11.2 OPES............................................................34
11.3 Midcom..........................................................34
11.4 Home networks...................................................35
12. Security considerations..........................................35
13. Summary..........................................................35
14. Authors' information.............................................36
15. References.......................................................37
H.T. Pham Expires May 2002 [Page 2]
Triggers and Handles Framework November 2001
1. Introduction
This document describes a communication framework between service
logic and network elements.
Today IP networks are evolving to more types of network elements,
more and more functionalities, protocols, applications, services,
... An uniform method for exchanging information with network
elements and controlling network elements from a service logic does
not exist because each service or application is forced to adapt
itself to different protocols, network services that are implemented
by different, vendor-dependent network elements. The distributed
nature of service platforms adds another degree of difficulty in the
sense that an interface between just 2 functional blocks is not
sufficient any more. Furthermore, valuable information existing in a
network element cannot be communicated to the service layer because
an appropriate existing protocol does not exist. For these reasons,
a uniform communication scheme is needed between services and
network elements.
This Internet-Draft contains a proposal of such a uniform
communication framework between the service logic and the network
layer called "triggers and handles". When implemented, the goal of
this concept is to allow application platforms to exploit more
efficiently resources in the underlying network in the services they
provide to end-users, i.e. this framework aims at improving network
awareness of applications. The concept is independent of network
element vendors, i.e. it will allow service providers to deploy
services in a network vendor independent manner on top of any
network. In order to enable deployment of this new concept, the
framework architecture, the semantics of messages flowing between
the service layer and network layer, the transport protocol for
these messages and possibly a language that allows to define
formally triggers and handles will need to be specified. Moreover,
considering that inventing new protocols is not desirable, the
proposed framework will try to reuse as much as possible existing
protocols. This draft will sketch all these points.
The document will be organised as follows:
- Section 2 defines the terms used in this document.
- Section 3 explains the triggers and handles concept.
- Section 4 describes requirements to be satisfied by the framework.
- Sections 5, 6 and 7 introduce functional components of the
framework.
- Section 8 discusses usage scenarios. This introduces the idea of
triggers subscription and handles registration.
H.T. Pham Expires May 2002 [Page 3]
Triggers and Handles Framework November 2001
- Section 9 proposes a triggers and handles conceptual architecture.
- Section 10 gives a detailed scenario on how triggers and handles
can be used by Internet services.
- Section 11 discusses implementation of the concept and makes the
liaison with the various on going working groups in IETF.
2. Definitions
The following definitions are applicable in this document.
- Network element: any network device able to deliver network
connectivity services. These services are considered as low-level
and are not directly seen by end-users as opposed to high-level
services. But network devices that include some very limited
application-level services (e.g. protocol proxies) are also
considered as network elements. This definition includes as well
network elements that provides non-IP connectivity from the moment
they possess an external control interface using an IP-based
protocol.
- Network layer: abstract layer in which all network elements are
located.
- Service:any value proposition offered to the user of the network.
This value proposition typically involves both application level
logic as well as network connectivity functions. In this document
the focus is on the application level part of the service, a
service is implemented by an application. The term service is
thus used as a synonym for the term application.
- Service logic: the logic that realises the service. This is
typically a software program with some control interfaces to the
network.
- Service layer: abstract layer where the service logic resides.
- Service platform: materialisation of the service layer.
- Handle: a command sent by the service logic to a network element.
This command typically requests the network element to execute
some actions (like configuration of QoS, setup of connections,
updating a router table, etc) that the network element is capable
of among all its networking capabilities.
- Trigger: a notification containing pieces of data sent by a
network element to the service logic upon occurrence of a specific
network event. Triggers are thus a way for network elements to
provide information that can be used by service logic. Examples of
triggers are presence triggers (indicating a user is online and
H.T. Pham Expires May 2002 [Page 4]
Triggers and Handles Framework November 2001
containing this user's addressing information and profile),
accounting triggers (containing network information used as basis
for billing), etc.
- Triggers and handles framework: an architecture making use of
triggers and handles as communication mechanisms between service
platforms and network elements. It allows to enforce the concept
of network-aware service platforms.
3. Concepts
3.1. Network configuration
Like it has been defined in section 2, the scope of the triggers and
handles framework is as shown on Fig 1.
|--------------------|
| SERVICE LOGIC |
|--------------------|
| ^
| |
Handle | | Trigger
| |
v |
|--------------------|
| IP NETWORK |
|--------------------|
Fig 1. Triggers and handles
Although the concept that is about to be explained is applicable to
all kinds of access networks and end-users, its primary target will
be the broadband access network. In the broadband access world, a
typical configuration with a typical Internet user would be like
shown in Fig 2 where DSLAM (Digital Subscriber Line Access Module)
is the access concentrator module, Netw1 and Netw2 are two ISP
networks served by the broadband access server BRAS.
Fig 2 provides as well some examples of network elements, i.e. User
terminal, broadband DSL modem, DSLAM and BRAS. All these elements
have triggers and handles capabilities. Triggers and handles of
network elements belonging to Netw1 and Netw2 may exist but not yet
identified at this point.
H.T. Pham Expires May 2002 [Page 5]
Triggers and Handles Framework November 2001
|------------------------------------------------------------------|
| SERVICE LOGIC (DISTRIBUTED SERVICE PLATFORM) |
|------------------------------------------------------------------|
| ^ | ^ | ^ | ^
| | | | | | | |
| | | | | | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
triggers and handles | | | | |
| | | | | | | | |---------|
| | | | | | | | | |
v | v | v | v | /| NETW 1 |
|----------| |---------| |---------| |-------| / | |
| | | | | | | |/ |---------|
| USER |---| DSL |-----| DSLAM |---| BRAS |
| TERMINAL | | MODEM | _| | | |\
| | | | |---------| |-------| \ |---------|
|----------| |---------| \| |
| NETW 2 |
| |
|---------|
Fig 2. A typical network configuration
3.2. Triggers and handles concept
Triggers and handles are closely linked to network elements.
Triggers and handles abstract pieces of information exchanged
between service logic and network elements.
A trigger is a notification containing pieces of data sent by a
network element to the service logic upon occurrence of a specific
network event. Triggers are thus a way for network elements to
provide information that can be used by service logic. Examples of
triggers are presence triggers (indicating that a user is online and
containing this user's addressing information), accounting triggers
(containing network information that is used as basis for billing),
etc. A trigger is always bound to a network event.
A handle is a command sent by the service logic to a network
element. This command typically requests the network element to
execute some actions (like configurations of QoS, setup of
connections, update a router table, etc. [NAT] provides examples of
handles to control a NAT device) that the network element is capable
of among all its networking capabilities. Handles can as well
contain useful information. Handles are thus a way to drive network
resources for the benefit of a service platform.
H.T. Pham Expires May 2002 [Page 6]
Triggers and Handles Framework November 2001
An application belonging to the service logic can be completely
based on triggers and handles. For example, this application could
wait indefinitely for triggers from a list of well-known triggers.
It sends out a specific handle when it receives a specific trigger.
If the handle executes successfully, new triggers may be available
to the application and so on.
Triggers and handles can be provided by elements in existing network
protocols (SIP [SIP], SNMP [SNMP], RADIUS [RADIUS], ...) from the
moment they fit in the definitions given above. But they can also be
provided independently of existing network protocols (especially
when new triggers or handles are required but not already supported
in existing protocols) and have a customised construct starting from
information contained in or features of existing network protocols.
A service platform is different from a network management platform
although both are concerned with the communication with and control
of network elements. A network management platform is interested in
topology and configuration details, down to network layer and below,
sometimes up to application layer. A network management is network
centric. A service platform is user centric but wants to be network
aware. User centric because it aims to serve end users of the
Internet, i.e. it contains applications to deliver end-user
services. Network awareness to improve the available services but
network awareness is not set at the same details level as in the
case of a network management system. Furthermore, a service logic is
required to control network elements in a more dynamic way than the
rather static working of a network management system. This is
because the service platform must be able to react to user requests,
for example request to change on line QoS for a certain service. For
these reasons, a service platform is not a network management
system. The requirements for the design of the communication between
such a platform and the underlying network are thus different.
All the paragraphs above have explained conceptually triggers and
handles. The concept can then be materialised as a standard, vendor
independent interface between service platforms and network
elements. This interface should provide as well the semantics of
triggers and handles plus the syntax for a language whose purpose is
formal description of triggers and handles. The main requirement for
this language is that it should allow easy definition of new
triggers and handles. The main requirement for the triggers and
handles semantics is that it can easily be interpreted by
applications or network elements in order for them to identify
unambiguously a trigger or handle. The newly defined interface is
transported over either an existing (e.g. SIP [SIP] for triggers and
SOAP [SOAP] for handles) or a new communication protocol.
H.T. Pham Expires May 2002 [Page 7]
Triggers and Handles Framework November 2001
The advantages of a triggers and handles interface are:
- clear communication interface to control and manage various types
of messages between network elements and applications.
- triggers and handles make network events and commands available to
applications, while hiding the vendor-specific details of the
network element interface. Triggers and handles syntax allows to
describe triggers and handles in a vendor independent way. Hence
the application does not have to be aware of the vendor-specific
implementation aspects of the network element.
- triggers and handles contain information independent of networking
details. For example, an application is interested to receive a
trigger from the network when a certain end-user comes online. In
the network layer, this presence information can be implemented as
a SIP notification, as a successful PPP connection setup event, as
a RADIUS accounting message, etc. All these details are hidden to
the application that is only interested in the fact a user is
present and not in how this is detected in the network layer.
- triggers and handles improve network awareness of service
platforms.
3.3. Examples of triggers
BRAS sends a presence trigger when a user PPP session is
successfully established. This trigger contains for instance the
user IP address, username and password and other user profile
information, plus a user connection reference that allows the
service platform to identify this connection in BRAS.
Broadband DSL modem sends a presence trigger after it successfully
establishes a PPP session for a user in a home network. Same
parameters as in the above example can be provided in the trigger.
A user is allowed to open and stay in a VPN session for only a
limited period of time. When the session time expires, BRAS sends a
trigger so that appropriate actions can be taken by the application.
3.4. Examples of handles
Handle is sent to BRAS to request it to switch a user to a different
network. This handle contains for example an identity of the new
network and necessary login parameters.
Handle is sent to BRAS to support simultaneous connectivity to 2
different ISP networks for a certain user. This will result in
reconfiguration of the BRAS routing table.
H.T. Pham Expires May 2002 [Page 8]
Triggers and Handles Framework November 2001
Handles to an advanced DSL modem to setup bridges, PPP connections,
NAT/PAT entries, VP/VC, etc upon a user request.
Handle to DSLAM to setup dynamically VP/VC (SVCÆs) via a management
interface (e.g. SNMP). This is an example of reuse of an existing
interface.
Handle to the user terminal to start PPP connections upon user
request.
4. Requirements
As explained above, communication mechanism by triggers and handles
should address issues related to the framework itself, the transport
protocol, the semantics of messages and the formal description
syntax. This section tries to capture requirements for each of these
aspects.
4.1 Framework requirements
1) The framework must allow the service platform to adapt itself to
different network element capabilities in terms of triggers and
handles.
A mechanism must be provided that allows the service or
application platform to discover triggers and handles that are
available in the network.
2) The framework must isolate applications in a service platform
from how a certain network functionality is implemented in the
network.
Applications must not be concerned with network elements details.
This is handled in the framework.
3) The framework must provide support for on the field network
elements, i.e. it must be possible to deploy the framework over
already installed network elements.
4) to be continued.
4.2. Transport protocol requirements
1) In the research of a transport protocol for triggers and handles
messages between service platforms and network elements, various
existing protocols must be investigated. If none of them
satisfies the framework requirements, either existing protocols
need to be extended or a new protocol is to be designed.
H.T. Pham Expires May 2002 [Page 9]
Triggers and Handles Framework November 2001
2) Triggers and handles are supposed to carry small amounts of
information, the transport protocol should not introduce too many
overheads. It should be lightweight and simple.
3) It is not expected that a service platform imposes real-time
constraints on the transport protocol but it should comply to the
time constraints requirements if any is defined in the service
platform regarding its customers (e.g. if a service requires that
a connection setup time does not last more than x milliseconds
then the transport protocol for the handle should not introduce
too many overheads to respect this).
4) Triggers and handles information should be transported with a
reliable transport protocol. This requirement is necessary to
guarantee quality of the delivered services.
5) to be continued.
4.3. Semantics requirements
Semantics of triggers and handles describe what information is
carried by these objects.
1) Triggers and handles semantics should not contain network
elements low level information. This is in line with the
framework requirement 2).
2) Triggers and handles semantics should be such that it can easily
be interpreted by applications or network elements in order for
them to identify unambiguously a trigger or a handle.
3) Considering the almost infinite possibility of possible services,
the semantics should allow to extend easily the information that
a trigger or a handle contains.
4) Triggers and handles associated with certain network element
functionalities should be portable from one network element to
another network element if they both implement these same
functionalities. This will allow reusability of triggers and
handles.
5) to be continued.
4.4. Description syntax requirements
Description syntax is about how triggers and handles objects are
described. The only requirement here is that it should be easily
processed to generate corresponding triggers and handles objects for
each service platform.
H.T. Pham Expires May 2002 [Page 10]
Triggers and Handles Framework November 2001
XML, the Extensible Markup Language [XML] is a simple and flexible
language for data description. XML tools are widely available
nowadays. XML is thus a good candidate to be considered.
In the case, triggers and handles are viewed as manageable objects,
languages used in SNMP [SNMP] and COPS-PR [COPS-PR] managed
networks should be considered.
4.4.1 Examples of triggers and handles syntax
The syntax description uses XML notation but it does not mean that
XML has to be used to encode the trigger nor that network elements
have XML processing capability.
Trigger:
vendor name
network element name
event domain
event name
trigger name
list of trigger parameters
The most important part is of course the trigger body. Vendor,
network element, triggering network event are informational.
Handle:
vendor name
network element name
handle name
list of command parameters
H.T. Pham Expires May 2002 [Page 11]
Triggers and Handles Framework November 2001
5. Triggers and handles discovery
The triggers and handles a certain network element can support are
identified by investigating its network interfaces and its supported
network protocols (e.g. Command line interface, SOAP [SOAP], SNMP
[SNMP],...). Objects that can be passed between service logic and
network elements are perfect candidates to become parameters of
triggers and handles.
A protocol can be designed to allow applications to discover
automatically capabilities of a network element in terms of
supported triggers and handles (e.g. list of messages). A simple and
obvious choice is for example the SNMP protocol in which case the
network element MIB needs to be extended to contain managed objects
describing these new resources. In the application platform, there
will be a Network Interface Discovery Module whose function is to
get the list of triggers and handles available in a network element
and to store this information in a database that applications
interested in triggers and handles can consult.
An interesting alternative is to let the network element to register
with the service logic about its capabilities in terms of triggers
and handles. This is more useful in the situation where the network
element's configuration is changed by an external system than the
application platform itself (e.g. a network management system may
modify configuration via SNMP, COPS [COPS], command line
interface,...).
Thus, triggers and handles discovery is to be realised in 2 modes.
The service platform may either request triggers and handles list
(solicited mode) or the network element itself takes the initiative
to notify the service platform in case of changes in its
configuration (unsolicited mode).
6. Security
As triggers and handles interface is meant to be a completely open
interface between network elements and service platforms, it is
expected that any service or application provider can deploy
services and applications on any network owned by any network
provider. It should therefore be taken into consideration the model
where the network element belongs to an Network Access Provider
whereas the application platform belongs to a Service Provider or an
Application Provider, the Network Access Provider may want to
restrict third party actions on its network (handles) or third party
benefits from its network (triggers). Openess is an obvious
advantage of triggers and handles but introduces an issue that must
be tackled in the framework design. An optional Network Interface
Security (NIS) module will be introduced between the service
platform and network elements. This module can be configured by the
service provider to either grant or not grant access to triggers and
H.T. Pham Expires May 2002 [Page 12]
Triggers and Handles Framework November 2001
handles depending on the service agreement it has with the provider
of the underlying network. The configuration consists in adding a
list of triggers and handles each service entity is allowed to
send/receive to/from a network element. The Network Interface
Security will authenticate the service platform to the network and
will perform autorisation, i.e. check that all triggers and handles
passing between applications and network elements comply with the
contract existing between the service provider and the network
provider. One might wonder why the Network Interface Security
function is not implemented in the network element instead ? But if
it is desired to keep triggers and handles logic simple in the
network element (i.e. interprete and execute handles, bind triggers
to network events and send triggers), it is more interesting to
implement this function in the service layer logic.
7. Adaptation to existing network elements
7.1. Network Interface Adaptation module
In today networks, triggers or handles already exist as protocol
specific APIÆs or messages. This kind of triggers and handles will
probably not change with the introduction of the new types of
triggers and handles. In order to provide the same interface to the
service logic, the approach suggested below will be further
investigated. It provides a solution for the fact that installed
base network elements are difficult to update to support additional
interfaces or SW.
An intermediate protocol module (part of the triggers and handles
framework) called for example Network Interface Adaptation (NIA)
will exist to convert triggers and handles to the proper syntax. A
mapping between ôexisting protocols triggers and handles" and "new
standard triggers and handles" has to be kept track of inside this
module. The Network Interface Adaptation principle is shown on
Fig 3.
H.T. Pham Expires May 2002 [Page 13]
Triggers and Handles Framework November 2001
| ^
| |
| Handle A | Trigger B
| |
v |
|--------------------------------|
| NETWORK INTERFACE ADAPTATION |
|--------------------------------|
| ^
| |
|<-- protocol messages ->|
| |
| |
v |
|------------| |------------|
| Protocol A | | Protocol B |
|------------| |------------|
Fig 3. Network interface adaptation principles
7.2. Protocol interceptor
A protocol interceptor, as its name implies, intercepts protocol
messages originating from protocol stacks. It then forwards either
the whole message or a part of the message (by copying partially the
message) to another processing module. The original message is still
forwarded to the first intended destination. A protocol interceptor
thus copies a part of or duplicates a protocol message. The
processing module is an application that is interested by the
protocol message but is not registered in the protocols stack as the
receiver of this message.
7.3. Internal structure of the Network Interface Adaptation module
A possible Network Interface Adaptation structure can look like it
is shown on Fig 4.
Obviously, a triggers and handles conversion function is necessary.
It is fulfilled by the Triggers and Handles Converter.
For triggers, this Network Interface Adaptation module must
necessarily implement the protocol interceptor function in order to
forward protocol messages to their first intended destinations.
Indeed, these messages do not primarily serve the triggers and
handles purpose, they are simply ôinterceptedö on the way by the
protocol interceptor. The protocol interceptor extracts the
necessary information from protocol messages, passes it on to the
triggers and handles converter. The output of this latter is a
trigger in proper format that can be sent to applications.
To protocol-
H.T. Pham Expires May 2002 [Page 14]
Triggers and Handles Framework November 2001
| ^ specific
| | application
| Handle A | Trigger B ^
| | |
v | |
|-------------------------| |
| | |
| Triggers and Handles | |
| Converter | |
| | |
|-------------------------| |
| ^ |
| | |
| | |
| |-------------| |
| | | |
| | Protocol |-----------
| | Interceptor |
| | |
| |-------------|
| ^
| |
| |
v |
protocol A message protocol B message
Fig 4. A possible structure of Network Interface Adaptation
8. Scenarios
8.1. Scenarios for triggers
8.1.1. General scenario
Triggers that a network element is able to send are mainly
determined by its functionalities and interfaces. The list of
triggers may then be configured and fine-tuned by a network
management system.
An application, part of the service logic, consults the database
that was populated by the Network Interface Discovery module for the
list of triggers supported by this network element.
The application first subscribes to the triggers and triggers
parameters it is interested to receive.
The application also has the possibility to unsubscribe or modify
the list of triggers it has subscribed to.
H.T. Pham Expires May 2002 [Page 15]
Triggers and Handles Framework November 2001
Subscription, Unsubscription, Modify Subscription messages can be
considered as handles between Application and Network Element.
Note that all operations are performed in agreement with the Network
Interface Security that is not shown on the figure.
This subscription / notify mechanism allows efficient communication
between network elements and the service platform, and saves
processing on the network elements. If no subscribe/notify mechanism
is foreseen then the network element should be configured as to
always send all triggers with full information, and it would be up
to the applications platform to filter. With the approach described
here, the network elements only needs to send the relevant triggers
with only the relevant parameters.
|------------------|
| APPLICATION |
|------------------|
| | |
| subscribe to triggers
| | |
| | modify subscription
| | |
| | | unsubscribe to triggers
| | |
v v v
|------------------|
| NETWORK ELEMENT |
|------------------|
Fig 5. Subscription/Unsubscription/Modification of subscription to
triggers
Upon occurrence of a network event, the network element consults its
configuration data to decide which trigger corresponding to this
network event it must send.
The scenario is summarized in the figure below.
H.T. Pham Expires May 2002 [Page 16]
Triggers and Handles Framework November 2001
|--------------------|
| | 3. populate |------------|
| Triggers & Handles |<---------------| Network |
| Database | | Interface |
| | | Discovery |
|--------------------| |------------|
| ^
| 4.get list of |
| triggers |
| |
v |
|------------------| |
| | |
| APPLICATION | |
| | 2.supported |
|------------------| triggers |
|----------| | ^ |
| | | | |
| NETWORK | | | 7.trigger |
| MANAGER | | 5.subscribe | |
| | | | |
|----------| v | |
| | |------------------| |
| | | | |
| |-----------\| NETWORK ELEMENT |--------------------|
|-------------/| |
1. configure |------------------|
supported triggers ^
|
| 6.network event
|
|
Fig 6. Triggers general scenario
8.1.2. Scenario for triggers using policies
The scenario that is described above is the general usage scenario
for triggers. This scenario can be implemented with the policy
framework [POL]. The main idea here is to fulfil the network manager
role with a policy control system.
The policy approach defines two models in a management framework. In
the outsourcing model, it is possible for a network element to
request to a policy server how it should deal with an external
incoming network event like for example DiffServ packets, RSVP
reservation messages, security messages. On reception of a network
event, the network element (Policy Enforcement Point in the policy
terminology [TERM]) sends a request for decision to a policy server
(Policy Decision Point in the policy terminology [TERM]) which will
access a policy rules repository, retrieves the policy rule,
H.T. Pham Expires May 2002 [Page 17]
Triggers and Handles Framework November 2001
evaluates it and sends a decision back to the network element. In
the provisioning model, the PDP provisions the PEP with
configuration data that allows the network element to act
autonomously on network events without having to send a decision
request to the PDP at every occurrence of a network event.
The model proposed for triggers and handles between network elements
and applications is similar to the mechanisms used in the policy
framework combined with the subscribe / notify mechanism explained
in the general scenario.
First, policy rules are created in the policy rules repository.
Policy rules are in the format ôif < condition > then < actions >ö.
Applied to triggers, < condition > becomes < a certain network event
occurs > and < actions > becomes < send a trigger specific to this
event to the application >. Either a network element is provisioned
with policy data or it has to access the server every time it is
triggered by a network event. In this proposal, the provisioning
model must be preferred to the outsourcing model because of heavy
overheads introduced by the latter in the network element
performance.
Policy rules are evaluated by the policy server, the results are
sent to the network element as configuration data.
The rest of the scenario works like it has been described
previously. Note that the application could be the PDP itself. For
example, the PDP may be interested in triggers that ôtriggerö it to
update the policy rules database for this network element. On the
other hand, it can be questioned why applications cannot implement
the PDP function themselves instead of making use of an external PDP
server ? That is because of their distributed nature (it is
desirable that the PDP function remains centralized).
The main advantage of using the policy framework is flexibility,
i.e. the flexibility to execute release upgrades of network elements
because only policy rules need to be modified and the flexibility to
deal with new types of events by making and adding new policy rules.
This scenario can be visualized in the following figure (Fig 7).
H.T. Pham Expires May 2002 [Page 18]
Triggers and Handles Framework November 2001
|--------------------|
| | 4. populate |------------|
|------------| | Triggers & Handles |<---------------| Network |
| | | Database | | Interface |
| Policy | | | | Discovery |
| rules | |--------------------| |------------|
| repository | | ^
| | | 5.get list of |
|------------| | triggers |
/\ | |
|| v |
|| 1.get -------------------| |
|| policy | | |
|| rules | APPLICATION | |
|| | | 3.supported |
\/ |------------------| triggers |
|----------| | ^ |
| | | | |
| Policy | | | 8.trigger |
| Server | | 6.subscribe | |
| | | | |
|----------| v | |
| | |------------------| |
| | | | |
| |-----------\| NETWORK ELEMENT |---------------------|
|-------------/| |
2. configuration |------------------|
^
|
| 7.network event
|
|
Fig 7. Triggers scenario using policies
8.2. Scenarios for handles
The list of handles a network element supports can be consulted in a
database that has been populated by the Network Interface Discovery
module. An application is then able to send these handles to the
network element. If the Network Interface Security module exists, an
application must first register with this module which handles it
intends to send to the network element. The Network Interface
Security module is responsible for the management of a number of
applications. It is up to the Network Interface Security module to
authenticate with the network element.
The registered handle list can be modified by the application.
Modification of registered handles has to be checked as well by the
Network Interface Security module.
H.T. Pham Expires May 2002 [Page 19]
Triggers and Handles Framework November 2001
|------------------|
| APPLICATION |
| |
|------------------|
| |
| register handles
| |
| |
| | modify handles
| | registration
| |
v v
|------------------|
| NETWORK |
| SECURITY MODULE |
|------------------|
Fig 8. Registration of handles
The scenario is summarised below in Fig 9.
|---------------|
|---------------| | |
| | | Triggers and |
| APPLICATION |<--------------| Handles |
| | 4.check list | Database |
|---------------| of handles | |
| | |---------------|
| | ^
5.register | | 6.handle |
| | | 3.populate
v v |
|--------------| |
| | |-----------|
| Network | | |
| Interface | | Network |
| Security | | Interface |
| | | Discovery |
|----------| |--------------| | |
| | | |-----------|
| NETWORK | | ^
| MANAGER | | 7.handle |
| | | |
|----------| v |
| | |------------------| |
| | | | |
| |-----------\| NETWORK ELEMENT |---------------|
|-------------/| | 2.supported handles
1. configure |------------------|
list of handles
Fig 9. Handles general scenario
H.T. Pham Expires May 2002 [Page 20]
Triggers and Handles Framework November 2001
9. Architecture
Finally, Fig 10 attempts to draw an overall triggers and handles
architecture. The different functional blocks that have been
explained previously plus the relationships between them are
gathered and shown. The figure must be understood as showing only a
conceptual architecture, implementation will be discussed in the
next section.
The Network Security Configuration module has not been described in
previous sections. It is a tool that knows the contract between the
service provider and the network provider and it allows to control
the Network Interface Security functional module. Some intelligence
is required in the tool to translate the agreement between network
and service providers in a list of triggers and handles on which
that agreement is to be enforced.
2 types of interface are showed on the figure:
- interface between functional blocks belonging to the service
platform. It will probably be a SW interface that might or not be
subject to standardisation.
- interface between the service platform and network elements. This
interface relies either on a triggers and handles specific
interface(specific transport protocol, semantics) or existing
protocol, in which case, a Network Interface Adaptation is
required.
H.T. Pham Expires May 2002 [Page 21]
Triggers and Handles Framework November 2001
SERVICE PLATFORM
|------------------------------------------------------------------|
| APPLICATIONS AREA | FRAMEWORK AREA |
| | |
| | |---------------| |
| | | Network | |
| | | Security |-------| |
| |-----------| | | Configuration | | |
| | |------------| | |---------------| | |
| | | |-------------| | | |
| | | | | | |------------| |------------| | |
| |-| | Application |<-|--| Triggers & |<-----| Network | | |
| |-| | | | Handles | | Interface | | |
| |-------------| | | Database | | Discovery | | |
| ^ ^ | |------------| |------------| | |
|-------|----------|----| ^ | |
| | | | | |
| v v | | |
| |--------------------------------------------------------| | |
| | | | |
| | Network Interface Security (optional) |<---| |
| | | |
| |--------------------------------------------------------| |
| ^ ^ ^ |
| | | | |
| | v | |
| | |------------| | |
| | | Network | | |
| | | Interface | | |
| | | Adaptation | | |
| | |------------| | |
| | ^ | |
| | | | |
| | | | |
|-------|----------|----------------------------------|------------|
| | |
v v |
|------------------------------------------------------------------|
| |
| NETWORK ELEMENT |
| |
|------------------------------------------------------------------|
Fig 10. Overall triggers and handles architecture
H.T. Pham Expires May 2002 [Page 22]
Triggers and Handles Framework November 2001
10. Example of applications making use of triggers and handles
This section describes an example that shows the type of
applications (or services) making use of triggers and handles to
communicate with network elements. The network configuration is as
Fig 2. Five actors are considered in the scenario:
- User is a Internet end-user. It is a consumer of Internet
services. User works for a corporate and has the possibility to
connect to the corporate network. User also has its private
Internet Service Provider.
- Services Server is an application that delivers to User the
services of network connectivity, video on demand and VoIP call
forwarding. The service Network Connectivity proposes a list of
networks User can enter, Services Server then executes necessary
actions to provide connectivity to User. Video On Demand is a
service available in one of the network User is connected to. VoIP
Call is a service whereby a VoIP call is forwarded to the User by
Services Server. User is a subscriber to services provided by
Services Server.
- Stat is an application that gathers statistics on how frequent
User connects to a network or requests a service. There is an
agreement between User and Stat so that the latter is authorised
to collect the user statistics data.
- Both applications run on a Service Platform that belongs to the
service provider. Service Platform contains an implementation of
the triggers and handles framework. In the scenario, the actor
Service Platform refers to this framework.
- BRAS, the Broadband Remote Access Server, represents the network
element that applications will interact with (see Fig 2). In
addition to basic access support, BRAS supports proxying of VoIP
call control messages.
To simplify the scenario, it is supposed the Network Interface
Security module is disabled. This means there is a trust
relationship between the Service Platform owner and the BRAS owner.
H.T. Pham Expires May 2002 [Page 23]
Triggers and Handles Framework November 2001
The scenario is described below:
1) Service Platform (i.e. the Network Interface Discovery module)
makes a request to the BRAS to know the list of supported
triggers and handles. As an example, BRAS sends back the
following list:
{ triggerUserOnline,
triggerUserOffline,
triggerVoIPCallRegistration,
triggerIncomingVoIPCall,
triggerVoIPCallEnd,
handleConnectUserToNetwork,
handleDisconnectUserFromNetwork,
handleSetUserQoS,
handleCallForward }.
Explanations related to each trigger and handle are provided in
the following points of the scenario.
This list is stored in the framework and can be offered to
interested applications.
2) Stat subscribes to the BRAS to receive the triggers:
- triggerUserOnline: a presence trigger when the user comes on
line.
- triggerUserOffline: a disconnect trigger when the user is not
any more on line.
Services Server subscribes to the triggers:
- triggerVoIPCallRegistration: a trigger when a VoIP client wants
to register with a VoIP server (e.g. when a SIP/REGISTER
message is received in BRAS).
- triggerIncomingVoIPCall: a trigger when the BRAS for example as
a SIP proxy receives for example a SIP/INVITE.
- triggerVoIPCallEnd: a trigger when the BRAS for example as a
SIP proxy receives for example a SIP/BYE.
The presence trigger should contain the user profile parameters
the BRAS has about the user (for example its QoS, location and
access network profile).
The incoming call trigger should contain the destination user
identity (for example a SIP URL).
H.T. Pham Expires May 2002 [Page 24]
Triggers and Handles Framework November 2001
3) User is teleworking from home. It launches an application on his
PC that gives him connection to the Service Platform. It is
authenticated and his list of personalised services is downloaded
to his WEB browser.
4) User starts a VoIP client to listen to any incoming phone call.
There is a registration message sent to BRAS which relays it as a
triggerVoIPCallRegistration to Service Platform.
5) User starts by connecting to his or her corporate network. It
requests this service to Services Server. This latter sends the
handle handleConnectUserToNetwork to BRAS. BRAS executes the
handle and connectivity is setup for the user. triggerUserOnline
is sent by BRAS to notify Stat that User is online.
6) During a break, User connects to his ISP network to check his
private email account and downloads some files. This happens
simultaneously with the connection to the corporate network.
Services Server sends handleConnectUserToNetwork to BRAS to
connect the user to that network. A trigger is sent to Stat to
notify it is now present in the ISP network.
7) At the same time (because User takes a rather long break ;-)),
User connects to a dedicated network that offers VoD service to
watch some movie previews. It is a simultaneous connection. This
service is selected. First, Services Server sends a handle to
connect this user to the said network. Next, Services Server
sends the handle handleSetUserQoS to adjust the bandwidth to
reach the level required by this service (according to the
service level User is subcribed to). A WEB page is sent to the
user that contains links to the video server. A trigger is sent
to Stat to notify it that User is now present in the VoD network.
8) A phone call arrives. The call originates from a network the user
is not connected to. BRAS sends a triggerIncomingVoIPCall to
Services Server. This realises User is not connected to this
network, so it sends a handle to BRAS to connect User.
Subsequently, it sends handleCallForward to request BRAS to
forward the incoming call request to the user. At the user side,
the video being watched is paused and User answers the phone.
9) When the call ends, BRAS detects it, sends triggerVoIPCallEnd to
Services Server that disconnects User from the network with the
handle handleDisconnectUserFromNetwork.
10) User disconnects from the VoD network. Notified by User,
Services Server sends handleDisconnectUserFromNetwork to BRAS.
Furthermore, triggerUserOffline is sent by BRAS to notify Stat.
H.T. Pham Expires May 2002 [Page 25]
Triggers and Handles Framework November 2001
11) User disconnects from the ISP network. Notified by User,
Services Server sends handleDisconnectUserFromNetwork.
triggerUserOffline is sent to notify Stat.
12) At the end of his/her work session, User disconnects from the
corporate network. Notified by User, Services Server sends
handleDisconnectUserFromNetwork. triggerUserOffline is sent to
notify Stat.
13) The scenario ends for User.
Note that in the case User is authenticated by a Radius server
located in Service Platform, the Radius accounting messages can
be intercepted by Service Platform to simulate the presence
trigger. Thus, BRAS does not have to send these presence
triggers. This is an example of how Service Platform can take
benefit of existing protocols.
Note that this scenario will also work in other kinds of access
networks (e.g. the mobile access network) as well, only the BRAS
would be different.
11. From concept to implementation
The above specified conceptual architecture needs to be mapped to a
real implementation architecture. Several observations must be made
prior to implementation considerations.
As stated above, the triggers and handles concept is built around
the idea of communication between applications and network elements.
It is an idea that is fundamentally not revolutionary but the only
merit this proposal has is to encapsulate this interaction between
applications and network elements in a framework with addition of
new features such as triggers subscription, network interface
adaptation, network interface discovery, dynamic control of network
elements upon user requests, ...
In addition, a transport protocol is required to carry triggers and
handles from and to a network element. For many years, applications
have been successfully controlling network elements with the sole
SNMP protocol. Nowadays, several new protocols and framework
architectures addressing various different problems in different
domains are being developed in IETF. So, it would be a waste of time
and energy to design new protocols and to deny existing work in
IETF.
As described previously, the concept covers network elements in
general, meaning that it is about communication between applications
and any device that sits in the network. But today network element
functionalities are not limited any more to processing of traffic at
H.T. Pham Expires May 2002 [Page 26]
Triggers and Handles Framework November 2001
and below the transport layer. It becomes more and more frequent
that network elements have knowledge of application-level traffic
(e.g. web intermediaries and middleboxes treated in opes and midcom
frameworks are such examples). Network elements can be located
either at the edge of the network or close to the end-user (e.g.
home network devices). The conclusion is that it cannot be envisaged
to find a global transport mechanism for all triggers and handles in
all the possible areas due to varieties in both functionalities and
locations of network elements.
Therefore, the goal is to look for existing protocols and frameworks
that are capable of realising, if not completely, at least a major
part of the triggers and handles framework. Missing functionalities
might be introduced as extensions to existing protocols. The
candidates must as well be examined against the requirements that
are stated in a previous section of this document.
In order to take a maximum benefit of currently existing protocols
(and thus minimising introduction of new protocols or extensions of
existing protocols), the following strategy can be applied to the
framework implementation. Assuming the fact that functionalities of
a network element will always be clearly specified, each network
element will be viewed from service platforms as composed of
functional blocks, each functional block corresponds to well
delimited functionalities (or protocols) supported by the network
element. Then, triggers and handles are identified for each of these
functional blocks. As such, a network element presents what are
called network interface views to the service platform. In addition
to these functional views, aggregated views could be defined.
Aggregated views combine several interfaces from other functional
views supported by the network element. For example, a subscriber
profile management view may concern both the QoS view and the VPN
view functionalities. Another advantage of views is reusability of
triggers and handles, i.e. 2 network elements presenting the same
views will offer support of the same triggers and handles to service
platforms. The global management of all the views is assumed to be
located in the framework, more exactly in the Network Interface
Discovery module. It is then up to Network Interface Discovery to
discover all the views the network element has. The primary role of
the Network Interface Discovery module is to construct a map of all
the views of network elements that may be served by this service
platform. The service platform can then adapt itself to the
requirements of underlying network element, this will allow to
provide a wide support of network interfaces in the service
platform.
The network interface security and network interface adaptation have
to be mapped to equivalent functionalities found in these protocols.
H.T. Pham Expires May 2002 [Page 27]
Triggers and Handles Framework November 2001
Because a service platform is user centric, interaction between the
service platform and networks most of the time is the result of user
requests. Therefore, views exported by a network element can be
interpreted as the reflection of some kind of control the network
element offers to a certain user via the service platform serving
that user. This is a quite new concept because until now, network
elements are exclusively configured and controlled by the network
provider.
Applications in the service platform communicate with the framework
via standardised triggers and handles API's. This interface will
probably be a purely SW interface.
A layered implementation architecture of the triggers and handles
framework can be deduced. This is depicted in Fig 11.
|----------------------|
| Applications layer |
|----------------------|
| Framework layer |
|----------------------|
| Network views layer |
|----------------------|
^
|
v
|----------------------|
| Network element |
|----------------------|
Fig 11. Layered implementation architecture
Fig 12 shows the network views and the Network Interface discovery.
Based on Fig 12, the subsequent sections will present a suggestion
of how a network element can be splitted in views. It is inspired by
existing work in standardisation (IETF and others) that are believed
to relate to value-added Internet services. For each study case, the
various aspects of the triggers and handles framework will be
discussed:
- core functionality of triggers and handles.
- network interface discovery.
- triggers subscription.
- handles registration.
- network interface adaptation.
- network interface security.
H.T. Pham Expires May 2002 [Page 28]
Triggers and Handles Framework November 2001
|--------------------------------------------------------------|
| SERVICE PLATFORM |
| |
| |---------------------------------------------| |
| | NETWORK INTERFACE DISCOVERY | |
| |---------------------------------------------| |
| | | | | |
|--------------------------------------------------------------|
| | COPS | OPES | MIDCOM
| | | |
| | | |
|------------| |------------| |------| |-----------|
|-| Aggregated |---| Networking |---| OPES |---| NAT, |---|
| | views | |------------| |------| | Firewall | |
| |------------| | |-----------| | |
| |------------------------------------------| |
| | |
| |------> functional |
| views |
| NETWORK ELEMENT |
|--------------------------------------------------------------|
Fig 12. Network element views in a service platform
11.1 Networking related view
11.1.1 General
Networking functionalities (for example network configuration,
network switching, QoS settings, QoS change... i.e. any service
related to configuration in and below the network layer) are
essential for delivering value-added services. Service platforms are
required to be able to control these networking functionalities and
to provision network elements for the services they are delivering
(e.g. multimedia applications, VPN or access services). If triggers
and handles can be envisaged from the point of view of "policies for
network elements", then the standardised policy framework is a good
candidate for the implementation. The COPS [COPS] protocol offers
many enhancements to the SNMP protocol. As a real time protocol it
is more suitable for dynamic control of network element. COPS and
its extension COPS-PR [COPS-PR] for provisioning network elements
with operational policies can be proposed for the exchange of
triggers and handles that are related to networking functionalities.
Furthermore, as already described in section "Scenario for triggers
using policies", the triggers framework might be implemented with
the policy framework in which COPS and COPS-PR play an important
role.
H.T. Pham Expires May 2002 [Page 29]
Triggers and Handles Framework November 2001
The COPS client will work with triggers and handles PIB objects.
Instead of specifying the network element behaviour at network level
(considered as low level), these new kinds of COPS objects will
specify the network element's behaviour at a service level. More
exactly, the PIB specifies the views that service components or
applications have on network elements (views have been described in
the previous section). The behaviour is enforced when the PIB
objects are requested to be installed. The high level behaviour
objects may then be mapped by the network element to more low level
PIB objects. Some kind of aggregation of PIB objects is obtained,
i.e. a service level PIB object will be composed at network level of
a series of low level PIB objects. High level objects are related to
a certain functionality of a network element as it is viewed by the
service level whereas low level objects relate to how the network
element implements that functionality.
Thus, low level objects are device-dependent and high level objects
can be device-independent. For example, in a network switching
service, a handle PIB object could be defined to instruct a
broadband remote access server (BRAS) to switch one user from one
network to another network. When a COPS command to install the
"SwitchNetwork" object is received, the BRAS first reallocates the
user IP address and second reconfigures its routing table to route
all traffic from the user access connection to a new network. These
2 last actions are performed for example by reinstalling PPP, PPPoE
and Routing Table PIB objects.
A handle is a Decision message with the INSTALL command on the
corresponding PIB object. A trigger is a Report State message
containing the corresponding PIB object. The intelligence is placed
in the network element that knows how to map high level to low level
(= device configuration level) PIB objects.
Triggers and handles provisioning in the network element is
performed by network management. In the case this makes use of
COPS-PR, a policy server (or PDP) installs the necessary PIB objects
in the network element. The policy framework for provisioning of
triggers objects described in section "Scenario for triggers using
policies" fits particularly well in this case.
According to the COPS-PR framework [COPS-PR], at initialisation
time, the network element sends a request describing its
capabilities in terms of triggers and handles to the service
platform. The role of Network Interface Discovery is thus fulfilled.
After this procedure is completed, the network element is ready to
execute handles and to send triggers under supervision of the
service platform. Any change in the network element configuration
can be notified to Network Interface Discovery by a REQ message.
H.T. Pham Expires May 2002 [Page 30]
Triggers and Handles Framework November 2001
The Network Interface Adaptation module can be implemented with a
COPS proxy that takes COPS messages as input and translates them to
the real underlying protocol (SNMP, telnet e.g. for command line
interface, etc). Triggers coming from the network element are
intercepted and converted to COPS Report State messages.
Subscription to triggers may be implemented by the definition of a
special PIB object called "TriggersSubscription". The object would
be instantiated by each application, each instance contains its own
list of triggers the application would like to receive.
Network Interface Security could be realised with the COPS internal
security feature (Integrity Object). More investigation needs to be
done here.
There are some considerations on the COPS client type. The COPS-PR
client type can apply because for the moment, the triggers and
handles framework maps relatively well on the COPS-PR framework. But
if it is identified in the future that triggers and handles actually
opens the door to a new study domain, a new client type will be
proposed and described.
11.1.2 Architecture
The policy framework requires a PDP (Policy Decision Point) and a
PEP (Policy Enforcement Point). The PEP is obviously located in the
network element. The PDP is part of the service platform and serves
as proxy between applications and the network element. There is a
COPS connection established between PDP and PEP. Initially, the idea
was that every application plays the role of PDP. The advantages
would be a cleaner separation of each application PIB data and would
be to avoid specification of an interface between each application
and the unique PDP. But this would not be scalable because this
would introduce one additional COPS connection per application.
Distinction between applications in the case of a unique PDP can be
obtained with the Request State mechanism (see [COPS]).
Fig 13 shows the different components of the framework architecture.
Three interfaces are denoted by (1), (2) and (3).
Interface (1) is entirely contained in the service platform. It is a
purely SW interface (it could actually be standardised triggers and
handles API).
Interface (2) is a device-dependent interface. It is foreseen for
network elements not supporting the triggers and handles framework
with COPS-PR.
Interface (3) is completely specified in [COPS] and [COPS-PR].
H.T. Pham Expires May 2002 [Page 31]
Triggers and Handles Framework November 2001
Triggers provisioning (see section "Scenario for triggers using
policy") can be done with a second PDP which does not interface with
the applications. This second PDP is possibly not hosted by the
service platform.
|--------------------------------------------------------|
| SERVICE PLATFORM |
| |-----------| |
| | |------------| |
| | | |--------------| |
| | | | | |
| |-| | Applications | |
| |-| | |
| |--------------| |
| ^ |
| | |
| - - - - - - - - - - - - -|-(1)- - - - - - - - - - - |
| | |
| v |
| |--------| |-----| |
| | | | | |
| |---------->| PDP |<--------> | PIB | |
| | | | | | |
| | |--------| |-----| |
| | ^ |
| | | |
| | | |
| v v |
| |---------------| |-----------| |
| | Network | | COPS-PR | |
| | Interface | |-----------| |
| | Adaptation | | COPS | |
| |---------------| |-----------| |
| ^ ^ |
| | (2) | (3) |
|--------------------------------------------------------|
| |
v v
|--------------------------------|
| |
| Network element (PEP) |
| |
|--------------------------------|
Fig 13. A COPS-PR solution for triggers and handles
H.T. Pham Expires May 2002 [Page 32]
Triggers and Handles Framework November 2001
11.1.3 Scenario
Note that COPS defines a Handle Object that is not to be confused
with handles in the triggers and handles framework.
Refer to [COPS] for details about the COPS protocol.
Here again, it is made abstraction of the Network Interface Security
module.
The scenario is as follows:
1) PEP is provisioned on triggers and handles capabilities by a
network management system (COPS-PR, SNMP, Command Line Interface,
...). It is assumed the network management function is not in the
service platform.
2) PEP establishes a COPS connection with the PDP in the service
platform. There is one PDP serving all aplications wishing to
send handles/receive triggers to/from the network element.
3) PEP sends a REQ message to PDP. The request message contains the
list of triggers and handles this PEP is able to deal with. This
message creates a new request state in PDP.
4) PDP acknowledges with a DEC message.
5) PEP acks the DEC message with a RPT message.
6) A first application (will be called Application 1) registers with
PDP via the triggers and handles API interface. It gets back a
pointer to the list of available triggers and handles. Security
check is performed between PDP and the application during this
step.
7) Application 1 subscribes to triggers with PDP via the triggers
and handles API interface. The PDP sends a DEC message containing
the list of subscribed triggers to PEP.
8) Now Application 1 is able to communicate with PEP via PDP. A
handle is sent to PDP that converts it to the right format and
sends it to PEP. A trigger, part of Application 1 subscribed
list, is forwarded by the PDP to that application. A handle is a
DEC message with a INSTALL command whereas a trigger is a RPT
message. All DEC and RPT messages contain the corresponding COPS
Handle Object.
9) Application 2 registers with PDP. To create a new request state,
PDP sends a DEC message to PEP with the Decision Flag set
accordingly. A pointer to the list of available triggers and
handles is returned to Application 2.
H.T. Pham Expires May 2002 [Page 33]
Triggers and Handles Framework November 2001
10) Application 2 follows the same procedure as Application 1 to
interact with the PEP.
11) For example, Application 1 changes its subscription to triggers
via the triggers and handles API interface. This causes PDP to
send a DEC message with the new list of triggers (and with the
Handle Object corresponding to Application 1).
12) One of the applications unregisters with PDP. A DEC message is
sent to cause the corresponding request state be deleted in PEP.
A DRQ message is sent by PEP to cleanup this Handle Object in
PDP as well.
13) Changes in configuration in the network element are notified to
PDP with a REQ message. It is up to the PDP to synchronise with
the applications. It is also able to trigger request state
deletion or new triggers subscription by a DEC message.
14) The COPS connection can be closed either by PDP or PEP.
11.1.4 XML-based interface
If the network element supports XML-based interface, the interface
described above can be replaced by a XML-based interface, thus
taking benefit of advantages of the XML language [XML]. The SOAP
protocol [SOAP] is a good candidate.
More investigation is needed here.
11.2 OPES
The OPES model [OPES] describes an external callout server that
implements open pluggable services. If the service platform offers
services such as OPES services, it can control typically WEB
intermediary devices with triggers and handles defined in the OPES
framework.
11.3 Midcom
The midcom framework [MIDCOM] defines a method by which applications
can control middleboxes with NAT, firewall functionalities (other
kinds might be possible in the future). This is another instance of
realisation of triggers and handles. If the service platform offers
midcom services, it can rely on a transport protocol such as midcom.
The COPS protocol might be envisaged here as well (recently, it has
been proposed. See [COPSMIDC]).
H.T. Pham Expires May 2002 [Page 34]
Triggers and Handles Framework November 2001
11.4 Home networks
As the service platform is expected to be distributed, some of its
components may be located in home networks devices such as user
terminal, modems, ... In this situation, triggers and handles may
use the applicable protocols and frameworks defined for example in
UPnP, OSGI, etc. SOAP-based triggers and handles are as well
possible between a home network device and an application server
located in the edge network.
12. Security considerations
A Network Security Module is foreseen in the framework to deal
explicitly with security issues.
Security issues must be considered when the applications provider is
not the same as the underlying network provider. The Network
Interface Security module must be correctly configured to either let
handles and triggers pass through or to reject them if they do not
comply with the agreement between service provider and the network
provider and if they have not successfully registered with the
Network Interface Security module.
Security issues should be dealt with at 2 places in the framework
architecture (see Fig 11):
- between the applications layer and the framework layer
- between the network views layer and the network element.
13. Summary
This paper only draws the guidelines for a new concept that should
improve the communication between a service platform and underlying
networks by isolating network and vendor-specific details to the
service logic. This should allow applications to be more easily
deployed on a heterogeneous and complex networks. Further work has
to be accomplished with if possible support from the IETF community.
H.T. Pham Expires May 2002 [Page 35]
Triggers and Handles Framework November 2001
14. Authors' information
Hien-Thong Pham
Alcatel Bell
Francis Wellesplein 1
B-2018 Antwerp
BELGIUM
Phone: +32-3-2408630
Email: hien-thong.pham@alcatel.be
Dominique Chantrain
Alcatel Bell
Francis Wellesplein 1
B-2018 Antwerp
BELGIUM
Phone: +32-3-2408518
Email: dominique.chantrain@alcatel.be
Claudine Batsleer
Alcatel Bell
Francis Wellesplein 1
B-2018 Antwerp
BELGIUM
Phone: +32-3-2409331
Email: claudine.batsleer@alcatel.be
Comments should be sent to all the above listed email addresses.
H.T. Pham Expires May 2002 [Page 36]
Triggers and Handles Framework November 2001
15. References
[NAT] Framework for interfacing with Network Address Translator,
draft-ietf-nat-interface-framework-03.txt, P. Srisuresh,
April 2001, work in progress.
[SIP] SIP: Session Initiation Protocol, RFC2543,
M. Handley, H. Schulzrinne, E. Schooler, and J.
Rosenberg, March 1999.
[SNMP] Simple Network Management Protocol, STD 15, RFC1157,
J. Case, M. Fedor, M. Schoffstall, and J. Davin, May 1990.
[RADIUS] Remote Authentication Dial In User Service (RADIUS), RFC2865,
C. Rigney, S. Willens, A. Rubens, W. Simpson, June 2000.
[SOAP] Simple Object Access Protocol (SOAP) 1.1, World Wide Web
Consortium (W3C), W3C Note, http://www.w3.org/TR/SOAP, May
2000.
[XML] Extensible Markup Language (XML), World Wide Web Consortium
(W3C), W3C Recommendation,
http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
[COPS-PR] COPS Usage for Policy Provisioning (COPS-PR), RFC3084,
K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie,
S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith, March 2001.
[COPS] The COPS (Common Open Policy Service) Protocol, RFC2748,
D.Durham, J.Boyle, R.Cohen, S.Herzog, R.Rajan, A.Sastry,
January 2000.
[POL] A Framework for Policy-based Admission Control, RFC2753,
R. Yavatkar, D. Pendarakis, R. Guerin, January 2000.
[TERM] Terminology, draft-ietf-policy-terminology-03.txt,
A. Westerinen, J. Schnizlein, J. Strassner, Mark Scherling,
Bob Quinn, Shai Herzog, An-Ni Huynh, Mark Carlson, Jay
Perry, Steve Waldbusser, April 2001, work in progress.
[OPES] A Model for Open Pluggable Edge Services,
draft-tomlinson-opes-model-00.txt, G. Tomlinson, R. Chen,
M. Hofmann, July 2001, work in progress.
[MIDCOM] Middlebox Communication Architecture and Framework,
draft-ietf-midcom-framework-03.txt, P. Srisuresh,
J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, July 2001,
work in progress.
H.T. Pham Expires May 2002 [Page 37]
Triggers and Handles Framework November 2001
[COPSMIDC] COPS applicability as the MIDCOM protocol,
draft-aoun-midcom-cops-00.txt, C.Aoun, K.Chan, L-N.Hamer,
R.Penno, S.Sen, September 2001, work in progress.
H.T. Pham Expires May 2002 [Page 38]