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

From: "Jeff Hinchey" <[email-masked]>
Date: Mon, 12 Feb 2001 15:36:53 -0500

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. 

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]]
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:
>
> >
> >
> > 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?
>
> 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
>
> >
> >
> > Jeff Hinchey
> > Succession Network Architecture                           Nortel
> > Networks
> > 613 763 8007 / 613 765 4881 (fax)                       3500 Carling
> > Ave.
> > [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
>
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML

--
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: "Hussein F. Salama" <[email-masked]>
Date: Tue, 13 Feb 2001 12:38:36 -0800

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

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

> We, TRIP's authors, had a long discussion about the NoA field a few
> months ago. At
> prefixes used in that domain. So the NoA can be inferred from the
> prefix. This is
> 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