Subject: [drinks] The NP use-case

From: Otmar Lendl <[email-masked]>
Date: Wed, 10 Nov 2010 10:26:41 +0100

Alex told me that this came up in yesterday's session, and asked me to
elaborate:

On 21.07.2010 15:47, Otmar Lendl wrote:
> 
>> 3.7.  Category: Number Portability
>>
>>   UC NP #1  EDITOR's NOTE: Need to clarify this further.
>>
>>
>>             The SSP wishes to provide in query response to public
>>             identifiers an associated routing number or RN.  This is
>>             the case when a set of public identifiers is no longer
>>             associated with original SSP but have been ported to a
>>             recipient SSP who provides access to these identifiers via
>>             a switch on the SS7 network identified by the RN.  In this
>>             case a destination group containing all numbers that should
>>             be routed to this RN needs to be created and the route
>>             group associated with this DG needs to contain the RN
> 
> I do not think this is a good idea.
> 

[ I'm not 100% sure I know how RNs are assigend and used in the NANP, I
only know how they operate under +43, so I might be completely off-base here. ]

It's been I while, but if I remember correctly, I had the following problem
with this:

In my mind, the main feature of DGs is that of aggregation: I can group
destinations together and can make routing decisions based on the DGs, and
not individual numbers. This shrinks the routing-table down from
O(#TNs in use) to O(#operators * #service-areas). That is a difference of
several orders of magnitude.

This makes a dynamic routing-protocol based on DGs possible. (Just imagine
how BGP would just fall over and die if it had to deal with /32 routes for
all hosts on the Internet.)

The TN->RN mapping is a good use-case for the DRINKs protocol. But leave
DGs and RGs out of it. The RN is an attribute of the TN, not of the DG.

In my opinion, the TN->RN mapping is a simple querier-independent lookup
process, not a routing decision. We thus don't need the selective
visibility features that are built into RouteGroups. Pure overkill.

Furthermore, RN are not SED. They do not immediately tell the switch what
to do with the call: they are the INPUT to the PSTN call routing algorithm,
not the result.

In Drinks terms, I'd recommend the following:

* Allow RNs as an attribute of the TN-Range object. (I have little clue
whether it would be helpful to allow regex here to work on real ranges and
not just individual numbers. Open numbering plans probably need this.)

* Alternatively, allow a RN object to list the TN which it serves.

* On the querying side, a query for a TN thus returns also the RN, which is
then the input for the next query.

HTH.

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: David Schwartz <[email-masked]>
Date: Wed, 10 Nov 2010 13:06:02 +0200

So first of all my apologies for missing the discussion - time zone difference made it kind of hard to attend.

Comments inline...

:D

> several orders of magnitude.
DS: Agreed

> DGs and RGs out of it. The RN is an attribute of the TN, not of the DG.

DS: imho this is only partially true. I completely agree that RNs are attributes of TNs (LUF), however, they are used as well in routing responses (yes LRF --> "just route via PSTN and here is the information you need") and as such do belong (at least the carrier prefix part of it) on the routing side. As for the scaling issue, the solution is to regroup ported numbers into new DGs that share the same RNs. In other words, it is true that the porting process is a 1-1 where an 11 digit number is associated with a routing number, however, there are probably many ported numbers associated with any one RN such that aggregation makes sense.
> visibility features that are built into RouteGroups. Pure overkill.

DS: hummm. Not sure. In Europe, RNs are displayed as prefixes to the user info while in the US they are returned as "rn=..." tags so there is some level of querier dependency. Since this is geography based more than originator based I remian on the fence on this issue. Am OK leaving it as it is.
> to do with the call: they are the INPUT to the PSTN call routing algorithm,

DS: They do tell you what to do --> route via PSTN (an IP representing a PSTN GW) which is no different than route to an IP representing a SIP based SBC.

> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Wed, 10 Nov 2010 08:49:02 -0500

So in the US an NP rn is an LRN; it identifies a PSTN end office switch/
point of interface (some switches serve multiple Local Access and
Transport Areas; they need an LRN per LATA). I suspect that there are
probably many more LRNs than there will be ingress points in SIP
interconnection. (There ought to be! If not we are missing the whole
point of the evolution to IP interconnect).

With this in mind I find myself coming out a little closer to Otmar's
position. 

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Schwartz
Sent: Wednesday, November 10, 2010 6:06 AM
To: Otmar Lendl
Cc: IETF DRINKS WG
Subject: Re: [drinks] The NP use-case

So first of all my apologies for missing the discussion - time zone
difference made it kind of hard to attend.

Comments inline...

:D

DS: Agreed

> DGs and RGs out of it. The RN is an attribute of the TN, not of the
DG.

DS: imho this is only partially true. I completely agree that RNs are
attributes of TNs (LUF), however, they are used as well in routing
responses (yes LRF --> "just route via PSTN and here is the information
you need") and as such do belong (at least the carrier prefix part of
it) on the routing side. As for the scaling issue, the solution is to
regroup ported numbers into new DGs that share the same RNs. In other
words, it is true that the porting process is a 1-1 where an 11 digit
number is associated with a routing number, however, there are probably
many ported numbers associated with any one RN such that aggregation
makes sense.
> visibility features that are built into RouteGroups. Pure overkill.

DS: hummm. Not sure. In Europe, RNs are displayed as prefixes to the
user info while in the US they are returned as "rn=..." tags so there is
some level of querier dependency. Since this is geography based more
than originator based I remian on the fence on this issue. Am OK leaving
it as it is.
> to do with the call: they are the INPUT to the PSTN call routing
algorithm,

DS: They do tell you what to do --> route via PSTN (an IP representing a
PSTN GW) which is no different than route to an IP representing a SIP
based SBC.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 10 Nov 2010 09:38:30 -0500

I'm not a fan of this use case.  In fact I do not at all remember it being in the document in this form the last time I reviewed the document from top to bottom.  The protocol certainly does not do anything to explicitly support this use case.  What the protocol needs in terms of RNs is the ability to provision RNs into DGs.  The management of the relationship between an RN and TNs is not directly in scope for SPPP.  We decided this several months ago, and correctly so.  In north america, for example, the relationship between an RN and TNs is managed by the NPAC.

Ken
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Otmar Lendl [[email-masked]]
Sent: Wednesday, November 10, 2010 4:26 AM
To: IETF DRINKS WG
Subject: [drinks] The NP use-case

HTH.

otmar

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.