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]