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]