Wednesday, May 24, 2006
Spring VON Europe - ENUM Now? and what ENUM?
I know this is a bit late, but I still owe you a report from the ENUM Now? panel I moderated. I opened up with a short presentation setting the scene. Here a more detailed explanation:
User ENUM as defined in RFC 3761 and to be used in e164.arpa is around quite a long time already. The up-take is quite slow, although there are already over 40 countries delegated in e164.arpa. But only two countries have noteworthy commercial operations (Austria and Germany), a few others are soon to come. Most countries are still in different stages of trials, stuck into legal, regulatory, privacy and validation discussions, thwarted by the existing PSTN operators (not only the incumbents), other countries seem even to have no idea yet what to do with ENUM.
How long can you trial that the DNS works? Of course this is not the real reason. Nowadays in any new development all concerns have to be taken into account up-front and solved, including world-hunger. And if the trial is nearing the end, it is very easy to raise another concern. Existing commercial implementations are of course suffering from Metcalfe's law. If GSM would have been introduced in this way, we would still have trials only, not to mention the Internet itself.
Country opt-in and especially end-user opt-in seems not to be the best idea (yet). So in the mean-time ETSI TISPAN started to investigate Infrastructure ENUM. The basic idea of Infrastucture ENUM was to provide a separate tree for service provider opt-in, without user opt-in and country opt-in.
This approach had three serious draw-backs:
But in the meantime more and more providers got the idea that peering via IP networks for VoIP applications has some advantages. And since E.164 numbers are still the main vehicle for public user identities (and not SIP URIs), some kind of mapping is necessary. So there was a requirement and a market for ENUM technologies and service providers looked around and started to joined private clubs enabling them to peer (or interconnect) via IP.
These ENUMs have many names (carrier, operator, enterprise, etc. ENUM). The generic term now is Private ENUM. Companies started to offer such "services" in the public Internet, some with restricted access and also within private networks. For more information see here.
These implementations work fine (showing also that no more ENUM trials are needed), but they all have a serious drawback: you may only reach the E.164 numbers hosted by the members of the club. This can be quite a large number, e.g. if one considers GSMA, but nevertheless. To reach other numbers, you may either use again the PSTN, which reduces service availability and QoS and requires transit charges per minute, or a provider needs to participate in quite a number of such ENUM trees.
One solution to this problem could be to provide a globally accessible Ueber-ENUM tree e.g. Infrastructure ENUM in ie164.arpa.
In the second half of 2005 IETF finally got the message, gave up the resistance and re-chartered the ENUM WG to deal also with Infrastructure ENUM issues. In the meantime and after some discussions a (stable) requirements draft exists and also a proposal for an RFC to create a parallel Infrastructure ENUM tree in ie164.arpa. There exists in addition a proposal for temporary national solutions to be implemented immediately during the time the negotiations with IESG, IAB, RIPE and ITU-T may take, but still keep a linkage with e164.arpa. Some trials are already in preparation and I will report here about their progress.
How comes the ITU-T into play?
As mentioned above, the ETSI TISPAN idea failed because a global service provider club defining the policy and also having the responsibilty for the root of a common Infrastructure ENUM tree simply cannot be established at all, or at least in a reasonable timeframe.
So the second choice was to involve the ITU-T and the national regulators again and go down a parallel path as was done with RFC3761 and e164.arpa. The draw-back for service providers is that again a country opt-in is required. It is also up to the national regulators to define what the rules are for service providers to be able to opt-in. That is to define what a "Carrier-of-Records" is within the given country code.
So we may be back again in future from Private ENUM to Infrastructure ENUM. Infrastructure ENUM has to potential, together with the work of the IETF WG SPEERMINT to provide a global framework for IP-based peering or IP Interconnection for real-time and multi-media communictions, helping to migrate finally all communications from the PSTN to IP. Infrastructure ENUM is also the ultimate number portability solution, allowing a global all call query (ACQ) for any E.164 number.
Are we going a full circle? So what about User ENUM?
If Infrastructure ENUM is implemented by the service providers, is there still room for User ENUM?
Yes.
Infrastructure ENUM will be the default routing used by service providers to provide basic connectivity for all their end-users (no end-user opt-in) based mainly on SIP.
User ENUM will not be used by all end-users, it still is opt-in, but it will be used by power-users on the Internet and especially by enterprises to provide them with an overlay network. User ENUM allows additional applications (basically any application locatable via an URI) to be linked to E.164 numbers. One type of power users are the communities now emerging on the Internet. At the last two IETF meeting a number of new innovative Enumservices where proposed and I expect more to come.
So User ENUM is not dead and may be revived soon.
I think I got carried away a bit.
And what about the ENUM now panel? - see next post ;-)
User ENUM as defined in RFC 3761 and to be used in e164.arpa is around quite a long time already. The up-take is quite slow, although there are already over 40 countries delegated in e164.arpa. But only two countries have noteworthy commercial operations (Austria and Germany), a few others are soon to come. Most countries are still in different stages of trials, stuck into legal, regulatory, privacy and validation discussions, thwarted by the existing PSTN operators (not only the incumbents), other countries seem even to have no idea yet what to do with ENUM.
How long can you trial that the DNS works? Of course this is not the real reason. Nowadays in any new development all concerns have to be taken into account up-front and solved, including world-hunger. And if the trial is nearing the end, it is very easy to raise another concern. Existing commercial implementations are of course suffering from Metcalfe's law. If GSM would have been introduced in this way, we would still have trials only, not to mention the Internet itself.
Country opt-in and especially end-user opt-in seems not to be the best idea (yet). So in the mean-time ETSI TISPAN started to investigate Infrastructure ENUM. The basic idea of Infrastucture ENUM was to provide a separate tree for service provider opt-in, without user opt-in and country opt-in.
This approach had three serious draw-backs:
- first, all service providers need to agree on ONE common tree and
- second, to be globally available, the tree need to be public
- and last, but not least, to be reachable via the public Internet and also via ENUM, service providers need to provide their users with SIP URIs.
But in the meantime more and more providers got the idea that peering via IP networks for VoIP applications has some advantages. And since E.164 numbers are still the main vehicle for public user identities (and not SIP URIs), some kind of mapping is necessary. So there was a requirement and a market for ENUM technologies and service providers looked around and started to joined private clubs enabling them to peer (or interconnect) via IP.
These ENUMs have many names (carrier, operator, enterprise, etc. ENUM). The generic term now is Private ENUM. Companies started to offer such "services" in the public Internet, some with restricted access and also within private networks. For more information see here.
These implementations work fine (showing also that no more ENUM trials are needed), but they all have a serious drawback: you may only reach the E.164 numbers hosted by the members of the club. This can be quite a large number, e.g. if one considers GSMA, but nevertheless. To reach other numbers, you may either use again the PSTN, which reduces service availability and QoS and requires transit charges per minute, or a provider needs to participate in quite a number of such ENUM trees.
One solution to this problem could be to provide a globally accessible Ueber-ENUM tree e.g. Infrastructure ENUM in ie164.arpa.
In the second half of 2005 IETF finally got the message, gave up the resistance and re-chartered the ENUM WG to deal also with Infrastructure ENUM issues. In the meantime and after some discussions a (stable) requirements draft exists and also a proposal for an RFC to create a parallel Infrastructure ENUM tree in ie164.arpa. There exists in addition a proposal for temporary national solutions to be implemented immediately during the time the negotiations with IESG, IAB, RIPE and ITU-T may take, but still keep a linkage with e164.arpa. Some trials are already in preparation and I will report here about their progress.
How comes the ITU-T into play?
As mentioned above, the ETSI TISPAN idea failed because a global service provider club defining the policy and also having the responsibilty for the root of a common Infrastructure ENUM tree simply cannot be established at all, or at least in a reasonable timeframe.
So the second choice was to involve the ITU-T and the national regulators again and go down a parallel path as was done with RFC3761 and e164.arpa. The draw-back for service providers is that again a country opt-in is required. It is also up to the national regulators to define what the rules are for service providers to be able to opt-in. That is to define what a "Carrier-of-Records" is within the given country code.
So we may be back again in future from Private ENUM to Infrastructure ENUM. Infrastructure ENUM has to potential, together with the work of the IETF WG SPEERMINT to provide a global framework for IP-based peering or IP Interconnection for real-time and multi-media communictions, helping to migrate finally all communications from the PSTN to IP. Infrastructure ENUM is also the ultimate number portability solution, allowing a global all call query (ACQ) for any E.164 number.
Are we going a full circle? So what about User ENUM?
If Infrastructure ENUM is implemented by the service providers, is there still room for User ENUM?
Yes.
Infrastructure ENUM will be the default routing used by service providers to provide basic connectivity for all their end-users (no end-user opt-in) based mainly on SIP.
User ENUM will not be used by all end-users, it still is opt-in, but it will be used by power-users on the Internet and especially by enterprises to provide them with an overlay network. User ENUM allows additional applications (basically any application locatable via an URI) to be linked to E.164 numbers. One type of power users are the communities now emerging on the Internet. At the last two IETF meeting a number of new innovative Enumservices where proposed and I expect more to come.
So User ENUM is not dead and may be revived soon.
I think I got carried away a bit.
And what about the ENUM now panel? - see next post ;-)
Comments:
Post a Comment
