Internet Engineering Task Force Amit Kaul Network Working Group Nitesh Varshney Internet-Draft Ravi kumar Koyyana draft-kaul-sip-fsm-framework-00 Samaga Prasanna Krishna Expires: September 13, 2003 Udaya Shankara Vivek Jaiswal Intel Corporation March 14, 2003 Finite State Machine (FSM) Framework for SIP Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This draft defines a Finite State Machine (FSM) Framework for the SIP Extensions using which various SIP extensions, having their unique definitions of a SIP transaction or a Dialog, can be implemented in a scalable manner, while keeping the logical meaning of a dialog or a transaction (as defined by RFC 3261 [1]) intact. This draft proposes a set of guidelines for implementing FSM in various SIP extensions. Amit Kaul et al. Expires Sept 13, 2002 [Page 1] Internet Draft FSM Framework for SIP Extensions March 14, 2003 Table Of Contents 1 TERMINOLOGY..............................................2 2 INTRODUCTION.............................................3 3 FSM FRAMEWORK FOR SIP EXTENSIONS.........................3 3.1 BACKGROUND...............................................3 3.1.1 Finite State Machine Background..........................3 3.1.2 Control and Data Context.................................4 3.1.3 Interaction between FSMs.................................4 3.1.4 SIP as Layered Protocol..................................4 3.2 FRAMEWORK OBJECTIVES.....................................4 3.3 FRAMEWORK MODULES........................................5 3.3.1 FSM Manager..............................................6 3.3.1.1 FSM Manager Types for SIP..............................6 3.3.1.2 FSM Manager Interfaces.................................7 3.3.2 FSM Handler..............................................7 3.3.2.1 Conformance Module.....................................7 3.3.2.2 Interoperable Module...................................7 3.3.2.3 FSM Trigger Interface..................................8 3.3.2.4 FSM Schema Interface...................................8 3.4 FRAMEWORK FUNCTIONING....................................8 3.4.1 Trigger Routing..........................................8 3.4.1.1 Service Layer..........................................9 3.4.1.2 Trigger Point-Routing Mechanism........................9 3.4.2 FSM Routing Schema......................................11 3.4.2.1 Designing FSM Routing Schema..........................11 3.4.2.2 Registration Procedures...............................11 3.4.2.3 FSM Schema Interface..................................11 3.5 FRAMEWORK WITHIN RFC 3261 LAYERED ARCHITECTURE..........11 3.5.1 Transaction FSM Framework Design Guidelines.............13 3.5.2 Dialog FSM Framework Design Guidelines..................14 3.5.3 Framework Interfaces....................................15 3.5.3.1 Dialog Manager and Transaction Manager Peer Interface.16 3.5.3.2 Interface between a Manager and a Handler.............16 4 ADVANTAGES..............................................16 5 EXAMPLE: MODELING OF RFC 3265 FSM USING FSM FRAMEWORK...16 6 SECURITY CONSIDERATIONS.................................19 7 REFERENCES..............................................19 8 AUTHORS ADDRESSES.......................................19 1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Amit Kaul et al. Expires Sept 13, 2002 [Page 2] Internet Draft FSM Framework for SIP Extensions March 14, 2003 2 Introduction RFC 3261 defines a transaction and a well defined state machine for the same. RFC 3261 has also defined an INVITE initiated dialog and the state machine for the same, but does not talk about the state machine of dialogs created by non-INVITEs. The transaction is defined based on messages - a request and a final response typically forms a SIP transaction as per RFC 3261. However, SIP extension drafts might introduce messages, which are logically sub-tran- sactions as they affect the main transaction state machines. The SIP PRACK method is one such example. Even though PRACK constitutes a tran- saction of its own, logically it is an INVITE sub-transaction. As Per RFC 3261, a single transaction state machine is involved in driving the dialog state machine from one state to another. How the transaction state machine affects the dialog state machine for a SIP extension is specified by the respective extension, and it may differ from the definitions in RFC 3261. The Event Notification framework defined by RFC 3265 [3] is a good example. This along with possible introduction of sub-transactions puts a limita- tion on the RFC 3261 defined model wherein the transaction state machine directly drives the dialog state machine as multiple tran- sactions might be involved in creating / modifying/ terminating a dialog. There is a possibility that there might be few more draft in future that might define SIP Dialog (Non-INVITE) or SIP transaction different from the RFC3261 definitions. All these different definitions have resulted in a need for a common framework where all the different SIP extensions can reside and interact with each other, if required and with SIP RFC 3261. This draft proposes a FSM Framework for SIP extensions, for current as well as future SIP extensions. The implementation will lie within the framework of SIP protocol's sub-layers as defined in RFC 3261. The Framework provides SIP-Extension developers and implementers easy way to abstract away their proprietary and heterogeneous FSMs and expose well defined and accepted definitions of RFC3261 FSMs. 3 FSM Framework for SIP Extensions 3.1 Background 3.1.1 Finite State Machine Background Finite State Machine (FSM), also known as Finite State Automation(FSA), at their simplest, are behavioural models of a system, with a limited Amit Kaul et al. Expires Sept 13, 2002 [Page 3] Internet Draft FSM Framework for SIP Extensions March 14, 2003 number of defined conditions or modes, where mode transitions change with circumstances. This system is referenced as 'Modelled System'. This draft discusses 'SIP Modelled System' based on RFC 3261. FSM consist of four main elements: ¸ States that define behavior and can produce actions ¸ State transitions which are changes from one state to another ¸ Rules or conditions that are to be met to allow a state transition ¸ Events which are either externally or internally generated, which can possibly trigger rules and lead to state transitions. Protocol procedures can be represented as one or more state machines. 3.1.2 Control and Data Context A state machine is always in a certain state. A state is normally structured as a control context and a data context. The Control Context determines the 'thread of execution', while the Data Context represents the relevant information accumulated by the state machine. Data Contexts are typically composed of set of state variables or data- structures that are manipulated depending on the actual control state of the state machine. 3.1.3 Interaction between FSMs Various FSMs within a Modelled System can interact with each other to achieve the basic functionality. The interaction between FSMs are based on FSM Trigger passing. Triggers are the input events e.g. firing of timer, receipt of a message, sending of response etc. in a FSM. 3.1.4 SIP as Layered Protocol SIP is structured as a layered protocol, each layer designed to take care of a set of independent tasks and supposed to follow well defined set of rules and state machines, as defined by section 5 in RFC3261. Most of the existing SIP layer implementations would be following the layered architecture given in RFC 3261 strictly or some variant of it though logically fitting into the same. The main focus of this draft is the dialog layer and the transaction layer of RFC 3261 layered architecture. 3.2 Framework Objectives The scope of this draft is limited to interactions between various SIP FSMs (as defined in RFC 3261 and a few SIP extension), and a possible Amit Kaul et al. Expires Sept 13, 2002 [Page 4] Internet Draft FSM Framework for SIP Extensions March 14, 2003 way for their seamless integration. This draft's scope is limited to 'Control Context' of FSM and SHALL NOT discuss the 'Data Context'. The intention of this draft is to provide a set of guidelines in which the SIP Extension design or implementation can fit in. The Framework intends to facilitate robust design and quick deployment of different SIP extensions with the RFC 3261 implementations, with minimal inter- operability issues. The Framework is designed taking care of following considerations. ¸ Interoperability: Two or more FSM can communicate even if they are heterogeneous. ¸ Conformance: Different SIP extension FSMs obeys the RFC3261 FSMs. ¸ Defining a FSM Trigger Point Interface: A interface, which is extensible and intuitive, so that new triggers can be added or existing triggers modified incrementally, if required. ¸ Generic Framework: A framework, which enables any vendor to plug-in state-machine implementation of any third party vendor conforming to this framework, with minimum integration effort. 3.3 Framework Modules The Framework defines following components. ¸ FSM Handler is an abstract virtual machine for dialog FSM or transac- tion FSM in SIP layer. It interacts with other FSM handlers during interactions between different FSMs. It needs to get registered with a controlling component called FSM Manager. ¸ FSM Manager is a stateless component which defines simple and scalable Trigger Point Interface with neighbouring modules, routes and re-routes triggers into right FSM Handler or FSM Manager. Figure 1 describes various modules of the Framework. Amit Kaul et al. Expires Sept 13, 2002 [Page 5] Internet Draft FSM Framework for SIP Extensions March 14, 2003 +------------------------------------------------+ | FSM Manager | | +-------------------------------+ +------+ | | | FSM Trigger Routing Interface | |FSM | | | +-------------------------------+ |Schema| | | |Inter-| | | |face | | | +-------------------------------+ | | | | | FSM Trigger Routing Interface | +------+ | | +-------------------------------+ | +------------------------------------------------+ +-------+ | FSM | | Schema| +-------+ +------------------------------------------------+ | FSM Handler | | +-------------------------------+ +------+ | | | Upper | | | | | | FSM Trigger Routing Interface | |FSM | | | +-------------------------------+ |Schema| | | |Inter-| | | +-------------+ +---------+ |face | | | | Conformance | FSM | Interop | | | | | | Module | | Module | | | | | +-------------+ +---------+ | | | | +-------------------------------+ | | | | | Lower | | | | | | FSM Trigger Routing Interface | +------+ | | +-------------------------------+ | +------------------------------------------------+ Figure 1: Framework Modules 3.3.1 FSM Manager FSM Manager is a module, which SHALL manage one or more FSM handlers. For details on FSM Handler, please refer to section 6.3.2. FSM Manager SHOULD be a stateless entity whose main job is to do routing based on FSM Trigger Point. For details of routing based on Trigger Point, refer to section 6.4.1. 3.3.1.1 FSM Manager Types for SIP FSM manager in a typical SIP implementation SHALL be of two types: ¸ Transaction FSM Manager ¸ Dialog FSM Manager Amit Kaul et al. Expires Sept 13, 2002 [Page 6] Internet Draft FSM Framework for SIP Extensions March 14, 2003 3.3.1.2 FSM Manager Interfaces As shown in Figure 1, FSM Manager has following interfaces: ¸ FSM Trigger Interface Using FSM Trigger Interface, FSM Manager MAY interact with following Framework modules. ¸ SM Manager(s) (peer-peer communication) ¸ SM Handler(s) (parent-child communication) This interface is a uniform and scalable way to pass FSM Trigger Point and associated information to other component within the framework. Please refer to section 6.4.1 for details on Trigger Point Routing. ¸ FSM Schema Interface Please refer section 6.4.2 for details. 3.3.2 FSM Handler FSM Handler is an implementation of FSM defined by RFC 3261 or by any SIP extension. FSM handler also contain following modules: ¸ Conformance Module ¸ Interoperable Module ¸ FSM Trigger Interface ¸ FSM Schema Interface The FSM handler implementing the SIP RFC 3261 dialog/transaction is referred to as RFC 3261 FSM Handler. All other FSM Handlers implement- ing the extensions SHALL be conformant to RFC 3261 module, and MAY require interoperability amongst themselves. The FSM Handlers requiring interoperability can be called a sibling FSM Handlers. 3.3.2.1 Conformance Module Conformance Module has the intelligence to make sure that the SIP extension FSM Handler is conformant with the RFC 3261 FSM Handler. This is an important assumption based on which the proposed Framework glues all the components together. This implies that the SIP extension FSM Handler SHOULD be able to identify and route or re-route the Trigger Points to RFC 3261 modules of the Framework as and when it is necessary. Further, some of these modules SHOULD be ready to receive Trigger Points from RFC 3261 module being routed to them and act on them as needed. 3.3.2.2 Interoperable Module Interoperable module in a FSM Handler provides for the possibility of interactions between any two sibling FSM Handlers. Interoperable Module in a FSM Handler make sure that current FSM Handler is interoperable with other SIP Extension FSM Handlers. This module is required only when Amit Kaul et al. Expires Sept 13, 2002 [Page 7] Internet Draft FSM Framework for SIP Extensions March 14, 2003 a SIP extension FSM handler needs to inter-operate with any SIP extension FSM handler. 3.3.2.3 FSM Trigger Interface The FSM handler SHALL interact with FSM Manager(s) and FSM Handler(s) using FSM Trigger Point Interface. This interface is a uniform and scalable way to pass FSM Trigger type and associated information to other component within the framework. Please refer to section 6.4.1 for details. 3.3.2.4 FSM Schema Interface The FSM handler SHALL register with its controlling FSM Manager via FSM Schema Interface. See Section 6.4.2.3 for the details of this interface. 3.4 Framework Functioning This section discusses the following concepts of the Framework. ¸ Trigger Point Routing ¸ FSM Schema FSM Manager and FSM handler uses these concepts to achieve the various objectives of the Framework. 3.4.1 Trigger Routing Trigger is an event like Timer Expiry, Message Received, and Message Sent Etc. in a FSM. An event can result in a state transition in a FSM. This state transition might be a trigger for some other FSM of the SIP modelled system. As a result of this, triggers need to be passed across various FSMs of the SIP modelled system. The routing of FSM Triggers SHALL be achieved using a logical routing entry called Trigger-Point. Trigger-Point is a representation of all the FSM Trigger information that is needed to route FSM Trigger from one Framework module to another. Following information SHALL be passed as a part of Trigger Point. . Manager Id: This id uniquely identifies the FSM Manager. In a SIP modelled system, the FSM manager can be either a Transaction FSM Manager or a Dialog FSM manager. Refer to section 6.5. ¸ Handler Id: This id uniquely identifies the type of FSM Handler. For e.g., within a Dialog FSM Manager, a Handler Id can represent a 3261 dialog FSM handler or a 3265-dialog FSM handler. ¸ Trigger Id: This id uniquely identifies the input event into the FSM. In order to realise the interaction between various SIP FSMs, triggers MAY be passed along with any other relevant information. Trigger Point SHALL be logically encapsulated in an 'Trigger Point Interface Data Unit' (TP-IDU), while routing it across various Framework modules. Amit Kaul et al. Expires Sept 13, 2002 [Page 8] Internet Draft FSM Framework for SIP Extensions March 14, 2003 Design and implementation of the Trigger Point is implementation dependent. Note: Along with the identifiers mentioned as a part of Trigger Point, the implementers will also need identifiers which uniquely identify the FSM within the FSM handler. These would typically come from SIP message fields like CallId, From Tag and To Tag. However, these are not discussed in this draft as these are part of a data context of the FSM. Any extra context information between the various Framework Modules MAY be shared using any other means. Following section discusses Trigger Point Routing and various modules which MAY be involved in it. 3.4.1.1 Service Layer Any layer or module, which makes use of this Framework, is defined as 'Service Layer'. As shown in Figure 2 'Trigger Point Routing', the Service Layer SHALL communicate with 'Interface Conversion Logic' module, if the Service Layer has got its own proprietary APIs implemented at its interface. This module is not required if the Service Layer implements 'Trigger Point Interface' as its lower interface. 3.4.1.2 Trigger Point-Routing Mechanism This section explains in brief the steps involved in routing 'Trigger Point' information between various Framework modules. Figure 2 illustrates how the 'Trigger Point' is routed via different modules using the routing logic. Following steps SHALL be followed in routing of TP-IDU. ¸ TP-IDU is routed to appropriate FSM Manager based on 'Manager-Id'. Manager-Id is obtained from Trigger Point. ¸ FSM Manager routes the trigger point to one of the FSM handlers, by extracting 'Handler Id' from the Trigger Point. ¸ The FSM handler identifies and routes the trigger-id to a specific FSM, by extracting 'Trigger-Id' from the 'Trigger Point'. Particular FSM instance uses the Trigger-Id to invoke its Trigger Handling routine. Following figure illustrates the above steps. Amit Kaul et al. Expires Sept 13, 2002 [Page 9] Internet Draft FSM Framework for SIP Extensions March 14, 2003 +-----------------------------------------------+ | SERVICE LAYER | +-----------------------------------------------+ ^ | V +-----------------------------------------------+ | INTERFACE CONVERSION LOGIC | +-----------------------------------------------+ TP Interface data +-TP-+ | Unit +----+ | V Trigger point Interface ================================================================ +-TP-+ |\ +----+ | +------------------+ |Mgr Id==1 | V V +-----------------+ +-----------------+ | FSM Manager,Id=1| | FSM Manager,Id=2| +-----------------+ +-----------------+ Trigger point Interface /|\ ==============================/===\============================= +------------------+ | +--------------------+ | +-TP-+ | | | +----+ | | | | Hld Id=2 | +------V---------+ +------V---------+ +-------V--------+ |FSM Handler,Id=1| |FSM Handler,Id=2| |FSM Handler,Id=3| +----------------+ +----------------+ +----------------+ | +-TP-+ | +----+ | To Individual V FSM +-------------------------------------------------------------+ | FSM entry point primitive with Parameter as Trigger Id and | | any context information | +-------------------------------------------------------------+ +-TP-+ | +----+ |Trigger Id=2 V +-----------------------------------------------------+ |Do the processing depending on the trigger Id | +-----------------------------------------------------+ Figure 2: Trigger Point Routing Amit Kaul et al. Expires Sept 13, 2002 [Page 10] Internet Draft FSM Framework for SIP Extensions March 14, 2003 3.4.2 FSM Routing Schema FSM Schema is defined as the information that is needed to execute routing of TP-IDUs from one Framework module to another. FSM Routing Schema is accessible to each Framework Module. 3.4.2.1 Designing FSM Routing Schema As a part of FSM Routing Schema design activity, the implementer SHALL decide following relationships: ¸ Manager-Id and its Handler-Id(s). ¸ Handler-Id and its Trigger-Id(s). Implementer SHALL build relationship(s) between Manager-Id and Handler- Id as a part of Registration procedure, as defined in Section 6.4.2.2. Relationship between Handler-Id and its Trigger-Id(s) SHALL be built statically. 3.4.2.2 Registration Procedures Each FSM Handler SHALL have the knowledge about the FSM Manager which controls it. FSM Handler MAY know its controlling FSM Manager through any mechanism e.g., configuration. Each FSM Manager shall know about its FSM Handlers during their registration. Each FSM Handler SHALL register itself with its controlling FSM manager. FSM manager gets the Handler-Id of FSM Handler and as a part of this process it SHALL build relationship in FSM schema between its Manager-Id and the Handler-Id(s) of the FSM Handler(s) it controls. This registration MAY be runtime or static depending on the design. 3.4.2.3 FSM Schema Interface FSM Schema Interface facilitates the access to FSM Schema information by individual FSM Handlers or FSM Managers. The details of this interface is outside the scope of this draft. 3.5 Framework within RFC 3261 Layered Architecture Figure 3 explains how the proposed Framework can fit into any existing SIP implementation based on RFC 3261 layered architecture. Amit Kaul et al. Expires Sept 13, 2002 [Page 11] Internet Draft FSM Framework for SIP Extensions March 14, 2003 +----------------------------------------------------------------------+ |+--------------------------------------------------------------------+| || SIP Application Layer || |+--------------------------------------------------------------------+| | ^ ^ ^ | | | | | | | | v | | | | +----------------+ | | | | | UA/Call | | | | | | Stateful Proxy | | | | | | Dialog Core | | | | | +----------------+ | | | | ^ | | | | ===|==================== | | | | v | | | | +--------------------------------------------+ | | | | | Dialog FMS Manager | | | | | |+-----------+ +-----------+ +------------+| | | | | || 3261 Dlg | | 3265 Dlg | | REFER Dlg || | | | | || FSM Hndlr | | FSM Hndlr | | FSM Hndlr || | | | | |+-----------+ +-----------+ +------------+| | | | | +--------------------------------------------+ | | | | ^ ^ | | | | ====|=========== | ===== | | | v v v v | |+----------------+ +------------------------+ | +-------------------+ | || | | UA/Call-Stateful Proxy | | | Redirect/Trans-SF | | || Registrar Core | | Transaction Core | | | Proxy Core | | |+----------------+ +------------------------+ | +-------------------+ | | ^ ^ | ^ | | =======|====|=============| ==========|========= | | v v v v | |+--------------------------------------------------------------------+| || Transaction FMS Manager || || +----------------+ +----------------+ || || | 3261 Txn | | PRACK Txn | || || | FSM Hndlr | | FSM Hndlr | || || +----------------+ +----------------+ || |+--------------------------------------------------------------------+| | ^ | | ============|=================================== | | v | |+--------------------------------------------------------------------+| || Transport Layer (UDP/TCP etc.) || |+--------------------------------------------------------------------+| | ^ | | | | | v | |+--------------------------------------------------------------------+| || ABNF Encoder/Decoder || |+--------------------------------------------------------------------+| +----------------------------------------------------------------------+ Figure 3: Framework within SIP Layered Architecture Amit Kaul et al. Expires Sept 13, 2002 [Page 12] Internet Draft FSM Framework for SIP Extensions March 14, 2003 As shown in Figure 3, the SIP implementation following RFC 3261 archi- tecture SHALL have following Framework modules. ¸ Dialog FSM Manager and various Dialog FSM Handlers. ¸ Transaction FSM Manager and various Transaction FSM Handlers. Figure 3 also shows the Trigger Point Interface on the top and the lower edge of each of the Dialog FSM Manger and Transaction FSM Manager. This is to emphasize that the Service Layers like Transport Layer or UA Transaction Core or UA Dialog Core etc. need to communicate with these modules of Framework using a standard Interface. Figure 3 does not show the Trigger Point Interface within the individual Manager blocks because that is implicitly assumed at this point of discussion. The sections below discuss guidelines for design of a SIP system within the proposed Framework. A SIP implementation MAY have following two logical systems. ¸ Transaction FSM Framework ¸ Dialog FSM Framework 3.5.1 Transaction FSM Framework Design Guidelines SIP Transaction Framework comprises of a Transaction FSM Manager and one or more FSM Handlers interacting with each other using Trigger Points, with FSM Manager acting as a routing element. Implementers who want the Transaction model to fit into this Framework SHOULD follow the steps listed below: ¸ Define the low level SIP message flow, possibly comprising of one or more requests or responses that the extension would like to define as a transaction. As per RFC3261, transaction is defined as a group of one request and one or more responses. ¸ After defining the message flow, the implementer creates a mid level state machine which comprises of the core functionality of the extension. This core FSM will be called a 'Sub-Transaction FSM'. ¸ The transitions within the sub-transaction FSM which can affect the RFC 3261 transaction FSM will be tagged, and identified as triggers for the RFC 3261 transaction FSM handler ¸ The transitions within the RFC 3261 transaction FSM handler which can affect the dialog will be tagged, and identified as triggers for the Dialog Manager. RFC 3262 [2] or the reliable provisional response RFC is an example whose implementation within this Framework MAY require use of concepts like sub-transactions. The triggers from the sub-transaction state machine will be fed as input events into the RFC 3261 transaction state machine. This will ensure conformance( Figure 4) The routing of the triggers across FSMs SHALL be taken care by FSM Managers using Trigger Point. Amit Kaul et al. Expires Sept 13, 2002 [Page 13] Internet Draft FSM Framework for SIP Extensions March 14, 2003 Following figure illustrates various relationships that are built between various Transaction Handlers and their Manager. +----------------------------------------------------------------------+ | | |+--------------------------------------------------------------------+| || || || Transaction FSM Manager || || || |+--------------------------------------------------------------------+| | ^ ^ ^ | | | | | | | v v v | |+----------------+ +----------------+ +----------------+| || RFC 3261 Txn | | PRACK Txn | | RFC abc Txn || || FSM Hndlr o--------| FSM Hndlr o--------o FSM Hndlr || || |Conform | | Inter | || |+-------o--------+ -ing +----------------+operable+----------------+| | | | | | +---------------------conforming---------------------+ | | | +----------------------------------------------------------------------+ Figure 4: Transaction FSM Framework 3.5.2 Dialog FSM Framework Design Guidelines SIP Dialog Framework comprises of a Dialog FSM Manager and one or more Dialog FSM Handlers interacting with each other using Trigger Points with FSM Manager acting as a routing element. Implementers of SIP extensions who want their extension fit into this Framework SHOULD follow the steps listed below: ¸ Identify triggers from Transaction Handler for the Dialog Manager. Refer to section 6.5.1 ¸ Design a mid level state machine which comprises of the core functionality of the extension (without any consideration for the dialog). This FSM will be called as a 'Sub-Dialog FSM'. This Sub- Dialog FSM is defined in a way that it gets the triggers from the Transaction State Machine. Tag various transitions in the sub-dialog FSM and identify the triggers for the main dialog state machine. ¸ Define the Dialog state machine, which can accept triggers from sub- dialog state machine or from transaction state machine. The triggers MAY flow from the Transaction FSM Manager to Dialog FSM Manager. This trigger MAY get routed to a sub-dialog FSM. A trigger from sub-dialog FSM MAY be routed to top-level Non-INVITE Dialog FSM by the Dialog FSM manager. Amit Kaul et al. Expires Sept 13, 2002 [Page 14] Internet Draft FSM Framework for SIP Extensions March 14, 2003 Typically, the designer SHOULD have a standard RFC3261 Non-INVITE Dialog state machine to which all the Non-INVITE Sub-Dialog Handlers will feed the triggers. The use of sub-dialog to implement a SIP extension is optional and is left as a design decision for the implementers. As discussed above, for any Non-INVITE dialog state machine, the triggers SHOULD NOT flow from the basic low level Transaction State machine, but from Sub-Dialog State machine which can be different for different extension. The routing of the triggers across FSMs SHALL be taken care by FSM managers using Trigger Point. Following figure illustrates various relationships that are built between various Dialog Handlers and their Manager. +-------------------------------------+ | | +---->| Dialog FSM Manager |<-----+ | | | | | +-------------------------------------+ | | ^ ^ | | | | | v v v Siblings v +-----------+ +------------+ +------------+ +-----------+ | RFC 3261 | | RFC 3265 | | REFER | | xyz | | Dialog FSM|<-.| Dialog FSM | | Dialog FSM |<=>| Dialog FSM| | Handler | | Handler | | Handler | | Handler | +-----------+ +------------+ +------------+ +-----------+ ^ | . | . | . Conforming | . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | . . | Conforming | +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ Legend: -.-. One way relationship <=> Two way relationship <--> Routing of triggers Figure 5: Dialog FSM Framework 3.5.3 Framework Interfaces The following section discusses the interfaces between various modules of the Framework within RFC 3261 layered architecture. Amit Kaul et al. Expires Sept 13, 2002 [Page 15] Internet Draft FSM Framework for SIP Extensions March 14, 2003 3.5.3.1 Dialog Manager and Transaction Manager Peer Interface The Dialog Manager and Transaction Manager Peer interface is used when a trigger is to be routed from a FSM Handler controlled by Transaction Manager to a FSM Handler controlled by a Dialog Manager. An example can be a trigger issued by a INVITE transaction FSM (RFC 3261 Transaction Handler) destined to a RFC 3261 dialog FSM (RFC 3261 Dialog Handler). This is achieved using the Trigger Point Interface and the TP is routed Using: 1. Manager-Id in case the peer entities are FSM Managers 2. Handler-Id, in case the peer entities are FSM Handlers. Refer Section 6.4.1 for more details on Trigger Routing. 3.5.3.2 Interface between a Manager and a Handler This is achieved using Handler-Id in Trigger Point. Refer Section 6.4.1 for more details. 4 Advantages The proposed Framework provides following advantages to SIP implementers. ¸ Provides a scalable framework under which any new extensions can be implemented. ¸ Allows easy implementation of any SIP extension, which might have defined a dialog/transaction different from RFC 3261 definitions. ¸ Keeps the logical meaning of a dialog or a transaction (as defined by RFC 3261) intact. ¸ Provides for standardized interactions between various state machines. 5 Example: Modeling of RFC 3265 FSM using FSM Framework This section uses one scenario from RFC 3265 as an example to explain how a SIP extension can be implemented under this framework. The example details only the control context required for the Framework. The design of the data context is left to implementers of this draft. For this example, it is assumed that the RFC 3261 has been implemented under the proposed framework. RFC 3261 Implementation under the proposed framework, would have following framework modules. ¸ RFC 3261 Transaction Handler ¸ RFC 3261 Dialog Handler ¸ SIP Dialog Manager ¸ SIP Transaction Manager Scenario being considered in this example is basic Subscription and Dialog establishment scenario as per RFC3265. This example is valid for a subscriber and assumes that the initial exchange of SUBSCRIBE and Amit Kaul et al. Expires Sept 13, 2002 [Page 16] Internet Draft FSM Framework for SIP Extensions March 14, 2003 200 response has already taken place. When the NOTIFY message is received at the Subscriber which has 'Subscription State' value as 'Active', this message shall be converted into appropriate trigger by the Service Layer and fed into the FSM Framework. In a typical implementation, Handler Id MAY be obtained using the FSM Schema information and the data context information. This is not shown in the Figure 6. As illustrated in the Figure 6, following steps briefly outline the procedures for this scenario: 1. Registration of FSM Handlers with their respective FSM Managers. (S1, S2, S3). This process happens before any trigger comes in or out of the framework. 2. Receipt of NFY_RCV trigger from Service Layer (S4). 3. Routing of Trigger Point between Transaction Manager and 3261 Transaction Handler (S5, S6). As shown in the diagram, Transaction Handler along with the process- ing in Data Context of an implementation encapsulates and sends new Trigger-Point NFY_ACTV to be routed to the Dialog Manager (Mgr-Id=2) via its Transaction Manager (Mgr-Id =1). This trigger represents the fact that NOTIFY message was identified containing the subscription state as 'active'. Also, since the 3261 Transaction Handler won't be knowing the Dialog Handler-Id which will eventually get this trigger, hence the the Target Handler-Id is blank. 4. Routing of Trigger Point from Transaction Manager to Dialog Manager (S7). Once the Transaction Manager gets the Trigger from 3261 Transaction Handler, it will consult the Schema Information and fill-in the Dialog Handler-Id, before sending it to the Dialog Manager. 5. Routing of Trigger Point between Dialog Manager and 3265 Dialog Handler (S8, S9). The trigger Id is changed to SUBSC_ACTV, meaning that the subscrip- tion has become active. Since, RFC3265 Dialog Handler won't know the Handler-Id of RFC3261 Dialog Handler, the trigger point is routed back to the controlling Dialog Manager with empty Handler-Id. 6. Routing of Trigger Point between Dialog Manager and 3261 Dialog Handler (S10). Dialog Manager consults the schema information and fills in the correct handler-Id in the trigger-point before routing it to the RFC3261 Handler. This trigger will eventually go into the Non-Invite Dialog FSM and create a dialog. Amit Kaul et al. Expires Sept 13, 2002 [Page 17] Internet Draft FSM Framework for SIP Extensions March 14, 2003 3261 Trans Trans Dlg 3265 Dlg 3261 Dlg Hndlr(H=1) Mgr(M=1) Mgr(M=2) Hndlr(H=2) Hndlr(H=3) | | | | | | | | (S2)Regis. | | | | | Process | | | | | {H=2,M=2) | | | (S1)Regis | |<------------| | | Process | | | | | {H=1,M=1} | | | (S3)Regis. | |------------->| | | Process | | | | | {H=3,M=2) | (S4)TP: | | |<-----------------------------| T=NFY_RCV| | | | | H=?;M=1 | | | | | ----------------------->| | | | | | | | | | (S5)TP: | | | | | {T=NFY_RCV | | | | | H=1;M=1} | | | | |<-------------| | | | | | | | | | (S6)TP: | | | | | {T=NFY_ACTV | | | | | H=?;M=2} | | | | |------------->| | | | | |(S7)TP: | | | | |{T=NFY_ACTV | | | |H=2;M=2} | | | | |-------->| | | | | | (S8) TP: | | | | | {T=NFY_ACTV | | | | | H=2;M=2} | | | | |------------>| | | | | (S9) TP: | | | | | {T=SUBSC_ACTV | | | | H=?, M=2} | | | | |<------------| | | | | (S10)TP: | | | | | {T=DLG_ACTV | | | | H=3, M2} | | | |----------------------------->| | | | | Legend ====== H : Handler-Id M : Manager-Id T : Trigger-Id TP: Trigger-Point S : Step Figure 6: FSM Framework Example Amit Kaul et al. Expires Sept 13, 2002 [Page 18] Internet Draft FSM Framework for SIP Extensions March 14, 2003 6 Security Considerations This draft addresses general requirements for the integration of various Finite State Machines as identified in the RFCs and Internet Drafts of SIP domain. Specific security requirements, if any, SHALL have to be addressed by the implementation dependent features. 7 References Normative References [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.Peterson, R. Sparks, M. Handley and E. Schooler: "SIP: Session Initiation Protocol", Request for Comments 3261, Internet Engineering Task Force, June 2002. [2] J. Rosenberg and H. Schulzrinne: 'Reliability of Provisional Responses in the Session Initiation Protocol (SIP)', Request for Comments 3262, Internet Engineering Task Force, June 2002. [3] AB Roach: 'Session Initiation Protocol (SIP)-Specific Event Notification', Request for Comments 3265, Internet Engineering Task Force, June 2002. Non-normative References [4] R. Sparks: 'The SIP Refer Method draft-ietf-sip-refer-07', Internet Draft, Internet Engineering Task Force, November 2002 8 Authors Addresses Amit Kaul Intel Corporation, 5th Floor, Creator Building, International Technology Park Limited, Whitefield Road, Bangalore 560 066, India e-mail: amit.kaul@intel.com Nitesh Varshney Intel Corporation, 5th Floor, Creator Building, International Technology Park Limited, Whitefield Road, Bangalore 560 066, India e-mail: nitesh.amit@intel.com Ravi kumar Koyyana Intel Corporation, 5th Floor, Creator Building, International Technology Park Limited, Whitefield Road, Bangalore 560 066, India e-mail: ravi.koyanna@intel.com Amit Kaul et al. Expires Sept 13, 2002 [Page 19] Internet Draft FSM Framework for SIP Extensions March 14, 2003 Samaga Prasanna Krishna Intel Corporation, 5th Floor, Creator Building, International Technology Park Limited, Whitefield Road, Bangalore 560 066, India e-mail: samaga.krishna@intel.com Udaya Shankara Intel Corporation, 5th Floor, Creator Building, International Technology Park Limited, Whitefield Road, Bangalore 560 066, India e-mail: udaya.shankara@intel.com Vivek Jaiswal Intel Corporation, 5th Floor, Creator Building, International Technology Park Limited, Whitefield Road, Bangalore 560 066, India e-mail: vivek.jaiswal@intel.com Amit Kaul et al. Expires Sept 13, 2002 [Page 20]