Subject: Re: GLP, number portability and wireless subscribers

From: [email-masked] (Patrice Calhoun)
Date: Mon, 8 Mar 1999 14:00:19 -0800

Greg,

Some of us have been addressing this problem, but not necessarily in the IPTel
space. Alot of work was done in TR45.6 (3G cellular systems), and much of this
was brought forth at the Mobile IP WG. Perhaps the work there applies here 
as well. I would be interested in seeing your requirements/architecture.

For a start you can look at draft-hiller-3gwireless-00.txt. For protocol 
information you can look at draft-calhoun-diameter-mobileip-03.txt. Again,
perhaps the problem is not exactly the same, but we may be able to re-use
some of the work already done.

PatC

>Hello,
>
>One issue needs to be considered is number portability. Number portability
>(NP) is reality for wired POTS lines for some time now. Wireless Number
>Portability will be a reality in a few years' time. The portable numbers
>cannot
>be routed by strictly following the hierarchy derived from the digits of
>called
>number. When the number of portable numbers is small compared to all
>telephone numbers in the network, it can be handled on an exception bases
>meaning route the call following the hierarchy then back track when hitting
>a dead end. This is approach used in the first generation systems that
>supports number portability. However, when the number of portable numbers
>gets higher, the inefficiency in the approach becomes more pronounced.
>Differentiation of portable numbers or the correct lookup of the
>switch/gateway
>where the called number resides needs to be done much earlier in the
>SETUP forwarding path.
>
>With the competition in local access market heating up and new area code
>added using overlay instead of split, aggregation based on the number
>hierarchy starts to make less and less sense. On top of this, with cell
>phones
>becomes cheaper and cheaper to have, and the wireless bandwidth grows
>higher, to support roaming/mobility of wireless subscribers both within
>wireless networks and across wireless and wireline based networks,
>phone numbers will need to be handled more and more on a individual
>bases.
>
>To make GLP for IP based telephony networks future proof, the protocol
>needs to support unaggregated  location information for telephone numbers.
>Of course, this will increase the volume of traffic. But if the information
>is
>basically unaggregable, it is just the nature of the problem itself. It will
>probably requires a different solution than it is currently outlined in the
>two proposals that we currently have.
>
>I am in the process of writing up a design that is used for propagating
>location information among mobile telephony gateways. Although the
>original design target is a IP based carrier class wireless telephone
>network. It can be used to solve the generic gateway location problem
>in a IP telephony network. If there is enough interest, I can outline the
>design or send my document to the group for discussion.
>
>Best regards,
>
>- Greg
>
>
>
>---------
>This message came from the IETF IPTEL Working Group Mailing List.

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

---

From: Ami Amir <[email-masked]>
Date: Tue, 9 Mar 1999 02:44:23 +0200

Greg,

I, for one, would be very interested in your design.

Ami Amir

-----Original Message-----
From:	Patrice Calhoun [SMTP:[email-masked]]
Sent:	Tuesday, March 09, 1999 12:00 AM
To:	Greg Zhang; Matt Squire; Jonathan Rosenberg; David R. Oran
Cc:	iptel; Alok Mittal; Scott Petrack
Subject:	Re: GLP, number portability and wireless subscribers

Greg,

PatC

---------

---------

---

From: Matt Squire <[email-masked]>
Date: Tue, 09 Mar 1999 08:09:51 -0500

I agree with the importance of number portability.   But we are just
talking about the signalling messages here.  Having a user register with
with a 'home server' which serves as a proxy signalling server for that
user (as he/she roams about) doesn't seem unreasonable.  Data would go a
more direct route via RTP.   Unlike the PSTN, the data is not tied to the
signalling path.  

The problem of users roaming after the data path is established is an
interesting problem, but I think its a problem for a different working
group.  In this case, you'd want the RTP stream to switch from one
destination to another in mid conversation.  My personal opinion is that
the 'inter-domain' signalling messages should still go to a home server
which then has worry about maintaining current status on its users.  Having
the inter-domain world-wide call routing protocol update every time any
user changes cell towers would be impractical.  

I think that most people agree that aggregation is going to be difficult.
Exactly how difficult is hard to say.  If it can be done, then it should
be, so that the database size is reduced.  This leads to smaller table
transfers, fewer updates, and quicker lookups.  If it can't be done, then
it can't be done.  How much effort should be spent attempting aggregation
was one of the points of our previous thread.  I think that Dave feels
aggregation will be more successful than I think it will be.  

