NANC 407

NPAC Range Operations and Associated Notifications

Origination Date :09/01/2005

Originator:Neustar

Description:

Currently some activities are impacting range operations as follows:

  • Some Service Providers are creating SVs in TN ranges, and then sending subsequent requests (modify, activate, disconnect, cancel) as a single TN.
  • To support NANC 179 – Range Notifications, the NPAC must maintain range information from the original create request.
  • In a distributed environment, maintenance of the range information must be kept consistent using application locks.
  • All requests operating on the range must acquire an exclusive lock to ensure consistency of the range information while it’s being updated.
  • Providers that rapidly send single requests on a group of TNs that were originally created in a range will incur delays and potentially failures as a result of lock contention.

Situations where locks are denied or failed causes misses in the NPAC response time requirement (SLR3).

This change order recommends that NPAC incorporate logical range decomposition to alleviate problems with range operations when subsequent activity is for less than the full range submitted in the initial create request:

  • The NPAC will break up range information into singles upon receipt of the first request that doesn’t match the original create range.
  • The assumption is that a single request indicates the provider isn’t going to use range operations.
  • This will have the side effect of causing single notifications in the event T1 or T2 expire after the subsequent request.

Range requests from providers will still have the potential to generate range notifications (based on support of NANC 179). 

Final Resolution:

Add to the IIS, section 2.3.3 Notifications:

Impact of Range Operations on Notifications.  In situations where Subscription Versions are initially created in ranges, then have subsequent activity (modify, activate, disconnect, cancel) performed in singles, TN Range Notifications may change.  Specifically, if subsequent activity on a TN range does not equal the initial TN range (subsequent activity is either singles or a subset of the TN range), then initial and final timers (T1, T2) will result in single TN Notifications.  TN range requests after the timers would still have the potential to generate TN Range Notifications for Service Providers that support this feature.

New Requirement:

TN Range Notification Information – Breakup of TN Range Notifications

NPAC SMS shall send more than one TN Range Notification when a subsequent request is received for a TN range that was different than the original create TN range by breaking up the TN Range and sending single TN Range Notifications.

NOTE:  An example of a different subsequent request is an original create range of 5 TNs, followed by an activate of a single TN.  This leads to the NPAC breaking up the range into singles upon receipt of the first request that doesn’t match the original create range request.  This breakup also causes multiple TN Range Notifications.

Incorporated in FRS and IIS 3.3.2

Related Release:

Incorporated in FRS and IIS 3.3.2

Status: Implemented