issue 1.2 compas id 134539 work item: 8609 - avaya support processor ethernet (pe) for duplicated...

Processor Ethernet (PE) for Duplicated Main Servers

Issue 1.2

Compas ID 134539

Work Item: 8609

PROPRIETARY

- i -

February 4, 2009 Avaya Inc. - PROPRIETARYUse pursuant to Company Instructions

February 4, 2009

1. Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -11.1 Testability - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -21.2 PRD Reference - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -21.3 Scope - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -21.4 External Documentation Impact - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -21.5 Related Documents - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -21.6 Document History - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -2

1.6.1 MR’s Incorporated in Current Issue - - - - - - - - - - - - - - - - - - - - - - - - - - -21.7 Terminology - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -3

2. Earlier Work - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -43. Architecture - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -5

3.1 PE State of Health (SOH) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -63.1.1 PE SOH Timing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -73.1.2 Failure Cases - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -7

3.1.2.1 Active Server Failure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -73.1.2.2 PE Path Failure: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -83.1.2.3 Dual Active - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -8

3.2 TTS IP Telephone Behavior - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -93.3 H.248 Gateway Behavior - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 10

3.3.1 Existing Behavior - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 103.3.2 New Interchange Behavior - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 11

3.4 A Summary of CM Changes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 123.4.1 Socket Initialization - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 123.4.2 Mixed PE and IPSI Configurations - - - - - - - - - - - - - - - - - - - - - - - - - - 13

3.5 Server Interchange Link Bounce Behavior for Other Far Ends - - - - - - - - - - - - - - - - 133.5.1 H.323 Trunks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 133.5.2 SIP Trunks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 143.5.3 Adjuncts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 14

3.6 CLAN vs. PE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 153.7 LSP Operation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 153.8 Why no ESS; Why no Port Networks - - - - - - - - - - - - - - - - - - - - - - - - - - - - 153.9 PE NIC and Address Assignment - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 173.10 System Availability - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 193.11 Call Center Availability - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 203.12 Scalability - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 203.13 File Sync - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 203.14 Backup/Restore - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 203.15 Upgrades and Restore from an Earlier Release - - - - - - - - - - - - - - - - - - - - - - - 20

3.15.1 Duplicated Main Servers - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 203.15.2 Simplex Main/ESS/LSP Servers and Duplicated ESS Servers - - - - - - - - - - - - - 20

3.16 Operation on ESS/LSP with Main Server on an Older Release - - - - - - - - - - - - - - - 213.17 System Impacts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 21

4. Hardware Requirements - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 215. H.248 Gateway Requirements - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 216. CM Software/Firmware Requirements - - - - - - - - - - - - - - - - - - - - - - - - - - - - 22

6.1 SAT Form Changes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 287. Integrated WEB Tools Impact - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 28

Table of Contents

- ii -

February 4, 2009 Avaya Inc. - PROPRIETARYUse pursuant to Company Instructions

February 4, 2009

8. Firewall - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 339. Other Systems Impacted - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3510. Special Requirements - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3511. Acknowledgements - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 37

PE for Duplicated Main Servers - 1 -

Compas ID 134539Issue 1.2

Avaya Inc. - PROPRIETARYUse pursuant to Company Instructions

Last Modified: February 4, 2009

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

1. Introduction

Support for Processor Ethernet (PE) on duplicated servers was examined in an earlier work1, but not implemented because the solution did not support recovery in the spirit of five 9’s availability. New ideas have surfaced which are causing a re-look at the problem.

The new "idea" is based on the discovery that certain IP telephones will accept an incoming connection request from a server on their gatekeeper list, use this new connection to replace an existing connection, and continue operation without the need to re-register. This mechanism allows Communication Manager (CM) to quickly originate a new connection to each of these telephones during a server interchange, causing the telephones to move quickly to the server transitioning from the standby to active state.

Stimulated by the discovery of telephone behavior, a modification to H.248 gateways is specified to cause gateways to accept an incoming connection as a signal that an interchange has occurred. This causes the gateway to re-connect to the new server more quickly. Additional modifications to the "audit" behavior in CM immediately following an interchange are also made to reduce processor workload immediately after the interchange.

These requirements are focused on support of Processor Ethernet (PE) on duplicated MAIN servers and server interchange of duplicated MAIN servers when IP devices are connected to the PE interface of the MAIN servers. Improvements are made to IP telephone and H.248 gateway recovery following a server interchange in the MAIN CM servers. Behavior of other devices is not improved or modified by these changes.

The following limitations apply:

1. Support for Processor Ethernet (PE) on duplicated servers is limited to duplicated MAIN servers only.

2. Port networks (G650) and ESS servers are NOT supported. Certain enhancements needed to state of health calculations are not implemented in this release for a mixed configuration. See also the discussion in on page 15.

3. Improvements are made for Time to Service (TTS) aware IP telephones only. These telephones will require a new firmware release.

4. H.248 gateways will require a new release of software for this configuration. Improved availability is only achieved if ALL H.248 gateways are upgraded to the new release of software.2

5. The S8710 server will NOT be supported (MR 68051).

A key goal of the work specified herein is to shorten the time for recovery following a server interchange in order to improve availability. This work will make significant improvements to recovery times for TTS aware IP telephones and H.248 gateways in the event of server interchange and hence will improve availability. The ability to achieve five 9’s availability depends heavily on a significant improvement in gateway recovery time, which will not be totally understood until modification of the gateway interface is implemented and measured. On paper, this looks very favorable. A full discourse on this topic is provided by Bahareh Momken in "PE Duplication Availability Analysis, CM 5.2" CID 135123.

Note that the work specified herein does not provide any improvement in the behavior of adjuncts. In some cases, behavior could be worsened because links to the PE interface will drop whereas this does not happen when CLANs are used.

1. SRAD: Processor Ethernet (PE) on Duplicated Servers, CID 122596.

2. Strictly speaking, this is not exactly true. The software will not prevent a mix of "old" gateways (or phones) and upgraded gateways (phones) and the availability will depend on the mix. If one out of 250 gateways or one out of 12,000 phones is not upgraded, the impact should be minimal, unless, of course, its your phone or the gateway you need. However, if only one gateway out of 250 and 1 phone out of 12,000 is upgraded, availability goals will not be met. It is possible that performance may be worse if only part of the system is upgraded, but this needs to be understood via testing when the code is available.





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

1.1 Testability

All requirements in this document are considered "testable" unless otherwise marked. Testable has a broad meaning which includes inspection of code as well as lab based operation.

1.2 PRD Reference

This effort corresponds to work item 8609 to be MR’d into the PRD for Communication Manager 5.2, CID 132632.

1.3 Scope

This document does not affect current operation of PE on LSPs or ESSs. Operation of PE on these servers is not changed by these requirements.

1.4 External Documentation Impact

See the Learning Development Plan for CM, Gateways, and Servers for R5.2, CID 134883.

1.5 Related Documents

• Processor Ethernet and Enhanced LSP, CID 104793

• SRAD: Processor Ethernet (PE) on Duplicated Servers, CID 122596

• Performance Analysis of Processor Ethernet on an S8500B in CM 3.1, CID 114055, and

• PE Performance Analysis, a power point presentation CID 122664.

• Flexible Ethernet Usage on CM Servers, CID 126798, work item 9419

• CM SRAD for Simplified Licensing via WebLM, CID 126467, work item 8472

• Auto-Migration of Media Gateway to Primary Media Server Controller ACM 2.1, CID 98465

• G700 Media Gateway: H.248 Link Bounce Recovery, CID 94767

• Maintenance Application Design: H.248 Link Establishment, CID 102216

1.6 Document History

Each official revision of the document is assigned a revision number. This section provides a historical record of the revisions of the document.

Issue 0.n Initial pre-baseline drafts

Issue 1.0 First Baselined version

1.6.1 MR’s Incorporated in Current Issue

This section contains the MR number and abstract for any MR that has been incorporated into this document after this document has been baselined.

MR # Included in Issue # Sections Affected Abstract

67263 1.1 section 7, Require-ments 42, 48, and 53.

Inconsistency in where doc says PE address is stored

67356 1.1 Requirement 20 Add a requirement for a feature bit to identify phone FW as supporting the new recovery strategy.

67593 1.1 Section 3.15, Table 3, Requirements 30 and 44

Correct usage of the terms server number and server ID





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

1.7 Terminology

Glossaries of terminology can be found in the following references:

• Glossary (S75/S85/DEFINITY Terminology), J. H. Coyne, Compas ID 26837

• OR&M GLossary and Acronyms (OR&M 202), OR&M PMT, Compas ID 38023

• Mongoose Project Glossary, R. Windhausen, Compas ID 54154

• Glossary for DEFINITY R6 Technical Prospectus, J. C. Raphel, Compas ID 56340

• Stingray Project Glossary, Compas ID 70610

ACL Access Control List

AGL Alternate Gatekeeper List

ARP Address Resolution Protocol

ARQ Admission Request

CET Concept Evaluation Team

C-LAN or CLAN or clan. The IP interface board in a port network

CM Communication Manager

CNA/B Control Network A/B

DHCP Dynamic Host Configuration Protocol

ESS Enterprise Survivable Server

GCF Gatekeeper Confirm

GIP or gip: Gaz Interface Process within CM/TA

GK Gate Keeper

GRQ Gatekeeper Request

IP Alias IP aliasing is the process of adding more than one IP address to a network interface. With this, one node on a network can have multiple connections to a network, each serving a different purpose.

IPSI IP Server Interface. The board in a port network that talks to CM.

LSP Local Survivable Processor

MAC Address Media Access Control Address

MCIPADD Manually Configured IP Address

NIC Network Interface

OS Operating System

67705 1.1 section 3.2 update the list of supported phones

67920 1.2 Table 5 Added a comment to arbiter ports 1332 and 1333 to say they need to be opened on PE for PE-only systems.

67922 1.2 Requirement 37 Requirement 37 re-written to reflect enhanced alarm strat-egy

68051 1.2 section 1.0 Item 5 added to introduction to note non-support of S8710.

68159 1.2 Table 5, Requirement 56

Ports 81 and 411 modified per MR.

68345 1.2 -- This MR was no-changed.

MR # Included in Issue # Sections Affected Abstract





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

PCD Packet Control Driver: The interface process within CM/TA that talks to IPSIs.

PE Processor Ethernet; a LAN interface inside of the TA.

PST Primary Search Timer

pTLS Pseudo TLS -- an variant on TLS used to connect to gateways

RCF Registration Confirm

RRQ Registration Request

Server Interchange The process in which a pair of servers change roles, the active server becomes the standby server and the standby server becomes the active server.

SOH State of Health

SRAD System Requirements and Architecture Document

SUSER or suser: the user manager process within CM/TA

TA Telephony Application: the application running on a Communication Manager server that provides telephony services as opposed to other applications such as the arbiter, watchdog or global maintenance manager also running on the platform.

TTS Time to Service

UDP User Datagram Protocol

UDT Unsuccessful Discovery Time

In addition, abbreviations and acronyms are generally defined where first used within this document.

2. Earlier Work

An earlier SRAD was written on this same subject and can be found in compas 122596, SRAD: Processor Ethernet (PE) on Duplicated Servers. This earlier work contains a large amount of background material that generally will not be repeated here.

It is possible to assign multiple IP addresses to a given NIC. This is known as IP aliasing. See figure 1. The PE

function can be assigned to one of these "alias" addresses as illustrated in the figure.

When CM main servers are duplicated, IP aliasing can already be used for the control networks and the customer LAN interfaces in a special way. For each NIC assigned to a given function (CNA, CNB, Customer LAN), one address is assigned uniquely to each server and the second address is assigned the same (shared) address on both servers. However, only one server (the active server) responds to the "shared" IP address. During a server

nic

ipCipA

Figure 1. IP Aliasing

PE PCD

GIP

TA

CM Server

procr=ipC





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