I'm not sure that this is the right group for your proposal, but I'd be
interested in seeing it.

- Matt

---------

---

From: John Schnizlein <[email-masked]>
Date: Tue, 09 Mar 1999 12:49:19 -0500

Notice that names, aka "directory numbers", don't look different from 
addresses, aka "routing numbers" in the PSTN as they do on the Internet.
The tradeoff is that an early lookup can avoid extra call routing,
but that cost is saved only for the relatively few numbers that are ported.

If most numbers really needed lookup, a (LDAP) directory with its schema
reflecting the hierarchy of delegation of ported numbers would be better
than the tedious process used in the PSTN to manage the LPN database.
It might require extensions to LDAP because the parsing of a phone number
into the delegation hierarchy is different in different parts of the world.

The other obstacle to this early-translation approach is the administration
of this directory. While the rudiments of distributing subtrees of the
directory, referrals to other authorities, access control for changing 
pointers, and replication to avoid the chain of queries are specified;
interoperability of these features are still progressing through LDAPext
and LDUP working groups.

One way to deal with it is for gateways to perform only as much lookup
as they desire to avoid poor routes until the directory standards settle.
Even then, would is be OK for some gateways to use poor routes as a local
option to using the global directory?

Even though standardizing these issues is outside the scope of IPTEL,
it is important that the (external) solution is feasible withing the
scope of existing IETF working group charters.

John

At 12:09 PM 3/9/99 -0500, Matt Squire wrote:

>>Translation before the gateway selection is *obviously* the correct model. 
>>We should strive towards this goal.
>>
>>PatC
>
>The next question is when before gateway selection.  Translation 
>could be done as a pre-cursor to call-routing by the ingress, 
>could be done by signalling itself via things like SIP redirections/proxies, 
>or could be done within the routing infrastructure itself.  
>
>I'd prefer one of the first two alternatives.  
>
>- Matt

---------

---

From: "Greg Zhang" <[email-masked]>
Date: Tue, 9 Mar 1999 13:19:37 -0800

Scott Petrack wrote:
>Well, yes, but there are lots of 800 numbers whose translations change on
>time scales MUCH slower than the GLP advertisement changes. In fact, most
>800 numbers are this way -- they are used by small-to-medium
>businesses, point to the 'real' telephone number, with no
>logic at all, and don't change at all.
>
>If a GW wants to advertise that it can service such a number, I don't see
>why it should be forbidden from doing so.

I agree.

>The general problem of for how long the advertisements are valid, and how
>quickly change can be propogated, is just that general -- there is nothing
>special about 800 numbers or other directory numbers.

The duration of the validity of a advertisement should be decision of the
originator. One approach to have a time to live field in the advertisement
and letting it to expire if it has not been refreshed. Another approach
is to let the advertisement lives to perpetuity unless it specifically
updated or canceled by the originator. A Hello mechanisms is employed
to maintain the status of connectivity to the originator. When the
connection
to the originator is lost, all its entries will be removed from the
database.

The second approach will limit the updates to only the changes that have
occurred. There is no need to send refreshes periodically. The overhead
of hello messages are very low comparing with the amount of data in
the actual advertisement.

Aging management of this potentially large database is also greatly
simplified. There is no need for a aging timer that goes off periodically
and a aging handler to go through the entire database to decrement time
to live field, remove the expired ones, and possibly call a handler to
notify
the expiration. Instead, the aging is done on a per originator bases. You
only need to maintain a time or counter to indicate when the last hello was
received. When it exceeds the hello interval * dead factor, the originator
is
declared dead. All its entries get removed. Otherwise, they are all valid.

- Greg

---------

---

From: "Lu, Henry" <[email-masked]>
Date: Thu, 11 Mar 1999 16:48:33 -0600

Dear John,

>option to using the global directory?

The answer to your question will really depending on how gateway getting 
its response from SS7 network. If the gateway just query SCP, then we may
have problem. The normal process works in PSTN is that when a call initiated

from local switch, it consult SCP when destination is not the same prefix. 
I do not see there is a reverse query, from SCP to consult local switches, 
because SCP then has to have all switches information to route this
signaling request. It's not a good news but I hope it will help. Thanks.

Henry W. Lu
SBC, Technology Resources, Inc.
4698 Willow Road,
Pleasanton, CA 94588

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

John

---------

---------

---

