A Bulding Block Approach to Standardization

For decades, the telecommunications industry has standardized solutions from A to Z, with little if any reuse of existing specifications when creating new ones. The progressive migration from circuit switched to IP based services did not initially change this fact much: MMS or OMA IMPS (that I take as an example in this post) are typical examples of creating telco-specific standards based on a loose reuse of IETF ones (SMTP for MMS, HTTP for OMA IMPS).

This has changed with IMS, and more especially its SIP component. 3GPP and the IETF collaborate with each other, and needed extensions to the SIP protocol due to IMS requirements are under the control of the IETF.

By importing IETF specifications into telecom standards, 3GPP implicitly accepted the building block approach to specifications that is common place in the Internet domain. In this post I will try to describe this approach and its benefits.

Building block standardization of SIP

SIP is a textbook example of a building block approach to standardization. The people and groups in charge of specifying SIP constantly try to apply the following rules:
- Do not reinvent the wheel. Reuse and adapt existing specifications if they fulfill your requirements. Only create when needed.

- Make everything as generic as possible. Even if your requirements are very precise, try to make your solution generic enough to be reused for other requirements.

Here follow some examples of how this was applied to SIP standardization:

- SIP sessions make use of the Session Description Protocol (SDP), which was specified prior to SIP. In effect, it is possible to use SDP without SIP.

- SIP SUBSCRIBE and NOTIFY methods were initially created to support a very specific requirement, actually related to the telecom domain (the support of the telephony Automatic Call Back service with SIP). However, it was decided to make the concept a generic and extensible means to distribute event notifications in a SIP network through event packages (see the first draft for SUBSCRIBE/NOTIFY here). When a part of the IETF community decided to support presence through SIP, they simply had to reuse the event package specification and create two presence-specific event packages. While the requirement was initially very specific, it gave birth to a concept that is fundamental for SIP and constantly evolving through the creation of new event packages. It is actually remarkable that this is a telephony -related requirement that led to a SIP concept which opens the door to a large variety of non-telephony related applications of the protocol.

- In the Instant Messaging (IM) area, presence was initially no more than a single state, describing if a recipient could accept an IM. The IETF decision to support presence through the inclusion of an XML document in the body of SIP methods, and allowing extensions to the basic schema, permitted the definition of presence to be gradually extended to become a large set of information about users (or services), their communication means, terminals and applications.

- SIP PUBLISH was initially created specifically for a client to remotely update presence information. The first versions of the draft were tightly linked to the presence event package and made impossible the reuse of PUBLISH in different contexts (see the very first draft here). However, the IETF community rapidly ensured the possibility to reuse PUBLISH for all existing and future event packages. PUBLISH therefore contributed to the enrichment of SIP-based presence, but at the same time a requirement initially scoped to presence contributed to the enrichment of the whole SIP protocol.

- Instant Messaging through SIP was initially supported only through the creation of a new SIP method: MESSAGE. However, it rapidly emerged that this approach was far from optimal to support all potential requirements associated to instant messaging: the concept of chat, which embeds IMs in a specific dialog context, the need to potentially exchange large documents via IM (e.g. a video file) while SIP is a control protocol and not a transport one like HTTP, or the need to support potentially high IM traffic while a SIP infrastructure might not have been implemented with this purpose in mind. It took time and several tries for the IETF community to address these requirements, and the final decision was to reuse the concept of SIP session as well as another protocol to transport an IM within the session. As a protocol like HTTP was not optimal to support the requirements for this IM transport protocol, it was decided to specify a new one called MSRP. This decision makes the comparison between Jabber/XMPP and SIP to support IM very biased. Maybe Jabber/XMPP is a better protocol than SIP for IM. However, Jabber/XMPP was initially specified and optimized for it, making its extension for, say VoIP, far from straightforward. On the other hand, in a SIP context, IM can be perceived as one communication component among others in a multimedia session.

OMA IMPS vs. IETF Presence and IM

The vertical standardization mindset that still prevailed a few years ago in the telecom community can be illustrated with OMA IMPS (initially called Wireless Village), a mobile specification to support instant messaging, chat rooms and presence.

Instead of reusing IM and presence related protocols available in the Internet, the Wireless Village group decided to specify a client to server protocol and a server to server protocol that would be specific to the mobile telecom domain, just reusing HTTP as a semantic-less transport protocol for OMA IMPS commands.

The group also decided to define IM, chat rooms and presence as tightly coupled together from a protocol and an architecture perspective, and to tightly link presence information to the mobile context.

