Subject: RE: TRIP

From: James Yu <[email-masked]>
Date: Tue, 7 Dec 1999 10:19:45 -0600

Hussein,

Please see my comments below (although you addressed your questions to
Jonathan).

James

-----Original Message-----
From: Hussein F. Salama [mailto:[email-masked]]
Sent: Monday, December 06, 1999 7:56 PM
To: Jonathan Rosenberg
Cc: James Yu; [email-masked]'
Subject: Re: TRIP

Jonathan Rosenberg wrote:
> 
> James,
> 
> Thanks for the excellent description of the process. Comments below:
> 
> James Yu wrote:
> >
> > Jonathan,
> >
> > North American Numbering Plan numbers have the format of NPA+NXX+XXXX
where
> > NPA (Numbering Plan Area) is the area code and has the format of NXX
(The
> > area codes used to have the format of N0/1X where the second digit can
be
> > either 0 or 1. That restriction has been removed to allow more area
codes to
> > be assigned.). N is any digit from 2 to 9 and X is any digit from 0 to
9.
> > The NXX after NPA is called "office code."  Normally, a switch is
assigned
> > the whole block of NPA+NXX (e.g., 212-455-0000 to 212-455-9999).  Now
> > "number pooling" will allow several LECs to share one NPA+NXX.  That is,
a
> > LEC will be assigned, for example, 212-477-1 (block from 212-477-1000 to
> > 212-477-1999) and another LEC assigned 212-477-2 (block from
212-477-2000 to
> > 212-477-2999).  We can talk about "number pooling" later if you or
others
> > have questions.  The focus of this discussion is on LRN and number
> > portability.
> 
> Hmm, sounds familiar.... CIDR?
> 
> > If the TRIP information contains the reachability of subscriber number
> > ranges, A GW that can reach Switch A but not Switch B will have to
indicate
> > that it can reach +1-212-455-0000 to +1-212-455-1233 and
> > +1-212-455-1235-+1-212-455-9999 (if only one number has been ported out
of
> > Switch A).  The problem of this is that many ported-out numbers need to
be
> > singled out from the reachable phone number ranges ranges.  This is a
minor
> > problem when comparing to the bigger problem of updating the TRIP
> > information every time a number changes its assoicated LRN after been
ported
> > to a new LEC.
> 
> I think TRIP should carry subscriber numbers, but that the LNP dip
> should happen before the TRIP database is accessed. So, returning to
> your example, a gateway reaching only switch A would advertise
> +1-212-455* and a gateway reaching only switch B +1-212-466*. A PC users
> calls +1-212-455-1234. The INVITE is sent to its local proxy, which
> first does an LNP dip. 

The N-1 agreement in classic telephony makes the (N-1)th network (i.e.
the next to last network), on the path towards the destination,
responsible for making the LNP database query. I wonder what's the
reason for this? Wouldn't executing the LNP database query at the
originating network have resulted in more efficient routing? 

****** In the U.S. the N-1 network is usually the IEC network.  The reason
that N-1 network is to perform the NPDB query is because the caller is
served by his/her long-distance carrier for this call.  That is, the IEC
will bill the caller (sometimes the billing is done through the LEC, but
from the provider-customer relationship, the IEC is the service provide for
long distance service) and pay the originating and terminating networks
(local exchange carriers) for providing "access."  If the originating
network performs the NPDB dip, it will want to be paid (by the IEC) to
perform that function.  That is why the originating network is not required
to perform the NPDB for long distance calls unless the IEC requests it to do
so.  

If a call terminated at a cellular/PCS network in the U.S., the N-1 network
(the second to the last network) would be the terminating local exchange
carrier that is connected to the terminating cellular/PCS network if the IEC
does not terminate the call to cellular/PCS network directly over direct
trunk connection between the two networks. There won't be any routing
efficiency whether the originating or IEC network performs the NPDB query
for long distance calls.  When location portability is supported in the
future (across the Local Access and Transport Area (LATA) boundary), the
originating network would be the one to perform the NPDB queries for all the
calls because it cannot be determined whether a call is a long distance or
local call before NPDB query is done.

Please note that the internet in many cases will be the "N-1" network for
VoIP for SCN-terminated calls where the calls are originated from within the
internet or from SCN via internet.
******

> It translates this to an LRN of +1-212-456, which
> is looked up in TRIP. The longest prefix match (which is an exact match
> for the LRN) is found. The INVITE is then sent to the next hop towards
> that LRN as learned through TRIP. The original dialed number will be
> carried in the To field.
> 

Looks like a SIP extension is required to indicate to other signaling
points on the call path that an LNP query has already been done for this
destination, in order to avoid multiple LNP queries for the same call.
Is such a flag already there?

****** If ISUP is carried over IP, the information would be carried in the
encapsulated ISUP message.  Otherwise, SIP may need to be enhanced to carry
not only the dip indicator but also the LRN (in addition to the dialed
number).  I don't know whether a flag is already there. ******

Hussein

> Note that we could also allow switch B to advertise +1-212-455-1234 in
> TRIP. If the LNP dip is not done, the proxy will pick this because of
> longest prefix matching, and the call still completes. However, I would
> recommend doing this, since it will result in a completely flat TRIP
> routing table.
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120
> dynamicsoft                                 West Orange, NJ 07052
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

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

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