interchange, the active server becomes the standby server and the standby server becomes the active server. The server becoming the active server sends an "ARP broadcast" for the shared address on the interface where the aliasing is administered. This causes all connected devices to update their "ARP cache" to point to the new active server. Figure 2 illustrates this with focus on the NIC assigned to the PE interface. Note that PE interface is not active

on the standby server because the GIP is loaded but not executing.

Note the following:

• Using an alias IP address means that all devices connected to this interface see the same IP address regard-less of which server is active.

• The active server attempts to capture control of the IP address assigned to the alias

• Only signaling links go through CM servers. The bearer channel (talk path) does not; it might connect to a media processor but not to the server itself.

• In the above figure, the telephone is a generic stand-in for any device connected to the TA via PE.

3. Architecture

Processor Ethernet on duplicated MAIN servers will "work" if we simply remove the blocks in the code that prevents its use today. However, removing such blocks is only of interest if doing so results in a system with sufficient availability. For a discussion of what is sufficient, see PE Duplication Availability Analysis, CM 5.2, CID 135123. Suffice it to say here, that the following areas must be addressed in order to support a notion of availability for the core servers and equipment:

• Each server must be able to determine the state of health (SOH) of its Processor Ethernet (PE) interface .

• The SOH of the PE interface must be included in server interchange decisions.

• H.248 gateways must switch allegiance to the server becoming the active server in a timely fashion and without undue burden on that server.

Additionally, IP telephones must recover from a server interchange in a timely fashion and without undue burden

nic

ipA

PE PCD

GIP

TA

nic

ipB

PCD

GIP

TA

CM Server ACM Server B

Signaling PathSignaling Path

Talk Path

ipC

procr=ipC

Figure 2. IP Aliasing on the PE interface

ipA = Ip address of server AipB = ip address of server BipC = shared ip address





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

on the CM server becoming the active server if the customer’s experience is to be one of high availability.

3.1 PE State of Health (SOH)

Determining the health of the PE interface is not as easy as it might seem at first glance. Approaches to making this determination include the following:

• The gip is the termination point for the PE interface. So perhaps the gip could report loss of message traffic. But this isn’t reliable by itself because there may be legitimate periods when there is no message traffic on this interface and a failure would go undetected for an unknown length of time. The gip is not running on the standby server and so PE SOH could not be determined on the standby.

• Perhaps a ping message could periodically be sent out the NIC associated with the PE interface to the NIC associated with the PE interface on the other server. If the message receives a proper response, this confirms that the NIC assigned to the PE interface is working. However, if the message receives no response the result is inconclusive. If either of the NICs fail, both servers will think their PE interface is down.

• Perhaps a ping message could periodically be sent out the NIC associated with the PE interface on the local server to each of the NICs on the other server. This would require that there be more than one NIC on each server and that all the LANs to which these NICs connect are interconnected. If we ever implement the feature called flexible NIC assignment, it is possible there would be only one NIC (plus the laptop NIC) on each server. Further, it is not a good assumption that the LANs are always interconnected.

• To solve the above dilemma another device must be available on the local subnet. It must be on the local subnet so as not to confuse failure of PE’s NIC/path with downstream network failures. The possibilities include the following:

1. The data network default gateway. In some sense, this is the ideal choice because the default gate-way must be present on the local subnet anyway. However, a Communication Manager server could have multiple NICs and it is possible that the customer has assigned the default gateway to a LAN not connected to the NIC associated with the PE interface. For example, the "customer LAN" might be assigned to a NIC different from the one used by PE and the default gateway could be on the "customer LAN".

2. An H.248 gateway on the local subnet. An H.248 gateway on the local subnet has the advantage of being part of the communication system. However, the data network default gateway is still a bet-ter choice, because reaching the default gateway is generally necessary to reach equipment in other parts of the network.

3. Another device that will respond to queries used to determine the SOH of the PE interface.

Another issue in determining PE SOH is use of the ping message. The easiest message to use is ping since it doesn’t require some special new code in the router. However, ping can be disabled in the router or in firewalls. An

alternative is ARP ping1, which is a layer 2 message that asks, "who has this IP address". This message won’t be blocked because it is necessary to make layer 2 function properly. Thus the ARP ping will be used instead of ping.

To conclude, the SOH of the PE interface must be determined independent of the health of the other server via another device on the same subnet as the NIC associated with the PE interface. Choices for this device, in order of preference, are:

a. The data network default gateway

b. An H.248 gateway on the local subnet

c. Another device on the local subnet

The following table shows the SOH contribution provided by pinging both the other server and some other device

1. Thanks to Phil Whelan for this great solution.





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

on the subnet using the NIC assigned to the PE interface.

3.1.1 PE SOH Timing

In order to avoid lowering SOH of the PE interface due to short transient conditions, failure is not declared on a single lost ping message response. Three lost responses are normally used. As figure 3 illustrates, if the time between ping messages is Tp and if the failure occurs immediately before a ping response is to be sent, the time to detect the failure is essentially only 2 ping intervals (2 x Tp). If the failure occurs immediately after a ping response is sent, then failure isn’t detected for 3 ping intervals (3 x Tp), which is the worse case.

3.1.2 Failure Cases

There are three failure cases of interest. Note that in all cases it is assumed that the standby server is refreshed.

1. The active server fails. In this case the active server does not close open sockets and does not respond to any messages on any interface beyond the time of failure.

2. The network path being used by PE on the active server fails. This might be due to a cable being unplugged, an ethernet switch failure, or a failure of the network interface (NIC) on the Communication Manager (CM) server. In this case, the active server responds on other interfaces, e.g. duplication link, but connections are not closed on the PE path and no messages are sent or received on this path following the failure.

3. An operator initiates an interchange. In this case the active server will close connections, which means all connected devices will become aware of the interchange as it happens. This produces the shortest recov-ery time and is of least interest here as it is not really a failure.

3.1.2.1 Active Server Failure

Table 1. PE SOH Contribution

Reply Received

from Default Gateway

Reply Received From the

Other Server

PE SOH

yes yes healthy

yes no healthy

no yes healthy

no no PE SOH lowered

Tp

Failure immediately before ping response

Failure immediately after ping response

Failure declare PE Failure

declare PE Failure

1

1 2

2

3

3

Figure 3. Gateway Failure Detection

Time

ping/response





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

If the active server fails, an interchange is made up of the following time segments:

Arbiter Detect: "Inter-arbiter heartbeats are generated every 875 milliseconds, with SOH changes being transmitted asynchronously and within 1 millisecond. The timeout for having a Standby server start to go active is 4.1 seconds. So with those those two bits of information, we know that if the active server fails, the Standby will start to go active within 3.225 - 4.100 seconds." (E.-mail from Luke Young)

PE Verification1: The standby server needs to know it has a good PE interface. If the ping rate is one per second, the standby server will receive confirmation that its PE interface is working within 1 second, so this time does not add to the interchange time. That is, the standby server will receive multiple responses on a good PE interface in less time than it takes the arbiter to decide the active server is not responding.

Go Active: The arbiter on the standby server causes processes on the standby server to start up. 4-7 seconds.

Interchange Time: The interchange time is the sum of the above times or 7.2 to 11.1 seconds. Note that this is the first point at which the newly active server could enter "normal op". Changes specified herein will lengthen the time to "normal op" in order to speed recovery.

3.1.2.2 PE Path Failure:

When an interchange is done as a result of a failure of the PE interface/path on the active server, the time to perform the interchange is made up of the following time segments.

PE Detect If the ping interval is once per second, it will take the active server 2-3 seconds to verify that its PE path has failed.

Arbiter Detect It will take the arbiter in the active server 1 millisecond to decide to do an interchange in the face of a critical loss of call control (no PE interface). So this time can be ignored.

PE Verify The standby server will be sending ping messages once per second and will receive multiple responses on a good PE interface in less time than it takes the active server to lower its PE SOH, so this time can be ignored.

Go Active: The arbiter on the standby server causes processes on the standby server to start up. 4-7 seconds.

Interchange Time: The interchange time is the sum of the above times or 6 to 10 seconds. Note that this is the first point at which the newly active server could enter "normal op". Changes specified herein will lengthen the time to "normal op" in order to speed recovery.

3.1.2.3 Dual Active

It is possible that both servers could go active at the same time and remain so for an undetermined duration. This is not a supported configuration and any service provided in this state is provided courtesy of the gods and may be interrupted randomly via the same courtesy. These requirements do not necessarily increase nor decrease the likelihood of a dual active condition. If both servers are active, each will try to take over control of the alias IP address associated with each LAN connected to the servers. This will occur on the NIC associated with PE as well as the NICs associated with the control LANs or Customer LANs.

1. If a standby takes over as active because it cannot hear from the active, it will still try to go active, REGARDLESS of what the standby's SOH is. ( E-mail from Luke Young. )





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

3.2 TTS IP Telephone Behavior1

The behavior described in this section is for Time to Service (TTS) aware IP telephones that have an as yet-to-be-developed version of firmware in accord with IPT MR# IPT00036834, written on our behalf by Cherian

Abraham. As of July 2, 2008, the plan for TTS aware telephones that will support the new firmware2 include the following:

• 46xx Broadcom sets if firmware R2.8 or later release.

- 4601+, 4602SW+, 4610SW, 4620SW, 4621SW, 4622SW, 4625SW

• 96xx all phone models if firmware S1.2.1 or later

- 9610, 9620, 9630, 9640, and 9650

The following telephones do not support the new firmware:

• 16xx telephones

• 4601/02/06/12/24/30/90

• 46xx Agere sets

- 4620, 4606, 4612 and 4624

The phone firmware modification is designed specifically to address server interchange when telephones connect to the server PE interface. In this case the telephone has a connection/socket up to the active server at IP address IPa with MAC address M1; a server interchange occurs.

1. There is a time period on the order of 10 seconds during which neither CM server is providing service. During this time, messages from telephones will receive no response (messages may be "lost"), even though the connection may "appear" to be up.

2. The existing connection/socket from the phone to the CM server may or may not be torn down (FIN)

3. When the standby server transitions to the active state, it will open a new socket to each telephone that had a connection to the other server. The connection will originate from IP address IPa and MAC address M2; that is, the same IP address but a different MAC address.

4. The telephone will respond as follows:

a. If the incoming connection is from the same IP address (IPa) as the current connection or the last connection, in case there is no current connection, and the connect arrives prior to the primary search timer expiry: See figure 4.

• The phone shall accept the incoming connection. (TCP syn, syn/ack, ack)

• The phone shall close the "old" connection if it has one (FIN)

• The phone shall simply replace the old connection with the new one without attempting to register or establish a new session (setup olc). The newly active server will have shadowed status/state data from the active server.

• Should this process fail for any reason, the phone shall do normal recovery using its exist-ing timers.

b. If the incoming connection is not from the same IP address, the phone will behave as it does today. The following description is provided courtesy of Rob Mitchell.

1. Note that these requirements are concerned with server interchange, not server initialization or boot-up. SV notes that we are limited to about 5000 encrypted phone connections on initialization; more than this and the server never boots. These requirements do not address this problem. Also note that encrypted phone links provide better security from a number of perspectives at the cost of increased boot time.

2. The list of telephones is believed accurate as of the date shown. Which phones will or will not support the new firmware is neither con-trolled by, nor baselined in this SRAD. This list will not be updated if the supported set models change in the future. Consult telephone development for this information.





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

My answer is grounded in the assumptions implicit in your Section 3.2 -- we're talking TTS environments, and the telephone has had a normal registration in progress. The source RFS and Requirement for the 96xx sets is COMPAS ID 111782, Requirement 96xxACP.2.1.500, and for the 46xx sets it is COMPAS ID 76339, Requirement 46xxDefIP.3.1.607.

Case 1: The telephone received a FIN, or the TCP keep-alives time out, before getting the incoming TCP connection invite -- this case is generically termed "TCP Connection failure". In this case, the phone starts the PST (Primary Server Search Timer), sets the "current server address" to the first primary server address in the Gatekeeper List, and sends Keep-alive RRQs to the current server address until the KA-RRQs time out (or we get a response). In the case of a timeout, the telephone sends a KA-RRQ to the next server address, etc., until the PST expires, in which case the phone goes back to the beginning of RAS.. In the case of a positive response (KA-RCF with matching module ID), the telephone assumes it has found the server, and uses the (potentially new) server address.