In order to support its requirements, the Wireless Village group had to define various kinds of user lists (or groups) serving different purposes. Instead of creating a generic user group concept, they decided that each group fulfilling a specific purpose was a distinct object. Consequently, each group object led to a set of specific commands in the protocol, for creating/deleting the group, adding/removing elements to it, etc. With such an approach, if you define, say 4 types of user groups and 6 management commands, you end up with 24 distinct commands in the protocol.

In comparison, to address similar objectives, the IETF decided to decouple various concerns.

While presence is a concept originated in an IM context, the IETF decoupled one from the other, permitting each to evolve independently, thus permitting presence to apply to a much broader scope than simply IM.

By reusing the SIP session concept for session-based IM, the IETF permitted both the implementation of IM-specific systems, and multimedia systems using IM as one component among others in a SIP session.

The approach to address user groups and associated management, specified in RFCs related to XCAP, followed this approach:

- A user group is a user group, no matter what it is used for. The same user group can serve different purposes, and the set of applications for user groups is not arbitrarily bounded.

- A user group is user data, and there might be other user data that require similar access and management. No need to specialize access and management methods to user groups.

Consequently, XCAP is an HTTP-based protocol defining a few data management methods. The data itself is specified in XML, and there exist specifications for these data being user groups. As one of the requirements associated to data management was to be able to notify a user about changes made to data, the IETF decided to use a SIP event package. In effect, the IETF specifications for user data management include the joint usage of XCAP and SIP.

Building block standardization approach in IMS

The building block mindset to specifications has spread to IMS and non IMS standardization into 3GPP.

For instance, despite a terminology which is heavily related to SIP sessions (e.g. CSCF - Call Session Control Function), the IMS core network can be seen as a SIP connectivity network able to route SIP signaling, whether it is session-related or not, within an IMS domain, across IMS domains, and between IMS and non-IMS SIP domains.

In this context, IMS Presence, Messaging, and Chat Rooms are implemented as independent applications on top of the IMS core network and that make use of it. Once again, the comparison with OMA IMPS is quite interesting:

- OMA IMPS specifications lead to an implementation based on a network of IMPS servers over the mobile IP network. An IMS implementation relies on deploying application servers on top of an IMS core network. The IMS core network directly supports some of the requirements that are supported vertically in the OMA IMPS specifications (and implementations), like user authentication or routing and interfacing between various operators' OMA IMPS networks.

- OMA IMPS specifications tightly link the concepts of IM, presence and user groups. On the other hand, IMS specifications treat each of them as independent enablers which can be used together or in different contexts.

- OMA IMPS specifications were totally under the control of the Wireless Village group, and then OMA. On the other hand, by reusing IETF specifications, IMS specifications directly benefit from the evolutions performed in the IETF community, including some originating from people and companies which do not belong in the telecom or IMS domains.

A quite similar comparison can be applied to MMS and the equivalent support through IMS messaging.

Another interesting example is the 3GPP Generic User Profile specification, which permits to provide a centralized and homogeneous access to user data actually residing in various locations (e.g. HLR, HSS, AuC, application servers) and normally accessed through a variety of protocols (e.g. MAP, Diameter, LDAP). At the beginning of the erratic standardization process for GUP, 3GPP intended to standrdize a specific GUP protocol as well as a specific GUP schema to describe user data. Later on, it was decided to align on the specifications for Liberty Alliance, which define web services permitting 3rd party service providers to access user data owned by the network operator. As a consequence, GUP can be used directly as the means to access user data in network databases to support the Liberty Alliance web services exposed to 3rd parties.

The GUP specifications were also made generic enough to clearly distinguish between the methods used to access and manage user data and the data itself, that needs to be specified by instantiating and extending the generic GUP schema. On the other hand, the GUP specifications also include a SOAP-based user data modification notification mechanism, which duplicates what SIP event packages can and do support for XCAP. However, one can argue that the usage scope of GUP is broader than IMS and cannot rely on a protocol that 3GPP only uses in the context of IMS.

Some advantages associated to building block standardization

Reusing existing specifications instead of defining them from scratch permits to speed up the standardization process.

A protocol component or an application performing a generic task can be implemented once and reused several times, leading to faster development and validation.

In some cases, building blocks can be re-arranged with others to create new solutions. I gave the example of session-based messaging which, by applying the concept of SIP session to instant messaging, permits to integrate IM as one component among others in a multimedia SIP session.

Christophe

Does IMS Create a New Walled Garden?

Definitly no!

IMS was made from the begining to permit end-to-end SIP signalling between IMS and non-IMS endpoints, and if the non-IMS endpoint does not support SIP, the IMS service architecture permits an easy integration of protocol gateways.

