Emergency Services Interconnection Forum (ESIF) Emergency Services Messaging Interface Task Force ( Task Force 34 )

Transcription

1 Emergency Services Interconnection Forum (ESIF) Emergency Services Messaging Interface Task Force ( Task Force 34 ) Contribution Title: Implementing ESMI with SIP and ESTP Contribution Number: Submission Date: October 20, 2004 Source: Intrado Inc. Technical Contact(s): Abstract: Name: Brian Dupras Phone: bdupras@intrado.com This submission is in response to a call for contribution by the chairperson of ESIF Task Force 34 in regards to possible implementation strategies for ESMI. This paper presents a method of implementing ESMI using a simple TCP/IP connection model. In this proposal, ESMI application messages are exchanged via Emergency Services Transfer Protocol (ESTP) using connections negotiated by Session Initiation Protocol (SIP). Recommendation: Post as informative contribution related to discussion of possible strategies for implementing ESMI.

2 Executive Summary The ESIF ESMI Task Force is currently reviewing proposed requirements that detail the functional characteristics of the Emergency Services Messaging Interface (ESMI). These requirements describe various layers of internetworking which will become proposed standards through the ESIF ESMI Task Force. The end product of the standards process is a definition of a complete communications stack, including: 1. A set of recognized endpoints such as CESE and Response Gateway 2. Accepted dialogs or interactions between endpoints 3. ESMI Application Messages (EAM) - individual business messages, their semantics and syntax, that are the building blocks of the dialogs 4. A security strategy including authentication and data privacy 5. A framework for discovering interfaces, managing connections and participating in dialogs 6. Networking protocol(s) to marshal messages between endpoints (roughly equivalent to layer 7 in the OSI Reference Model) 7. A transport protocol, which is widely assumed to be an Internet Protocol (IP) suite (roughly equivalent to layers 3-5 in the OSI Reference Model) Definitions EAM ESTP SIP SOAP ESMI Application Messages, the set of all business messages exchanged which provide the operative portions of the CESE / ESNet relationship. Emergency Services Transfer Protocol, a TCP/IP protocol designed to frame ESMI Application Messages (EAM). ESTP provides the framing necessary to carry EAM over a transport connection. The syntax of ESTP is based on RFC 822. (HTTP, SMTP and SIP use similar syntax). Session Initiation Protocol, a connection negotiation protocol. Its primary purpose is to assist two endpoints in establishing an application session. Simple Object Access Protocol. SOAP is a key protocol in web services which provides message enveloping in a standard XML format. WSDL Web Services Description Language, an XML schema which is used to define the properties of web services (such as a SOAP service). UDDI Universal Description, Discovery and Integration, an online registry of services, typically listing WSDL documents so web service clients can locate and attach to specific instances of web services.

3 Scope Network Stack This document presents a new protocol, ESTP, designed specifically to meet all the needs of the ESMI requirements when used in combination with SIP. The topics detailed in this document cover the networking portion of the communications stack items 4, 5 and 6 listed above a security framework, service discovery, connection management and message marshalling. Network Stack Requirements Overview The technologies chosen to implement the communications stack must meet the requirements of the ESMI endpoints and dialogs, as it is the endpoints and dialogs that define and codify business of emergency service. Additionally, the complexity of implementation and support must be weighed against the functionality provided. The network stack must be extensible to allow the introduction of new services [ESMI.Exten ] without impacting existing services. The ESNet must be able to monitor the communications capabilities of the CESE both at the messaging level [ESMI.Avail ] and at the connection level [ESMI.Protocol ]. Additionally, the protocol must enable intelligent use of computing and network resources [ESMI.Protocol , , , , ]. The standard must provide for a secure environment including strong authentication and data privacy [Section ]. It is erroneous to rely on the non-public nature of an ESNet to provide adequate security. The ESNet environment is open to multiple business entities to make connections and to offer or subscribe to services. It is not feasible to rely on the collective practices of all participants to provide a secure ESNet environment. According to the ESMI networking requirements, the CESE must be the IP client and the ESNet must be the IP server [ESMI.Network ]. It is undesirable for PSAPs to operate IP socket servers, as this necessitates a number of infrastructure and security elements that are not necessary for IP clients. Such elements include published listening points, DNS servers, firewalls, intrusion detection, authentication, authorization, etc.

4 Emergency Services Transfer Protocol (ESTP) + SIP Introduction The EAM messages defined by ESMI require a method of exchange between CESEs and the ESNet. It is not sufficient to state that TCP/IP will be used to exchange the messages since TCP/IP is a stream oriented protocol and as such doesn t provide the constructs necessary to define a message within the stream. Emergency Services Transfer Protocol (ESTP) provides this generic messaging framework. The syntax of ESTP is based on RFC 822, which is the same RFC from which HTTP, SMTP, and SIP derive their syntax. ESTP strongly resembles HTTP, but with different connection semantics. The diagram below depicts the role provided by ESTP within the ESMI communications stack. In the OSI Model, ESTP operates at layer 7. ESTP is a connection-oriented protocol designed to meet the specific needs of the interface between the CESE and ESNet. In an ESMI implementation, CESEs use SIP to negotiate EAM sessions over ESTP connections to the ESNet. Session Initiation Protocol (SIP), often associated with VoIP but useful for data connections, is an IP protocol designed primarily to negotiate connections for other protocols. A peer in a SIP enabled network, called a user agent (UA), INVITEs another peer to begin a media session. The media session is an application exchange defined by the peers. The combination of SIP, ESTP and EAM makes a potent combination that addresses all of the connection and message flow requirements of ESMI. Design Attributes Figure 1 This diagram depicts ESMI as broken down into EAM, ESTP, SIP and related protocols in a complete communications stack implementation. ESTP and SIP provide critical features which support the requirements of ESMI. Since ESTP is designed specifically to support ESMI, its attributes directly meet the requirements of the message dialogs. It is not necessary to use workarounds or other less than optimal strategies to achieve a complete ESMI implementation. Much like HTTP, EAM message bodies are framed by ESTP headers to implement the overall ESMI protocol.

