Subject: RE: [IPTEL] TRIP question on routing numbers

From: Scott Cadzow <[email-masked]>
Date: Thu, 8 Feb 2001 08:53:13 +0100

Is there a confusion between routing number and subscriber (or dialled)
number? Conventionally telephone users do not enter a routing number (in
real terms an address in numeric form). The dialling plan may however imply
certain routing restrictions/rules based upon the dialled number.
 
Scott Cadzow, ETSI

-----Original Message-----
From: Jeff Hinchey [mailto:[email-masked]]
Sent: 07 February 2001 11:01 PM
To: [email-masked]'
Subject: [IPTEL] TRIP question on routing numbers

I was reviewing the latest version of the TRIP draft and was a little
confused over a statement in section 5.1.1.2, second paragraph, which reads:

	"The type of Decimal Routing Number (private, local, national, or
international) can be deduced from the first few digits of the prefix"

How is this accomplished? Telephone numbers only have meaning within the
context of a specific number plan. E.164 public numbers and numbers from
private number plans can begin with the same digits. Also, there is no way
to determine if a public number is local, national or international based on
leading digits. There is no reliable way to determine what number plan a
number belongs to from only the number itself. 

Is the intent to include dial plan prefixes in addition to numbering plan
addressing information in the routing numbers specified in the TRIP route?
If so, how will this work when TRIP information is disseminated between
ITADs serving different regions with different dial plans?

Jeff Hinchey 
Succession Network Architecture                           Nortel Networks 
613 763 8007 / 613 765 4881 (fax)                       3500 Carling Ave. 
[email-masked]                               Nepean, Canada
K2H 8E9

---

From: "Anderson, Darby" <[email-masked]>
Date: Thu, 8 Feb 2001 14:31:24 -0800

I know this is kinda off the beaten path of what the current conversation
is,but still quazi-related...
 
Is there/Will there be any convention of a ITAD Regestration dirrectory, and
if so,where/how will someone be able to view it, and also InLieu of TRIP not
yet being a finialized protocol,is there anything similar to a VoIP Gateway
Service Provider Dirrectory out there CURRENTLY?

-----Original Message-----
From: Scott Cadzow [mailto:[email-masked]]
Sent: Thursday, February 08, 2001 12:53 AM
To: 'Jeff Hinchey'; [email-masked]'
Subject: RE: [IPTEL] TRIP question on routing numbers

Scott Cadzow, ETSI

-----Original Message-----
From: Jeff Hinchey [mailto:[email-masked]]
Sent: 07 February 2001 11:01 PM
To: [email-masked]'
Subject: [IPTEL] TRIP question on routing numbers

Jeff Hinchey

---

From: "Jeff Hinchey" <[email-masked]>
Date: Tue, 20 Feb 2001 11:53:21 -0500

Sorry for not responding sooner, I've been busied out since mid last week.
Please see my response to your questions in line below.
 
-----Original Message-----
From: Hussein F. Salama [mailto:[email-masked]]
Sent: February 13, 2001 3:39 PM
To: Hinchey, Jeff [CAR:VS00-M:EXCH]
Cc: [email-masked]'
Subject: Re: [IPTEL] TRIP question on routing numbers

Jeff Hinchey wrote: 

Hussein, 

I'm trying to envision how the exchange of TRIP routing numbers will be
managed given they include dial plan prefixes. I see this being very complex
and error prone. 

You suggest that an LS can manipulate the prefixes used with the routing
numbers forwarded in UPDATE messages into a format understandable by peer
LSs. This implies that for ITADs which serve multiple regions with differing
dial plans and ITADs with peering relationships with other ITADs serving
regions with differing dial plans, UPDATEs between peers will need to be
manipulated potentially on a per peer basis. Routing numbers in UPDATEs must
be formatted according to the LS to which they are being sent. 

- How are these LS-LS prefix mapping relationships established, how are they
kept in sync? I understand this is outside the scope of TRIP, but will
necessary in order for TRIP to be useful. If too complex to manage, TRIP
loses its utility. 