From: "Greg Zhang" <[email-masked]>
Date: Tue, 9 Mar 1999 18:40:08 -0800

Jonathan Rosenberg wrote:
>For example, for corporate addresses, I would say scopes are not needed.

In the case of VPN overlaid on top of the public network, a scope that is
not geographically or topologically based provides a easy solution to the
problem.

>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.

Correct me if I have misunderstood the statement. You are allowed to
call any number you want at any given time. A subscriber normally
acquires a phone number to call out of band of any call routing or
location update protocol. Our job is to determine how to route the
call after the subcriber has dialed the digits. In the process, we need
to avoid route the call to a wrong location and to determine if a call
is misdialed and cannot be routed quickly.

>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.

Skip the following in case I am just stating the obvious here. There is
difference between a enterprise IP network implemented using NAT
on firewalls and the IP telephony network that we are discussing here.
In IP telephony network, the gateways that are within a operator's network
is exposed to the outside world. You need to propagate the local addresses
beyond the boundaries of your network to allow other people to call your
subscriber. And the local address is not translated by a firewall to some
globally significant address. The local address is the global address.
With number portability, the local address in one operator's network does
not need to fall within a predefined prefix. To allow some numbers to
be only locally meaningful, you need to block them from being advertised
beyond its scope so that when people outside the scope dial the number,
they are not routed to the local number by accident. Whether the scope
itself has a hierarchy and be aggregatable is another matter though.

- Greg

---------

---

From: Matt Squire <[email-masked]>
Date: Wed, 10 Mar 1999 08:05:05 -0500

At 06:14 PM 3/9/99 -0500, David R. Oran wrote:
>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?
>

I think we just have many different ideas of what 'scope' means, and I
offered a poor explanation.

When this whole discussion started, I was in the middle of writing
something on the possibility of a 'vpn-scope' (I was unfortunately using
that word) to satisfy a requirement that I received via email from a couple
of providers.  I was going to suggest an attribute whose basic purpose was
to map overlapping address spaces into a globally unique number (ie
vpn-scope+number is globally unique).  

When I read Greg's ideas on heirarchical arrangements, it seemed like what
he wanted was a basic filtering mechanism so that if we have A as a parent
of B and B as a parent of C, then advertisments get propagated up, but not
down.   From one of Greg's notes:

>I agree with the spirit of the above statement. However, if the scope can
>be expressed in simply the number of level or a list of peer group ids
>that a advertisement gets to propagate and aggregated to, we would
>not need to administrate, propagate and manage a separate sets of
>scope code throughout the network. We can then have a simple solution
>that serves our needs. Each gateway receives its nodal hierarchy
>information from the peer group leaders in the hierarchy.

It seems like a heirarchy could be built now (using either scsp or bgp
approach) if each peer group/level was considered a domain, and we just
defined filters so that at B, information coming from A didn't get sent
down to C.   So I think one could deploy a heirarchy using static
port-based filters, which requires some administrative work.  But I think
Greg was after something more dynamic, where the attribute itself defined
which ports it would go out on based on the peer/server group on each port.
 I was hoping that, if we decide that that this support is necessary, a
single attribute could be used to satisfy both.  I'm not yet convinced that
its either necessary for us to support such dynamic heirarchical filtering,
nor that it can be done with a single attribute.  The more I look at it,
the more I think that different attributes would be necessary.

