Subject: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETF Paris)

From: "Fullbrook Kim \(UK\)" <[email-masked]>
Date: Fri, 08 Jul 2005 04:32:29 -0400

Would agree with previous definitions of User ENUM. On to my definition of carrier enum. 

First a bit of background. In most countries of the world where there are multiple mobile operators it is possible to keep your E.164 number when you move your service to a different mobile operator. In a smaller number of countries it is possible to do the same when moving between fixed line operators. This is called Number Portability. Before NP was introduced you could figure out the end operator who provided service to a number purely by analysing the digits in the number. When NP is introduced you can no longer do this.

The primary purpose of Carrier ENUM is to solve the number portability problem. Given an E.164 number, which operator provides connectivity to that number for the desired service (strictly: for the desired enumservice) ? Of course ENUM relates an E.164 number to a URI so there is other information available in the URI such as the protocol needed and there may possibly be other optional information as well.

For privacy reasons this information needs to be restricted to carriers and not made available to end users - except transparently when they make a call.

The call obviously needs to be routed to the destination network and may actually be routed via several intermediate carriers. For example if I make a circuit-switched call from my mobile on the O2 network in the UK to Mr Y in China, there is no direct peering between O2 and any Chinese network. We would route the call to one of our International carriers who may forward it to another International carrier (and maybe forwarded again), before reaching the local Chinese carrier of Mr Y.  Once we know the end destination of the call we figure out which of our carriers is the "next hop" and forward the call. They then forward it as appropriate. This is how the circuit-switched world works today. The same model will inevitably be followed for IMS's SIP-based calls because direct peering is not realistic on a global telco scale.

Peering and routing information between carriers is nothing to do with ENUM at all. There is definitely a need for this information somewhere but it is not ENUM.  Discussion about "Carrier ENUM" tends to include peering and routing information because of the need for privacy at a carrier level but this is a separate (although related) subject. Perhaps we need to introduce a term "Carrier DNS" for non-ENUM related information held in a DNS ?  Alternative terms could be "Carrier Routing" and/or "Carrier Peering".

Kim Fullbrook
O2 UK

-----Original Message-----

=====================================================
This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.
=====================================================

From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Stastny Richard
Sent: 07 July 2005 22:44
To: Patrik Fältström; Livingood, Jason
Cc: enum at ietf.org; Richard Shockey
Subject: Re: [Enum] Agenda items for IETF Paris

Hi all,
 
>For example, I know Stasny have said several times "this is not ENUM" 
>and personally, I do agree with him. But, to be able to have that 
>discussion, we first need the meta-discussion... 
 
I agree that there seems to be a discussion necessary
 
to clarify this, as I tried to state in the definitions I posted:
 
The purpose of User ENUM is for mapping end-user URIs to E.164 numbers.
basically a service for end-users. The basic requirement for end-users
is to find other end.users. The second requirement is that orig end-user
must be able to reach the destination user, because the Internet is
end-to-end. User ENUM is conformant to the Internet principles
 
The purpose of Carrier ENUM is to help carriers finding peering partners
using E.164 numbers to map to URIs, basically find the destination networks
from an origination network. The basic requirement for carriers is to find other 
carriers. Here it is NOT required that every carrier must be able to reach any
other carrier, this is depandant on peering agreements.
 
These two implementations are orthogonal and independant.
 
If there is an efficient way to use the same nfrastructure for these
differnt purposes, fine.
 
IMHO the VoIP peering requirements necessary to do so are out of scope 
of ENUM WG. I leave it to the discussion if they are within the scope of the IETF.
On the other hand, many IETF protocols are used on IP-based networks separated
from the Internet (e.g. SIP within 3GPP).

-richard

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Fri, 08 Jul 2005 10:44:46 -0400

At 04:32 AM 7/8/2005, Fullbrook Kim \(UK\) wrote:
Would agree with previous definitions of User ENUM. On to my definition of 
carrier enum.