- How is route selection performed? Again, outside the scope of TRIP but
directly impacted by the way route information is communicated in TRIP. For
example, a route may be selected in ITAD A based on matching routing number
information with dial plan prefix X that directs call signaling to a
NextHopServer in ITAD B. The ITAD B server then queries its own LS to
determine its preferred route and the next NextHopServer. Given ITAD B uses
different prefixes than ITAD A, the called number information in the call
signaling will need to be manipulated into ITAD B's routing number prefix
format in order to correctly query ITAD B's LS. 

- If the same route can be represented with different routing number
information (different prefixes) in different ITADs/LSs, how is route
aggregation performed? What is the impact to flooding within an ITAD and
routing loop detection? 

- This approach implies that a single LS can only represent routes from a
single region delimited by dial plan. There may be instances where a single
LS could serve many regions if not for this restriction.  

I suggest it would be much simpler if TRIP routing numbers where based on
numbering plans (endpoint address/alias, fixed, independent of regional dial
plan) rather than dialing plans (method by which the numbering plan is used,
varies from region to region). Within the context of a given number plan,
each number/address/alias is unique. Routing numbers and associated number
plan can be passed around in UPDATEs and used independent of regional dial
plan without the need to manipulate prefix digits.

Can the number plan identifier be translated by an LS at the egress of an
ITAD?  Otherwise certain number plans will be confined to the their local
domains. 

[JH] Let expand on my original notes to clarify.
 
Public numbering plan:
 
There is only one public number plan, E.164. A single, predefined number
plan id can be assigned for use with E.164 public routes within and between
all ITADs, therefore no need to translate/map the number plan id. All public
routes are expressed in E.164 format (fully qualified number or a prefix of
a fully qualified number range), therefore no need to manipulate routes when
exchanged in UPDATEs between LSs and ITADs.
 
Private numbering plans:
 
A private numbering plan is established and administered by a private
Enterprise or by a service providers on behalf of an Enterprise. An ITAD
being a service provider for an Enterprise defines the numbering plan and
associated private routes (the VPN). 
 
Typically an Enterprise VPN is served by a single service provider, and
there is no need to exchange the private route information outside of the
ITAD. If an Enterprise VPN is served by more than one service provider, then
the ITADs must agree on a common private number plan id or map at the egress
LSs which exchange private route info (your point above).
 
Within the private numbering plan, routes are expressed in fully qualified
format as with public routes, therefore no need to manipulate routes when
exchanged in UPDATEs between LSs (or ITADs if multiple serve the VPN).
 
 For example what will happen to a few local routes when they reach an LS at
the egress of that local ITAD? Will they be simply dropped and nothing else?
I think the LS should aggregate these local routes, prepend the appropriate
area code, translate the number plan identifier, then advertise outside the
ITAD. But since it has to prepend the area code anyways, what's the need for
the number plan identifier? 

Hussein

[JH] The key here is to separate dialing and numbering plans, express routes
in a fully qualified number format and avoid configuring and mapping between
routes which are local, national or international in the context of regional
dial plans. For example, my office phone is associated with the fully
qualified public E.164 number of 16137638007 (where CC=1, NDC=613,
STN=7638007) and a fully qualified private Nortel Networks number 3938007.
Consider the following use cases:

Originating Dial Plan    Dialed Digits   Note

Ottawa public            7638007         local abbreviated dialing

New York public          16137638007     leading 1 is the toll prefix, not
CC

UK public                0016137638007   Intl prefix plus fully qualified
E.164 number

Ottawa Nortel private    38007           local abbreviated extension dialing

UK Nortel private        63938007        inter site prefix plus fully
qualified number

Consider the Ottawa public case. Somewhere abbreviated dialing formats must
be taken into account so that it can be determined that 7638007 implies
16137638007 instead of 18197638007 (Ottawa supports abbreviated 7 digit
dialing spanning area codes 613 and 819). Building this knowledge into the
routing databases with local, national and international routes will require
manipulation of routing info passed between LSs (even within an ITAD),
implying LSs must have knowledge of all the dial plan formats associated
with the routes they exchange in order to manipulate the routing prefix
digits correctly. This also implies that multiple routing databases must be
maintained to handle originations to the same number from originators with
different regional dial plans. 

