Date: Fri, 8 Aug 1997 21:56:12 -0500

From: /DDV=mdfassoc@mindspring.com/DDT=RFC-822/OU=SMTP/P=AMRTCH4/A=MCI/C=US/

Subject: RE: Midwest LNP SCP Call Reminder & Pooling Info

To: "'WAYNE HEINMILLER'" <>

Wayne,

I'd like to provide some additional information on the status of range

downloads from the NPAC. The range download operation the NPAC SMS

supports today is part of the mandatory functionality that all LSMSs and

SOAs must demonstrate in order to obtain their IIS interoperability

certification with the NPAC. So, all of the LSMSs must provide this

functionality today. Their ability to forward range-operations downstream

to the SCPs is the obvious next question.

If not, the problem may be that most of the LSMS vendors developed their

local database around TN-level records, and so currently have no way to

maintain range-level semantics downstream. Once the download is received

at the LSMS, if it populates individual TN records and queues them up for

download, then they'll appear to the SCPs as individual records.

In any case, the NPAC/SMS subcommittee is not planning on changing the

range download operation in release 2, other than to add a new code point

for the LNP-type indicator which is currently in the downloaded record.

There are currently two values, LSSP (normal service provider port), and

LISP (intra-provider port, AKA location port). For pooling, we'll add a

third value, POOL to indicate the port is for a pooled number.

Consequently, LSMS/SCP vendors could start today developing the necessary

enhancements to support a two-level record scheme, which could be

introduced with or without pooling independent of the release 2 cycle. It

is my understanding that the LSMS/SCP currently ignores the LNP-type field,

since the record contents and processing for both types are otherwise

identical. Other than capacity concerns, I'm under the impression that no

additional LSMS/SCP functionality is absolutely required to commence

pooling. Consequently, there should be minimal problems with the

previously scheduled NANC release 2 deployment activities on 2/20/98.

It would be useful if you could socialize this with the SCP subcommittee.

It would also be worthwhile understanding when this capability could start

to be introduced by the vendors. At that time, it would seem that

pre-porting would be essential in order to obtain range-records from the

NPAC for use in the LSMS/SCPs using the two-table lookup scheme. The

compatibility of pre-porting vs. on-demand with the long-term SCP capacity

strategy should be injected into the policy debate.

R, Mark

---------------------------------------------------------------

Mark D. Foster | mdfassoc@mindspring.com

MDF Associates | Tel: +1(703) 404-2258

Telecoms Consulting | Fax: +1(703) 404-2591