5 Connection Management SIP provides service discovery and resolution are for ESMI. The CESE sends a SIP INVITE, addressed to a service s logical Address of Record (AOR), which is resolved by DNS, to the ESNet which is responsible for directing the INVITE to an appropriate system. For instance, a CESE sends an INVITE to sips:rg@esnetprovider.com for an ESMI application (EAM) session using ESTP over SSL. The response from the ESNet SIP Proxy contains a detailed endpoint address along with parameters to connect to an instance of a Response Gateway. Client / Server Relationship ESTP allows the CESE to be an IP client and the ESNet to be the IP server as required by ESMI [ESMI.Network ]. This is important to the implementation of ESMI, as socket clients require far fewer security constraints to operate in a secure environment than socket servers. ESTP connections are initiated by the CESE as a result of SIP negotiation. At the application level, the EAM is a bidirectional message exchange. Some EAM messages originate at the CESE (e.g. emergency event messages), and others originate at the ESNet (e.g. notification messages). ESTP directly supports the bidirectional nature of EAM [ESMI.Protocol ] over a single TCP/IP connection. The connection oriented nature of ESTP allows the CESE to maintain a single messaging connection to the ESNet [ESMI.Protocol , ] which can be periodically rolled over to exercise all connection paths over time [ESMI.Protocol ] and to aid in load balancing for ESNet resources [ESMI.Protocol ]. Monitoring ESNet monitoring of the CESE is accomplished both via messaging (i.e. heartbeats) [ESMI.Avail ] as well as connection monitoring [ESMI.Protocol ]. Monitoring the CESE connection allows the ESNet to respond more quickly and accurately to a communication path failure than it could by heartbeat intervals alone. Security SIP includes standard methods for strong authentication of users [ESMI.SEC ] via Digest for secure password authentication [ESMI.SEC ] or S/MIME for digital certificate authentication (RFC3261 [3]). Strategic Direction By using SIP as a core supporting technology for the ESMI, the ESNet environment becomes strategically positioned to implement VoIP technologies in the future [ESMI.Exten ].

6 Web Services Comparison Web Services (SOAP) is attractive due to its position as an Internet standard. Many third party products exist which support SOAP and related protocols. In combination with Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI), SOAP provides a rich mechanism for deploying and advertising services in a network. However there are layers in the communications stack that SOAP does not address which must also be specified for the standard to be complete if SOAP is chosen to implement ESMI. Figure 2 This diagram depicts ESMI as broken down into EAM, SOAP, WSDL, UDDI and related protocols. The communications stack is incomplete without choosing a transmission protocol for SOAP such as HTTP. Additionally, SOAP is unidirectional in nature. To fully support EAM with its bidirectional nature, workarounds to the unidirectional model of SOAP must be employed. One such workaround may be to deploy both SOAP clients and servers on each side of the ESMI relationship. This greatly increases the complexity of the CESE, creating a more costly deployment solution. The benefits gained from SOAP s internet standard status are lost in the complexity of such an implementation. According to the ESMI networking requirements, the CESE must be the IP client and the ESNet must be the IP server [ESMI.Network ]. It is undesirable for PSAPs to operate IP socket servers, as this necessitates a number of costly infrastructure and security elements that are not necessary for IP clients. Such elements include published listening points, DNS servers, firewalls, intrusion detection, authentication, authorization, etc.

7 Conclusion Prior to choosing a network stack standard to implement the ESMI, the ESIF ESMI Task Force must take into consideration the technology s ability to meet ESMI s requirements (e.g. message flows like ALI and Notification messages; security and data privacy; monitoring and alarming). To be complete, the standard produced by ESIF Task Force 34 must specify every layer in the network and communications stack. It is not enough, for instance, to standardize only on a set of messages, or only on SOAP or ESTP as this will not necessarily lead to interoperable products between vendors. The combination of TCP/IP, SSL, SIP, ESTP and EAM provides a complete ESMI communications stack that can be standardized by ESIF and implemented by any IP enabled environment. ESTP/SIP Pros and Cons Pro: Optimized for the ESMI application Pro: Bidirectional support enables ESMI s asynchronous messaging requirements Pro: Connection oriented, which reduces the security overhead of establishing connections Pro: ESTP/SIP are less complicated than SOAP/WSDL/UDDI Pro: SIP is expected to be a technology present at the PSAP of the future Pro: Stack components are open standards or based on standards that are widely deployed and adopted Con: Not a current standard Web Services Pros and Cons Pro: Rich service description and discovery support Pro: Established internet standard for business transactions Pro: 3 rd party servers and client libraries exist Con: Unidirectional, requiring a workaround for ESMI s bidirectional messaging Con: Workarounds increase infrastructure costs at the PSAP Con: The Internet community is still evolving the standards (e.g. WS-Eventing) Note: TF34 must still specify a layer 7 protocol to carry SOAP messages

8 References [1] Fargano, Mike, et al. Emergency Services Messaging Interface, Section 6. Stage 1 Emergency Services Messaging Interface Requirements [Draft]. Submitted to ESIF ESMI Task Force. [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June [3] Crocker, D., "Standard for The Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.