Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03

From: James Yu <[email-masked]>
Date: Thu, 10 Aug 2000 08:50:43 -0500

Jonathan,

In the example you gave, the gateway can still announce that it can reach
the range of numbers that the user has as "routing numbers."  If the call to
the user is received at the gateway, it then knows that it has a direct T1
trunk to the user which is a more direct route than the one going through
the PSTN.  But if that T1 trunk fails, it can set the routing to route the
call through the PSTN.  Certainly, some other gateways may get the call and
route the call through the PSTN to the user.   So if the users owns/controls
+1-202-533-0000 to +1-202-533-0999, the gateway that the user has direct T1
trunk connection with can advertise that it can reach +1-202-533-0 in
addition to others as "routing numbers."  If those POTS numbers are not
ported, this particular gateway may receive the calls to the user ("may"
indicates that other gateways may receive some calls because they can reach
those "routing numbers"). If those POTS numbers are ported and if the IP
networks do not have the NP routing information (e.g., LRN in the U.S. and
Canada), this particular gateway may receive the calls to the user just like
the previous case.  But if those POTS numbers are ported and if the IP
networks do have the NP routing information, I do see one extra effort by
the gateway - to get and announce the additional "routing number" of the
PSTN switch/network that serves this users' POTS numbers in addition to
+1-202-533-0 and others  This is to ensure that this gateway an receive
calls to the user when routing number for NP is available to the IP
networks.  But this is considered a minor effort comparing to the effort of
announcing the POTS number address family via TRIP.

When NP is involved, if we only use one address family, the "routing number"
table will get the call routed to the correct gateways whether both routing
number and POTS number are present or just POTS number is present.  But if
both address families are used, there must be a rule about which number has
the precedence if both routing number and POTS number are present.  If only
the POTS number is present, I assume that the rule must be to use the "POTS
number" table for routing.  This will force "POTS numbers" be announced even
if "routing number" table is sufficient for routing.