I suggest that digit manipulation should occur upon call origination, at the
originating access device and/or host server, which, with knowledge of the
local dial plan can extract called number information from the dialed input
and convert to a fully qualified format. The originating access
device/server must have at least basic knowledge of the local dial plan of
the originator in order to determine when enough digits have been collected
(otherwise call set up times become excessive) and what type of routing to
apply (for example operator assist (not TRIP trip enabled) versus called
number (TRIP enabled)) Adding the ability to fully qualified the called
number shouldn't be much of a stretch and is also required many cases anyway
(for example NA LNP where the number must fully qualified to the national
level in order to perform a portability check).

To handle routing of public calls to my office phone, the ITAD providing
public routes to Nortel Networks in Ottawa would configure an E.164 route as
1613763, a fully qualified number prefix under which all numbers are
associated with Nortel Networks. This route information can be exchanged and
aggregated with other ITADs in the context of the global E.164 public
numbering plan without having to manipulate route info between ITADs.

Consider the Ottawa Nortel private case. Again, the dialed number (38007) is
abbreviated and can be fully qualified (3938007) in the context of the
private dial plan. The ITAD providing VPN/private routes for Nortel Network
would configure a corresponding Nortel route as 39 to route to the
NextHopServer serving the Ottawa portion of the VPN. This route is
applicable to both calls originated in the Ottawa and the UK regions of the
VPN. A single routing database can be used for calls originated from any
location within the Nortel Networks' VPN.

I believe this scheme could be implemented quite easily by introducing a new
"Fully Qualified E.164" Address Family to TRIP. A range of Address Families
could also be reserved for use with VPNs/private numbering plans within
ITADs. 

Using this approach will drastically reduce the number of TRIP routes that
need to administered and remove the need for complex mapping to occur when
TRIP routes are exchanged in UPDATE messages.

The existing E.164 standard provides for fully qualified numbers which are
globally unique within the public numbering plan. Although there are no
specific standards, the same concept applies to private number plans. The
combination of a numbering plan identifier and fully qualified number can be
used to uniquely identify an endpoint (and number ranges used to identify
routes to endpoints) independent of region and dial plan. 

Public routing numbers expressed in and identified as E.164 format can be
exchanged within and between ITADs without requiring any
conversion/manipulation of numbers between LSs. Within an ITAD, private
numbering plan identifiers (VPNs) can be easily standardized to accomplish
the same. I can't think of a scenario requiring private routing numbers to
be exchanged between ITADs as all ITADs except for the ITAD serving the VPN
would route calls based on an E.164 number associated with the private
network. If a private network was served by multiple ITADs, then a private
numbering plan identifier would need to be agreed upon between the ITADs. 

With this approach, the responsibility for understanding dial plans is
pushed to the access devices and/or associated call servers which already
have this knowledge in order to parse end user input to determine call
intent. Using this knowledge, the originating access device/call server can
interpret dialed digits in the context of the appropriate regional dial plan
to extract called number information and create a fully qualified number.
The fully qualified number and its numbering plan identifier can then be
used to query an LS for routing information. This approach removes the need
for TRIP implementations and administrators to deal with dialing plans and
as such regional variations in dialing plan formats/prefix digits.

 Feedback welcome. 