Based on the input from the providers and on the amount of work in various
ietf WGs on VPN definition and usage, I do think that a 'vpn-id' attribute
(I'll no longer refer to it as scope) would be useful.  In this case,
splitting it out is simply syntactical, and its used as a way to map
overlapping addresses into a unique global address. 

Jonathan's scope is completely different.

- Matt

---------

---

From: "Lu, Henry" <[email-masked]>
Date: Thu, 11 Mar 1999 17:52:47 -0600

Dear Jonathan,

in AIN SS7 network, we call the first three digit of your local
phone number as prefix. 800, 212 in NY are called area code.
When a guy call 800 number, it is actually send a request to 
national SCP to get the real destination number across the country.
The billing will be paid by 800 number receiver. I hope it will help.
Thanks.

Henry W. Lu

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, March 10, 1999 7:16 AM
To: Matt Squire
Cc: Greg Zhang; hsalama; Scott Petrack; Alok Mittal; David R. Oran;
iptel

Phew. Lots of mail flying around here. let me take a moment to summarize
what I think I've heard so far on scopes. Several definitions have been
explicitly or implicitly used. These include:

1. Scope is a way to disambiguate prefixes which are not globally
unique. For example, a particular 800 number might exist in NY, and
another in CA, and they are the same number, but who you get connected
to is different in NY and in CA. The scope would be used as an extra
identifier to make prefix+scope (or vpn-id as Matt calls it in this
email) globally unique. 

2. Scope is a way to disambiguate prefixes which are not globally
unique, but the scope further defines the places where the prefix is
valid. Ideally, this would mean "this prefix is only valid in NY" or
something like that. These scopes might be registered as tags with IANA,
or defines as prefixes themselves. For example, a prefix of Y with scope
X means that entities within scope X can call the prefix Y.

3. Scope is a way to define how far a prefix is propagated. If LS's were
organized hierarchically, the scope would indicate the level in the
hierarchy. Boundary LS's wouldn't propagate prefixes with a scope
corresponding to their level outside their level. Matt has also
mentioned a TTL for this purpose.

Functions (1) and (2) are similar, (3) is different. The question is:
(1) do we need all three functions, and (2) can a single identifier
serve both purposes? We might be able to get a grip on this by first
figuring the first one out - what is it we wish to accomplish with
scopes, and then we can decide how many attributes we are talking about.

-Jonathan R.

Matt Squire wrote:
> 
> At 06:56 PM 3/9/99 -0500, Jonathan Rosenberg wrote:
> >David R. Oran wrote:
> >>
> >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).
> 
> I don't see how we can guarantee any determination of 'where you are
> calling from.'  What does my pc call from?  Where is an LS?  A gateway
> might be considered to have a 'location', where the location is given by
> the area code of its PSTN connectivity, but other devices without PSTN
> connectivity aren't tied to a PSTN location.
> 
> It seems like any definition of scope along these lines requires alot of
> administrative help, ie where LSs are tied/located with certain geographic
> areas.  Would not a TTL-like attribute provide similar functionality
(again
> based on geographic ties/connectetions in LSs)?  A number could be
> advertised with a certain TTL that prevents it from being advertised after
> too many hops.  If your connections are geography-based, then this gives
> you geographic scoping.  We make an additional statement that given
> multiple potential routes to a destination, the one with the higher/lower
> TTL is preferred (because its 'closer').
> 
> >
> >>
> >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.
> >
> 
> Unless someone says something to convice me otherwise, I'd vote against
> this concept of scoping.
> 
> - Matt

-- 
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: "Lu, Henry" <[email-masked]>
Date: Fri, 12 Mar 1999 13:13:00 -0600

Dear Henry,
Any carrier want to provide IP telephony service will need to
build their own "confederation" in IP world to register users and billing.
Since it is in IP world, the routing information will be able to exchange 
with each other via BGP-4 with attributes between  different "confederation 
serving domain". It won't be free so you don't have to worry. Thanks.
Henry W. Lu

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

Matt Squire writes:
>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.

Is there such an authority?

Thanks, Henry

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Matt
> Squire
> 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
>
>
> 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
>
>
> ---------

---------

---------

---

From: "Lu, Henry" <[email-masked]>
Date: Fri, 12 Mar 1999 12:18:46 -0600

Dear Louise,
Did SIGTRAN group promise to deliver that through SS7
gateway from IP world can get right PSTN call routing
in the case of 1-800 and number been ported? I think
the problem is in SS7 world and need to be fix there
in stead of doing patches in IP world. It is just like
shooting a moving duck. Thanks.
---Henry W. Lu

-----Original Message-----
From: Louise F. A. Spergel [mailto:[email-masked]]
Sent: Wednesday, March 10, 1999 8:19 AM
To: Jonathan Rosenberg
Cc: Greg Zhang; David R. Oran; Matt Squire; Scott Petrack; Alok Mittal;
iptel

My comments below are specific to the US. I don't have any knowledge on
other countries.

With 800 numbers, the issue is different due to the current implementation
and regulatory constraints. In 800 service, the called party pays,
therefore the called party picks the carrier, which currently are all
PSTN-type carriers. The carrier for each number is contained in a database
which is accessed by SS7 TCAP. This database is maintained by a neutral
party. In the near-term, you will need to consult this particular database
and to find the right carrier and then hand the call to a gateway to that
carrier. 

At some point I think the SIGTRAN protocols will enable this.

Of course, in the long run, this may change somewhat.

Louise