James 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2000 10:52 PM
> To: James Yu
> Cc: [email-masked]; [email-masked]'
> Subject: Re: [IPTEL] [TRIP] Address Families in 
> draft-ietf-iptel-trip-03
> 
> 
> James,
> 
> Your argument is predicated on the fact that the gateway knows the
> ported numbers
> and/or routing numbers supported by the switch its connected 
> to. This is
> simply
> not going to be the case when the gateways are own by normal folks who
> simply call
> up the phone company and get a T1 that they plug into their 
> gateway. In
> this case,
> the owner of the gateway will choose routing information for 
> the gateway
> NOT based
> on PSTN routing, but rather on cost structures in place for reaching
> certain numbers
> from that gateway.
> 
> Yes, this can lead to triangle routing and all, but if you 
> are a USER of
> the PSTN, not
> a LEC, you have no information nor control over PSTN routing.
> 
> -Jonathan R.
> 
> James Yu wrote:
> > 
> > Jonathan, Hussein,
> > 
> > I agree that there are two types of numbers or address 
> families that exist
> > in the GSTN and are available to the Internet for routing.  
> My argument is
> > about whether there is a need to broadcast both address 
> families in TRIP.
> > My concern is about the use of the "POTS number" address 
> family when the
> > POTS numbers are in countries that support number 
> portability (NP).  Right
> > now, service provider portability (e.g., changing the 
> service provider while
> > keeping the same telephone number) is the only one 
> supported.  Many years
> > later, location portability (e.g., changing location while 
> keeping the same
> > telephone number) is likely to be supported at least in 
> some countries such
> > as the U.S.  This would mean that many more POTS numbers 
> would be ported at
> > that time.  The scheme selected by the U.S. and Canada 
> already supports
> > routing to the correct switch that serves a particular 
> ported-out number.
> > Caller confusion (e.g., charging issue) is the main reason 
> that prevents
> > location portability across rate center boundaries (e.g., 
> different call
> > charges) from being offered.
> > 
> > If we try to broadcast the reachability to the POTS numbers 
> in countries
> > that support NP, it may not be realistic to do so.  For 
> example, if a switch
> > in the U.S. handles +1-202-533-xxxx but 4,000 numbers in 
> that number range
> > have been ported out, it has to broadcast that it can reach 
> +1-202-533
> > prefix except for the other 3,000 individual POTS numbers. 
> I'll have no
> > problem to broadcast the reachability of those POTS numbers 
> if there is an
> > "efficient" way to broadcast the information.  Also the 
> same switch will
> > have ported-in POTS numbers.  It has to broadcast those 
> numbers via TRIP.
> > Also, every porting event, ported-out or ported-in, has to 
> be broadcasted to
> > change the reachability to this POTS number by all the 
> gateways that are
> > impacted by the change.  So it is not only the number of 
> records to be
> > broadcasted but also the frequency of changes that concern 
> me if we try to
> > broadcast the reachability of the POTS numbers in 
> NP-capable countries via
> > TRIP.
> > 
> > Most routing numbers are national routing numbers, but 
> since Internet may
> > not have national boundaries, we can add the country code 
> to a national
> > routing number so that this international routing number 
> can be used in the
> > Internet unambiguously when the involved IP networks are not in the
> > terminating GSTN.  For example, if an IP network in the 
> originating country
> > can retrieve the NP information (many mechanisms may be 
> used depending on
> > what may be available, e.g., it can launch a terminating 
> country's NP TCAP
> > query via sigtran), the received information would be in 
> the terminating
> > country's national format.  To use the information over the 
> Internet, it may
> > need to add the terminating country's country code to the 
> national numbers.
> > 
> > ITU-T has also allocated specific country codes that allows 
> for identifying
> > "networks" (see E.164 Supplement 2).  Those can be viewed 
> as "international"
> > routing numbers.  Those international routing numbers won't 
> overlap with
> > those national routing numbers plus their country codes.
> > 
> > The connection between the GW and GSTN via PRI or T1 has no 
> implication on
> > TRIP.  TRIP's role is to get the call to the GW that can 
> reach the GSTN
> > switch/network that serves a particular POTS number.  If 
> the routing number
> > for a ported-out POTS number is available, the routing 
> number will get the
> > call to be routed to the correct GW(s).
> > 
> > For a non-ported POTS number or a ported POTS number 
> without the routing
> > number (e.g., networks/countries that support Query on 
> Release, Onward
> > Routing or Dropback scheme where the call is routed to the donor
> > network/switch first), the "routing number" in the TRIP 
> "routing number"
> > table will get the call routed to a GW that can reach the donor
> > network/switch that serves that POTS number.  In that case, 
> the POTS number
> > is used as the routing number for routing.  So if the TRIP 
> "routing number"
> > table contains the special routing prefixes/numbers that 
> contain digits A
> > through E and the regular POTS number ranges/prefixes 
> assigned to the donor
> > network/switch, there won't be a need to broadcast the 
> "POTS number" address
> > family via TRIP.
> > 
> > If the GW is connected to the subscribers directly, I 
> assume that the GW
> > will have a routing number assign to it in the NP-capable 
> environment.  The
> > GW will broadcast that routing number and any other number 
> ranges that are
> > assigned to it (e.g., the GW is the donor switch of those 
> number ranges) in
> > TRIP.  In a non-NP environment, the number ranges assigned 
> to the GW are
> > broadcasted as "routing numbers" in TRIP.
> > 
> > So if a GW can reach N GSTN networks/switches, it will broadcast its
> > reachability to all the POTS number ranges that are 
> assigned to those GSTN
> > networks/switches (e.g., as the donor networks/switches) 
> plus the special
> > routing numbers (e.g., with digits A through E) that are 
> assigned to those
> > GSTN networks/switches.   If an IP node has both a routing 
> number and POTS
> > number, it uses the routing number to check against the 
> TRIP "routing
> > number" table to determine the routing.  If it only has the 
> POTS number, it
> > uses the POTS number to check against the same TRIP 
> "routing number" table
> > to determine the routing.  Certainly, when an IP node only 
> sees the POTS
> > number, it may be provisioned to retrieve the NP related 
> information.  After
> > that, it may have the routing number in addition to the 
> POTS number and will
> > use the routing number to check against the TRIP table.
> > 
> > James
> > 
> > > -----Original Message-----
> > > From: Jonathan Rosenberg [mailto:[email-masked]]
> > > Sent: Tuesday, August 08, 2000 10:02 PM
> > > To: [email-masked]
> > > Cc: James Yu; [email-masked]'
> > > Subject: Re: [IPTEL] [TRIP] Address Families in
> > > draft-ietf-iptel-trip-03
> > >
> > >
> > >
> > >
> > > "Hussein F. Salama" wrote:
> > > >
> > > > James,
> > > >
> > > > We decided to define two address families, and not just 
> one as your
> > > > suggesting, for the foloowing reasons:
> > > > - In order to perform aggregation we need to know when 
> we have all
> > > > possible next characters. Routing numbers have a different
> > > character set
> > > > than other POTS numbers, and hence the need for 
> defining a dedicated
> > > > address family for routing numbers.
> > > > - Other reasons concern the nature of routing numbers:
> > > >         * they don't represent destinations
> > > >         * their scope is limited to national boundaries
> > >
> > > I agree. Also note that TRIP might be used to represent routes to
> > > gateways which don't have ss7 access to the PSTN; they are simply
> > > connected through PRI or T1 or whatever. For such gateways,
> > > the prefixes
> > > to which the gateway can route are limited to only pots 
> numbers, as
> > > these are the only ones exposed through these interfaces.
> > >
> > > -Jonathan R.
> > >
> > > --
> > > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > > Chief Scientist                             First Floor
> > > dynamicsoft                                 East Hanover, NJ 07936
> > > [email-masked]                     FAX:   (973) 952-5050
> > > http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> > > http://www.dynamicsoft.com
> > >
> 
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Hussein F. Salama" <[email-masked]>
Date: Thu, 10 Aug 2000 09:28:17 -0700

James Yu wrote:
> the precedence if both routing number and POTS number are present.

The rule is: 
- If the destination number is a ported number, and NPDB lookup has
already occured. In this case, we have both the LRN and the destination
POTS number. In this case the intermediate signaling server should route
the call using the LRN. The intermediate signaling server should specify
"address family = routing number" when it queries TRIP for a route to
the given LRN.  TRIP then searches only those routes with address family
= routing number.
- If destinatination is not a ported number, or if it is a ported
number, but NPDB lookup hasn't occured yet (because e.g. the signaling
servers traversed so far do not have access to the appropriate NPDB). In
this case, the intermediate signaling server should route the call using
the destination number. The intermediate signaling server should specify
"address family = POTS number" when it queries TRIP for a route to the
given destination. TRIP then searches only those routes with address
family = POTS number.

My main concern about using a single address family is still the
difficulty of aggregation, because of different alphabets. If we define
a single address family with the alphabet {'1' .. '9', 'A' .. 'F'},
automatic aggregation will not be easy. For example it will never happen
in the US. For example, a TRIP LS receives the following routes:
202530*, 202531*, 202532*, 202533*, ...., 202539*
The LS will not aggregate these routes into 20253*, becasue it has not
received 20253A*, 20253B*, ..., 20253F*, which do not exist.

Hussein