Clarification Of Any Restrictions On DSR Network In Split Releases During Upgrade Validation Cycles

Asset ID:	1-71-2277359.1
Update Date:	2017-06-20
Keywords:

Solution Type Technical Instruction Sure

Solution 2277359.1 : Clarification Of Any Restrictions On DSR Network In Split Releases During Upgrade Validation Cycles

Applies to:

Oracle Communications Diameter Signaling Router (DSR) - Version DSR 5.0 to DSR 7.2.0 [Release DSR 5.0 to DSR 7.0]
Tekelec

Goal

We are preparing for several upgrade cycles of Diameter Signalling Router (DSR) in a customer environment from DSR 5.0 to 7.0 and then to 7.1.

While NOAM is upgraded to the newer version, some DSR nodes in the network will remain at lower version of an extended period of time and customer needs to be made aware of any restrictions that may exist while network is in mixed versions.

In each upgrade procedure (referring to DSR Softwar Upgrade Guide 7.0) the following statement is made:
"Provisioning activities at the NOAM and SOAM servers will have certain limitations during the period where the NOAMs are upgraded and the sites are not yet upgraded"

Please provide references to specific restrictions that may occur after upgrading the NOAM but before upgrading SOAMs with the below combinations.

Scenario 1: Upgrading NOAM and FFA site from 5.0 to 7.0

All other DSR nodes in the network remain on 5.0 and might be for a long period of time (weeks, months).

What are the provisioning restrictions (if any) that might exist between NOAM in 7.0 and DSRs that are on 5.0?
Pls detail what operations are not permitted (or point to where I can find those).
Pls list if there are any DB replication/merging restrictions between NOAM and SOAM while on the above mixed releases and weather such restrictions impact customer's operations in any way.

Scenario 2: Upgrading NOAM and FFA site from 7.0 to 7.1

All other DSR nodes in the network remain on 5.0 and might be for a long period of time (weeks, months).

What are the provisioning restrictions (if any) that might exist between NOAM in 7.1 and DSRs that are on 5.0?
What are the provisioning restrictions (if any) that might exist between NOAM in 7.1 and DSRs that are on 7.0 (when those are upgraded)?
Pls detail what operations are not permitted in any of the above combinations.
Pls list if there are any DB replication/merging restrictions between NOAM and SOAM while on the above mixed releases and weather such restrictions impact customer's operations

Solution

Unfortunately, we do not have an exhaustive list of what is and what is not possible.

Scenario 1: Upgrading NOAM and FFA site from 5.0 to 7.0

Writing down an exhaustive list of all operations and provisionings that are allowed/restricted is not possible as we cannot test all of them with your prescribed configuration. Please note that traffic and message processing shall continue for the DSR release running on the particular NE (i.e. 5.0 in your case). Actions like site level (SOAM) operations, administration, maintenance, disaster recovery and provisioning of any DSR NE is possible while in split-release mode.

Adding a peer node to a DSR network while in split-release mode is limited to NEs upgraded to the target release when the addition of the peer requires the addition of an IP route. A workaround does exist for adding an IP route to a non-upgraded site.

In split mode, addtion of new entities should be limited but if required; it will be on NOAM (higher) release but then its DR and replication possibilities may or may not work depending upon which node it is. Similarly, expanding an existing DSR NE while a DSR Network is in split release mode is limited to NEs upgraded to the target release. FRU and smaller hardware maintenance activities are possible.

Please note that all features that are introduced post 5.0 till 7.0 on NOAM may not function as intended due to fact that complete system is on different releases.

As DB Replication is done by Active NOAM to SOAMs (top down); so this will continue. There maybe a limitation due to difference in tables between two releases but if such a situation arise; workarounds can be done. Such limitations and workarounds need to be documented once they arise. This includes, but is not limited to indicating which data may not be getting replicated, what data may need to get reapplied, etc. If customer needs to take action because of a limitation or work-around, then this needs to be documented.

Please note that upgrade phases are supposed to be transient phases. System is designed to support normal functioning during transient phase.

In summary, the recommendation is to keep the transient time between NOAM and other elements as low as operationally possible.

Scenario 2: Upgrading NOAM and FFA site from 7.0 to 7.1

NOAM Upgrade to 7.1 while NEs are at 5.0 is simply not supported. Please refer to Feature Description below. 7.1.0 upgrade is supported from 7.0.x or 6.0.x or 5.1.x.

http://docs.oracle.com/cd/E57516_01/docs.70/E61552_rev_7.pdf

For questions b,c,d please refer to scenario 1.

References

cgbu_eg_1970 DSR Upgrades

Attachments

This solution has no attachment