While all the above is going on, if a TCP connection request comes in, the phone checks to see if the request came from an address in its Gatekeeper List. If no, the telephone ignores the request; otherwise, the telephone accepts the TCP connection, cancels the PST, and returns to normal registration.

Case 2. The telephone has not received a FIN, or the TCP keep-alives time out, before getting the incoming TCP connection invite. The key difference between this Case and Case 1 is that in this Case, the telephone does not know it has lost its connection to the original server. Therefore, the phone assumes it still has a TCP connection with the original Gatekeeper (assume it is GK A). In this Case, the telephone sends a KA-RRQ to GK A, and waits for a response. If the telephone gets a KA-RCF (presumably not, in your scenario), the phone ignores the TCP Connection request from the new server (GK B). More likely, the telephone's KA-RCF and retries all timeout, then and only then does the request from GK B get accepted.

Note that the interchange process works for both H.235 Annex H and non-annex H phones although recovery of Annex H phones may take longer.

3.3 H.248 Gateway Behavior

3.3.1 Existing Behavior

The existing H.248 gateways reconnect to a CM server in the following high level sequence:

1. The gateway establishes the TCP connection

2. The gateway initiates a PTLS session (if the session is to be encrypted)

a. CM starts key exchange

Server A Server BPhone

Existing Connection

Server interchange from A to B

Syn - TCP establish

phone drops old Connection if it exists

Figure 4. Phone Behavior During Interchange

StandbyActive

Server A Phone

Standby Active

Syn/ack - TCP establish

ACK - TCP establish

Connection status unknown; might have closed; might not.

Continue processing as if no failure

Server B





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

b. The gateway acknowledges key exchange

c. CM acknowledges the gateway's acknowledgment.

3. The gateway sends registration

a. CM either accepts registration or denies it. If the latter, the gateway tries again about 5 sec-onds later.

Following registration:

4. User Manager handles gateway registration, sends a registration stim to the HMM and stims itself to run the provisioning process. This function downloads some 1500-2600 bytes of parameters.

5. User Manager tells HMM of gateway registration20 (0x0014) = MO_ANALYZE, really runs the alarm resolution function.

6. Gateway sends the board information, i.e.. what boards are present1522 (0x05f2) = MG_FIRST_BD_CHG 1522 - handle first gateway bd chg msg

7. Gateway starts the context rebuild process1617 (0x0651) = MG_CTXT_RBLD 1617 - start user manager context rebuild

8. Bring up D channels1641 (0x0669) = CK_MG_DCHAN 1641 - Check for D chan ports on gateway

9. Audit the physical port connections1523 (0x05f3) = MG_ADT_CONN 1523 - audit connections

10. HMM tells the user manager to let in the next gateway

11. Get the tone detector count1637 (0x0665) = MG_TTR_AUDIT 1637 - get available TDs on a GW

12. Three minutes later1586 (0x0632) = MMM_BDM_AUD 1586 - MMM BDM audit

13. If connection preservation timed out;1524 (0x05f4) = MG_TERM_ADT 1524 - audit MG terminations

3.3.2 New Interchange Behavior

The new behavior on server interchange is as follows:

1. As was described for IP telephones in the previous section, there is a time period on the order of 10 seconds during which neither CM server is responding to messages from any devices, even though the gateways are not yet aware there is a problem. Messages sent during this time are most likely to be lost.

2. The existing connection/socket from the gateway to the CM server may or may not be torn down (FIN)

3. When the standby server transitions to the active state, it will open a new socket to each gateway that had a connection to the other server. The connection will originate from IP address IPa and MAC address M2; that is, the same IP address but a different MAC address.

4. The H.248 gateway will respond as follows:

a. If the incoming connection is from the same IP address (IPa) as the current connection or the last connection, in case there is no current connection:

• The gateway shall accept the incoming connection. (TCP syn, syn/ack, ack)

• The gateway shall close the "old" connection if it has one (FIN)





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

• If the gateway is using a secure connection, the gateway will initiate re-establishment of the secure connection. Note that re-establishing a secure connection will take longer than the time for a non-secure connection.

• No other recovery messages shall be required.

• The gateway shall not reset in response to just the connection change. Both connections and calls shall be preserved.

• Should this process fail for any reason, the gateway shall do normal recovery using its existing timers.

b. If the incoming connection is not from the same IP address, the gateway will respond to the incom-ing connection with a FIN.

5. CM shall not artificially rate limit the set up of secure connections to the gateways.

6. CM shall bring the gateway into service immediately on negotiation of the new connection without waiting for ANY audits, in particular context audits. Audits shall be run at normal background priority.

7. CM shall respond to a context error by auditing the single context on which the error was received.

3.4 A Summary of CM Changes

There are 4 main areas of change being made to support the PE interface on duplicated MAIN servers:

1. Modify the suser and gip processes to perform special socket initialization on interchange

2. Add PE to the State of Health (SOH) calculation

3. Remove blocks on use of the PE for duplicated MAIN servers and add necessary administration and initialization.

4. Increase capacity of gip/suser processes if/as necessary e.g. file descriptors, message queues, simul-taneous requests

The next sections provide additional discussion on the first two items.

3.4.1 Socket Initialization

As a duplicated pair of MAIN servers operate, status information is transmitted from the active server’s memory tables to the standby server’s memory tables in a process known as memory shadowing. Of particular importance to the present discussion is the connection information from the suser and gip processes to external devices as illustrated in figure-5.





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

The suser process has a "D-socket" (Oryx/Pecos connection) to the gip for each connected device; the gip in turn has an associated Linux socket to the OS to maintain a TCP connection to the device. Tables containing data for these connections are shadowed from the active server to the standby server as illustrated in the figure. Immediately after a server interchange, the newly active server has a set of tables in the suser and gip processes containing data for all the device connections, but the Linux socket does not exist; there is no real connection to the device. In the current system, the D-sockets are closed, the gip socket tables are cleaned up and an entirely new connection is established. How the connections get re-established depends on the specific device; see CID 122596.

These requirements will have the suser process mark the sockets connected to H.248 gateways and TTS aware IP telephones as the sockets are created. Then, on interchange, the suser will not tear down these sockets; the gip will automatically create new Linux sockets for all sockets marked for H.248 gateways and TTS aware IP telephones.

Tests on a Dell 1950 class machine indicate that Linux can open 12,000 sockets in under 3 seconds. Because this can happen very quickly, the suser/gip can be modified to re-establish all the TTS sockets prior to entering suser "normal op" and a priority among these sockets is not necessary. For example, it was originally thought that busy phones would be brought back first or maybe call center phones first; but if they all come back in 3 seconds, order doesn’t matter.

3.4.2 Mixed PE and IPSI Configurations

Determination of SOH for the PE has already been described in section 3.1 on page 6. Although port networks are not supported in this release when PE is enabled on duplicated main servers, administration is not blocked. In this release, an interchange will occur to the server with the best SOH for PE regardless of SOH of the IPSI connections. If the SOH of the PE interfaces is the same on both servers, then the existing algorithms for IPSI connectivity will govern.

3.5 Server Interchange Link Bounce Behavior for Other Far Ends

3.5.1 H.323 Trunks

H.323 trunks currently connect to two places -- other CM servers or the AT&T network. Calls to other CM servers generally recover well from a link bounce; calls to the AT&T network generally drop. Remember that the talk path does not involve the PE interface and so the talk path will remain up until either end takes action on the signalling link to disconnect it.

suser

gip

Oryx/Pecos Definity Socket (D-Socket)

Linux OS

Linux Socket

suser

gip

Oryx/Pecos Definity Socket (D-Socket)

Linux OS

Linux Socket

TCP connection to phone

Standby ServerActive Server

Figure 5. Data Shadowing

Memory Shadowing





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

Following a server interchange initiated link bounce on the PE interface, the newly active server will attempt to re-establish the signalling socket for all known H.323 trunks after entering "normal op". CM retains the call records for calls on these trunks for up to two hours. If the signaling link for the call can be re-established for the call within this time, operation is resumed. If it cannot, CM will disconnect the call. The far end (e.g. AT&T) may choose to disconnect the call sooner.

3.5.2 SIP Trunks

SIP trunks are currently used in CM to support the following types of connections:

• To connect to another CM

• To connect to a service provider such as AT&T

• To connect to SES

• To connect to a G860 high density trunk gateway

In all cases, the behavior is the same. The end that needs to send a message (CM or the "other end") will bring up the trunk if it needs to do so to send a message. The trunk will be established as needed and not necessarily at the time of server interchange. This means that link bounce for SIP is pretty innocuous.

If there are signaling messages being exchanged on a SIP trunk precisely at the time of failure and if a message is lost, the associated call (or action) may fail. Activity during an interchange is not guaranteed regardless of interface (PE or CLAN) or type of application (SIP, IP, DCP, etc.).

Specifically regarding SES:

Per Marsh Gosnell: "SES doesn't really care about link loss. SES is largely oblivious to the state of the connection (actually connections since there is one in each direction). If a connection doesn't currently exist when SES wants to send CM a SIP message, it will create a new one. If SES hasn't yet discovered that the connection is broken, it is possible for one SIP message destined for that connection to fail and get returned with an appropriate error. Likewise, SES will gladly accept a new connection from CM and receive messages on it and SES will eventually tear down the dead connection

SES expects CM to send us an unsolicited NOTIFY when it starts up so that SES can re-establish its bulk subscription. In the case of link bounce, we don't expect to get a NOTIFY. I don't know if enough stuff is mirrored on CM to keep track of the SES subscriptions so CM may have no choice but to send that NOTIFY to SES after an interchange."

Specifically regarding G860, Xiaoyan(Sharon) Xiong ran the following test:

"I made a call from PSTN stimulating switch (DS1 to T3) through G860 then to CM via sip trunk, left call up, unplugged CLAN cable for 30 seconds. After reconnecting network cable to clan, checked talk path (it remained up), made a call transfer from CM to another CM extension. It worked fine. Repeated once, result is the same."

Although this is not exhaustive testing by any means, it does tend to confirm the G860 should have reasonably good behavior during a server interchange link bounce.

3.5.3 Adjuncts

CID 122495 provides additional detail regarding adjunct behavior. Table 2 shows a summary of anticipated behavior of adjuncts as a result of a server interchange initiated link bounce on the PE interface when these devices are connected to the PE interface.

Table 2. Adjunct Response to Link Bounce

AdjunctCoded for Link Bounce

Comments

AES, IR, IMS, softphone, IP agent softphone, SIP softphone, SES

yes These devices understand link bounce and attempt to recover with minimal user impact. Specific times, affects of operator behavior etc vary by product.





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

3.6 CLAN vs. PE

There are significant differences between connecting through CLANs and connecting directly to the PE interface.

• When connecting through a CLAN, sockets are not lost during an interchange. Except for a few second loss of service during the actual interchange, an interchange with CLANs can be transparent to telephones. An interchange will never be transparent if connectivity is through PE.

• When connecting through CLANs, multiple CLANs are generally used. Failures do not necessarily affect all the CLANs at the same time. Some kinds of failures (e.g. network outages) may affect only a subset of users. However, connectivity through PE is like having a single CLAN for the entire system. If the PE is affected in any way, failure is total; all users are affected. This tends to result is a larger disruption.

3.7 LSP Operation

Operation of LSPs is not altered by the changes specified herein.

3.8 Why no ESS; Why no Port Networks

The primary motivation for supporting Processor Ethernet on duplicated servers is precisely to provide a configuration that has no port networks. This results in a system with a smaller hardware footprint, with lower hardware cost, and with a better competitive configuration in the marketplace.

