Print this page Print NPIF » NANC Change Orders » NANC 370

NANC 370

NPAC Maintenance Mode

Origination Date :10/23/2002

Originator:Neustar

Description:

Business Need:

The NPAC and Service Provider’s SOA/LSMS exchange messages over a CMIP association.  The current implementation supports one of two scenarios:

 

  1. The SOA/LSMS is associated with the NPAC, and messages are exchanged over that interface.
  2. The SOA/LSMS is NOT associated with the NPAC, and NO messages are exchanged over that interface.

 

Currently, the NPAC doesn’t support a “maintenance mode” (hybrid of 1 and 2) where SOA/LSMS associations are maintained, but porting activities are not allowed.  This means that with the current implementation, the NPAC allows porting activities to continue during Service Provider maintenance windows.  Service Providers who are not doing maintenance can continue porting activities, which in turn generate partial failures as well as notifications.  All of this activity must be recovered by Service Providers that do perform maintenance when they associate their SOA/LSMS systems with the NPAC, yielding even more notifications.  Additionally, an NPAC maintenance mode will allow NeuStar to perform most of the required NPAC maintenance while maintaining service provider associations.

 NeuStar presented this to the NAPM LLC, who requested that NeuStar propose an approach and the required system modifications to keep associations alive, while not allowing any transactions to be created by Service Providers.

Final Resolution:

Interface and Functional Backwards Compatible:  NO

Nov ’02 LNPAWG, Jim Rooks explained that a large percentage (~80%) of NPAC maintenance (e.g., DB maintenance) can be performed while holding a Service Provider’s association.  NeuStar would use the approach where the system is quiesced and therefore won’t accept any further activity to process.  A universal benefit for all parties, as the NPAC maintains associations for Service Providers that are not taking any maintenance, and therefore, don’t need to unnecessarily abort/re-associate.

 

Colleen Collard (Tekelec) expressed a concern about backwards compatibility, which will be discussed during the once detailed requirements are drafted.  The group did discuss possible solutions to the backwards compatibility issue.

 

Jim Rooks stated that the industry could look into two modes, the one initially documented in this change order, and a second mode where a limited set of functionality is available over the interface.  We could also look into allowing Service Provider’s to come back up (i.e., bind) in non-recovery mode, but still during the maintenance window to address a concern raised by Sean Hawkins (AWE).  This is because of possible notifications that would be sent to other SPs if the binding SP caused notifications to occur.

 

All of these issues will be revisited.

 

Dec ’02 LNPAWG, include text indicating a large impact to inter-op testing to handle the processing failure message.

 

Jim Rooks also explained a second option, where some Service Providers are in maintenance, the NPAC is available, and the NPAC imposes restrictions on the types of messages that the other Service Providers are allowed to submit to the NPAC.

 

Feb ’03 LNPAWG, Dave Garner (Qwest), requested that text be added of our initial discussions regarding maintenance mode.  This included, rejecting association binds, but allowing queries for SPs associated when maintenance mode is initiated (maybe more types of transactions, but will be decided during the analysis phase).  This functionality is considered phase I, nothing yet for phase II.

 

Jim Rooks (NeuStar) indicated that we really need two modes, one that allows queries (for example, maintenance where the NPAC was doing application updates), and non-query mode (for example, maintenance where the NPAC was doing DB maintenance - rebuilding indexes, so the database would not be available, so queries would not be allowed).

 

A third mode was also discussed where the NPAC was performing maintenance that did not allow existing associations to be maintained (for example, a system upgrade that required the production server to be rebooted).

 

Mar/Apr ’03 LNPAWG – Major points/processing flow/high-level requirements:

  1. NeuStar will work with the industry to determine maintenance dates (same as today), and also the type of maintenance and it’s associated maintenance mode.
  2. There will be three different maintenance modes:
    • Mode – No Service Available.  During this mode, the NPAC is performing maintenance that does NOT allow existing associations to be maintained.  An example would be a system upgrade that requires production servers to be rebooted.
    • Mode – Non-query Functionality.  During this mode, the NPAC is performing maintenance that does allow existing associations to be maintained, but does NOT allow any type of query functionality.  An example would be a database upgrade that requires indexes to be rebuilt, so the database would not be available.
    • Mode – Query Functionality.  During this mode, the NPAC is performing maintenance that does allow existing associations to be maintained and also allow query functionality.  An example would be an application upgrade that does not affect router functionality or the database.
  3. For this change order, only modes 2b and 2b are discussed.  Mode 2a is the same as the current unavailable mode.

Related Release:

N/A

Status: Closed