Subject: RE: GLP, number portability and wireless subscribers

From: Matt Squire <[email-masked]>
Date: Tue, 09 Mar 1999 17:02:29 -0500

At 04:34 PM 3/9/99 -0500, David R. Oran wrote:
>Or, alternatively, project all numbers into a global, unambiguous space.
>This seems cleaner and much less error prone than topologically
>established scope boundaries, and less administratively burdensome than
>solving the problem of scope name collisions and information propagation
>boundaries. It also avoids having to talk about translations between
>scopes, which I'm sure will happen when the other shoe drops :-).
>

I'm a little confused by this comment. To me, scopes provide the
unambiguous global number space.  If there is a scope registration
authority (maybe this wasn't clear before), then the combination of
scope+number is globally unambiguous, with the default scope being global
e164.  If someone registers a scope and they wish it to have topological
significance, then that's an administrative matter and they should be able
to set up their peer association and policy accordingly.  

I'd probably be against scopes of the form "+1-405" because that would just
lead to too many headaches in interpreting, aggregating, etc.   

An opaque scope using a equal/!equal test might provide what we desire.  I
haven't convinced myself completely, but I think it has the potential.

- Matt

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Mar 1999 18:45:18 -0500

Hussein F. Salama wrote:
> 
> Christian Huitema wrote:
> >
> > Well, it seems that we are back again to the distinction between naming
> > and routing. With GLP, the phone number in the E164 space is really an
> > alias to a "local" phone number.  Basically, the translation is:
> >
> > a) use the number to obtain the id of the local provider,
> >
> > b) route to the local provider
> >
> 
> But there may be multiple local providers (multiple egress gateways
> owned by different providers) servicing the same number. Therefore, I
> think we should route to the destination number. Then local provider
> selection will automatically occur as part of route selection, and it
> can still be controlled by injecting appropriate policy at the various
> GLP speakers.

You took the words right out of my mouth (well, keyboard perhaps).

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------

---

From: "Hussein F. Salama" <[email-masked]>
Date: Thu, 11 Mar 1999 15:39:41 -0800

Hussein

PS: Am I the only person receiving old, and out-of-order messages from
IPTEL?

> c) within the local provider, route to the user based on the number.
> 
> This means that we will have a two phase look-up:
> 
> a) maybe using DNS:
>         look up number, get provider ID.
> b) within GLP:
>         maintain routes based on provider ID, and maybe also prefix.
> 
> --
> Christian Huitema
> ------------------------------
> Please note my new address: [email-masked]
> http://www.telcordia.com/

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

---------

---

From: Richard Shockey <[email-masked]>
Date: Fri, 12 Mar 1999 15:28:20 -0600

>	look up number, get provider ID.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^      

Was'nt this within the charter of the ENUM BOF?  Number translation sounds
a bit like number resolution to me.

Richard Shockey
Shockey Consulting LLC                  
8045 Big Bend Blvd. Suite 110    
St. Louis, MO 63119
Voice 314.918.9020
Fax   314.918.9015
INTERNET Mail & IFAX : [email-masked]
eFAX 815.333.1237  
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---------

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 9 Mar 1999 18:14:50 -0500

Then scopes are identical to a deeper hierarchy and splitting them out
is simply a syntactical, not a semantic distinction, right?

Do you think we would need hierarchical scopes? If so, do you see
aggregation of hierarchical scopes? How would this differ from
hierarchical aggregation of addresses? Are scopes always more global
than addresses?

Are we in sync here or am I being obtuse?

> -----Original Message-----
> From: Matt Squire [mailto:[email-masked]]
> Sent: Tuesday, March 09, 1999 5:02 PM
> To: David R. Oran; Greg Zhang; Jonathan Rosenberg
> Cc: hsalama; John Schnizlein; Scott Petrack; Alok Mittal; iptel
> Subject: RE: GLP, number portability and wireless subscribers
>
>

---------

---

From: Christian Huitema <[email-masked]>
Date: Thu, 11 Mar 1999 18:12:47 -0500 (EST)

a) maybe using DNS:

---------

---

From: Scott Petrack <[email-masked]>
Date: Thu, 11 Mar 1999 19:09:26 -0500 (EST)