It is recognized that existing customers would want to use Processor Ethernet in place of adding additional CLANs, especially if they would need to add another port network to accommodate the additional CLANs. Technically, this could be supported in some future release. However, the present effort is focused on delivery to release 5.2 which is currently scheduled for February of 2009 (and these requirements are being written in May 2008). In order to fit the development in this compressed schedule, the work is being minimized. The additional work to support port networks in both development and testing is beyond what can be done in the short term. The next paragraphs provide an overview of the problem/work.

• Processor Ethernet on duplicated main servers requires that the PE interface be assigned to the shared, alias address of the servers; because of the way the system is currently designed, PE on duplicated ESS servers requires the PE interface to be assigned to the server unique IP address.

• Processor Ethernet cannot be used on simplex ESS either, as will be discussed shortly.

MultiTech Gateway,G150, No but OK These devices are not coded for link bounce specifically but have other behaviors which make operation through a link bounce acceptable.

CMS No May cause a re-pump of the CMS data base. CMS detects link failure within 15 seconds.This product is not being enhanced. Note that SV observes that the re-pump "always" occurs and may take 30 minutes to complete.

IQ/CCR no Expected behavior is similar to CMS.

Voice Portal, IALX, MM, Legacy Octel

No See CID 122596.

Apollo No all calls will drop

emmc, meeting exchange, crystal

No All calls will drop

Table 2. Adjunct Response to Link Bounce

AdjunctCoded for Link Bounce

Comments





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

• If port networks are used on the main servers, then an ESS must be present in the configuration to provide a survivability story. In the event that an ESS takes control, all the devices connected to PE on the main server would have to connect to CLAN on the ESS. This means that the port networks/CLANs must have sufficient capacity to handle all devices without using PE on the main. This defeats the purpose of trying to use PE for cost reduction in the first place.

The obvious question is, why can’t we use PE on the ESS servers like we do on the main servers. The answer is related to the technical implementation of LSPs and ESSs and what makes an LSP different from an ESS. The primary distinguishing feature that makes the two different is that a port network can connect to an ESS but not an LSP and IP devices can connect to the PE on an LSP but not to the PE on an ESS. If IP devices connect to PE on an ESS, what is it? An ESS or an LSP? Lets look at LSPs and ESSs more closely.

• ESS: Enterprise Survivable Servers (ESS) are designed specifically to support port networks. ESS servers provide no service until one or more port networks choose the ESS server for service via the Packet Con-trol Driver (PCD) interface in CM. Telephones and gateways connect through a CLAN to the ESS server and never to the PE interface on the ESS itself. In order to return service to the main servers, the port net-works must move back to the main, which they can do on command or at a specified time. The return to main policy is administered on the system-parameters ess form as shown in figure 6. The ESS server per-

forms a reset system 4 when it no longer controls any port networks. The reset system 4 is used to clear alarms, busy-outs and allow any pending translations to be loaded.

• LSP: Local Survivable Processors (LSP) are designed to support H.248 gateways. Port networks cannot be hosted on an LSP. LSPs provide no service until (1) at least one H.248 gateway registers with the LSP and at least one IP telephone registers with the LSP. Because there are no port networks there are no CLAN interfaces and all IP devices must connect to the LSP’s PE interface. In order to return service to the main server(s), the H.248 gateways poll the main every 30 seconds when connected to the LSP. If the main can be contacted, the gateway tries to register with the main. The main server looks at gateway recovery rules and decides when to allow the gateway to register back at the main. When all the gateways have finally left the LSP, a maintenance process in the LSP sends an unregister message to groups of IP telephones, which causes them to re-process their gatekeeper list and find the main server again. The return policy for gate-ways connected to LSPs is administered on two forms, the system-parameters mg-recovery-rule form,

Figure 6. Change system-parameters ess





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

shown in figure , and the media-gateway form illustrated in figure 8. The LSP could also be reset manually

to cause the return to main, but this would cause everything to return to main at once rather than metering out the load.

In addition to the "return to main" differences, ESSs and LSPs are administered on different SAT forms and register differently when registering with CM.

In order to support PE on ESS servers, something would need to be done about "return to main" differences between ESS and LSP to prevent fragmentation and performance problems. The "right" solution would be to merge the concepts of ESS and LSP into a single concept of survivable server which could support both port networks and H.248 gateways and could fully utilize the PE interface. Doing this merge requires a number of changes in administration, ESS/LSP registration, and recovery behavior. It would also require complete retesting of server survivability. It is not something that could be done as a rush late adder to any release.

3.9 PE NIC and Address Assignment

Processor Ethernet (PE) is an interface within the Telephony Application (TA) of a Communication Manager (CM) server. See figure 9. PE is assigned to a hardware NIC via the CM server web pages and to an IP address by the TA. Within the TA, PE is known by the node name, procr. As the figure illustrates, PE is not the same interface as the Packet Control Driver (PCD) interface which is used to talk to IPSIs, even if they might share use of the same

Figure 7. Change system-parameters mg-recovery-rule

Figure 8. media-gateway form





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

hardware NIC and have the same IP address. (They will use different port numbers.) The PE interface is also not the same interface as is used by file synchronization, even though both might use the same NIC and have the same IP address.

In current systems, the web interface allows the customer to assign the PE interface to either control network or to the customer LAN. This assignment results in two variables being set in ecs.conf.

• PClanIntf0 is set to the identity of the NIC to be used. e.g. eth4

• PEInterface is set to a string to specify which logical interface (customer lan or control network) is assigned.

PClanIntf0 is read by the routine long_ipinfo and a license check for PE made in the routine allow_procr within CM. This information is read as CM starts up and the node name procr assigned the appropriate IP address automatically. PEInterface is used only by the web in order to be able to display the correct selection back to the user.

Currently, when procr is assigned an IP address within the TA on duplicated servers, it is assigned the server unique IP address, not the alias address of the NIC. (This is done on duplicated ESS servers so they can register with the main server.) On duplicated MAIN servers, procr needs to be assigned to the alias address of the NIC assigned to PE.

Both PClanIntf0 and PEInterface variables will be deleted from ecs.conf and PE information stored in servers.conf. The arbiter needs to know the address not only of the near end for PE but for the other server as well.

Note that there is only one default gateway in the routing tables in a server. Usually the default gateway is assigned to the customer LAN. If devices are connected to a LAN other than the LAN where the default gateway is located, static routes are often needed to achieve the needed routing. (This is not new to these requirements -- just an interesting but important configuration issue.)

Table 3 is an example of servers.conf content from an S8720 modified to show PE information added. Comments

in the actual1 file are not shown. The first column (use) and the title line are added here for readability, otherwise the table shows the actual file content. Other Columns contain data as follows:

Name This column is the record identifier or function to which the other data applies

Eth This is the Ethernet interface number. i.e. 2 means Ethernet 2 as seen by the Linux Operating system.

Host This is the host name on that interface

IP Address IP Address, Mask, and Default Gateway are the standard Ethernet parameters for the interface. Note that the Default Gateway is set only on the "enterprise LAN".

1. This data was taken from a real switch and then PE entries added to illustrate how the data would appear. This example does not represent a commitment to support any particular configuration, such as PE and port networks at the same time.

PEPCD

TACM Server

Eth-xVLAN-x

non-alias alias

Eth-ynon-alias alias

Physical NIC

Logical Interfaces

Figure 9. Relationship of PE to NICs, and IP Addresses

File Sync





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

SNMP The SNMP GET and SET columns contain the SNMP community strings for GET and SET operations on the Cajun switches that make up the control network. The original Stingray web interface has/had a page where unused ports on the Cajun switches could be disabled for better security. This was a convenience to the customer so that they didn’t have to access the Cajun’s independently. Since Avaya no longer ships these switches and since customers do not necessarily keep the control networks independent, this is a useless feature in newer systems. Its not clear that SNMP messages sent to the Cajuns would work on non-Cajun switches. The data in the SNMP column in the table would only appear in the line(s) for the Ethernet switches. There is no data for the Ethernet switches in this example servers.conf file.

Server ID/number Each server in "the system" is assigned a unique number in the range 1-256 which appears in the last column as "server ID". Each duplicated server also has a number, either 1 or 2 appended to its name in the "name" column of the table. e.g. cna1 or cna2. If the state of health of the duplicated servers is equal, the server whose names end in "1" will generally be preferred to be the active server.

Note that there are entries in the file for both servers in the duplicated pair. The "active" entry refers to the alias address shared by the two servers on that LAN. Note that the default gateway does not necessarily appear on the same LAN as the NIC assigned to PE.

3.10 System Availability

The enhancements specified in these requirements are targeted specifically at TTS aware telephones and H.248 gateways connected to the PE interface. Recovery time for these devices is significantly improved. A configuration with only H.248 gateways and no port networks is expected to support five 9’s availability in specific conditions. A formal availability analysis is being done by Bahareh Momken and will be available in "PE Duplication Availability Analysis, CM 5.2" CID 135123.

Table 3. Servers.conf on S8720

Use Name Eth Host IP Address MaskDefault

GatewaySNMP GET

SNMP SET

Server ID

CN-A active-cna 2 sv-st10-cna 198.152.254.200 255.255.255.0 NA NA NA NA

CN-A cna1 2 sv-st10-1-cna 198.152.254.201 255.255.255.0 NA NA NA NA

CN-A cna2 2 sv-st10-2-cna 198.152.254.202 255.255.255.0 NA NA NA NA

laptop laptop 1 NA 192.11.13.6 255.255.255.252 NA NA NA NA

dup dup1 0 sv-st10-1-dup 192.11.13.13 255.255.255.252 NA NA NA NA

dup dup2 0 sv-st10-2-dup 192.11.13.14 255.255.255.252 NA NA NA NA

CN-B active-cnb 3 sv-st10-cnb 198.152.255.200 255.255.255.0 NA NA NA NA

CN-B cnb1 3 sv-st10-1-cnb 198.152.255.201 255.255.255.0 NA NA NA NA

CN-B cnb2 3 sv-st10-2-cnb 198.152.255.202 255.255.255.0 NA NA NA NA

cust active 4 sv-st10 172.21.22.3 255.255.254.0 172.21.23.254 NA NA NA

cust server1 4 sv-st10-1 172.21.22.1 255.255.254.0 172.21.23.254 NA NA 96

cust server2 4 sv-st10-2 172.21.22.2 255.255.254.0 172.21.23.254 NA NA 97

PE active-pe 2 sv-st10-pe 198.152.254.200 255.255.255.0 NA NA NA NA

PE pe1 2 sv-st10-1-pe 198.152.254.201 255.255.255.0 NA NA NA 96

PE pe2 2 sv-st10-2-pe 198.152.254.202 255.255.255.0 NA NA NA 97

#SAMP/MPC

#Ethernet Switches

#UPS





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

3.11 Call Center Availability

TTS aware telephones and H.248 gateways connected to the PE interface, are expected to recover quickly from a server interchange. However, CMS/CCR/IQ declare link failure within 15 seconds and will re-pump its data base (re-pump time can be 30 minutes). In the most optimistic case, interchange in less than 15 seconds is marginal at best. Notice that this time is independent of whether the adjunct is connected to the PE or to a CLAN.

Ideally, CMS/CCR/IQ would be enhanced to either tolerate a longer link outage or have a mechanism to accurately determine whether it needs to do a pump-up after the outage. The call center organization believes the pump-up is not a problem for their customers and has declined modification of these adjuncts.

3.12 Scalability

These changes to do not affect scalability. Numbers of supported IP telephones or H.248 gateways is not changed.

3.13 File Sync

Assignment of the PE interface is done on a server by server basis and is not part of the data that is file synchronized.

3.14 Backup/Restore

There is no direct impact on backup and restore from the same release.

3.15 Upgrades and Restore from an Earlier Release

The upgrade processing described here is to keep the data files consistent in the new release. There is no real upgrade of the feature "PE on duplicated main servers" because the feature doesn’t exist prior to this release. If a duplicated main server is upgraded, port networks will be present; following the upgrade, the port networks will work as before, and PE will be disabled.