First a bit of background. In most countries of the world where there are 
multiple mobile operators it is possible to keep your E.164 number when 
you move your service to a different mobile operator. In a smaller number 
of countries it is possible to do the same when moving between fixed line 
operators. This is called Number Portability. Before NP was introduced you 
could figure out the end operator who provided service to a number purely 
by analysing the digits in the number. When NP is introduced you can no 
longer do this.

The primary purpose of Carrier ENUM is to solve the number portability 
problem.
Hummm .. there are some other solutions to the number portability problem 
... :-)

Given an E.164 number, which operator provides connectivity to that number 
for the desired service (strictly: for the desired enumservice) ? Of 
course ENUM relates an E.164 number to a URI so there is other information 
available in the URI such as the protocol needed and there may possibly be 
other optional information as well.

For privacy reasons this information needs to be restricted to carriers 
and not made available to end users - except transparently when they make 
a call.
So to requirements .. To answer Patrik's call ...there is a requirement 
among service providers for some form of database technology that, based on 
a E164 number, can provide information on how to route a service to a point 
of carrier interconnection or ALG as expressed as a URI. For privacy 
reasons this information needs to be restricted to service providers and 
not generally available to end users.

Peering and routing information between carriers is nothing to do with 
ENUM at all. There is definitely a need for this information somewhere but 
it is not ENUM.  Discussion about "Carrier ENUM" tends to include peering 
and routing information because of the need for privacy at a carrier level 
but this is a separate (although related) subject. Perhaps we need to 
introduce a term "Carrier DNS" for non-ENUM related information held in a 
DNS ?  Alternative terms could be "Carrier Routing" and/or "Carrier Peering".
Kim you've made a excellent point which is that all of this discussion 
tends to be wrapped up in the term ENUM.  Carrier DNS might be a clean term 
and nicely expresses the desire or requirement for a database technology, 
based on the DNS "technology" of 3761 for service providers to exchange 
various forms of information necessary for service delivery. Carrier DNS 
technology might be used in e164.arpa but could also be used in other 
domains that may or may not be globally visible to the general Internet.

Now that begs the question ..could SIP redirect be used to satisfy this 
requirement? I personally doubt it since SIP redirect is not a globally 
distributed database. Could SIP redirect be used to distribute routing 
information both internally to a domain as well as among a group of private 
service peers ..certainly ..but then you run into the scale problems.

Could LDAP work .. very very doubtful the client is too heavy and LDAP is 
not X.500 ..and some of you long timers might remember that in the early 
early days of the WG..yes X.500 was discussed but it was the desire of the 
IESG that the ENUM WG focus only on DNS solutions and that other proposals 
would require a separate WG.

Kim Fullbrook
O2 UK
-

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 08 Jul 2005 11:03:32 -0400

> not generally available to end users.

Good. We got to the meat of the interconnect and partial info release world
that drives real-world telco (and real-world managed IP, too, in the US
fragment of the net, for that matter).

> domains that may or may not be globally visible to the general Internet.

Good. Now we have a statement that inter-provider interconnect arrangement
apply to DNS, in any naming tree, like all other shared infrastructures.
 
> would require a separate WG.

X.500 was profiled in IETF for multi-provider routing in email addressing
and handling; it was a well-addressed topic, in 1990s IETF WGs, with a full
panoply of technical specs, and requirements docs. It was a total waste of
time, as we eventually discovered that the IAB of the day had NO intention
of ever allowing it to be deployed, and was secretly politiking against it
all along. It facilitated and rationalized international interconnects
between and amongst providers doing value-add: precisely what some saw as
abhorrent to the Internet way of doing things.

Now we have spam for everyone, at the lowest quality of email service
possible.

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 08 Jul 2005 12:49:05 -0400

On Jul 8, 2005, at 16:44, Richard Shockey wrote:
...there is a requirement among service providers for some form of  
database technology that, based on a E164 number, can provide  
information on how to route a service to a point of carrier  
interconnection or ALG as expressed as a URI.
Ok, this is for me one requirement. Sorry for maybe not being clear.
For privacy reasons this information needs to be restricted to  
service providers and not generally available to end users.
Is the requirement that this information (the mapping from E.164 to  
URI) is only to be visible for the party that need to know, or "any  
service provider being part of the same club"?

   paf
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________
enum mailing list
enum at ietf.org

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 08 Jul 2005 12:51:56 -0400

