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

From: [email-masked]
Date: Tue, 8 Aug 2000 15:42:26 -0400

Just to clarify the statement in your second bullet below:

For NP in the US, calls to non-ported numbers are not routed via an LRN.  They
are routed based on the dialed digits.  In your example, that would be
202-533-1234.  Calls to 202-533-1234 would not route via the switch's LRN of
202-533-0000 because the two numbers are not associated with each other in the
NP database since 202-533-1234 is not ported.   Only ported numbers are in the
database and they require routing via an LRN that is unique to the switch that
serves the ported number.

Gary Sacra
Verizon

"James Yu" <[email-masked]> on 08/04/2000 11:35:37 AM

 To:      "[email-masked]'" <[email-masked]>           
                                                              
 cc:      "[email-masked]'"                       
          <[email-masked]>(bcc: GARY M.            
          SACRA/EMPL/MD/Bell-Atl)                             

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

Hussein,

Section 5.1.1 of TRIP defines two address families, One for POTS numbers and
the other for routing numbers. Since TRIP deals with "routing," it is
suggested that only the "routing numbers" address family is used.  This will
avoid the handling of two address families in TRIP for supporting number
portability (NP).  The basic rule is:
(1) Use the "routing number" for routing (e.g., check against the TRIP
routing table) if both the "routing number" and "POTS number" are present.
(2) Use the "POTS number" for routing if "routing number" is not present.

The reasons are described below.

- For countries such as U.S. and Canada that support NP and use routing
numbers that overlap with the POTS numbers (e.g., the same format and
length), and use the POTS numbers as the routing numbers for non-ported POTS
numbers, the "routing number" address family is sufficient for call routing.

 * For a ported-out number, a location routing number (LRN) is retrieved
from the NP database.   That LRN (plus the country code if required) is used
for routing.
 * For a non-ported number, that POTS number is used for routing because its
prefix (e.g., the first 6 digits of the national number) can identify the
donor switch that serves this non-ported number.  The POTS numbers in this
case are actually treated as the routing numbers!  For example, if the POTS
number is 202-533-1234 and is not ported, a LRN of 202-533-0000 can be used
as the LRN for routing the call.  Use of "202-533-1234" or "202-533-0000"
does not make any difference because the GSTN switches in the North America
routes national calls based on the first 6 digits of the national POTS
numbers.  That is why the POTS numbers are used for routing for non-ported
numbers.
  So all we need is the "routing number" address family.  If the routing
number is present, it is used to check against the TRIP routing table.  If
it is not present, the POTS number is used to check against the TRIP routing
table.  Only one TRIP routing table is needed.  We only need to use the
"correct" number to check against the TRIP routing table if both the routing
number and POTS number are present.

- For countries such as Austria and Belgium that support NP and concatenate
a routing prefix (called network routing number) with the POTS number (e.g.,
Cxxxx+POTS number in Belgium), it does not matter whether we view this
"concatenated number" as a routing number or POTS number if we only use
"routing numbers" address family.  The TRIP table will contain Cxxxx
prefixes and also regular POTS prefixes.  So if the called party number does
not contain the routing prefix, the POTS routing prefixes are checked for
routing.  But if it contains the routing prefix such as Cxxxx, the Cxxxx
prefixes in the same routing table are checked for routing.  The key point
is that only one TRIP routing table is needed.

- For countries that do not support NP, the POTS numbers can be viewed as
the routing numbers.  So we still have just one TRIP routing table/address
family.

Please note that the routing number will not contain digit F that was
pointed out by Monika Muench in  an earlier e-mail discussion (I'm not sure
whether it was posted to iptel or sip discussion list).

James

James Yu
Principal Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue, NW,
Suite 550
Washington, D.C. 20005
USA
+1-202-533-2814 (B)
+1-202-533-2976 (Fax)
+1-202-256-1200 (Mobile)
[email-masked]
http://www.neustar.com

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

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

---

From: James Yu <[email-masked]>
Date: Wed, 9 Aug 2000 11:10:17 -0500

Gary,

If a number is not ported, the ISUP Called Party Number (CdPN) parameter
will still contain the POTS number, but the Translated Called Number
Indicator (TCNI) bit in the ISUP Forward Call Indicator (FCI) parameter is
set to imply that NPDB query has already been performed.  This is because
the NP database today only contains records assoicated with the ported-out
numbers.  There are no records in the NP databases (in the U.S. and Canada)
for those POTS numbers that are not ported out from the "donor switch," the
switch that is allocated a block of numbers (e.g., 202-533-xxxx).