Wikipedia defines a walled garden as follows: A walled garden, with regards to media content, refers to a closed set or exclusive set of information services provided for users (a method of creating a monopoly or securing an information system). This is in contrast to providing consumers access to the open Internet for content and e-commerce.

I have seen in surveys that many operators believe that IMS will permit them to create a new walled garden, and they like the idea very much, even defining it as one of the main advantages of IMS.

But this is not the case, and in this post I will try to clarify some points related to this, as well as give examples of how 3GPP always intended to keep IMS open to non-IMS networks, and more especially the Internet.

I think that creating new walled gardens is not a strategy that will be sustainable for operators in the years to come. Concerning IMS, I believe that the extent of its eventual success will be proportional to the traffic generated between it and the Internet. An IMS with very low traffic to and from the Internet would be an IMS which has failed to deliver any added value to end-users, who would bypass it to directly access services in the Internet. On the other hand, high traffic would means that IMS is integrally part of the place where everything happens.

3GPP IETF Dependencies List

3GPP maintains a long list of dependencies on IETF specifications. Some may interpret it as the sign that IMS is full of telco-specific extensions to the IETF protocols it uses (mainly SIP and Diameter).

This would be totally wrong. 3GPP essentially reuses specifications elaborated within the IETF space. Moreover, more often than not, IMS has been an essential driver to improve and extend SIP-related specifications in the IETF. Without the push from the whole telco industry, I doubt the IETF SIP community would be as dynamic as it is.

The reason for this list is that it is essential for 3GPP specifications to be based on stable RFCs, and not drafts that have an expiration time and may once simply disappear. The list permits 3GPP to clearly identify the IETF drafts that are of importance for IMS, and to speed up their progress towards RFC status.

IMS Proprietary SIP Extensions

In the course of standardizing the IMS core network, 3GPP created new SIP headers, and submitted them for endorsement to the IETF.

Some extensions were accepted, as they were deemed to be useful to all types of SIP implementations. Others, related to e.g. user authentication, QoS, or charging were harder to swallow and led to very harsh discussions. Most of these extensions are directly related to the fact that, unlike the Internet, IMS is a network of privately owned networks, whose usage is supposed to involve money exchanges.

Between 3GPP, which wanted to have IETF RFCs for all IMS SIP extensions, and IETF hardliners, the following compromise was found: the questionable IMS SIP extensions would be specified in IETF RFCs, but they would have a specific "proprietary" status, meaning that their usage is not recommended for general SIP usage. These headers are easy to recognize, as their name starts with "P-".

These P- headers do not threaten end-to-end interworking with non-IMS clients:

- Many of them are used between IMS network entities, and are invisible to IMS or SIP endpoints

- Some might be visible to non-IMS endpoints, but the endpoint does not absolutely need to understand them

- Gateways between IMS and the Internet may perform relevant SIP adaptations, if needed.

IMS specifications explicitly support session setup with non IMS endpoints

In order to offer a user experience that matches the one in a circuit switched network for a voice or video session, IMS adopted a session setup model which is more complex than the basic IETF SIP one. This extended session set up is also possible in the Internet, as it does not make use of any 3GPP-specific extension, but it is only optional and may not be supported by all SIP clients.

3GPP then started a study to address the issue of interworking between IMS-compliant clients and clients that would not support the optional features required by IMS session setup. This resulted in the requirement specified in chapter 5.4.2 of TS 23.228 named "Interworking with Internet" that an IMS client (or a user agent in the network acting on its behalf) must be able to fall back to basic SIP session setup procedures, if the peer cannot support the IMS-required extensions.

IMS Communication Services

In the course of its Release 7, 3GPP defined the concept of "communication service". I will not describe it here, but it is enough to say that some of the requirements associated to Communication Services could possibly lead to the creation of IMS walled garden services.

In order to avert this risk, the following requirements were added to the concept:

- The usage of communication service identifiers shall not adversely affect interoperability between IMS networks and interoperability with external SIP networks and CS networks

- The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.

All IMS enablers rely on IETF specifications, and can be implemented in the Internet

This might need to be emphasized.

There is not such a thing as an IMS-specific presence, IMS-specific conferencing or IMS-specific messaging. These enablers and services are implemented in IMS with a specific service architecture, but the protocol(s) and data model(s) used are standard IETF ones.