On Jul 8, 2005, at 17:03, Peter Williams wrote:
X.500 was profiled in IETF for multi-provider routing in email  
addressing
and handling; it was a well-addressed topic, in 1990s IETF WGs,  
with a full
panoply of technical specs, and requirements docs. It was a total  
waste of
time, as we eventually discovered that the IAB of the day had NO  
intention
of ever allowing it to be deployed, and was secretly politiking  
against it
all along.
Peter, as co-chair of this wg, I have to ask you to please stop  
repeating your view of the history. Part from not helping this wg  
moving forward, your memory does not match other people's memory of  
what the issues where surrounding X.500.

Please concentrate on what problem we try to solve *NOW*, and let us  
know what you think is needed for ENUM.

   Patrik
   co-chair of the ENUM wg
Attachment:
PGP.sig

---

From: Richard Shockey <[email-masked]>
Date: Fri, 08 Jul 2005 13:08:05 -0400

At 12:48 PM 7/8/2005, Patrik Fältström wrote:

On Jul 8, 2005, at 16:44, Richard Shockey wrote:
...there is a requirement among service providers for some form of
database technology that, based on a E164 number, can provide
information on how to route a service to a point of carrier
interconnection or ALG as expressed as a URI.
Ok, this is for me one requirement. Sorry for maybe not being clear.
For privacy reasons this information needs to be restricted to
service providers and not generally available to end users.
Is the requirement that this information (the mapping from E.164 to
URI) is only to be visible for the party that need to know, or "any
service provider being part of the same club"?
oh fine distinction can you elaborate a bit ?...what is the difference been 
'party that needs to know' or 'service provider being part of the same 
club' .. what is the distinction?

as some here might postulate the exposure of the URI of the ALG may or may 
not be visible to A. all parties as in the use of .carrier.e164.arpa B. 
just visible to the club as in 3GPP.NET or e164MSO.ORG and the visibility 
of the ALG URI does not necessarily imply a formal peering agreement 
between party A and party B.

What the egress ALG does once it gets in INVITE is a matter between 
consenting capitalists.

Does that help?

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 08 Jul 2005 15:42:50 -0400

On Jul 8, 2005, at 19:06, Richard Shockey wrote:
Is the requirement that this information (the mapping from E.164 to
URI) is only to be visible for the party that need to know, or "any
service provider being part of the same club"?
oh fine distinction can you elaborate a bit ?...what is the  
difference been 'party that needs to know' or 'service provider  
being part of the same club' .. what is the distinction?

In the first case, the only parties that see the URI are the ones  
that will be able to make a call via that ingress point, while in the  
2nd case the ingress point might be announced also to parties that  
can not use it, but still not to everyone on the Internet.

   paf
Attachment:
PGP.sig

---

From: Richard Shockey <[email-masked]>
Date: Fri, 08 Jul 2005 17:05:52 -0400

At 03:42 PM 7/8/2005, Patrik Fältström wrote:

On Jul 8, 2005, at 19:06, Richard Shockey wrote:
Is the requirement that this information (the mapping from E.164 to
URI) is only to be visible for the party that need to know, or "any
service provider being part of the same club"?
oh fine distinction can you elaborate a bit ?...what is the
difference been 'party that needs to know' or 'service provider
being part of the same club' .. what is the distinction?
In the first case, the only parties that see the URI are the ones
that will be able to make a call via that ingress point, while in the
2nd case the ingress point might be announced also to parties that
can not use it, but still not to everyone on the Internet.
ah .. I have heard both scenerios
As I understand the various proposals both cases you describe usually 
assumes a non visible private domain..the issue is how peering policy is 
applied and where.

If the domain is globally visible then the URI usually describes a ALR/SBC 
where ingress policy is applied.