The way ISUP routing is designed to support NP is so that switches that need
not understand NP are not impacted by NP (e.g., backward compatibility).
Those switches always analyze the ISUP CdPN parameter to determine call
routing.  Today, they analyze the first 6 digits of the "national" CdPN to
route the call.

James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2000 3:42 PM
> To: James Yu
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: [IPTEL] [TRIP] Address Families in 
> draft-ietf-iptel-trip-03
> 
> 
> 
>

---

From: [email-masked]
Date: Thu, 10 Aug 2000 00:21:03 -0600

This is a really confusing issue, but I think I agree with Mr. Yu that only
one address family is necessary for telephone-number based routing.

Firstly, I suppose nothing prevents a network administrator from using only
the "routing number" TRIP address family for both POTS numbers and LRNs;
after all, "routing number" seems to be a superset of "POTS number", and
these guys provision the GWs that are the roots of propagated routes.

I take some exception to the notion that an LRN does not represent a
destination. It represents the machine that is the ultimate destination of
signaling; I don't think that it should be excluded because it does not
represent a subscriber - one might similarly exclude TRIP for service logic.
I also do not think that a GWs relationship to this sort of address is
substantially different from that of a 'POTS' address - either address is
passed in a PSTN call-setup message to a switch that the gateway faces.

As Mr. Yu pointed out, it wouldn't be terribly difficult to internationalize
"routed numbers" - and in fact, doing so might facilitate aggregation
(especially if one is willing to allow the somewhat distasteful notion of
allowing different aggregation rules to be associated with different
national prefixes - which in practice might not be terrible to implement).
Dave Walker's recent proposal for using Carrier ID Codes in TRIP similarly
suggested an internationalizing prefix.

Finally, I think that the specifics of the VoIP signaling protocol used to
set up calls might make some options here more attractive than others. If
the VoIP protocol effectively distinguishes between the CPN and the LRN
(which I think it must if it hopes to map to SS7), and separate TRIP address
families are used for each, then it isn't obvious to me why, as an SS7 GW
operator, I would not have to propagate the same set of routes for both
address families.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: James Yu [mailto:[email-masked]]
Sent: Wednesday, August 09, 2000 1:41 PM
To: 'Jonathan Rosenberg'; [email-masked]
Cc: [email-masked]'
Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03

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

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2000 10:02 PM
> To: [email-masked]
> Cc: James Yu; [email-masked]'
> "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
>

---

From: [email-masked]
Date: Thu, 10 Aug 2000 18:15:09 -0400

James,

Perhaps I misinterpreted your statement in your second bullet below, extracted
here:
     "For example, if the POTS number is 202-533-1234 and is not ported, a LRN
of 202-533-0000 can be used
      as the LRN for routing the call."

  It appeared to me you were saying that an LRN would be used to route a call to
a non-ported number.

Thanks,

Gary

"James Yu" <[email-masked]> on 08/09/2000 12:10:17 PM

 To:      "[email-masked]'"                        
          <[email-masked]>                          

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

Gary,

James

---

From: James Yu <[email-masked]>
Date: Fri, 11 Aug 2000 20:31:14 -0500

Gary,

I was trying to say that LRN "could" or "can" be used for non-ported number;
but in real world, LRN is not used.  The non-ported POTS number remains in
the ISUP Called Party Number parameter and is used to route the call to the
destination (the donor switch) within the U.S. or Canada. 

James

> Sent: Thursday, August 10, 2000 6:15 PM
> To: James Yu

---

From: James Yu <[email-masked]>
Date: Fri, 18 Aug 2000 10:44:44 -0500

Hussein,

I checked the I-D.  Section 5.1.1.3 seems to imply that "POTS numbers" are
used to "identify actual POTS destinations" and that "routing numbers" are
used "to identify switches and line cards in the switches."   Does the
sentence about "POTS numbers" imply that the POTS numbers are the telephony
subscriber numbers? 

---------
 5.1.1.3 Routing Numbers

   This address family is used to represent Routing Numbers used in
   conjunction with Number Portability (NP). Unlike POTS Numbers, which
   are used to identify actual POTS destinations, Routing Numbers are
   used to identify switches and line cards in the switches. NP and
   routing Numbers are limited in scope to national boundaries.
   Different countries/regions define different routing number formats.
   The Routing Numbers address family defined herein is deemed
   sufficient to encompass all the different formats.
--------

James