At 10:27 AM 3/9/99 -0500, Jonathan Rosenberg wrote:
>Greg Zhang wrote:
>> number. 
>I agree LNP makes the problem harder. I have two responses here:
>
>1. Simply "not aggregating" is always an option for a protocol which
>provides aggregation. I don't want to not support aggregation because of
>LNP. If LNP gets in the way, it can just be turned off if needed.
>
>2. I'm not yet convinced LNP actually prevents aggregation. Lets say
>gateway X can reach ten numbers, +1 607-1* (using glob matching), +1
>607-2*, etc. so these could be aggregated to +1 607*. Lets further
>assume all ten numbers are LNP, and actually terminate all over the
>country. These numbers can still all be reached through the gateway.
>They cannot be aggregated only if the attributes for each are different.
>The only attribute likely to differ is cost. So, the question is, does
>the cost (to the gateway provider) for terminating calls to each of the
>numbers differ? Even if they do, is the cost the gateway provider wants
>to charge to its users different for each number? If the answer to
>either is no, then they can still be aggregated. With long distance
>rates at 10 cents a minute *anywhere* in the U.S., this seems not so
>unlikely.
>
>
>There is a related issue of 800 numbers, and any of the other
>non-routing numbers. Should these be advertised by GLP? Or, should they
>be translated first, and then the translated numbers advertised? (Please
>correct me if I have misunderstood some aspect of how this works in the
>PSTN).
>
>-Jonathan R.
>-- 

---------

---------

---

From: "Rollender, Douglas Harold (Douglas)" <[email-masked]>
Date: Fri, 12 Mar 1999 16:24:09 -0500

Translation before or after gateway selection seems to depend on the service
architecture (i.e., 800 is not the same as LNP) and the position of the
gateway service provider in the end-to-end routing of the call.  Is there
one "correct" model top apply in all cases?  Is one needed?...Doug.

	----------
	From:  Scott Petrack [SMTP:[email-masked]]
	Sent:  Tuesday, March 09, 1999 12:30 PM
	To:  [email-masked]
	Cc:  Jonathan Rosenberg; John Schnizlein; Greg Zhang; David R. Oran;
Matt Squire; Alok Mittal; iptel
	Subject:  Re: GLP, number portability and wireless subscribers

	On Tue, 9 Mar 1999, [email-masked] wrote:

	[Jonathan R:}
	> > This begs the question, then: does the translation of the 800
number get
	> > done before the gateway selection process, or after? By doing it
before,
	...
	> > if the translation occurs before gateway selection, the caller
can
	> > choose a local NY gateway and do much better.
	> 
	> Translation before the gateway selection is *obviously* the
correct model. We
	> should strive towards this goal.
	> 
	> PatC
	> 

	Well, yes, but there are lots of 800 numbers whose translations
change on
	time scales MUCH slower than the GLP advertisement changes. In fact,
most
	800 numbers are this way -- they are used by small-to-medium
	businesses, point to the 'real' telephone number, with no
	logic at all, and don't change at all.

	If a GW wants to advertise that it can service such a number, I
don't see
	why it should be forbidden from doing so. 

	[Of course there is a need for a separate look-up and translation
service,
	but this is outside the scope of Iptel - right Jonathan? ;-)]

	The general problem of for how long the advertisements are valid,
and how
	quickly change can be propogated, is just that general -- there is
nothing
	special about 800 numbers or other directory numbers. 

	Scott 

	---------

---------

---

From: "Lu, Henry" <[email-masked]>
Date: Tue, 9 Mar 1999 15:35:39 -0600

Dear Jonathan,
What if Lucent and Nortel solve this problem via SCP by including 
local number portability information, and the problem become much simpler. 
All we have to do is sync with SCP database. I understand 
that it is simpler to have local switch to keep local number
portability within one switch and do not have to consult
SCP, if it is local within a switch. The problem is that SCP
do not have these local information for ip world to sync with. 
I agree with you that IPTEL do not have to worry about this problem, 
but this database dependency on SCP and SSP may limit the calling 
scope from IP world. Do you know who we can refer this problem to?

Dear Greg,
I just want to provide information that I think will be helpful.
Based on my understanding, SS7 netwrok is very secured network
and their protocol is not like IP protocol at all. I do not think
that SS7 world will adapt the protocol we are discussing here, because 
the protocol nature of SS7. I hope that you will write the draft and
Lucent and Nortel work out their problem and we can accomplish the goal
to having wireless calling IP world or vis versa. Thanks.

