Internet-Draft H.T. Pham
D. Chantrain
C. Batsleer
File:draft-pham-triggers-and-handles-00.txt Alcatel
Expires: December 2001 June 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 June 2001
Table of contents
Status of this memo...................................................1
Copyright Notice......................................................1
Abstract..............................................................1
Table of contents.....................................................2
1. Introduction.......................................................3
2. Definitions........................................................3
3. Concepts...........................................................4
3.1. Network configuration............................................4
3.2. Triggers and handles concept.....................................6
3.3. Examples of triggers.............................................7
3.4. Examples of handles..............................................7
3.5. Triggers and handles discovery...................................8
3.6. Security.........................................................8
4. Usage scenarios....................................................9
4.1. Usage scenarios for triggers.....................................9
4.1.1. General scenario...............................................9
4.1.2. Scenario using policies.......................................10
4.2. Usage scenarios for handles.....................................12
5. Transport protocol................................................14
5.1. Requirements....................................................14
6. Semantics.........................................................15
6.1. Requirements....................................................15
6.2. Description syntax..............................................15
6.2.1 Requirements...................................................15
6.2.2 Examples of triggers and handles syntax........................15
7. Adaptation to the existing network elements.......................16
7.1. Network Interface Adaptation module.............................16
7.2. Protocol interceptor............................................17
7.3. Internal structure of the Network Interface Adaptation module...17
8. Architecture......................................................18
9. Security considerations...........................................20
10. Summary..........................................................20
11. Authors' information.............................................20
12. References.......................................................21
H.T. Pham Expires December 2001 [Page 2]
Triggers and Handles Framework June 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 unified 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.
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. 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.
H.T. Pham Expires December 2001 [Page 3]
Triggers and Handles Framework June 2001
- Service: any value 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,
update 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
containing this user's addressing information), 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
platform and network elements. It allows introducing
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.
H.T. Pham Expires December 2001 [Page 4]
Triggers and Handles Framework June 2001
|--------------------|
| 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 access server BRAS.
Fig 2 provides as well some examples of network elements (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.
|------------------------------------------------------------------|
| 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
H.T. Pham Expires December 2001 [Page 5]
Triggers and Handles Framework June 2001
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. [1] 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.
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 [2], SNMP [3], RADIUS [4], ...) 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.
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
the 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 semantic 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
H.T. Pham Expires December 2001 [Page 6]
Triggers and Handles Framework June 2001
transported over either an existing (e.g. SIP [2] for triggers and
SOAP [5] for handles) or a new communication protocol.
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 PPP session is successfully
established. This trigger contains for instance the user IP address,
username and password.
Broadband DSL modem sends a presence trigger after it successfully
establishes a PPP session for a user in a home network.
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 sent to BRAS to request it to switch to a different VPN. This
handle contains for example the new VPN-id and necessary login
parameters.
Handle sent to BRAS to reconfigure its routing table to support
simultaneous connectivity to 2 different VPN's.
Handles to an advanced DSL modem to setup bridges, PPP connections,
NAT/PAT entries, VP/VC, etc.
H.T. Pham Expires December 2001 [Page 7]
Triggers and Handles Framework June 2001
Handle to DSLAM to setup dynamically VP/VC (SVCÆs) via a management
interface (e.g. SNMP). Thus, reusing an existing interface
Handle to the user terminal to start PPP connections.
3.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, 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 applications 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.
3.6. Security
As triggers and handles interface is 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). An optional Network Interface Security
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 handles depending
on the service agreement it has with the provider of the underlying
network. The Network Interface Security will authenticate the
service platform to the network and will 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.
H.T. Pham Expires December 2001 [Page 8]
Triggers and Handles Framework June 2001
4. Usage scenarios
4.1. Usage scenarios for triggers
4.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.
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 need 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 3. Subscription/Unsubscription/Modification of subscription to
triggers
H.T. Pham Expires December 2001 [Page 9]
Triggers and Handles Framework June 2001
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.
|--------------------|
| | 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 4. Triggers general scenario
4.1.2. Scenario using policies
The scenario that is described above is the general usage scenario
for triggers. This scenario can be implemented with the policy
framework. The main idea here is to fulfil the network manager role
with a policy control system [6].
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
H.T. Pham Expires December 2001 [Page 10]
Triggers and Handles Framework June 2001
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 [7]) sends a request for decision to a policy server
(Policy Decision Point in the policy terminology [7]) which will
access a policy rules repository, retrieves the policy rule,
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 5).
H.T. Pham Expires December 2001 [Page 11]
Triggers and Handles Framework June 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 5. Triggers scenario using policies
4.2. Usage 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 elements.
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 December 2001 [Page 12]
Triggers and Handles Framework June 2001
|------------------|
| APPLICATION |
| |
|------------------|
| |
| register handles
| |
| |
| | modify handles
| | registration
| |
v v
|------------------|
| NETWORK |
| SECURITY MODULE |
|------------------|
Fig 6. Registration of handles
The scenario is summarised below in Fig 7.
H.T. Pham Expires December 2001 [Page 13]
Triggers and Handles Framework June 2001
|---------------|
|---------------| | |
| | | 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 7. Handles general scenario
5. Transport protocol
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 requirements, either existing protocols need to be extended or a
new protocol is to be designed. Elements of the framework like
messages for subscription to triggers should as well be transported
as a handle by this transport protocol. This section presents some
requirements that should be considered to choose such a protocol.
5.1. Requirements
1) 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.
2) It is not expected that a service platform imposes real-time
constraints on the transport protocol but it should comply to the
H.T. Pham Expires December 2001 [Page 14]
Triggers and Handles Framework June 2001
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
than the transport protocol for the handle should not introduce
too many overheads to respect this).
3) Triggers and handles information should be transported with a
reliable transport protocol.
4) etc (TBD)
6. Semantics
6.1. Requirements
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 handle.
Considering the almost infinite possibility of possible services,
the semantics should allow to extend easily the information that a
trigger or a handle contains.
To be continued.
6.2. Description syntax
6.2.1 Requirements
To be defined.
XML [8] is a good candidate to be considered. If triggers and
handles are viewed as manageable objects, languages used in SNMP
managed networks will have to be considered.
6.2.2 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.
H.T. Pham Expires December 2001 [Page 15]
Triggers and Handles Framework June 2001
Trigger:
vendor name
network element name
event domain
event name
trigger name
list of trigger parameters
If the policy track is followed, policy rules related to triggers
should be described by a syntax which extends if necessary the
existing syntax of policy rules.
The most important part is of course the trigger body. Vendor,
network element, triggering network event are informational.
Note that the network event format is network element dependent and
therefore will not be described in this paper.
Handle:
vendor name
network element name
handle name
list of command parameters
7. Adaptation to the 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
H.T. Pham Expires December 2001 [Page 16]
Triggers and Handles Framework June 2001
investigated. It provides a solution for the fact that installed
base network elements are difficult to update to support additional
interface 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 8.
| ^
| |
| Handle A | Trigger B
| |
v |
|--------------------------------|
| NETWORK INTERFACE ADAPTATION |
|--------------------------------|
| ^
| |
|<-- protocol messages ->|
| |
| |
v |
|------------| |------------|
| Protocol A | | Protocol B |
|------------| |------------|
Fig 8. 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 be as it is
shown on Fig 9.
Obviously, a triggers and handles conversion function is necessary.
It is fulfilled by the Triggers and Handles Converter.
H.T. Pham Expires December 2001 [Page 17]
Triggers and Handles Framework June 2001
For triggers, this Network Interface Adaptation module must
necessarily implement the protocol interceptor function in order to
forward protocol messages to their first intended destination.
Indeed, these messages do not primarily serve the triggers and
handles purpose, they are simply ôinterceptedö on the way by the
protocol interceptor.
To protocol-
| ^ specific
| | application
| Handle A | Trigger B ^
| | |
v | |
|-------------------------| |
| | |
| Triggers and Handles | |
| Converter | |
| | |
|-------------------------| |
| ^ |
| | |
| | |
| |-------------| |
| | | |
| | Protocol |-----------
| | Interceptor |
| | |
| |-------------|
| ^
| |
| |
v |
protocol A message protocol B message
Fig 9. A possible structure of Network Interface Adaptation
8. Architecture
Finally, the following figure 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 Network Interface Security functional block is controlled by the
Network Security Configuration, a tool that knows the contract
between the service provider and the network provider.
H.T. Pham Expires December 2001 [Page 18]
Triggers and Handles Framework June 2001
|------------------------------------------------------------------|
| SERVICE PLATFORM |
| |
| |---------------| |
| | 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. Tentative: overall triggers and handles architecture
H.T. Pham Expires December 2001 [Page 19]
Triggers and Handles Framework June 2001
9. 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.
10. 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 network. Further work has to
be accomplished with if possible support from the IETF community.
11. 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 December 2001 [Page 20]
Triggers and Handles Framework June 2001
12. References
[1] Framework for interfacing with Network Address Translator,
draft-ietf-nat-interface-framework-03.txt, P. Srisuresh,
April 2001.
[2] SIP: Session Initiation Protocol, RFC2543,
M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,
March 1999.
[3] Simple Network Management Protocol, STD 15, RFC1157,
J. Case, M. Fedor, M. Schoffstall, and J. Davin, May 1990.
[4] Remote Authentication Dial In User Service (RADIUS), RFC2865,
C. Rigney, S. Willens, A. Rubens, W. Simpson, June 2000.
[5] Simple Object Access Protocol (SOAP) 1.1, World Wide Web
Consortium (W3C), W3C Note, http://www.w3.org/TR/SOAP, May
2000.
[6] A Framework for Policy-based Admission Control, RFC2753,
R. Yavatkar, D. Pendarakis, R. Guerin, January 2000.
[7] 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
[8] Extensible Markup Language (XML), World Wide Web Consortium
(W3C), W3C Recommendation,
http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
H.T. Pham Expires December 2001 [Page 21]