The following description applies to upgrade or restore from a release prior to these changes. On an upgrade, files are copied from the "other" partition and on a restore, files are coped from a backup. Other than the source of data, the following operational behavior is common:

Upgrade processing for PE information depends on the role of server begin upgraded.

3.15.1 Duplicated Main Servers

Processor Ethernet was not supported on duplicated main servers in prior releases. The upgrade/restore process will need to take the following actions with respect to PE data. These steps get ecs.conf and servers.conf in the proper format for the new release and leave PE unassigned.

1. restore/copy servers.conf from the backup/other-partition

2. restore/copy ecs.conf

3. create a new variable, PEsohDeviceIP, in ecs.conf and assign it the value 0.0.0.0

4. delete the variables PClanIntf0 and PEInterface from the restored/copied ecs.conf

3.15.2 Simplex Main/ESS/LSP Servers and Duplicated ESS Servers

PE will always be assigned.

1. restore/copy servers.conf from the backup/other partition

2. restore/copy ecs.conf

3. create a new variable, PEsohDeviceIP, in ecs.conf and set its value to 0.0.0.0

4. add lines to the restored/copied servers.conf based on the content of ecs.conf/PClanIntf0 in the backup/other-partition data.

• use PClanintf0 to identify the NIC





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

• Use this NIC value to replicate entries in servers.conf to create the PE entries, except do not create an alias entry for PE even if the NIC already has one.

• Copy the server ID entries from the Cust entry in servers.conf to the PE entries

5. delete the variables PClanIntf0 and PEInterface from the restored/copied ecs.conf

3.16 Operation on ESS/LSP with Main Server on an Older Release

Operation and administration of the PE interface is server specific. There is no impact to having the main server running a different release from the LSP server. If an ESS is in the configuration (not recommended) if a fail-over to an ESS occurs, devices connected to the PE interface on the main will need to connect to a CLAN on the ESS.

3.17 System Impacts

• memory:

• real time:

• bugfix:

4. Hardware Requirements

None.

5. H.248 Gateway Requirements

<134539-1> Which Gateways

The following H.248 gateways shall be modified as specified in these requirements

• G450• G350• G250• G700• IG550

<134539-2> Accept Incoming Socket

H.248 gateways specified in requirement 1 shall listen on TCP port 1167 for an incoming connection from CM, and shall accept this connection only under the following circumstances:

• The incoming connection originates from an IP address that • the gateway thinks it already has a connection to, or• the gateway is currently not connect to a server and the IP address was where

the gateway was last connected.

If the incoming connection does not satisfy the above criteria, the gateway shall respond with a TCP FIN message.

Note that only one listening port is used for either encrypted or non-encrypted sessions. Both ends already know whether the link will or will not be encrypted because there had to be a prior connection.

<134539-3> Accept Response

If the gateway accepts an incoming connection per requirement 2, the gateway shall respond as follows:

1. If the gateway thinks it has an existing connection to this IP address, it shall close that connection.

2. If the gateway’s prior connection used pTLS, the gateway shall initiate a new pTLS connection on the new socket.

If pTLS was not in use, then the gateway will begin using the TCP connection immediately. However, it may take CM a couple of seconds to be able to begin to respond to messages. If the gateway has lots of activity,





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

messages may be lost.

3. The gateway shall use the new connection as a replacement for the old one.

4. The gateway shall not re-register.

5. The gateway shall not reset just due to the new connection arriving; both calls and connections shall be preserved from the gateway’s perspective.

Note that establishment of a new connection will reset packet sequence numbers and packets may be lost in either direction.

See related CM behavior beginning requirement 26 on page 25.

6. CM Software/Firmware Requirements

Note: the requirements define changes to provide faster recovery from a subset of all the devices that might be connected to a CM server. Devices which do no receive this new treatment will still recover as they do now, but not as quickly as devices receiving the new treatment.

<134539-4> SA9009

SA9009 shall be merged into the base as a normal system feature (ungreen); requirements in this document shall take precedence if differences are found in SA9009 implementation and these requirements.

It is important to not reference FEAT_DUP_PE_SIP_CFF in the code because this license bit could be removed or re-used for something else in a future release.

<134539-5> FEAT_PRETH License Bit

Software on all CM servers in all configurations shall operate as if the FEAT_PRETH bit is set to "on" regardless of its setting in the license file. Ideally, checks on the FEAT_PRETH bit would be removed from the code entirely; however it is acceptable for the code to force the bit to appear enabled internally regardless of its setting in the license.

<134539-6> H.248 Gateway License Support

CM shall be able to use both IPSIs and H.248 gateways connected to PE on duplicated servers as a license host. i.e. serial number, etc.

See routine "ls_gw_addr".

<134539-7> PClanIntf0 and PEInterface

The /etc/opt/ecs/ecs.conf variables PClanIntf0 and PEInterface shall be deleted.

<134539-8> PE on Duplicated Main Servers Requires An Alias Address

PE on duplicated main servers shall be assigned the alias address of the NIC to which PE is assigned. If an alias address is not administered, PE shall be disabled.

This is a requirement on how procr is assigned based on content of servers.conf.

<134539-9> PE on Duplicated ESS Servers

PE on duplicated ESS servers shall be assigned the server unique address of the NIC assigned to PE and never an alias address. See also requirement 53 on page 32.

This is basically a duplicate of the referenced requirement but is here to emphasize what is new in this release.

<134539-10> VoIp Resource

CM servers shall not accept new registrations from endpoints unless the server has a VoIP resource already registered. This requirement shall not inhibit recovery of sockets on a server becoming active as a result of an interchange. i.e. such sockets are recovered regardless of whether a VoIP resource is present or not.

An H.248 gateway must register before it is available to provide a VoIP resource. This "should" be boiler plate. i.e. this should be how it already operates, but in case there is some missing check when there is no port network....





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

<134539-11> IP Takeover

Only the active server shall listen on or otherwise use the PE interface on duplicated main servers. Control of the PE interface shall transition to the new active server during a processor interchange.

If the two servers are operational and if the two servers can communicate, the arbiter already has an algorithm to drop one server to standby in case both are active.

There are failure conditions (e.g. dual active) in which the PE interface may become non-functional due to two servers attempting to use the same IP address with different MAC addresses. The system will be out of service as long as this condition persists.

<134539-12> Flooding Prevention

Communication Manager already uses socket level flow control mechanisms. The PE interface shall be tested to verify that these flow control mechanisms operate properly.

See also Enhanced Firewall Administration, CID 122694 for use of the sklimit module.

<134539-13> PE Capacity

The Processor Ethernet interface shall be capable of supporting the full capacity of the server (numbers of active devices) for all permitted IP devices connected to the PE interface simultaneously. The BHCC of the server may be reduced; The call capacity shall be measured at 65% processor occupancy using comparable call mixes used to determine BHCC for other servers. The measured value shall be documented as the BHCC of the server.

<134539-14> Server Capacity

The total server capacity to support IP devices (numbers of active devices) shall not be reduced by use of the Processor Ethernet interface alone or in combination with CLANs.

<134539-15> PE and CLAN Mix (testable=n)

Implementation shall not preclude both the PE and the CLAN interfaces being used at the same time for any combination of devices provided that the published overall quantity and mix of devices permitted for the server is not exceeded. Note that five 9’s availability may not be supported with port networks in use.

i.e. you can use PE and CLANs in any mix but you don’t get any increased capacity.

A mixed configuration of PE and port networks will not be tested in this release.

<134539-16> Supported Adjuncts

The following types of adjuncts supporting IP connectivity shall be supported on the PE interface. Note that this requirement says these devices can operate on the PE interface; it does not prescribe interchange link bounce behavior which varies greatly among these devices.

• CDR• Messaging (all flavors that support IP connectivity)• AES• CMS/CCR/IQ• SES

Note that BCMS uses a SAT interface, not the PE interface. The SAT interface does not use PE even when connecting to port 5022.

<134539-17> System Initialization

Use of the Processor Ethernet shall not increase the time to service by more than 10% as compared to a system with the same configuration of devices connected via CLAN. This requirement shall apply in three cases:

• The time for server boot to full service• The time for a Communication Manager application-only full restart to full service• The time for an individual IP device to connect and achieve full service.

Full service is defined to mean the ability of all administered stations to receive an incoming call or originate an outgoing call.





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

Note that this requirement does NOT cover processor interchange.

<134539-18> PE and Processor Interchange

Use of the processor ethernet on duplicated main servers shall be possible with either hardware or software duplication. The advertised capacity of the servers shall not be reduced due to use of the PE interface as compared to use of CLAN only. (This is a capacity of phones, trunks, BHCC, etc. This is not necessarily internal capacity such as processor occupancy which could be higher at the same supported capacity.)

Design of specific data being shadowed for PE needs to be examined to ensure this works properly.

<134539-19> Delay of Normal Operation

On a server interchange with the standby refreshed, "Normal Operation" shall be delayed until after the gip has attempted to open all sockets per requirement 24 on page 25.

<134539-20> SUSER Connection Types

The suser process shall associate a type with each D-socket connection it establishes to the gip process for devices connected to the PE interface and shall share this type with the gip. e.g. setsockopt. Types shall include the following:

• Type 0: This connection is to a device, not otherwise identified by a unique non-zero type, that will not receive special recovery processing on server interchange.

• Type 1: This connection is to an H.248 gateway that will accept an incoming connection from the server to replace any existing connection from a gateway known to the device.

• Type 2: This connection is to a TTS aware IP telephone that identifies itself (protocol bit in the GRQ message TTSFeatureSet) as being able to respond to the new recovery strat-egy specified herein.

• Type 3: This connection is to a SIP trunk• Type 4: This connection is to an H.323 trunk

The nomenclature, Type 0, Type 1, etc, is used in this document to enable discussion of the concept; these terms do not imply an implementation, numeric or string value set.

<134539-21> Socket Port Numbers and Firewall Values

When the suser process informs the gip of socket type (type 1 and 2), the suser process shall also inform the gip of the port number and firewall rate limit values to use if/when these sockets are re-created as part of server interchange. Rate limits are only required for H.248 sockets. See also ecs.conf MGRateLimit.

The same port number can be used for all phones. The gateways normally originate the connection and listen on a specific port (which may be hard coded in the gip).

A rule like the following is established on the H.248 listen port:

ACCEPT tcp -- anywhere anywhere tcp dpt:h248message sklimit: avg 50/sec burst 100 port 2945

When CM "connects" the incoming socket to port 2945, the connection is moved to a different port, N. The sklimit associated with port 2945 is inherited by the connection moved to port N. When CM connects out to a gateway, the same inheritance does not occur. Thus CM needs to establish the rate limit "manually".

A similar processes is currently used for the H.323 port:

ACCEPT tcp -- anywhere anywhere tcp dpt:h323hostcall flags:FIN,SYN,RST,PSH,ACK,URG/SYN acl port: 1720listenerLOG tcp -- anywhere anywhere tcp dpt:h323hostcall flags:FIN,SYN,RST,PSH,ACK,URG/SYN limit: avg 5/min burst 5 LOG level warning

In the current CM implementation, when CM connects out to TTS phones, CM does not establish either the ACL nor the limit values for these sockets. But since this is only for logging, it only really affects debugging at some level.

<134539-22> SUSER Interchange Behavior

Suser in the server transitioning from standby to active on a server interchange shall not close D-sockets for type 1 and 2 connections. Processing of connections for other types of sockets shall not be modified.

<134539-23> GIP Connection Types

The gip process shall retain sufficient connection/socket type information received from the





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

suser to be able to satisfy requirement 24. The gip shall consider socket type to be type 0 unless told otherwise.

The gip will need to distinguish between type 1 and type 2 connections because they use different ports when creating the new socket. The gip does not presently need to remember the details of the other types. i.e it needs to know type 1, type 2 and everybody else.

<134539-24> GIP Interchange Behavior

In the server transitioning from standby to active, if the server interchange is

• in a server that is fully refreshed and• the startup is a warm start,

