NANC 353

Round-Robin Broadcasts Across SOA Associations (sister of ILL 5)

Origination Date :04/12/2002

Originator:AT&T

Description:

Business Need:

Currently, most SOA systems have one association to the NPAC SMS over which all interface traffic is sent and received.  As performance increases over the interface, a SOA may need to distribute their interface processing across multiple machines to gain additional memory, processor speed and stack resources.  This change order would enable an SOA/LSMS to distribute their interface processing across multiple machines.  This change order would also enable the NPAC SMS to accept multiple associations of the same function type from different NSAPs and distribute outbound traffic in a round robin algorithm across the multiple associations.

A benefit of allowing an SP to establish additional associations during heavy activity periods is that if one of the associations goes down, the other association still remains connected, which allows the SOA to continue to send/receive messages/notifications.

Final Resolution:

Func Backwards Compatible:  YES

Description of Change:

The NPAC SMS would support additional SOA associations and manage the distribution of transactions in a round robin algorithm across the associations.  For example, due to performance conditions a Service Provider may want to start another SOA association for notification data.  The NPAC SMS would accept the association, manage security, and distribute network/subscription PDUs across the 2 or more associations using the round robin algorithm (One unique PDU will be sent over one association only.)

Major points/processing flow/high-level requirements:

1.  The NPAC exchanges messages with the SOA.  For every request from either the SOA or NPAC, a response is required from the recipient system.

2.  The current FRS requirement (R6-28.1) calls for a sustained rate of 2 messages a second.  When this volume is exceeded, a delay in processing may occur.  This could be 1.) a small backlog in messages, 2.) interface congestion, or 3.) potentially an abort from the sending system for failure to respond to a message within a given period of time.

3.  A new SP specific tunable, SOA Round Robin (SRR), will indicate whether or not a SOA supports receiving messages across multiple SOA associations in a round robin fashion.

4.  SRR (when value set to TRUE) will be used to allow a Service Provider to maintain more than one SOA association using the same function mask and different NSAPs.

5.  SOA Round Robin is applicable for both requests and responses between the SOA and the NPAC.

6.  No reports are required for SRR.

7.  Round Robin algorithm.  Applicable for Service Providers with SRR set to TRUE.

a.  When a Service Provider supports one SOA association to the NPAC:

i.  All messages (requests and responses) flow across the one SOA association.

ii.  If the SOA association is down, the SOA is considered “down” or “unavailable”.

b.  When a Service Provider supports more than one SOA association to the NPAC:

i.  The NPAC treats the multiple SOA associations as one logical association for messaging and SOA recovery.

ii.  The NPAC uses a round robin or alternating algorithm, regardless of load on any given SOA association, when sending messages (requests or responses) to the SOA.

iii.  If at least one SOA association is up, the SOA is considered “available”.

iv.  In more that one SOA association is up, then requests and their corresponding responses may flow across different associations due to the round robin algorithm.

v.  If just one SOA association is up, then all messages (requests and responses) flow across the one SOA association.

vi.  If one SOA association is up, then subsequent SOA association bind requests must be initiated with recovery mode set to OFF (False).

Dec 05 – moved to Cancel-Pending per LNPAWG discussion.

 3/06 – Deleted after March LNPAWG meeting.

Related Release:

N/A

Status: Closed