The fact that this situation is a mess in the PSTN does not mean that it
must be a mess in GLP. And the fact that the "scope" of routing
numbers in the PSTN is the "provider ID" does not
mean that this is the only scope that we should allow within GLP.
Certainly, 1-700 numbers will absolutely require a scope which is a
"provider id", but 800 numbers might not. For example, my company owns a
certain 800 number, and it will resolve to our office telephone number no
matter what provider we happen to choose to give us service. Nothing in
GLP will require that the scope will be "provider id."

Routing is reasonably well defined in the Internet, and it is totally
separate from name-to-anything translations. 

Although there will be a need to have some sort of name-to-something
translation within the Internet, I do not think that this is within the
scope of Iptel. The use of DNS, LDAP, or anything else to effect the translations really
is outside the scope of iptel work, no? 

One of the reasons that I did not fire up ENUM in recent weeks is that we
needed to see better the structure required of the routing
numbers that GLP will use. These routing numbers will be (at least one of)
the outputs of some future translation protocol. I hope that this ENUM
service will be used by gateways, as well as by other applications.

I think that iptel should concentrate on the GLP problem, and deal only
with routing numbers. Once we decide what those numbers look like, it will
be much simpler to translate from "names" to them. 

Scott

---------

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 11 Mar 1999 18:25:52 -0500

Matt Squire writes:
>If there is a scope registration
> e164.

Is there such an authority?

Thanks, Henry

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Matt
> Squire

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 1999 18:56:01 -0500

> is simply a syntactical, not a semantic distinction, right?

My understanding is that it is semantic. By "splitting them out", I
presume you mean having them be separate from the address itself. The
prefix represents information on "where you're calling to", and the
scope information on "where you are calling from". So, a prefix Y with
scope X means you can call Y from X. I think we need explicit scopes if
there are cases where route attributes for a prefix only apply when
calling from numbers outside of the prefix (and apply only when calling
from somewhere defined by the scope).

For example, for corporate addresses, I would say scopes are not needed.
For some local address, don't propagate it beyond the boundaries of the
enterprise. No scope is needed since if you've received the prefix,
you're allowed to call it. Same idea as enterprise IP networks with
internal IP addressing that never goes outside. No special routing
protocols needed,or extra attributes. Just a policy at the periphery
which causes nothing to be propagated further.

> hierarchical aggregation of addresses? Are scopes always more global

We could potentially define hierarchical scopes (if they are also
represented as prefixes, they are hierarchical). The rules for
aggregation would presumably be the same. But, adding another
aggregatable entity in a route advertisement seems like it will make
route aggregation overall more complex, so I'd rather avoid this. Are
scopes global? I think they need to be. The whole idea is that a prefix
advertised in one place is only useful somewhere else. 

-Jonathan R.

---------

---

From: Christian Huitema <[email-masked]>
Date: Mon, 15 Mar 1999 01:14:23 -0500

> GLP will require that the scope will be "provider id."

I think that this all go back to a two phases approach for telephony
routing:

1) take a dip in a mapping directory to understand the "provider" for
the 
   phone number, which will result in a <provider, number> pair -- maybe
   with a specific provider that says "e164"

2) route based on the pair.

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Mar 1999 22:13:16 -0500

> 2) route based on the pair.

I think there is an important point here. To date, we have discussed two
models for handling number translations:

1. we do it in the IP side (perhaps via enum), before GLP, so that GLP
advertises routable numbers only
2. we do it in the PSTN side, so that GLP needs to advertise "names"
like 800 numbers

What Christian is really saying is that there is a third possibility:

1. a partial translation is done on the IP side, yielding a provider ID
or something like that. GLP also propagates provider ID's, so the call
is routed there. The final translation is done inside the PSTN.

I think its a valid requirement to support this. Comments?

-Jonathan R.

---------

---

From: Scott Petrack <[email-masked]>
Date: Sun, 21 Mar 1999 16:21:17 -0500 (EST)

> I think its a valid requirement to support this. Comments?

I want to make sure that I understand what you think Christian has in
mind. Are you suggesting the following scheme:

1. An endpoint wishes to route a call to 1-800-7387225. 
2. The endpoint does some IP lookup to discover that this number has a
   provider-ID of (say) "Qwest".
3. As a result of this lookup, the endpoint knows to route the call to 
   the provider-ID "Qwest." 
4. If there is a gateway which has advertised a route to "Qwest," the 
   endpoint will send it the call?

Is your point to use "Provider IDs" as a way to aggregate routes? 

