Network Working Group S.Cadzow Internet Draft C3L/ETSI Document: draft-tiphon-background-00.txt P. Mart Category: Informational Marconi Communications P.Sijben Lucent Technologies July 2000 TIPHON architecture background Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [5]. 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The background and objectives of the new ETSI project Tiphon architecture are described in this draft. The architecture is shown to be capable of use by a number of different signalling systems and session control protocols, including SIP and H.323. The opportunity exists for the IETF to help with the technology mappings for SIP to ensure inter-operation with other technologies through the TIPHON architecture. 2. Conventions used in this document SCN - Switched Circuit network. 3. Introduction to TIPHON For many observers TIPHON has been viewed as a Voice over Internet Protocol (VoIP) project. This is not wholly true. TIPHON has historically had two functions: 1. Standardisation of VoIP 2. Standardisation of VoIP interconnection and inter-working with existing SCNs Cadzow, Mart, Sijben Expires 1 February 2001 1 TIPHON backgrounder July 2000 TIPHON started in May 1997 with the scope to standardise the interworking between traditional PSTN/ISDN/GSM networks with H.323- based Voice over IP. Since then, the project has grown and has been refocused. The TIPHON project has moved into its current state largely by stealth. Unfortunately stealth does not lend itself to getting broad understanding. This paper attempts to bring context to the work of TIPHON and to try and put the new TIPHON architecture in focus. More details of the architecture can be found in a companion draft [1]. 3.1 TIPHON scope TIPHON concluded that H.323-based VoIP networks could not deliver the IP telephony service on a par with feature rich existing networks. This made defining interworking between these two networks a daunting task. Rather than suspending the project until VoIP technology was mature enough, the TIPHON membership decided to start helping to mature the technology so that the interworking could be defined. TIPHON's scope is to interwork with all existing switched networks. This means that TIPHON can not focus on one set of technologies to interwork. So TIPHON isn't Voice over IP (VoIP) although it addresses this topic. It isn't voice over ISDN or voice over GSM or voice over ATM. TIPHON is about voice over networks. Importantly it is about harmonisation of all voice over network technologies. This is shown in figure 1 where TIPHON acts as the convergence point for all Voice over Network technologies (only a selection is shown). +-----------------------------+--------------------------------+ + + + + + + + VoTETRA + + + + VoIP + + + + + +-------------+-------------+ + + + + + + + + + +---------------+ TIPHON +------------------+ + + + + + + + + + +---------------------------+ + + + + + + + + VoPSTN + VoISDN + + + + + + + + + + +-----------------------------+--------------------------------+ Figure 1: TIPHON as convergence technology for VoN Cadzow, Mart, Sijben Expires 1 February 2001 2 TIPHON backgrounder July 2000 Most attempts to forge new telephone technologies have been founded on a single service: 3.1kHz telephony support. With the possible exceptions of DECT and TETRA all new base technologies in telephony have done little more than support narrow-band voice. The other major aim of networks pre-TIPHON has been to maintain reachability and connectivity. TIPHON concluded that H.323-based VoIP networks could not deliver the IP telephony service on a par with feature rich existing networks. This made defining interworking between these two networks a daunting task. Rather than suspending the project until VoIP technology was mature enough, the TIPHON membership decided to start helping to mature the technology so that the interworking could be defined. 3.2 TIPHON today Today, the objective of Project TIPHON is the specification of interoperability mechanisms and related parameters to enable multimedia communications to take place, to a defined quality of service, between switched circuit networks (SCN) and Internet Protocol (IP) based networks and their associated terminal equipment. The work is based on the following set of scenarios: 0. IP terminal to IP terminal 1. IP Terminal to an PSTN, ISDN or cellular terminal 2. PSTN, ISDN or cellular terminal to an IP terminal 3. PSTN, ISDN or cellular terminal to an PSTN, ISDN or cellular terminal, with the transit portion provided by an IP network 4. IP terminal to an IP terminal, with the transit portion provided over the ISDN 4 Introduction to TIPHON architecture TIPHON needed a well defined architecture to support its broad range of scenarios and technologies. Such an architecture has been defined in the last twelve months. This new TIPHON architecture was intended to support the deployment of commercial voice services over generic IP transport networks. A number of business constraints determine the architectural decisions made in the project. TIPHON's architecture was not intended to be constrained to a particular market or technology niche and has to take into account the freedoms of private network use as well as the constraints of Public Networks. This sets TIPHON apart from many other forums that focus on a particular application, business model or technology. Cadzow, Mart, Sijben Expires 1 February 2001 3 TIPHON backgrounder July 2000 4.1 Constraints The TIPHON deliverables should cater to vendors and operators for the purpose of commercial (multimedia) telephony service. This posed a number of constraints on its work: - The services provided by networks using TIPHON specifications are for sale in the same market as Public Telephony. For a number of possible operators it is important to show how costs are built up even if the users are never billed on a per use basis. This means that, in the limit, it is possible to account and charge customers for resources used or for the period for which communication is possible. Many options for charging need to be supported. - There is a need to establish media flows with predictable or known Quality of Service. The use of best effort only conveyance is not suited to many customer expectations that were established with non IP networks. - In general, operators have a duty to keep information about customers and their communications confidential. This means that steps are needed to minimise to ability of other parties to intercept or eavesdrop on communications. - There are requirements to provide identification and location services to the Public Telephone Network. Today, these are often based on Calling Line Identification. Such information is invaluable in enabling the Emergency Services to despatch vehicles in an appropriate way and this capability needs to be retained on IP networks. - Operators are, of course, carrying information that may otherwise have been conveyed on the Public Telephone Network and the same obligations to assist Law Enforcement agencies are expected to apply. This is because the basis of regulation is independent of technology. - Each service provider can have its own policies on addressing and protocol choices, Quality of Service mechanisms and access control. The services offered, as well as the type of customer that is targeted, usually drive these choices. This choice is at the discretion of the service provider operating the network! - The need to ensure privacy means that the traditional assumption that addresses should have end to end meaning across global networks, such as the Internet, need not be valid. - Service Providers often consider their deployment details a strategic issue and want to keep them secret from competitors. This leads to a reduced use of automatic discovery techniques when compared to the Internet as a whole. Cadzow, Mart, Sijben Expires 1 February 2001 4 TIPHON backgrounder July 2000 The combination of all of these constraints led to an architecture that is unlike either the traditional switched networks or the Internet. It attempts to address its challenges in a unique combination of the two. 4. Why a functional architecture? In the earlier stages of project Tiphon there was an over emphasis on one set of implementation choice, namely H.323, and in profiling it for use to interconnect with the PSTN, ISDN and GSM. This was closely focussed on the original aims of the project. As the project progressed it became clear that the competing work of other standards bodies was progressing at an enormous rate and often had different objectives. The work of other bodies was often focussed on specific kinds of implementation and this lead to heated debate on what should be open interfaces and what should not. We often stumbled on differing interpretations of the functions performed by a given device in various bodies. The debate over the function split between a Media Gateway Controller and a Gateway and the relationship with a Gatekeeper started the requirements capture process for Megaco. The work at this stage seemed to be focussed on particular implementation or "boxes". These "boxes" were being targeted at particular signalling systems, which were the real instruments of competition. The battles between SIP, H.323, MGCP and the rest embodied the problem space. It seemed that there had to be a better way than expecting one signalling system to win so that interoperation could be obtained. Focus moved to a more generic functional architecture which could allow the main combatant protocols to inter-work at a basic level without compromising their ability to offer novel features. The project generated a new Functional Architecture to allow the abstract specification of service capabilities in a protocol independent manner. This allows service capabilities to inter-work, where that best serves the market and the public interest. The degree to which services are to be made standard is minimal. The goal is to specify the framework for simple calls and the most important issues of inter-working of services. This will not usually extend to the specification of complete services. A complete architecture of this kind should allow SIP, H.323 and other specialist systems to inter-work in a global network. The objective is to promote competition whilst ensuring that the expectations of inter-operation, which the public associate with the public network, are met. The architecture must also meet the constraints of privacy, accountability and the legal obligations described above. Cadzow, Mart, Sijben Expires 1 February 2001 5 TIPHON backgrounder July 2000 5. Architecture design principles A number of principles have been used in the architecture, three are key: - Protocol independence, side-stepping protocol wars of-the-day and enabling interworking - separation of concerns into independent planes - orthogonality of the reference points through functional layers and domain separations. 5.1 Protocol independence The TIPHON architecture is defined in protocol independent information flows. These flows can be mapped to (implemented using) applicable protocols. The flows guarantee that the TIPHON architects can address the issues that need addressing first can be bothered with quirks of certain implementations later. Naturally, this process has not been performed in total isolation. During the definition of the information flows, protocol specifications of H.323, SIP, and ISUP have been consulted for sanity checks and to verify that the architecture would not place impossible demands on likely implementations. 5.2 Planes TIPHON separates the telephony application specific parts from generic (IP) transport issues. Figure 2, below shows this. +----------------------------------------------------------------+ + + + TIPHON Application plane + + + + + +---------------------------------+------------------------------+ /|\ / | \ | | \ | / \|/ +------------------------------+----------------------------+ + + + Network Service Plane + + + +-----------------------------------------------------------+ Figure 2. Separation of application and transport This split is significant for two main reasons: 1. Other applications need to use the same network infrastructure. This implies that the functionality in the TIPHON Application plane must not be generic for the transport of other applications, i.e. QoS transport mechanisms do not belong there. Cadzow, Mart, Sijben Expires 1 February 2001 6 TIPHON backgrounder July 2000 The transport plane on the other hand must not contain functionality specific for one application. i.e. media quality negotiation does not belong here. 2. Other service providers need to use the same transport network. This implies that the interface between the application and the transport may be the interface between two companies (i.e. transport user and transport provider), and other companies may have the same relationship (multiple transport users per transport provider and multiple providers per transport user). Each instance of the application-transport interface may be associated with its own contract and commercial relationship. 5.3 Domains A commercial deployment of any telecommunication service sees multiple domains or networks. The picture presented in Figure 3 offers a simplified view in which a terminal accesses TIPHON services through an access network, and that TIPHON service completes the service by combining the capabilities of a number of access and transit networks through a network service layer. +--------+ +---------+ +---------+ +---------+ +--------+ + + + + + + + + + + + Access + + Transit + + Transit + + Transit + + Access + + Network+--+ Network +--+ Network +--+ Network +--+ Network+ + 1 + + 1 + + 2 + + 3 + + 2 + + + + + + + + + + + +--------+ +---------+ +---------+ +---------+ +--------+ Figure 3: Architecture to provide TIPHON services TIPHON has to be able to differentiate the entity offering service from the one offering connectivity. In its earliest guise IP was conceived of as an example of an abstract network layer (i.e. to communicate between networks the actual network type did not need to be known, only its IP capability). A consequence of this separation is that protocols are not end to end in nature whilst information flows are end to end and generally symmetrical. Likewise, multiple domains may be associated with the registration of a user with a domain with which the user has a contractual relationship. Figure 4 shows the network types that may inter- operate during the registration of a user. One such domain is called an IP Telephony Network (IPTN). +---------+ +---------------+ +--------+ | Serving | | Intermediate | | Home | | IPTN |-------| IPTN |-------| IPTN | | | | | | | +---------+ +---------------+ +--------+ Figure 4. TIPHON generic network registration model. Cadzow, Mart, Sijben Expires 1 February 2001 7 TIPHON backgrounder July 2000 The Home IPTN is the principal place where the user information is stored. The Home IPTN provides the functions required for registration and for subscriber related operations. The Serving IPTN provides the function required to register the user and to forward the registration towards the Home IPTN. The Intermediate IPTN provides the functions required to connect the Serving IPTN and the Home IPTN during the registration. The intermediate IPTN is only present when the Serving IPTN and the Home IPTN are not directly connected. An IPTN may act as both the Serving IPTN and the Home IPTN. 5.4 Functional layers Each of the co-operating networks is treated as containing layers in which functional entities reside. It is these functional entities that provide the functionality of the network. Each domain is taken to have a similar set of functional elements although in each domain the functional elements may have different properties, protocols and other implementation specifics. The functional entities co-operate by exchanging information flows to provide simple calls and service capabilities. In the TIPHON documentation the information flows are described as a set of primitives with parameters (information elements) which are exchanged across reference points. Implementation of the TIPHON architecture means mapping the flows into signalling systems or protocols. This requires the primitives to be expressed as protocol messages and parameters. As a consequence a reference point may convey a set of information flows which are implemented using more than one protocol. Reference points in TIPHON are not described in terms of protocol. It is this separation between information flow and protocol that allows protocol independence. The implementation of information flows will be different for each protocol. Clearly the number protocol message needed to implement the information flows need not be equal to the number of primitives in the flows. The manner in which information elements are combined together, and with maintenance or error control information, to form protocol messages is a matter for the designers of each protocol. Each protocol implementation of the information flows must take account of transmission reliability, maintenance and security issues. Cadzow, Mart, Sijben Expires 1 February 2001 8 TIPHON backgrounder July 2000 6. TIPHON, a capable network environment TIPHON is best described as a capable network environment. It offers capabilities that serve to support the capabilities of terminals whilst at the same time ensuring that the needs of business are met. The latter really means the ability to sell and re-sell network side capabilities, to sell and re-sell terminals, and to ultimately generate revenues. It is not true to say that TIPHON is a network nor is it true to say that TIPHON is a system. It is an environment. This environment goes beyond IP but is in many ways a candidate for a new generation of inter-working networks that uses the best of IP and the best of OSI. It does that by simplifying the knowledge required of the lower layers (extending IP), and by making the upper layers less obscure (simplification of OSI). Figure 4 shows the non-network, non-system, conclusion can be arrived at. There is more than one network involved, and not all have to be there. +----------+ +---------+ +---------+ | a|------------|a A|-------------|A | | IP b|------------|b IP B|- -|G IP | | c|-\ /|f C|-\---------/-|C | | d| \ -----|e D| \ ---/--|E | +----------+ \ \ / / +---------+\ \ / / +---------+ \ \/ / \ \/ / \/\ / \ /\ / /\ \/ X \ / \/\ / \/ \ / /\ \ / /\ \ +----------+/ / \ \ +---------+/ / \ \ +---------+ | e| / ----|d E| / ---\--|D | | SCN f|--/ \-|c SCN F|-/---------\-|F SCN | | f|------------|f G|- -|B | | h|------------|h H|-------------|H | +----------+ +---------+ +---------+ Figure 4: The TIPHON interconnect architecture The architecture of TIPHON has been developed to reflect this and is broadly abstracted: Call control is catered for; Terminal and user registration is catered for; and, Reachability is catered for. The unique capabilities of different access networks are catered for within this abstraction. At its most basic the abstraction offers a simple data structure that determines the Quality of Service from a bearer network. This data element is called the Quality of Service Bearer Descriptor (QoSBD). Cadzow, Mart, Sijben Expires 1 February 2001 9 TIPHON backgrounder July 2000 There are a number of core documents in TIPHON used to describe different aspects of TIPHON. These address for example the use of H.323 terminals and the capabilities of such terminals in a TIPHON environment. 7. Protocol dependent issues The common features of the architecture are documented as information flows. Each protocol, which inter-works using the architecture, is an implementation of the information flows. The semantics of the information elements must pass transparently or with well understood mappings between the protocol implementations. Tiphon considers BICC, SIP and H.323 as some of the technologies that need to be profiled and mapped into the information flows. Clearly the flow of ideas needs to be bi-directional with the design of SIP and other technologies taking TIPHON into account as well as TIPHON mapping the already specified parts of SIP etc. Any protocol suite that can implement the information flows for Tiphon simple call and the service capabilities can inter-work successfully within the Tiphon architecture. In particular co- operation in establishing the technology mappings of relevance to the IETF, such as SIP, would be beneficial to both communities. The protocol requirements extend beyond session establishment to QoS, NAT control and traffic policing as well as privacy and interception matters. Each mapping of the architecture to a given technology will be subject to a threat analysis to ensure that the new weaknesses are not added. 8. Conclusion TIPHON provides an architecture supporting the convergence of network technologies under an umbrella of common service that gives assured inter-working. This permits end-to-end working over heterogeneous transport networks using the TIPHON specifications. The new TIPHON architecture allows clear separation of network and service provider roles and provides a structured approach to service provision, system design and analysis, and allows flexible business models. TIPHON has approached (after much debate) network technologies and network architectures as intrinsically abstract. This has been realised as an architecture showing capabilities of functional entities and the information flows between them across well defined relationships. This has many similarities to the Stage 2 of the ITU I.130/I.210 approach but with re-thinking. In order to define abstract networks TIPHON has reviewed the method for definition and it is proposed that this abstract method be adopted by developers of access networks for future enhancements (currently available as work item TIPHON-01007 [2]). Cadzow, Mart, Sijben Expires 1 February 2001 10 TIPHON backgrounder July 2000 The development of TIPHON that makes it independent of the specific capabilities of networks is in the development of service capability definitions that lead to the specifications of service capabilities (in turn themselves as either network or user/terminal capabilities). The capabilities are defined as visible at particular points of reference. Through its structured approach the architecture provides solutions for current issues like IP telephony in the presence of firewalls and IN interworking. The reference points, their flows and behaviours are defined in [3]. The QoS signalling companion document is defined in [4]. These documents are available for public download through the URLs given. 9. Security Considerations The architecture for simple call has been augmented by changes for Quality of service. The functional elements needed for Lawful Interception will be added and a full threat analysis performed. The results of that analysis will then be used to improve the architecture. As the flows are mapped onto particular technologies and protocols there will be further threat analysis work since each protocol can introduce new issues. 9. References [1] draft-tiphon-architecture-00.txt [2] TIPHON-DTR01007 http://docbox.etsi.org/Tech-Org/TIPHON/Document/ tiphon/07-drafts/wg1/DTR01007/ [3] TIPHON DTS02003 http://docbox.etsi.org/Tech-Org/TIPHON/Document/ tiphon/07-drafts/wg2/DTS02003/ version 0.10.8 and higher [4] TIPHON DTS05003 http://docbox.etsi.org/Tech-Org/TIPHON/Document/ tiphon/07-drafts/wg5/DTS05003/ version 0.7.0 and higher [5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 10. Acknowledgments Scott Cadzow is presently a support technologist to the TIPHON project and his contribution was funded by ETSI. 11. Author's Addresses Scott Cadzow C3L/ETSI 10 Yewlands Sawbridgeworth United Kingdom Email: scott@cadzow.com Cadzow, Mart, Sijben Expires 1 February 2001 11 TIPHON backgrounder July 2000 Philip Mart Marconi Communications Ltd. Edge Lane Liverpool United Kingdom Email: philip.mart@marconi.com Paul Sijben Lucent Technologies Huizen Netherlands Email: sijben@lucent.com Cadzow, Mart, Sijben Expires 1 February 2001 12