Henry W. Lu
925-598-1245
4698 Willow Road
Pleasanton, CA 94588

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, March 09, 1999 11:31 AM
To: Lu, Henry
Cc: [email-masked]'; Matt Squire; John Schnizlein; Greg Zhang;
David R. Oran; Scott Petrack; Alok Mittal; iptel
Subject: Re: GLP, number portability and wireless subscribers

Lu, Henry wrote:
> 
> Hello,
> 
> I am in favor of Pat's point but I am still hoping that we can
> achieve a sound solution in order for us to handle number portability
> environment in the future, including wireless.
> 
> The issues I see is how to synchronize two database between GLP and SS7
> world. In AIN, 800 number information are kept in not only Signaling
> Control Point(SCP) but also Service Switching Point(SSP), normally in
> local DMS-100 or 5ESS switches. The 800 calling process had to go through
> a conversation session between SSP and SCP to figure out the final
> routing to the destination. There are two information databases been
> kept on both SCP and local SSP. Do not forget that there are many SSPs
> in the network, not like SCP, we have to deal with.
> The major problem occur when a new portable number been provisioned,
> into both SSP and SCP but there is no information on GLP side.
> GLP and SS7 database is out of sync basically.

As you mention, the somewhat unusual way in which the database is
distributed in the phone network makes this a hard problem. The best way
to keep these databases in sync is to simply not have a separate
database. When a proxy or gatekeeper is going to make a call, it first
queries the phone network (somehow) to translate the number into a
routing number. GLP only advertises routing numbers. As such, the
database of number translations is stored only in the phone network, as
it is today. 

If, however, one chooses to deploy a parallel database in the Internet,
accessible by LDAP or some other means (enum perhaps?), the
synchronization problem exists.

Fortunately, it is outside of our charter to worry about this problem.
We need only decide what numbers may or may not be propagated by GLP,
and how they are represented and aggregated.

-Jonathan R.

---------

---

From: Matt Squire <[email-masked]>
Date: Tue, 09 Mar 1999 15:28:27 -0500

At 02:49 PM 3/9/99 -0500, Jonathan Rosenberg wrote:
>Greg Zhang wrote:
>> 
>> >This is another good example of why translation before gateway selection
>> >is a good idea. However, I'm not sure there is much we can do from a
>> >protocol perspective to prevent it. There may be valid reasons why a
>> >company would like to advertise an 800 number (only they own it, for
>> >example), and I'd rather not exclude this possibility. It seems like a
>> >sensible approach is to allow non-routing numbers in GLP, but mention
>> >that there are issues with them, and translation before routing is a
>> >good idea. Does this sound sensible?
>> 
>> I think to handle this type of cases correctly, we need to introduce a
>> concept of scope for the advertisement. Gateways in CA will advertise
>> the 800 number for company X in CA while gateways in NY will
>> advertise the same 800 for company Y in NY. The advertisement from
>> the CA domain does not get propagated to the NY domain and vice
>> versa. This way the numbers that are locally significant and are being
>> administrated locally stays local. This however does not prevent the
>> same 800 number being used by upper level for a third customer.
>
>A sensible idea, but seems hard to do. How does one represent scope? How
>does one encode the notion that "this number is valid within the greater
>new york metropolitan area", or "northern california" into a protocol? 
>
>Perhaps one solution is to allow scopes to be represented as opaque
>tokens. These tokens can be registered, perhaps with IANA, along with a
>desription of the what the scope means. This would allow peers to
>program their LS's to recognize certain scope tokens, and do something
>appropriate with them. Prefixes with unrecognized scope tokens probably
>shouldn't be propagated.
>
>As an alternative, scope could be represented by a separate phone number
>prefix. This second prefix indicates the set of numbers you need to call
>from for this scope to be defined. For example:
>
>phone numbers: +1-800-55*
>scope: +1-415*
>
>means that 800-55* is only defined within parts of California.
>
>Any other ideas? Or do people think that this isn't needed?
>

I've received similar comments from several providers.  This is one of
things I was going to bring up when discussing general data representation
issues.  Scope has applicability to 1-800 numbers, but it also has
applicability to private/corporate numbers.  I've received several comments
from providers saying that they need the ability to route on a
private/corporate number (in addition to 1-800 comments), where the same
address may have different destinations depending on its scope and the
number itself has no global significance.  In one sense, scope may be
indicate a vpn routing object, and in another it may indicate 1-800-type
limitation.  