In this way, rather arbitrary aggregations of phone numbers can be hidden
behind arbitrary "provider-IDs". And then it's up to ENUM servers 
to handle such globs. 

If this is what you meant, I'd just like to add the requirement that a
phone number might belong to several "provider IDs". This can't happen 
in the PSTN, of course, but there is no business
reason that I can't allow BOTH Qwest and Sprint to route 800 numbers for
me, putting them in competition for my business. (Of course the PSTN can't
handle this, but that is not GLP's problem. this whole issue
becomes an ENUM issue, not a GLP issue.)

Sorry if I misunderstood.

Scott

---------

---

From: Scott Petrack <[email-masked]>
Date: Sun, 21 Mar 1999 15:25:31 -0500 (EST)

> 2) route based on the pair.

Well, if "e164" is a provider, then I can see why there was some
confusion.

I am getting more and more partial to the basic requirement for the 
ENUM service being a translation from "Telephone Numbers" to "URLs". 

That is admittedly still a bit fuzzy, but I think it covers what everyone
wants: it will cover things like:

input: 1800xxxyyyy  to 
output: phone:[email-masked]

as well as

input: 1800xxxyyyy to 
output phone:[email-masked],sip:[email-masked] 
			
etc. etc. 

It would even allow me to list two separate phone URLs, in case I want to 
allow to competitors to give me 800 number service.The URLs that are 
returned could indicate "provider" in all the senses of
the word. 

But this will be part of the upcoming ENUM work.

Scott

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Mar 1999 10:18:37 -0500

>    endpoint will send it the call?

That was basically the idea.

> behind arbitrary "provider-IDs". And then it's up to ENUM servers

Yup. Its not clear to me yet how to represent such provider ID's. In one
way, they can (like the "scope" attribute we've been discussing), be
consider part of the address itself. So, if some gateway can route 800
numbers belonging to Bell Atlantic (who is provider 3, for example),
they might advertise the route:

3 1 800 *

On the other hand, I'm not so certain this is part of the address; its
more like an ID which represents a group of addresses (as you mention).
Perhaps what we need is two ways to represent "phone numbers" in GLP -
one is the phone-prefix type we've been discussing to date. Another
would be provider ID. That, of course, leads me to wonder about other
types of "addresses" in the PSTN one could advertise - point codes, for
example. Its a slippery slope....

-Jonathan R.

---------

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 22 Mar 1999 15:04:35 -0600

> they might advertise the route:

Some phrases to consider before using the provider-ID for aggregation:

1) Dual Homed Network: i.e., This number is serviced by GTE and MCI --
can't do this today because of provider aggregation.

2) Number Portability (local AND 800): A number once serviced by carrier
A that is now serviced exclusively by carrier B. LNP as we know and love
it as a relic of provider aggregation.

--
Dean

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Mar 1999 22:45:55 -0500

> can't do this today because of provider aggregation.

This problem needs to be solved with an intelligent database mechanism
in front of GLP. Basically, one would take +1 555-1234, and obtain two
provider ID's - one for GTE, and one for MCI. THen, GLP contains routes
to tell you how best to reach each. The entity which did the translation
can then decide which provider to connect to (also outside of GLP).

> it as a relic of provider aggregation.

Same story as above. 

I think Dean's point is that the set of numbers aggregated into a
provider ID is a complex thing. Agreed. My point is that, given a
translation service which can work this stuff out, it might be nice to
be able to route to a provider ID. 

-Jonathan R.

---------

---

From: "Hussein F. Salama" <[email-masked]>
Date: Tue, 23 Mar 1999 19:46:20 -0800

> is routed there. The final translation is done inside the PSTN.

Does the above discussion apply to 800 numbers only? Otherwise, we no
longer need route selection, because we won't do route selection among
routes being advertised by different providers.

Hussein

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Mar 1999 23:42:51 -0500

> routes being advertised by different providers.

Different notion of providers. We use this term loosely a lot and it has
gotten us into trouble. There are two providers here:

1. the gateway provider,
2. the telco which owns this 800 (or other) number - like Bell Atlantic
(number provider)

So, the translation would indicate which number provider to use. Since
an arbitrary number of gateways can reach this number provider, there
still needs to be a selection among gateway providers. So, directly
answering your question, this partial translation could be done for
non-800 numbers (such as LNP numbers), but we still need GLP to find the
gateway.

-Jonathan R.

---------