A small issue is that, thanks to OMA or 3GPP, some IMS services may be associated with explicit OMA or 3GPP names (feature tags) transported in SIP signalling. For instance, IMS messaging as currently specified in OMA makes use of an OMA specific feature tag. This might require some simple SIP adaptation between IMS and non-IMS networks, or the understanding of IMS-specific feature tags by non-IMS client, but this is a minor thing. In any case, I hope that the industry will eventually realize that these OMA/3GPP names should not even exist.

Simple Addition of Protocol / Domain Gateways to IMS

The IMS service architecture makes very simple to deploy protocol converters and gateways, without the need for any specific standardization. Any SIP message originated from or addressed to a user can be routed to such a protocol converter/gateway through the user's service profile provisioned in the HSS. The message can then be routed to any domain using any protocol. Conversely, these converters/gateways can generate IMS-compliant signalling from anything they receive.

It is even possible for an IMS client to use non-SIP user addresses in its SIP messages. For instance, John may issue a SIP/IMS Instant Message towards Mary, whose IM service is not based on SIP and whose IM address is not a SIP or TEL URI. The IMS client could address the IM to e.g., foo:Mary. The address is not routable in an IMS network but this is not an issue. John's request is first routed to an IMS S-CSCF serving John. The S-CSCF then checks John's service profile. The important thing is that the network still not has checked if foo:Mary was an IMS-valid address. John's service profile may define that a request addressed to a user with an addressing scheme "foo:" should be routed to an IM gateway, which will take care of the rest. This is only after, if no gateway was accessed through John's service profile, that the S-CSCF would look into recipient's address, realize that there is a problem, and would therefore reject it.

Christophe

A Classification of IMS Critics, Part 2

I see three more groups of people generally expressing reservations, if not more, against IMS.

#2 The non-IMS VoIP Suppliers

Telco suppliers which initially decided to implement VoIP using a non-IMS technology (e.g. H.323, Softswitch architecture, IETF SIP architecture) more and more face pressing questions from existing or potential customers about IMS compliance.

While some of them have plans to evolve towards IMS, others do not and need to find a way to get away with this strategy.

An approach for them is to relativize the existence of IMS as a coherent standard. They start to tell their customers about the existence of multiple "IMS flavors", and with a little bit of imagination their own solution can be considered as one of these IMS flavors.

Another approach is simply to attack IMS, this standardization monster, far too complex and expensive for VoIP.

And actually they have a point here. I am not sure that IMS brings a lot of value for money if an operator only intends to use it for VoIP. IMS starts to be valuable if you want to use it as a framework for multiple services, including but not limited to voice.

On the other hand, the non-IMS VoIP solutions are usually optimized to support voice, and will have great difficulties to evolve and support much more than that.

#3 IETF SIP People

IETF SIP people tend to think that IMS betrays the original spirit of SIP, defined in the IETF as an end-to-end protocol localizing intelligence and control at the edges of the network. IMS specifications are full of operator control mechanisms and tend to shift the intelligence balance from the edges to the network. IMS pushed for a set of SIP extensions that deal with charging, bundling of signalling and QoS, control of user identities from the network... a whole set of hair rising ideas when you believe into the free for all Internet.

Critics coming from IETF SIP people are the most interesting, as their vision of a SIP world is what the IMS application layer must aim at in order to be innovative and competitive.

On the other hand, my criticism to them is that they are shooting at the wrong target. Their attacks are more aimed at the classical telco mindset and what this mindset might be tempted to do with IMS, than the IMS technology as such. Used with the right attitude, IMS does not have too be so bad, and there might even be some valuable concepts in it that improve on the IETF ones.

To be frank, IETF people have excuses. You just have to rapidly browse through an IMS specification and an IETF RFC to see that there is a huge cultural gap between the two communities. I can understand that for IETF people, reading an IMS specification is just good to go to sleep. Moreover, it is true that some companies in 3GPP or TISPAN sometimes push very strange ideas, which definitely betray the SIP philosophy. However, these ideas rarely fly, even within the 3GPP community, which is generally very IETF-minded.

#4 Opportunists

Any hype calls for kill-the-hype people, and so did the IMS hype.

Anti-IMS opportunists rely on the belief that it is too late to avert the telco decline, and they consider IMS as the last pitiful gasp of the industry. They ride on the "Internet is cool, Telco is shit" wave, that a lot of people in the industry are deeply convinced of.

They use any good or bad argument to support their point, but usually very bad ones. Why would they take the time to read technical documents or speak with technicians when their role is to capture deeper philosophical problems?

A risk is that by repeating over and over to an already tormented industry that it cannot think "modern" and "right", these people actually deliver self-fulfilling prophecies.

Christophe