Note that these concepts of scope are not exactly the same, but I think a
single attribute might be able to cover them both.  I'm trying to flush
this out a little better before the meeting.  

What do folks think about the necessity of a 'scope' attribute for
 (a) 1-800
 (b) corporate/private addresses
(ie would I be wasting my time trying to address this concern?)

- Matt

---------

---

From: "Greg Zhang" <[email-masked]>
Date: Tue, 9 Mar 1999 11:44:13 -0800

>environment in the future, including wireless.

I agree whole heartedly that this should be one of the goals that we try to
achieve.

>How to solve this database synchronization problem, I do not have
>a solution for you but I hope that we can see the nature of the
>problem first.

When you have a Internet telephony gateway that is attached to a
PSTN network, the gateway needs to advertisement the reachability
of the numbers in the PSTN network. When provisioning of a new
portable number occurs, the portable number and its routing information
("office code") needs to be sent to the gateway. The gateway in turn
propagate this information to other gateways on the Internet through
GLP. The mechanism with which the information in SCP and SSPs
are kept in sync with the attached Internet telephony gateway could
be the same mechanism used to update this information from the
subscriber management system to SCP and SSPs. It is outside the
scope of GLP though.

- Greg

---------

---

From: "Greg Zhang" <[email-masked]>
Date: Tue, 9 Mar 1999 17:16:24 -0800

Jonathan Rosenberg wrote:
>In the current model, synchronization of the databases occurs from a
>point outward until an aggregation point, at which a route change is no
>longer propagated. This effectively creates a hierarchy along the
>boundaries of the addressing hierarchy. Of course, if the LS topology
>doesn't follow the topology of the phone number allocations in the
>gateways, aggregation will be more limited, and the system appears more
>flat. However, a system with explicitly defined boundaries, as you
>propose, will do no better in this scenario either. As such, I don't see
>much advantage to explicitly defining hierarchies.

I guess the difference really comes down to whether there is a high
degree of aggregatability among the phone numbers in the network.
If aggregation can be achieved for a large majority of the telephone
numbers in the network, the two approach's effect are similar.
Building a hierarchy may seems to be an unnecessary exercise.
However, if the aggregatability of phone number is low in the network,
the hierarchical approach used with some techniques outlined below
and some of my earlier messages will cut down the amount of update
needed in the network while still providing full reachability of all
numbers in the whole network.

In our target network, we have 1 million plus mobile subscribers and
about 400 to 500 telephony gateways. The numbering plan within the
network is flat. Any subscriber can be at any gateway at any given
moment in time. Within the network, the phone numbers are not
aggregatable by any means. Each one of them needs to be treated
individually.

A GLP or location update protocol as we have been calling it with
a hierarchy will allow us to limit the scope of each location
update as it happens when a handoff occurs to a small group of
gateways. This update will get propagated up through the hierarchy.
But it will not be propagated to other peer groups on the same level.
On each level, you only needs to propagate it in one peer group. When
a location look up request or a SETUP message gets generated in one
peer group, if the location look up fails, it will get passed up the
hierarchy by the peer group leader. Eventually, the location information
for the subscriber is resolved and SETUP message gets forwarded
to the gateway where the subscriber is currently at.

With this design, the location information is resolvable from any point
in the network at any given time. However, the updates does not
need to be propagated to every gateway in the network even though
the phone numbers cannot aggregated. The updates are only
propagated within small groups on each level. When used with
the concept of originator and a hello mechanism to check the status
of the connectivity to the originator, the location advertisement does
not need to be refreshed as long as no change has occurred, i.e. the
said user has not moved to a new gateway. This cuts down the
amount of update messages considerably thus providing the
scalability that is needed for a carrier class mobile telephone
network.

- Greg

---------

---

From: Tom Gray <[email-masked]>
Date: Mon, 22 Mar 1999 07:07:36 -0800 (PST)

Hi

Has the issue of a private network been considered here along with the
issues of tenanting? I'm new so please excuse me if this has been
considered. A server may be used to service several enterprises say in
a shared office building. Each may well want their help desk to be
HELP or 4357, the president to be 1111, etc. They will certainly not
agree to have special tenant suffixes applied. Additionally it will
probably be a requirement to extend this  over multiple servers with
overlapping sets of tenants at each server.

Tom Gray

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

---------