-----Original Message----- 
From: Hussein F. Salama [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: February 9, 2001 2:21 AM 
To: Philip Mart 
Cc: Hinchey, Jeff [CAR:VS00-M:EXCH]; [email-masked]' 
Subject: Re: [IPTEL] TRIP question on routing numbers 

Philip Mart wrote: 

> Hussein, 
> 
> If prefixes are to be included where are they specified so that
implementations 
> may interoperate? 

Not in TRIP. TRIP's specification of the address families is loose, on
purpose, to 
maximize the utility of the protocol with different number plans. 

> I guess I should also ask why a "Nature of Address" field 
> wasn't included instead of the unspecified prefixes? 

We, TRIP's authors, had a long discussion about the NoA field a few months
ago. At 
the end, we decided , we don't need an NoA field, because when an
administrator 
places an LS in a certain domain, it will definitely know the meaning of the

prefixes used in that domain. So the NoA can be inferred from the prefix.
This is 
identical to the case with IP routing. 

A TRIP LS located at the egress from an ITAD may have to manipulate the
prefix by 
prependinng/stripping off digits as necessary before forwarding an UPDATE to
its 
inter-domain peer in order to accommodate the prefix conventions in that
peer's 
ITAD. 

Hussein 

> This would have the 
> advantage of not mandating a particular national, local or even
hypothetical 
> dialling plan which may in any case conflict with interconnect
arrangements. 
> 
> Phil Mart 
> 
> "Hussein F. Salama" <[email-masked]> on 08/02/2001 03:37:36 
> 
> Please respond to [email-masked] 
> 
>  To:      Jeff Hinchey <[email-masked]> 
>  cc:      "[email-masked]'" 
>           <[email-masked]>(bcc: Philip 
>           Mart/MAIN/MC1) 
>  Subject: Re: [IPTEL] TRIP question on routing numbers 
> 
> Jeff Hinchey wrote: 
> 
> > 
> > How is this accomplished? Telephone numbers only have meaning within 
> > the context of a specific number plan. E.164 public numbers and 
> > numbers from private number plans can begin with the same digits. 
> > Also, there is no way to determine if a public number is local, 
> > national or international based on leading digits. There is no 
> > reliable way to determine what number plan a number belongs to from 
> > only the number itself. 
> > 
> > Is the intent to include dial plan prefixes in addition to numbering 
> > plan addressing information in the routing numbers specified in the 
> > TRIP route? 
> 
> Yes, otherwise how can an LS differentiate between a local prefix, a 
> national prefix, and international prefix? 
> 
> > If so, how will this work when TRIP information is disseminated 
> > between ITADs serving different regions with different dial plans? 
> 
> A TRIP LS located at the egress from an ITAD may have to manipulate the 
> prefix by prependinng/stripping off digits as necessary. 
> 
> Hussein

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 25 Feb 2001 20:22:06 -0500

Let me clarify here, at least based on my understanding. 

There was never an intention that TRIP would be used to exchange numbers in
local dialing plans. This is well known to be frought with problems, as has
been pointed out. Numbers represented as E.164 numbers would be exchanged
within the decimal address family.

However, it has been pointed out that we would like to use TRIP in
environments where routing numbers would be used. These, apparently, have a
different format, and in particular, they can have letters in some European
country. So, these numbers would be exchanged via the penta-decimal address
family.

What Hussein has been implying is that configuration of the LS would be used
to determine whether a peer was sending E.164 numbers, for example, or
whether trip was being deployed in some other, more unusual, locale, where
some other number type was being exchanged within the decimal address
family. THis gives us flexibility to use TRIP in a variety of different
applications.

Hopefully Hussein, James Yu, and others involved in this decision will
correct me or provide additional clarification.

I'd like to resolve this quickly (I think its just a misunderstanding), so
we can rev trip and then send the revised version to iesg.

-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: (973) 952-5000
http://www.dynamicsoft.com

> From: Philip Mart [mailto:[email-masked]]
> Sent: Thursday, February 08, 2001 7:52 AM
> To: [email-masked]
> Cc: Jeff Hinchey; [email-masked]'
> If prefixes are to be included where are they specified so 
> that implementations
> may interoperate? I guess I should also ask why a "Nature of 
> Address" field
> wasn't included instead of the unspecified prefixes? This 
> would have the
> advantage of not mandating a particular national, local or 
> even hypothetical
> dialling plan which may in any case conflict with 
> interconnect arrangements.
> 
> Phil Mart
> 
> 
> 
> 
> 
> 
> 
> > confused over a statement in section 5.1.1.2, second 
> paragraph, which
> > reads:
> >
> > [email-masked]                               Nepean,
> > Canada  K2H 8E9
> >
> 
> --
> Hussein F. Salama
> Cisco Systems
> Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134
> Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147
> 
> 
> 

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

---

From: James Yu <[email-masked]>
Date: Wed, 28 Feb 2001 09:00:58 -0600

As Jonathan pointed out, TRIP is used to exchange "routing numbers," which
can be decimal or hexadecimal.  Normally, international numbers are used;
however, national numbers can be used if there is an agreement between two
domains.  It is not clear when local numbers and private numbers may be used
as was pointed out by you.  May be Hussein can explain.

James 

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Sunday, February 25, 2001 8:22 PM
> To: Philip Mart; [email-masked]
> > >      international) can be deduced from the first few 
> digits of the
> > >      prefix"
> > >
> > > 613 763 8007 / 613 765 4881 (fax)                       
> 3500 Carling
> > > Ave.