before the system enters normal op, the gip process shall:

• Automatically create a new Linux socket for each type 1 and 2 connection and replace any old socket information it may have with the new socket information (e.g. file/socket descriptor).

• Automatically set socket option values, per information from the suser process, for sock-ets it opens

• If creation of the new Linux socket fails, the GIP remember this failure and shall close/drop the D-socket after entering normal op.

• The gip shall retain control during its initialization { init() } until one attempt is made to open all type 1 and type 2 sockets.

The last bullet is the mechanism to prevent the system from entering normal op until the gip has done its work.

Initialization processing in the gip for sockets other than types 1 and 2 is not altered by this requirement.

<134539-25> Socket Shadowing

Data tables in the suser and gip processes related to connections to external IP devices connected to the PE interface shall be shadowed. Sufficient data shall be shadowed to support the recovery action defined herein; the connection type shall be included in the information being shadowed.

<134539-26> H.248 Gateway Session Restore

Sockets to H.248 gateways connected to PE will be established by the gip before normal op.

After entering normal op, if the gateway is using an encrypted link, the gateway shall re-establish the pTLS session.

If the gateway is using an unencrypted link, the suser process shall resume operation without additional session resumption messages to the gateway. i.e. there will likely already be messages in queue from the gateway.

Ideally, if the session is encrypted, suser would send a special test message to the gateway using the current encryption. If the gateway understands this message it responds to the suser and the session continues without a key change. This would only happen if no packets were lost during the interchange. If the gateway does not understand the special message then some packets were lost and the gateway signals to create new keys.

<134539-27> H.248 Registration Preserved

H.248 gateway registration shall be preserved across a warm-start server-interchange.

<134539-28> H.248 Gateway Throttling

CM shall not artificially limit the speed at which gateways return to service following a warm-start server-interchange. Specifically, CM shall assume that state information is preserved across an interchange and shall not require audit of this data prior to allowing the gateway to return to service.

<134539-29> Upgrade/Restore of Duplicated Main Servers

This requirement applies to upgrade or restore from a release prior to these changes. On an upgrade, files are copied from the "other" partition and on a restore, files are coped from a backup. Other than the source of data, the following operational requirements are common:

• restore/copy servers.conf from the backup/other partition





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

• restore/copy ecs.conf from backup/other partition• create a new variable, PEsohDeviceIP, in ecs.conf and assign it the value 0.0.0.0• delete the variables PClanIntf0 and PEInterface from the restored/copied ecs.conf

Note that immediately following an upgrade from a prior release, PE is not usable because it was not usable in the earlier release.

<134539-30> Upgrade/Restore of Simplex Main/ESS/LSP Servers and Duplicated ESS Servers

This requirement applies to upgrade or restore from a release prior to these changes. On an upgrade, files are copied from the "other" partition and on a restore, files are coped from a backup. Other than the source of data, the following operational requirements are common:

• restore/copy servers.conf from the backup/other partition• restore/copy ecs.conf from backup/other partition• create a new variable, PEsohDeviceIP, in ecs.conf and set its value to 0.0.0.0• add lines to the restored/copied servers.conf based on the content of

ecs.conf/PClanIntf0 in the backup/other-partition data. • use PClanintf0 to identify the NIC• Use this NIC value to replicate entries in servers.conf to create the PE entries, except

do not create an alias entry for PE even if the NIC already has one.• Copy the server ID entries from the Cust entry in servers.conf to the PE entries

• delete the variables PClanIntf0 and PEInterface from the restored/copied ecs.conf

<134539-31> SOH with No IPSIs

The arbiter shall ignore IPSIs in the state of health calculation when no IPSIs are administered.

<134539-32> PE SOH Effect on Interchange

If the SOH of the NIC assigned to the PE interface on duplicated servers is not the same, an interchange shall be done to the server with the better PE SOH. Note that this is without consideration of IPSI connectivity.

<134539-33> PE SOH Determination

The state of health of the PE interface shall be monitored on duplicated main servers only, and shall be determined by analysis of the following:

• Responses to ARP ping messages sent out the NIC associated with the PE interface to an external device (PING device) whose IP address is administered on the server’s web pages. The recommended device is the subnet default gateway router.

• Responses to ARP ping messages sent out the NIC assigned to the PE interface to the PE interface on the other server.

• The SOH for the PE shall be lowered if both ping targets fail to respond.

<134539-34> Exchange of PE SOH

Servers shall include PE SOH status in SOH information exchanged.

<134539-35> PING Device Unreachable

The network device being used to assist in PE state of health determination (PING device) shall be ARP ping’d at a rate of once every 3 seconds.

If availability analysis later indicates that this rate must be faster than 3 seconds, the rate shall be increased as needed within the range from three times every 2 seconds to once every 3 seconds. The PING code shall be modified/incorporated into the application if necessary to satisfy the rate requirement.

The device shall be considered unreachable if 2 consecutive responses are missed/not-received. The response to a PING shall be considered missed/absent if not received prior to the time to send the next ARP ping.

The interval is not administrable; however it is desirable that the value be stored in ecs.conf such that it could be modified in the field if needed or made administrable in the future if desired.

The original version of this requirement required a 1 second rate, but the PING code does not operate reliably





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

at that rate. A custom version of the PING code is required to achieve a 1 second PING rate.

<134539-36> PING Priority

Tasks which monitor the state of health of the interface used for PE shall operate with a priority at least as high as the PCD.

Otherwise, the SOH of the PE may not be determined in a timely manner, especially on a busy switch.

<134539-37> PE SOH Alarm

Alarms shall be generated for SOH of the PE interface as follows:

• If there is no response to the PE SOH Ping message from the PE SOH device a minor alarm shall be generated.

• If there is no response to the PE SOH Ping message from the other server, a minor alarm shall be generated.

• If there is no response from the SOH device and there is also no response from the other server a 3rd alarm shall be generated.• If the PE priority is NOT ignore, the 3rd alarm shall be a major alarm.• If the PE priority is ignore, the 3rd alarm shall be a minor alarm.

Alarms shall be generated within 10 seconds after the failure condition occurs and resolved within 10 seconds after the associated test passes.

<134539-38> PE SOH in Server Command output

A new line, labeled "Processor Ethernet:", shall be added to the server command output and shall display the SOH of the PE interface for each server. Values shall be "up" or "down" or "unused". A blank value shall be used to indicate status is unknown and may appear during various transient states while status is being determined. This line shall appear only on duplex main servers. See figure 10.

<134539-39> Arbiter Interfaces

The arbiter shall use all available NICs when attempting to contact its peer on the other server. The priority order shall be:

1. The NIC assigned to the duplication interface

SERVER STATUS Cluster ID: 001 Duplication: sw Standby Busied? no Standby Refreshed? yes Standby Shadowing: on Duplication Link: up Elapsed Time since Init/Interchange: 11d 02:30:53 sv-st10-2 sv-st10-1 ID: 002 (2) ID: 001 (1) Mode: Active Mode: Standby Major Alarms: yes Major Alarms: no Minor Alarms: yes Minor Alarms: no Control Network: 0 / 0 / 0 Control Network: 0 / 0 / 0

Processor Ethernet: up Processor Ethernet: down Server Hardware: okay Server Hardware: okay

Processes: okay Processes: okay

Figure 10. Enhanced Server Command Output





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

2. The NIC assigned to Control Network A

3. The NIC assigned to Control Network B

4. The NIC assigned to the Customer LAN

5. The NIC assigned to the Processor Ethernet (Note that generally PE is assigned to an interface supporting one of the other functions in this list. If the feature known as flexible NIC assignment ever gets implemented, there could be only a duplication NIC and a NIC for PE, however.)

6.1 SAT Form Changes

7. Integrated WEB Tools Impact

The web interface is the target of a number of outstanding/queued work items including,

• Conversion of the web interface implementation from C++ to PHP,

• Server/software generalization,

• Flexible NIC Assignment (CID 126798), and

• Enhanced Firewall support (CID 122694).

If any of these work items appear in a work plan prior to or in the same release as the changes specified herein, the details for web changes specified herein will need to be revisited. The following requirements attempt to minimize the amount of re-work when the above projects are implemented.

Figure 11, illustrates the current "set identities" web page in the configure server wizard for an S8500 server. A simplex example is shown here because it illustrates the current mechanism for PE assignment. PE assignment is not presented on web pages for duplicated servers, currently. The first change that needs to be made to this page is to convert the syntax of the assignment of PE from assignment to a functional LAN (control network, customer LAN) to an assignment of ethernet interface (eth0, eth1). This change is illustrated in figure 12.





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

There is an additional problem, however. The assignment of the PE interface has a dependency on the role of the processor -- whether it is an LSP, ESS or main server. Specifically, the PE interface MUST be assigned on an LSP

Figure 11. Existing PE Assignment on S8500

Figure 12. New Set Identities Web Page





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

and on an ESS (although its use is restricted here), but PE assignment is optional on a duplicated main server. The way these pages are arranged, the "set identities" page, where PE assignment is done, occurs before the server role is administered (Configure ESS/LSP). The solution that is the simplest to make is to move the "configure ESS/LSP" page to be the first page following the "review notices" page; that is, before the "set identities" page. A more customer friendly change would be to split the "configure ess/lsp" page into two pages as defined in figures 18 and 21 of CID 126798. This would minimize later additional churn in customer visible operation of the web pages.

In addition to the changes described above, assignment of the PE interface on duplicated main servers, requires assignment of an external device to PING in order to determine PE state of health. This PING address defaults to the address of the default gateway which is entered on the "configure interfaces" page in the configure server wizard. Thus the fields are added to that page so entries can be defaulted and checked. See figure 13.

The field the IP address of the PING device appears only for duplicated servers (easy) and only for MAIN servers (harder). This is another reason for a move of the "configure ESS/LSP" page.

<134539-40> CNA CNB Optional

It must be possible to not assign CNA and CNB on main servers. i.e. no control network assigned. In configurations with no port networks, these functions have no purpose.

This is another reason to move the LSP/ESS decision very early in the configure server web pages. Note also that assignment of the Enterprise LAN to a real NIC is still required. It may be the same NIC as used by the PE interface or not.

<134539-41> Configure ESS/LSP

(preferred) The configure ess/lsp web page shall be split in two as defined in CID 126798 figures 18 and 21. The figure 18 screen shall appear prior to the set identities page and the figure 21 screen shall replace the current configure ess/lsp page.

(acceptable) The existing configure ess/lsp page shall be moved to appear prior to the set identities page.

Either solution is acceptable, but splitting the page now reduces later change for the customer.

<134539-42> PE Assignment to NIC

The semantics for assigning the PE interface in web administration shall be changed from a

Figure 13. PE Additional Parameters





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

selection of possible functional LAN types (CNA, CNB, customer LAN) to a selection of possible Ethernet interfaces (eth0, eth1, eth2, eth3, eth4, eth5) as illustrated in figure 12. The PE interface may be assigned to any externally facing server NIC on the server except the ones assigned to the duplication link or the laptop link. An external facing NIC is one which is intended for external customer connections as compared to a NIC which is used internally to connect to things like the SAMP card. See remaining requirements for additional constraints

Currently, the PE interface is assigned by the user to a functional interface (control Lan, Enterprise Lan).

<134539-43> PE Defaults

The web page that administers PE to a NIC shall present current assignments when the page is displayed. On a server that has not been previously administered, the values shall be as follows: For simplex servers, the default shall be for the same NIC as for the Customer LAN. For duplex servers, the default shall be "unset".

<134539-44> PE Address Data

New lines shall be created in servers.conf to identify the PE NIC and IP address information as illustrated in table 3 on page 19. These lines shall be created even if they replicate data for another interface. e.g. customer LAN. Also, the server IDs, at the end of the lines for the customer LAN entry shall be copied to the PE entry. On duplicated main servers, an alias address must be assigned.

<134539-45> PE Change Notice

If data for the PE interface is changed via the web interface, CM is already notified to re-read the PE data. This notification shall be extended to include notification of the software that is monitoring PE health.