> From: Hussein F. Salama [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2000 4:57 PM
> To: James Yu
> Cc: 'Jonathan Rosenberg'; [email-masked]'
> James Yu wrote:
> > What needs to be clearly indicated is that it should not 
> happen that some
> > LSs/GWs announce the reachability of subscriber "POTS 
> numbers" and others
> > announce the reachability of "routing" POTS numbers (e.g., 
> LRNs) in the U.S.
> > and Canada.  Is the current TRIP document very clear and 
> specific about
> > that?
> 
> The Route Types Supported capability says:
> "The Route Types Supported Capability Code lists the route types
>  supported in this peering session by the transmitting LS.  An LS
>  MUST NOT use route types that are not supported by the peer LS in
>  any particular peering session.  If the route types supported by a
>  peer are not satisfactory, an LS MAY terminate the peering session."
> 
> I think we should consider replacing the word "MAY" with "SHOULD" or
> "MUST."
> 
> The above text is sufficient to prevent peer-to-peer capability
> mismatch.  However, it doesn't prevent mismatches across an entire
> domain, because TRIP can't prevent that. May be an application note
> (TRIP applicability) is needed to clarify this issue and othe similar
> issues which may arise in the future.
> 
> Hussein
> 
> 
> 
> 
> > 
> > James
> > 
> > > From: Hussein F. Salama [mailto:[email-masked]]
> > > Sent: Monday, August 14, 2000 7:13 PM
> > > To: James Yu
> > > Cc: 'Jonathan Rosenberg'; [email-masked]'
> > > James Yu wrote:
> > > > In that case, do we just advertis the "POTS number" address
> > > family in the
> > >
> > > Yes, that should be sufficient.
> > >
> > > In general, TRIP defines two address families and also 
> allows peers to
> > > negotiate which address families each peer supports. More address
> > > families can be defined in the future, if needed. I think
> > > that should be
> > > sufficient to satisfy the needs of different applications 
> and regional
> > > requirements.
> > >
> > > Hussein
> > >
> > >
> > > > U.S. and Canada and those numbers are all "routing numbers"
> > > in the format of
> > > > +1+NPA+NXX?
> > > >
> > > > James
> > > >
> > > > > From: Hussein F. Salama [mailto:[email-masked]]
> > > > > Sent: Monday, August 14, 2000 4:42 PM
> > > > > To: James Yu
> > > > > Cc: 'Jonathan Rosenberg'; [email-masked]'
> > > > > James Yu wrote:
> > > > > > Jonathan,
> > > > > > Under NP, the NPA+NXXs in the U.S. and Canada are the
> > > > > "routing numbers" that
> > > > > > are used by the PSTN to route the call.  As indicated
> > > > > before, the LRN for
> > > > > > ported POTS number and the NPA-NXX of the non-ported POTS
> > > > > numbers are used
> > > > > > for routing.  Those numbers are viewed as "routing numbers"
> > > > > in the PSTN
> > > > > > until the calls reach the destination network/switch.
> > > > > >
> > > > > > For a ported POTS number, the destination switch/network
> > > > > retrieves the POTS
> > > > > > number from the ISUP Generic Address Parameter.  Note that
> > > > > the LRN is
> > > > > > carried in the ISUP Called Party Number (CdPN) parameter.
> > > > > For a non-ported
> > > > > > number, the POTS number is retrieved from the CdPN
> > > > > parameter (e.g., no LRN
> > > > > > is used, the "POTS number" is used for routing; therefore,
> > > > > is viewed as the
> > > > > > "routing number" before it reaches the destination
> > > network/switch).
> > > > > >
> > > > > > If a switch serves several NPA+NXXs, one of the NPA+NXXs is
> > > > > used as the LRN
> > > > > > (note that LRN is a ten-digit number, NPA+NXX+XXXX and more
> > > > > than one LRN can
> > > > > > be assigned to a switch).  For a gateway that can reach
> > > > > this switch, the
> > > > > > "routing numbers" it announces would be those NPA+NXXs
> > > > > assigned to that
> > > > > > switch.  The "POTS numbers" it announce would be those POTS
> > > > > numbers that are
> > > > > > served by that switch.  This would include:
> > > > > >
> > > > > > - All the POTS numbers that begin with those NPA+NXXs
> > > > > assigned to that
> > > > > > switch excluding those that have been ported out.
> > > > > > - All the ported POTS numbers to that switch from other
> > > switches.
> > > > > >
> > > > > > If a gateway can reach several switches, then aggregation
> > > > > is performed.  My
> > > > > > understanding of the POTS numbers are that they are the
> > > "subscriber
> > > > > > telephone numbers."
> > > > >
> > > > > POTS-Numbers is just an address family. It does not imply
> > > that numbers
> > > > > carried in that address family must be subscriber telephone
> > > > > numbers. For
> > > > > example, North American LRNs can be advertised using the
> > > POTS-Numbers
> > > > > address family.
> > > > >
> > > > > Hussein
> > > > >
> > > > >
> > > > > May be I have a misunderstanding of the definition of
> > > > > > the "POTS number" address family.
> > > > > >
> > > > > > James
> > > > > >
> > > > > > > Sent: Monday, August 14, 2000 2:37 AM
> > > > > > > To: James Yu
> > > > > > > Cc: [email-masked]; [email-masked]'
> > > > > > > Right, and thats called the "POTS Number" address family.
> > > > > > >
> > > > > > > -Jonathan R.
> > > > > > >
> > > > > > > James Yu wrote:
> > > > > > > >
> > > > > > > > It seems that there may be a need to define the routing
> > > > > > > numbers in such a
> > > > > > > > way (or by implementation?) that allows easy
> > > > > aggregation of "routing
> > > > > > > > numbers" that contain only digits 0 through 9 
> for countries
> > > > > > > that don't use
> > > > > > > > digits A through E in the "routing numbers."
> > > > > > > >
> > > > > > > > James
> > > > > > > >
> > > > > > > > > Sent: Friday, August 11, 2000 12:10 PM
> > > > > > > > > To: [email-masked]
> > > > > > > > > > James Yu wrote:
> > > > > > > > > > > As indicated earlier, the "POTS number"
> > > address family is
> > > > > > > > > a subset of
> > > > > > > > > > > "routing number" address family (not in 
> terms of the
> > > > > > > > > numbers but in terms of
> > > > > > > > > > > allowable digits).  Aggregation needs to be
> > > done for the
> > > > > > > > > "routing numbers"
> > > > > > > > > > > anyway if digits A through E may appear 
> in the routing
> > > > > > > > > numbers.   So you are
> > > > > > > > > > > not totally avoiding the problem.  If you need to
> > > > > > > > > aggregate for the routing
> > > > > > > > > > > numbers and one "routing number" table can do
> > > the work,
> > > > > > > > > why announcing the
> > > > > > > > > > > additional "POTS numbers" and managing an 
> additional
> > > > > > > > > "POTS number table at
> > > > > > > > > > > the LSs just because it is easier to 
> aggregate that
> > > > > > > > > address family (this is
> > > > > > > > > > > an "extra" work).  Under country code 1,
> > > digits A through
> > > > > > > > > E are not used.
> > > > > > > > > > > It is then easy to aggregate the "routing
> > > numbers" under
> > > > > > > > > country code 1.
> > > > > > > > > >
> > > > > > > > > > I prefer having two separate address families
> > > to having a
> > > > > > > > > single address
> > > > > > > > > > family with two, or may be more, sets of aggregation
> > > > > > > rules. Deciding
> > > > > > > > > > which set of aggregation rules to use based 
> on the first
> > > > > > > > > digit of the
> > > > > > > > > > prefix is too restrictive. For example, I can
> > > imagine TRIP
> > > > > > > > > applications,
> > > > > > > > > > with limited scope, local or national, 
> which advertise
> > > > > > > > > numbers without
> > > > > > > > > > prepending the country code to them. Hence we won't
> > > > > > > have the '1' to
> > > > > > > > > > decide which aggregation rules to use?
> > > > > > > > >
> > > > > > > > > THe other issue is that you are forced to do
> > > semantic based
> > > > > > > > > aggregation.
> > > > > > > > > We want to
> > > > > > > > > allow (but not mandate of course)aggregation of
> > > numbers based
> > > > > > > > > on syntax
> > > > > > > > > ONLY (i.e., I have 11, 12, 13 14, ... 10, and
> > > > > > > > > since there are ten digits, I can aggregate 
> to 1). This
> > > > > > > NECESSITATES
> > > > > > > > > knowing the number
> > > > > > > > > of digits that exist.
> > > > > > > > >
> > > > > > > > > -Jonathan R.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Jonathan D. Rosenberg                       72
> > > Eagle Rock Ave.
> > > > > > > > > Chief Scientist                             
> First Floor
> > > > > > > > > dynamicsoft                                 East
> > > > > Hanover, NJ 07936
> > > > > 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
> > > > >
> > >
> > > --
> > > 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
> > >
> > >
> 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
>