<134539-46> NIC Labels

The set identities web page shall display the names of all the functions assigned to a NIC when more than one function is assigned to a NIC. e.g. PE and customer LAN assigned to same NIC.

See figure 13 for example labeling of PE and Customer LAN on the same NIC.

<134539-47> PE Health Check

The web interface shall support assignment of an IP address for an external device to be PING’d as part of the health check of the PE interface. The IP address entered shall:

• be a valid IPV4 address • be on the same subnet as the PE interface• not be an IP address terminating on either server• be saved in the variable PEsohDeviceIP in the file /etc/opt/ecs/ecs.conf.

The field shall appear only for duplicated MAIN servers, and only if the PE is assigned to a NIC; when presented, the field is a required entry.

The help for the screen where this assignment is made shall recommend use of the default gateway for the subnet where the PE resides, although it is not required.

Note: It is acceptable for the user to specify a telephony gateway as the ping device so long as it is on the same subnet as the PE interface.

<134539-48> PE Administration by The User

The assignment of the PE to a NIC shall be user administrable on S8400, S8500 and S87xx servers. On S8300, assignment shall be automatic to the non-laptop interface.

This requirement may be generalized: If a server has only two ethernet interfaces (laptop + one other) then assignment is automatic to the non-laptop interface. If a server has more than two ethernet interfaces, then the user may assign the PE to any one of the external facing interfaces except the laptop interface or duplication interface.

Some servers use ethernet interfaces for internal communication to devices such as the SAMP. PE cannot be assigned to an internal interface.

Note that the ability to NOT assign the PE interface is new to this release. On duplicated MAIN servers, if an alias is not assigned, then the PE may not be used. This does mean that use of PE on duplicated MAIN servers





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

requires the servers to be on the same sub-net. In the normal case this means co-located, although there are schemes for extending sub-nets over distance.

<134539-49> S8300 PE Assignment and Use

Assignment of the PE interface on the S8300 shall not be administrable. The PE shall be assigned to interface eth1 per requirement 48 except that an alias is never assigned on an S8300. The configure server web page shall display the assignment "read only". THIS REQUIREMENT SIMPLY DOCUMENTS THAT THERE IS NO CHANGE FOR THIS SERVER TYPE.


Assignment of the PE interface on the S8400 shall administrable to interfaces,

• unused, eth0, eth2 or eth3

per requirement 48 except that an alias is never assigned on an S8400.

<134539-51> Xen Server PE Assignment and Use

Assignment of the PE interface on the Xen server shall administrable to interfaces,

• unused, eth0 or eth2

per requirement 48 except that an alias is never assigned on a Xen server.


Assignment of the PE interface on the S8500 shall be administrable to interfaces "unset" or to any non-laptop external facing NIC on the S8500 per requirement 48 except that an alias is never assigned on an S8500.

<134539-53> S87xx Duplicated Server PE Assignment and Use

Assignment of the PE interface on the S87xx servers shall be administrable to interfaces as defined in the following:

S87xx Main: The PE interface may be assigned to "unset’ or to any external facing NIC on the S87xx server except the laptop or duplication NICs.

The procr interface is disabled on duplicated main servers unless an alias address is assigned.

When enabled on a duplicated server, the procr interface shall be usable for the following purposes:

• Incoming registrations from an ESS or LSP• H.323 connections• H.248 connections• SIP Trunks• IP based adjunct connections

LSPs are always simplex servers. Duplicated servers may not be configured

as LSPs. (This is not changed from CM4.0)

S87xx ESS: On an S87xx ESS server, the PE interface must be assigned to one of the external facing ethernet interfaces.

Procr shall be assigned to a server unique IP address for the NIC assigned to PE.

On an S87xx ESS server the procr interface shall be usable for the following purposes: (This is not changed from CM4.0)

• Outgoing registrations to the main

<134539-54> Reset to Defaults

Reset to defaults on all servers shall mark the PE assignment unset.

The current S8300 reset to defaults web page sets the PE assignment to "unset". The configure server web pages then ensure that the PClanIntf0 value is set properly either via fixed assignment (e.g. S8300 ) or via customer administration.

S87xx LSP:





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

8. Firewall

There is a major revision to the firewall interface in queue as work item 8674 and defined in Compas ID 122694. If this work is done, the following general rules applied to the INPUT chain of all interfaces would eliminate any special work for the PE interface.

ACCEPT tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/SYN listenerACCEPT udp -- any any anywhere anywhere listenerACCEPT tcp -- any any anywhere anywhere state RELATED,ESTABLISHED

The "listener" module causes a port to be opened whenever there is a listen socket open on the port. Ports are open dynamically as CM opens listen sockets without having to establish unique rules per port or interface.

Adding these general rules without the other changes specified in CID122694 won’t work without additional modifications not related to PE support. For example, the "server access" web page manipulates the firewall and that page would have to be modified as well. Instead, the specific ports needed on the PE interface must be handled individually.

<134539-55> Firewall INPUT Chain

Firewall ports in the INPUT CHAIN, needed by the PE interface on duplicated main servers, shall be opened on the NIC to which the PE is assigned for those ports shown in tables 4 and 5 with "yes" in the PE column. PE assignment on other server types shall not be altered.

Ports shall be opened on the INPUT chain using a "listener" module.

Note that typical administration ports (e.g. ssh) are not opened on this interface. The customer LAN is still required to be administered and may or may not be on the same Ethernet interface as the PE.

Table 4. "Standard" Services

PE Service Port Protocol Comment

yes echo/ping 8 icmp

ftp 21 tcp File transfer. Disabled by default

ssh 22 tcp Used for server administration and SAT access.

telnet 23 tcp Used for server administration and SAT access. Dae-mon disabled by default

DNS 53 udp Domain Name Service

bootps 67 tcp/udp Used when IPSIs configured for DHCP

bootpc 68 tcp/udp Used when IPSIs configured for DHCP

yes tftp 69 udp Used in some configurations for Announcement fetch by gateways

http 80 tcp Server administration home page -- redirects to https.

sunrpc 111 tcp/udp Used by IA770

yes ntp 123 udp CM servers act as client to network time server and also act as source to gateways

snmp 161 udp SNMP administration access

snmp traps 162 udp CM receives some traps from Gateways and UPS units.

ldap 389 tcp Used by IA770 and by LDAP based Login processing

https 443 tcp Server administration via the web

syslog 514 udp CM servers may be configured to send logs to a cen-tral server. CM servers may also receive logs from gateways.

ldaps 636 tcp Used by LDAP based Login processing

radius 1812 udp Used by RADIUS based Login processing

radius accounting 1813 udp Used by RADIUS based Login processing

ssh 2222 tcp High Priority ssh. Used to gain control of server by Avaya services in cases of high server occupancy





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

SafeWord 5030 tcp Used by Secure Computing Corporation SafeWord based Login Processing. The default port is shown. Each installation could choose a different port.

securID 5500 udp Used by RSA Corporation SecurID based Login Pro-cessing. The default port is shown. Each installation could choose a different port.

Table 5. CM Specific Services

PE Service Port Protocol USE

samp-http 80 tcp Used between CM server and SAMP

samp-https 80 tcp Used between CM server and SAMP

http-ipphone 81 tcp IP phone firmware download; ports opened/closed by web pages based on use.

https-ipphone 411 tcp Secure IP phone firmware download; ports opened/closed by web pages based on use.

vphone 1037 tcp Used for older "double connect" IP phones

yes encrypted-h248 1039 tcp Encrypted links to gateways

samp 1234 tcp Used between CM server and SAMP

vaa 1320 tcp Used by IA770

arbiter 1332 udp duplicated systems only; Note this port must be opened on the PE interface in PE-only systems.

arbiter 1333 udp duplicated systems only; Note this port must be opened on the PE interface in PE-only systems.

yes h323gatestat 1719 udp ESS registration. In on Main servers, out on ESS

yes h323hostcall 1720 tcp IP phone call control link

ipsi-cmds 1956 tcp resetipsi, loadipsi, telnetenable commands for IPSI

yes h248message 2945 tcp Non-encrypted link to gateways

pcd-ipsi 5010 tcp Interface between CM and the IPSI for call processing

ipsi version 5011 tcp IPSI version port

ipsilic 5012 tcp IPSI license port

secure-sat 5022 tcp direct SAT access using ssh

def-sat 5023 tcp direct SAT access using telnet

yes sip 5060 tcp public sips

yes sip-tls 5061 tcp secret sips

dupmgr-swdup 5098 tcp software duplication

licsvr 5423 tcp should not be open on firewall

Enterprise wide Licensing

5424 tcp should not be open on firewall as EWL has not been adopted by CM.

audix 5500 tcp Used by IA770; see also securID in previous table

AE Services 8765 tcp Application Enablement Service

samp-ssh 10022 tcp Used between CM server and SAMP

dupmgr 12080 tcp duplicated servers only

samp 19121 udp Used between CM server and SAMP

filesync (1.3) 514 tcp CM 1.3 used this port

filesync (2.x) 21873 tcp Older servers used this port. It is left open for back-wards compatibility only.

filesync (3.0 and later)

21874 tcp input on LSPs and ESSs output on main servers

IMAPI 55000 tcp Used by IA770

message waiting 1024:65535 udp Used by IA770 to message manager

Table 4. "Standard" Services

PE Service Port Protocol Comment





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

<134539-56> Special Port Handling

The following ports shall be opened in the INPUT CHAIN with conditions as follows:

ACCEPT tcp -- PE * tcp dpt:2945 sklimit: avg 50/sec burst 100 port 2945 listenerDROP tcp -- PE * tcp dpt:2945

ACCEPT tcp -- PE * tcp dpt:1720 flags:0x3F/0x02 acl port: 1720 listenerLOG tcp -- PE * tcp dpt:1720 flags:0x3F/0x02 limit: avg 5/min burst 5 LOG flags 0 level 4 DROP tcp -- PE * tcp dpt:1720 flags:0x3F/0x02

ACCEPT tcp -- PE * tcp dpt:81 flags:0x3F/0x02 listener#conn/0 < 100 ACCEPT tcp -- PE * tcp dpt:411 flags:0x3F/0x02 listener#conn/0 < 100

This should represent no change to how the ports are opened currently, except they will be open on the PE interface as well as potentially other interfaces.

<134539-57> Firewall OUTPUT chain

TCP ports 1024 through 65535 and UDP port 1719 shall be opened in the OUTPUT CHAIN on the NIC assigned to the PE interface.

9. Other Systems Impacted

• Services systems -- none

See the discussion in CID 122596 for impacts to external devices using PE on duplicated servers.

10. Special Requirements

The following requirements were in the original SRAD (122596) and in the initial drafts of this SRAD. Code for these requirements is already in the base as part of the increased capacity of the S8510 servers. However, this feature was deleted from this release. So although the code is already in place it needs testing.

<134539-58> Socket Increases (Testing only)

The number of sockets, the number of simultaneous socket requests being processed, the number of simultaneous socket attempts (new socket establish) and the number of file descriptors shall be increased as necessary to meet the increased capacity and performance needs of the PE interface. This may involve an increase in both Linux and in the Telephony Application as necessary.

The amount of the increase will be discovered during design and initial testing. The number of sockets supported in the GIP is already 24,575 and may be sufficient.

<134539-59> S8500 LSP License Truncation Limits (Testing only)

The S8500 LSP servers shall have their license truncation limits raised to match those of the non-XL S87xx servers (Stingray) for all limits in order to allow an S8500 LSP to provide backup for an entire system. It is desirable that "XL" limits are supported if there is sufficient memory available.

In configurations without port networks, there is no ESS. So this change allows the customer to essentially have an enterprise backup solution. License truncation limits are defined in CID 88705. The differences are

yes ip-signaling-1 5000:5021 tcp Split into two parts, ip-signaling-1 and 2 due to use of 5022 and 5023 for SAT access.

yes ip-signaling-2 5024:9999 tcp

yes ip-signaling 2048:65535 udp

yes H.323 Signaling 1024:65531 tcp

yes h245 59000:59200 tcp Gateway interface.

Table 5. CM Specific Services

PE Service Port Protocol USE





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

highlighted in the following table.

Table 6. License_trunc[] From CM4.1

(6)STINGRAY

(12)S8500

(21)S8500_LSP

(9)CHAWK_

LSPUse

1 0,48000, 0,3200, 0,48000, 0,48000, /* PORT */

3 0,14, 0,14, 0,14, 0,14, /* VERSION */

5 0,27, 0,27, 0,27, 0,27, /* CCRELEASE */

7 0,7000, 0,1000, 0,7000, 0,7000, /* LOGGIN */

9 0,7000, ✰ 0,1000, 0,1000, ✰ 0,450, /* ADVOCATE */

11 0,9, 0,9, 0,9, 0,9, /* MODEL */

13 0,2, 0,2, 0,2, 0,2, /* ILOCATION */

15 0,36000, 0,2400, 0,36000, 0,36000, /* XMOB_NUM */

17 0,12000, 0,800, 0,12000, 0,12000, /* RO_TRK */

19 0,12000, 0,800, 0,12000, 0,12000, /* IP_TRK */

21 0,12000, ✰ 0,2400, 0,2400, ✰ 0,12000, /* IP_STN */

23 0,7000, ✰ 0,1000, 0,1000, ✰ 0,450, /* IPA */

25 0,2, 0,2, 0,2, 0,2, /* OFFER */

27 0,12000, 0,2400, 0,12000, 0,12000, /* RO_STN */

29 0,688, 0,80, 0,688, 0,688, /* DS1_ECHO */

31 0,128, 0,10, 0,128, 0,128, /* VAL_BRD */

33 0,3, 0,3, 0,3, 0,3, /* LBSTAR_CFF */

35 0,414, 0,68, 0,414, 0,68, /* IP_ATTD_CON */

37 0,6, 0,12, 0,6, 0,9, /* PLATFORM */

39 0,0, 0,0, 0,0, 0,0, /* IPSOFTPHONE */

41 0,250, 0,250, 0,250, 0,250, /* MGA_SRC */

43 0,5000, 0,800, 0,5000, 0,5000, /* SIP_TRK */

45 0,36000, 0,2400, 0,36000, 0,36000, /* OPT_EC500 */

47 0,36000, 0,2400, 0,36000, 0,36000, /* OPT_SSE */

49 0,36000, 0,2400, 0,36000, 0,36000, /* OPT_OPS */

51 0,36000, 0,2400, 0,36000, 0,36000, /* STA */

53 0,0, 0,0, 0,0, 0,0, /* 2602_VC */

55 0,300, 0,300, 0,300, 0,300, /* EMMC_PORTS */

57 0,12000, ✰ 0,2400, 0,2400, ✰ 0,12000, /* VC_H323 */

59 0,12000, ✰ 0,2400, 0,2400, ✰ 0,12000, /* VC_IPSP */

61 0,12000, ✰ 0,2400, 0,2400, ✰ 0,12000, /* UNAUTH_EPT */

63 0,128, 0,128, 0,128, 0,128, /* 2602_80VC */

65 0,128, 0,128, 0,128, 0,128, /* 2602_320VC */

67 0,36000, 0,2400, 0,36000, 0,36000, /* OPT_PBFMC */

69 0,36000, 0,2400, 0,36000, 0,36000, /* OPT_PVFMC */

71 0,12000, 0,1600, 0,12000, 0,12000, /* AVC_PORTS */

73 0,2500, ✰ 0,100, 0,100, ✰ 0,50, /*SIPEAS */

.. {0,0,12000} ✰ {0,0,2400} {0,0,2400} ✰ {0,0,450} /* IP_Agent */

.. {0,0,414} {0,0,68} {0,0,414} {0,0,68} /* IP_eCons */

.. {0,0,12000} ✰ {0,0,2400} {0,0,2400} ✰ {0,0,450} /* IP_Phone */

.. {0,0,12000} ✰ {0,0,2400} {0,0,2400} ✰ {0,0,450} /* IP_ROMax */

.. {0,0,12000} ✰ {0,0,2400} {0,0,2400} ✰ {0,0,450} /* IP_Soft */

.. {0,0,12000} ✰ {0,0,2400} {0,0,2400} ✰ {0,0,450} /* IP_API_A */

.. {0,0,12000} ✰ {0,0,2400} {0,0,2400} ✰ {0,0,450} /* IP_API_B */

.. {0,0,12000} ✰ {0,0,2400} {0,0,2400} ✰ {0,0,450} /* IP_API_C */

.. {0,0,12000} ✰ {0,0,2400} {0,0,2400} ✰ {0,0,450} /* IP_IR_A */





1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

<134539-60> S8500 Boot Time Parameters (Testing only)

The S8500 shall have boot time parameters not smaller than those of an S87xx processor. It is desirable that the S8500 boot time parameters support "XL" configurations if sufficient memory is present.

Comments from Tam:Currently the S8500 has the same btm_parm (Large) as the S87xx. As far as the XL part goes... The S8500C has 1GB of memory & therefore has enough capacity to run with the X Large Memory Configuration. If 512MB of RAM is added to an S8500B/C server, it too has enough capacity to run with XL. See Table 4 in Modhumita’s XL SRAD (117073)http://compasfs.dr.avaya.com/cgi-bin/wwwcompas?prodid=117073&dformat=pdf The desirable portion of this requirement would make the S8500 an XL server. For the CM4.0 XL SRAD, product management wanted ONLY the S8720 to be XL. For CM4.1, when opportunity presented to make the S7810 XL, product management demurred. We might want to run this past Debbie Goldman.

<134539-61> Ip-Interface Procr Form (Testing only)

The "target socket load" field on the "IP-Interface Procr" SAT form shall be increased to 5 digits (currently 4 digits).

11. ACKNOWLEDGEMENTS

Special thanks to Tam Noirot for guidance in ESS configurations, to Ji Ran for help in PE in general, and to Jim Rhodes for inventing the GIP/SUSER changes to build on current work by Bob Brown, and on-going mentoring.

PE for Duplicated Main Servers List of Requirements -38-




1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

<134539-1> Which Gateways - - - - - - - - - - - - - - - - - - - - - - - - - 21<134539-2> Accept Incoming Socket - - - - - - - - - - - - - - - - - - - - - 21<134539-3> Accept Response - - - - - - - - - - - - - - - - - - - - - - - - 21<134539-4> SA9009 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 22<134539-5> FEAT_PRETH License Bit - - - - - - - - - - - - - - - - - - - - 22<134539-6> H.248 Gateway License Support - - - - - - - - - - - - - - - - - 22<134539-7> PClanIntf0 and PEInterface - - - - - - - - - - - - - - - - - - - 22<134539-8> PE on Duplicated Main Servers Requires An Alias Address - - - - 22<134539-9> PE on Duplicated ESS Servers - - - - - - - - - - - - - - - - - - 22<134539-10> VoIp Resource - - - - - - - - - - - - - - - - - - - - - - - - - 22<134539-11> IP Takeover - - - - - - - - - - - - - - - - - - - - - - - - - - 23<134539-12> Flooding Prevention - - - - - - - - - - - - - - - - - - - - - - 23<134539-13> PE Capacity - - - - - - - - - - - - - - - - - - - - - - - - - - 23<134539-14> Server Capacity - - - - - - - - - - - - - - - - - - - - - - - - 23<134539-15> PE and CLAN Mix (testable=n) - - - - - - - - - - - - - - - - - 23<134539-16> Supported Adjuncts - - - - - - - - - - - - - - - - - - - - - - - 23<134539-17> System Initialization - - - - - - - - - - - - - - - - - - - - - - 23<134539-18> PE and Processor Interchange - - - - - - - - - - - - - - - - - - 24<134539-19> Delay of Normal Operation - - - - - - - - - - - - - - - - - - - 24<134539-20> SUSER Connection Types - - - - - - - - - - - - - - - - - - - 24<134539-21> Socket Port Numbers and Firewall Values - - - - - - - - - - - - 24<134539-22> SUSER Interchange Behavior - - - - - - - - - - - - - - - - - - 24<134539-23> GIP Connection Types - - - - - - - - - - - - - - - - - - - - - 24<134539-24> GIP Interchange Behavior - - - - - - - - - - - - - - - - - - - - 25<134539-25> Socket Shadowing - - - - - - - - - - - - - - - - - - - - - - - 25<134539-26> H.248 Gateway Session Restore - - - - - - - - - - - - - - - - - 25<134539-27> H.248 Registration Preserved - - - - - - - - - - - - - - - - - - 25<134539-28> H.248 Gateway Throttling - - - - - - - - - - - - - - - - - - - 25<134539-29> Upgrade/Restore of Duplicated Main Servers - - - - - - - - - - 25<134539-30> Upgrade/Restore of Simplex Main/ESS/LSP Servers and Duplicated ESS Servers 26<134539-31> SOH with No IPSIs - - - - - - - - - - - - - - - - - - - - - - - 26<134539-32> PE SOH Effect on Interchange - - - - - - - - - - - - - - - - - 26<134539-33> PE SOH Determination - - - - - - - - - - - - - - - - - - - - - 26<134539-34> Exchange of PE SOH - - - - - - - - - - - - - - - - - - - - - - 26<134539-35> PING Device Unreachable - - - - - - - - - - - - - - - - - - - 26<134539-36> PING Priority - - - - - - - - - - - - - - - - - - - - - - - - - 27<134539-37> PE SOH Alarm - - - - - - - - - - - - - - - - - - - - - - - - - 27<134539-38> PE SOH in Server Command output - - - - - - - - - - - - - - - 27<134539-39> Arbiter Interfaces - - - - - - - - - - - - - - - - - - - - - - - - 27<134539-40> CNA CNB Optional - - - - - - - - - - - - - - - - - - - - - - 30<134539-41> Configure ESS/LSP - - - - - - - - - - - - - - - - - - - - - - 30<134539-42> PE Assignment to NIC - - - - - - - - - - - - - - - - - - - - - 30<134539-43> PE Defaults - - - - - - - - - - - - - - - - - - - - - - - - - - 31<134539-44> PE Address Data - - - - - - - - - - - - - - - - - - - - - - - - 31<134539-45> PE Change Notice - - - - - - - - - - - - - - - - - - - - - - - 31<134539-46> NIC Labels - - - - - - - - - - - - - - - - - - - - - - - - - - - 31

PE for Duplicated Main Servers List of Requirements -39-




1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

<134539-47> PE Health Check - - - - - - - - - - - - - - - - - - - - - - - - 31<134539-48> PE Administration by The User - - - - - - - - - - - - - - - - - 31<134539-49> S8300 PE Assignment and Use - - - - - - - - - - - - - - - - - 32<134539-50> S8400 PE Assignment and Use - - - - - - - - - - - - - - - - - 32<134539-51> Xen Server PE Assignment and Use - - - - - - - - - - - - - - - 32<134539-52> S8500 PE Assignment and Use - - - - - - - - - - - - - - - - - 32<134539-53> S87xx Duplicated Server PE Assignment and Use - - - - - - - - 32<134539-54> Reset to Defaults - - - - - - - - - - - - - - - - - - - - - - - - 32<134539-55> Firewall INPUT Chain - - - - - - - - - - - - - - - - - - - - - 33<134539-56> Special Port Handling - - - - - - - - - - - - - - - - - - - - - - 35<134539-57> Firewall OUTPUT chain - - - - - - - - - - - - - - - - - - - - 35<134539-58> Socket Increases (Testing only) - - - - - - - - - - - - - - - - - 35<134539-59> S8500 LSP License Truncation Limits (Testing only) - - - - - - - 35<134539-60> S8500 Boot Time Parameters (Testing only) - - - - - - - - - - - 37<134539-61> Ip-Interface Procr Form (Testing only) - - - - - - - - - - - - - - 37