Avaya Aura® Application Server 5300 Planning and Engineering
Release 2.0 NN42040-200, Document Revision: 02.06 March 22, 2012 © 2010 Avaya Inc. different number of licenses or units of capacity is specified in the Documentation or other materials available to End User. “Designated All Rights Reserved. Processor” means a single stand-alone computing device. “Server” means a Designated Processor that hosts a software application to be Notice accessed by multiple users. “Software” means the computer programs in object code, originally licensed by Avaya and ultimately utilized by While reasonable efforts have been made to ensure that the End User, whether as stand-alone Products or pre-installed on information in this document is complete and accurate at the time of Hardware. “Hardware” means the standard hardware originally sold by printing, Avaya assumes no liability for any errors. Avaya reserves the Avaya and ultimately utilized by End User. right to make changes and corrections to the information in this document without the obligation to notify any person or organization of License Types such changes. Designated System(s) License (DS). End User may install and use Documentation disclaimer each copy of the Software on only one Designated Processor, unless a different number of Designated Processors is indicated in the “Documentation” means information published by Avaya in varying Documentation or other materials available to End User. Avaya may mediums which may include product information, operating instructions require the Designated Processor(s) to be identified by type, serial and performance specifications that Avaya generally makes available number, feature key, location or other specific designation, or to be to users of its products. Documentation does not include marketing provided by End User to Avaya through electronic means established materials. Avaya shall not be responsible for any modifications, by Avaya specifically for this purpose. additions, or deletions to the original published version of documentation unless such modifications, additions, or deletions were Concurrent User License (CU). End User may install and use the performed by Avaya. End User agrees to indemnify and hold harmless Software on multiple Designated Processors or one or more Servers, Avaya, Avaya's agents, servants and employees against all claims, so long as only the licensed number of Units are accessing and using lawsuits, demands and judgments arising out of, or in connection with, the Software at any given time. A “Unit” means the unit on which Avaya, subsequent modifications, additions or deletions to this documentation, at its sole discretion, bases the pricing of its licenses and can be, to the extent made by End User. without limitation, an agent, port or user, an e-mail or voice mail account in the name of a person or corporate function (e.g., webmaster or Link disclaimer helpdesk), or a directory entry in the administrative database utilized Avaya is not responsible for the contents or reliability of any linked Web by the Software that permits one user to interface with the Software. sites referenced within this site or documentation provided by Avaya. Units may be linked to a specific, identified Server. Avaya is not responsible for the accuracy of any information, statement or content provided on these sites and does not necessarily endorse Database License (DL). End User may install and use each copy of the the products, services, or information described or offered within them. Software on one Server or on multiple Servers provided that each of Avaya does not guarantee that these links will work all the time and has the Servers on which the Software is installed communicate with no no control over the availability of the linked pages. more than a single instance of the same database.
Warranty CPU License (CP). End User may install and use each copy of the Software on a number of Servers up to the number indicated by Avaya Avaya provides a limited warranty on its Hardware and Software provided that the performance capacity of the Server(s) does not (“Product(s)”). Refer to your sales agreement to establish the terms of exceed the performance capacity specified for the Software. End User the limited warranty. In addition, Avaya’s standard warranty language, may not re-install or operate the Software on Server(s) with a larger as well as information regarding support for this Product while under performance capacity without Avaya's prior consent and payment of an warranty is available to Avaya customers and other parties through the upgrade fee. Avaya Support Web site: http://support.avaya.com. Please note that if you acquired the Product(s) from an authorized Avaya reseller outside Named User License (NU). End User may: (i) install and use the of the United States and Canada, the warranty is provided to you by Software on a single Designated Processor or Server per authorized said Avaya reseller and not by Avaya. Named User (defined below); or (ii) install and use the Software on a Server so long as only authorized Named Users access and use the Licenses Software. “Named User”, means a user or device that has been expressly authorized by Avaya to access and use the Software. At THE SOFTWARE LICENSE TERMS AVAILABLE ON THE AVAYA Avaya's sole discretion, a “Named User” may be, without limitation, WEBSITE, HTTP://SUPPORT.AVAYA.COM/LICENSEINFO/ ARE designated by name, corporate function (e.g., webmaster or helpdesk), APPLICABLE TO ANYONE WHO DOWNLOADS, USES AND/OR an e-mail or voice mail account in the name of a person or corporate INSTALLS AVAYA SOFTWARE, PURCHASED FROM AVAYA INC., function, or a directory entry in the administrative database utilized by ANY AVAYA AFFILIATE, OR AN AUTHORIZED AVAYA RESELLER the Software that permits one user to interface with the Software. (AS APPLICABLE) UNDER A COMMERCIAL AGREEMENT WITH AVAYA OR AN AUTHORIZED AVAYA RESELLER. UNLESS Shrinkwrap License (SR). Customer may install and use the Software OTHERWISE AGREED TO BY AVAYA IN WRITING, AVAYA DOES in accordance with the terms and conditions of the applicable license NOT EXTEND THIS LICENSE IF THE SOFTWARE WAS OBTAINED agreements, such as “shrinkwrap” or “clickthrough” license FROM ANYONE OTHER THAN AVAYA, AN AVAYA AFFILIATE OR AN accompanying or applicable to the Software (“Shrinkwrap License”). AVAYA AUTHORIZED RESELLER; AVAYA RESERVES THE RIGHT (see “Third-party Components” for more information). TO TAKE LEGAL ACTION AGAINST YOU AND ANYONE ELSE USING OR SELLING THE SOFTWARE WITHOUT A LICENSE. BY Copyright INSTALLING, DOWNLOADING OR USING THE SOFTWARE, OR AUTHORIZING OTHERS TO DO SO, YOU, ON BEHALF OF Except where expressly stated otherwise, no use should be made of YOURSELF AND THE ENTITY FOR WHOM YOU ARE INSTALLING, materials on this site, the Documentation, Software, or Hardware DOWNLOADING OR USING THE SOFTWARE (HEREINAFTER provided by Avaya. All content on this site, the documentation and the REFERRED TO INTERCHANGEABLY AS “YOU” AND “END USER”), Product provided by Avaya including the selection, arrangement and AGREE TO THESE TERMS AND CONDITIONS AND CREATE A design of the content is owned either by Avaya or its licensors and is BINDING CONTRACT BETWEEN YOU AND AVAYA INC. OR THE protected by copyright and other intellectual property laws including the APPLICABLE AVAYA AFFILIATE ( “AVAYA”). sui generis rights relating to the protection of databases. You may not modify, copy, reproduce, republish, upload, post, transmit or distribute Avaya grants End User a license within the scope of the license types in any way any content, in whole or in part, including any code and described below. The applicable number of licenses and units of software unless expressly authorized by Avaya. Unauthorized capacity for which the license is granted will be one (1), unless a reproduction, transmission, dissemination, storage, and or use without
2 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] the express written consent of Avaya can be a criminal, as well as a civil offense under the applicable law.
Third-party components Certain software programs or portions thereof included in the Product may contain software distributed under third party agreements (“Third Party Components”), which may contain terms that expand or limit rights to use certain portions of the Product (“Third Party Terms”). Information regarding distributed Linux OS source code (for those Products that have distributed the Linux OS source code), and identifying the copyright holders of the Third Party Components and the Third Party Terms that apply to them is available on the Avaya Support Web site: http://support.avaya.com/Copyright.
Preventing Toll Fraud “Toll fraud” is the unauthorized use of your telecommunications system by an unauthorized party (for example, a person who is not a corporate employee, agent, subcontractor, or is not working on your company's behalf). Be aware that there can be a risk of Toll Fraud associated with your system and that, if Toll Fraud occurs, it can result in substantial additional charges for your telecommunications services.
Avaya Toll Fraud Intervention If you suspect that you are being victimized by Toll Fraud and you need technical assistance or support, call Technical Service Center Toll Fraud Intervention Hotline at +1-800-643-2353 for the United States and Canada. For additional support telephone numbers, see the Avaya Support Web site: http://support.avaya.com. Suspected security vulnerabilities with Avaya products should be reported to Avaya by sending mail to: [email protected].
Trademarks The trademarks, logos and service marks (“Marks”) displayed in this site, the Documentation and Product(s) provided by Avaya are the registered or unregistered Marks of Avaya, its affiliates, or other third parties. Users are not permitted to use such Marks without prior written consent from Avaya or such third party which may own the Mark. Nothing contained in this site, the Documentation and Product(s) should be construed as granting, by implication, estoppel, or otherwise, any license or right in and to the Marks without the express written permission of Avaya or the applicable third party.
Avaya is a registered trademark of Avaya Inc.
All non-Avaya trademarks are the property of their respective owners, and “Linux” is a registered trademark of Linus Torvalds.
Downloading Documentation For the most current versions of Documentation, see the Avaya Support Web site: http://support.avaya.com.
Contact Avaya Support Avaya provides a telephone number for you to use to report problems or to ask questions about your Product. The support telephone number is 1-800-242-2121 in the United States. For additional support telephone numbers, see the Avaya Web site: http://support.avaya.com.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 3 4 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Contents
Chapter 1: New in this release...... 11 Features...... 11 Other changes...... 11 Chapter 2: Introduction...... 13 Audience for this document...... 13 Chapter 3: Application Server 5300 overview...... 15 SIP Core components...... 16 AS 5300 Session Manager...... 17 System Management Console...... 19 AS 5300 System Manager and Fault Performance Manager...... 20 Database Manager...... 20 Accounting Manager...... 20 IP Client Manager (Non DoD)...... 21 Provisioning Manager and Personal Agent Manager...... 21 Provisioning Client...... 21 Media Server...... 22 Gateways...... 22 PRI Gateway...... 22 Integrated Access Device...... 23 AudioCodes EMS...... 23 Access clients...... 24 IP Phones...... 24 Avaya Aura AS 5300 UC Client...... 24 Avaya Aura AS 5300 Personal Agent ...... 25 Third-party network appliances...... 25 Edge Boundary Controller...... 26 Real-Time Monitors (RTMI) Switch Expert...... 26 Federal DoD Application Server 5300 Release 1.0 PBX1 migration path...... 27 Chapter 4: Application Server 5300 hardware and configurations...... 29 Hardware...... 29 System configuration...... 32 Small configuration...... 33 Medium configuration...... 34 Large configuration...... 36 SIP Core server configuration summary...... 41 VLAN and MultiSubnet...... 41 IP addressing...... 45 IPv4 addressing...... 45 IPv6 addressing...... 46 Chapter 5: Deployment planning...... 49 Logical hierarchy...... 49 L5 Network Control Center...... 50 L4 Network Signaling Center...... 50 L3 Media Concentration Center...... 51
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 5 L2 Local Point-of-Presence...... 51 L1 Customer Application Server 5300 Client Site...... 51 Chapter 6: Application Server 5300 deployment planning...... 53 Step 1: Data collection for site planning...... 53 Step 2: Domain trees planning...... 58 Domain management...... 59 Subscriber load distribution...... 60 Localized pooled entities for traffic and services optimization...... 61 Routing translation considerations...... 63 Step 3: Location trees planning...... 65 Step 4: Routability groups planning...... 70 Step 5: RTP Media Portal Groups planning...... 73 Step 6: Subscriber services planning...... 74 Step 7: Service quality planning...... 78 Chapter 7: System capacity planning...... 81 Weighted transaction model...... 81 System capacity engineering...... 83 AS 5300 Session Manager engineering...... 84 Master LSC SESM Engineering (DoD Only)...... 92 SS SESM engineering (DoD Only)...... 95 Understanding Presence impact on system capacity...... 96 Erlang...... 97 MAS capacity planning...... 98 Media gateway capacity planning...... 101 Media gateway V.150.1 traffic planning...... 103 Chapter 8: Application Server 5300 IP service network planning...... 105 VoIP anatomy...... 106 IP QoS parameters...... 107 Delay...... 107 Jitter...... 111 Packet loss...... 112 Codec...... 114 Echo...... 116 Assessing voice quality...... 119 Voice quality rating: MOS...... 120 Voice quality rating: R-values...... 122 IP network planning...... 124 Application Server 5300 reference networks...... 124 Network qualification...... 128 Traffic engineering...... 130 Voice traffic...... 131 Video traffic...... 135 Signaling traffic...... 136 Low speed link...... 138 Manage end-to-end impairment budgets...... 140 QoS recommendations...... 145 Ethernet 802.1q/p...... 145
6 Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 IP Differentiated Services...... 146 QoS queue mappings...... 149 Application Server 5300 QoS support...... 152 End-to-end QoS support...... 152 Assured Real-Time Services (DoD only)...... 152 Application Server 5300 ASAC configurations...... 154 Determine Interenclave ASAC voice-only budget...... 155 Determine Interenclave ASAC video budget...... 157 QoS accounting services...... 158 Global IP Sound NetEQ...... 159 IP addressing and routing recommendations...... 160 IP addressing recommendations...... 161 IP routing recommendations...... 161 IP over WAN recommendations...... 163 IP network services requirements...... 163 Firewall...... 164 DHCP...... 165 DNS...... 166 LDAP...... 166 Network Time Protocol...... 167 Chapter 9: Reliability and robustness...... 171 Server platform redundancy...... 171 Network and power redundancy...... 172 SIP Core component reliability...... 172 AS 5300 Session Manager reliability...... 173 Database Manager reliability...... 175 Accounting Manager reliability...... 175 AS 5300 System Manager and Fault Performance Manager reliability...... 175 Provisioning Manager and Personal Agent Manager reliability...... 176 Media Application Server...... 177 Media Gateway...... 178 Access Client reliability...... 179 IP Deskphone reliability...... 179 Avaya Aura AS 5300 UC Client reliability...... 180 Personal Agent reliability...... 180 Integrated Audio Device reliability...... 181 Overload control...... 181 Denial of Service mitigation...... 184 Layer 2 Geo-redundant network architecture...... 186 Chapter 10: Performance monitoring...... 189 Subscriber and service usage profiling...... 189 Performance analysis...... 192 SIP_Delay_Report...... 195 SIP Presence report...... 196 SIP Inbound and Outbound Response reports...... 198 SIP_Transaction_Report...... 200 Calculating SESM capacity utilization using OMs...... 202
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 7 OM transaction to SIP weighted transaction mappings...... 202 Authentication cost...... 204 Performing the calculations...... 205 Step 1: Calculating authenticated and untenanted requests...... 206 Step 2: Calculating mixed-call cost...... 206 Step 3: Calculating total SIP weighted transactions...... 206 Step 4: Calculating SESM server utilization...... 207 Understanding bursty traffic...... 208 Other performance impacting events...... 210 Appendix A: SIP response messages...... 211 Provisional 1xx...... 211 100 Trying...... 211 180 Ringing...... 212 181 Call Is Being Forwarded...... 212 182 Queued...... 212 183 Session Progress...... 212 Success 2xx...... 212 200 OK...... 212 202 Accepted...... 213 Redirection 3xx...... 213 300 Multiple Choices...... 213 301 Moved Permanently...... 213 302 Moved Temporarily...... 214 305 Use Proxy...... 214 380 Alternative Service...... 214 Request Failure 4xx...... 214 400 Bad Request...... 215 401 Unauthorized...... 215 402 Payment Required...... 216 403 Forbidden...... 216 404 Not Found...... 216 405 Method Not Allowed...... 216 406 Not Acceptable...... 216 407 Proxy Authentication Required...... 216 408 Request Timeout...... 217 410 Gone...... 217 413 Request Entity Too Large...... 217 414 Request URI Too Long...... 217 415 Unsupported Media Type...... 217 416 Unsupported URI Scheme...... 217 420 Bad Extension...... 218 421 Extension Required...... 218 422 Session Interval Too Small...... 218 423 Interval Too Brief...... 218 480 Temporarily Unavailable...... 218 481 Call/Transaction Does Not Exist...... 219 482 Loop Detected...... 219
8 Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 483 Too Many Hops...... 219 484 Address Incomplete...... 219 485 Ambiguous...... 219 486 Busy Here...... 220 487 Request Terminated...... 220 488 Not Acceptable Here...... 220 491 Request Pending...... 220 493 Undecipherable...... 220 Server Failure 5xx...... 221 500 Server Internal Error...... 221 501 Not Implemented...... 221 502 Bad Gateway...... 221 503 Service Unavailable...... 222 504 Server Time-out...... 222 505 Version Not Supported...... 222 513 Message Too Large...... 222 Global Failures 6xx...... 222 600 Busy Everywhere...... 223 603 Decline...... 223 604 Does Not Exist Anywhere...... 223 606 Not Acceptable...... 223 Appendix B: Deployment checklist...... 225 Checklists...... 225 Appendix C: IPv6 overview...... 235 IPv4 versus IPv6...... 235 ICMPv6...... 237 IPv6 addressing overview...... 240 Multicast...... 241 Address format...... 242 Address prefix and subnet...... 243 Stateless and stateful autoconfiguration...... 243 Address resolution and caching...... 247 IPv6 address management...... 248 Multiple IP addresses per interface...... 249 IPv6 routing...... 250 Upper layer protocols...... 250 DNS...... 251 DHCP...... 251 FTP...... 252 SDP...... 252 IPv6 migration...... 252 Appendix D: Acronyms...... 255
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 9 10 Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 Chapter 1: New in this release
This section details what’s new in Avaya Aura® Application Server 5300 Planning and Engineering, NN42040-200 for Avaya Aura® Application Server 5300 Release 2.0.
Features
For information about Application Server 5300 features, see Avaya Aura® Application Server 5300 Release Delta, NN42040-201.
Other changes Revision History
March 2012 Draft 02.06. This document is issued to support Avaya Aura® Application Server 5300 Release 2.0. Inserted section on Voice mail server capacity on page 100 March 2012 Draft 02.05. This document is issued to support Avaya Aura® Application Server 5300 Release 2.0. Updated the section Real-Time Monitors (RTMI) Switch Expert on page 26. February 2012 Draft 02.04. This document is issued to support Avaya Aura® Application Server 5300 Release 2.0. Changes were made to technical content. The following sections were updated to include Application Server 5300 SS SESM capacities: • AS 5300 Session Manager on page 17 • Medium configuration on page 34 • Large configuration on page 36
July 2010 Standard 02.03. This document is issued to support Avaya Aura® Application Server 5300 Release 2.0. Editorial changes were made. May 2010 Standard 02.02. This document is issued to support Avaya Aura® Application Server 5300 Release 2.0. Editorial changes were made. April 2010 Standard 02.01. This document is issued to support Avaya Aura® Application Server 5300 Release 2.0.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 11 New in this release
July 2009 Standard 01.02. This document is issued to support Nortel Application Server 5300 Release 1.0. Changes were made to technical content. June 2009 Standard 01.01. This document is issued to support Nortel Application Server 5300 Release 1.0.
12 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Chapter 2: Introduction
Avaya Aura® Application Server 5300 Planning and Engineering, NN42040-200 provides recommendations and guidelines for Application Server 5300 multimedia service network design and deployment. The document provides the system planners the information needed for planning and scaling Application Server 5300 services deployment in IP networks. Navigation
• Application Server 5300 overview on page 15 • Application Server 5300 hardware and configurations on page 29 • Deployment planning on page 49 • Application Server 5300 deployment planning on page 53 • System capacity planning on page 81 • Application Server 5300 IP service network planning on page 105 • Reliability and robustness on page 171 • Performance monitoring on page 189 • SIP response messages on page 211 • Deployment checklist on page 225 • IPv6 overview on page 235 • Acronyms on page 255
Audience for this document
This document is written to assist Avaya customers, engineers, and other technical professionals in deploying the Application Server 5300 in IP networks.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 13 Introduction
14 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Chapter 3: Application Server 5300 overview
The Application Server 5300 system is a Session Initiation Protocol (SIP)-based service platform designed for providing next generation location-independent secure communication services over standard Internet Protocol (IP) networks. Application Server 5300 delivers a rich set of VoIP telephony features and multimedia services for advanced Unified Communications solutions deployments. It allows users to define their own communication preferences and provides users with a fully integrated voice, video and multimedia communication experience. Furthermore, services and communications can continue without interruption no matter where the users are located. The Application Server 5300 consists of several network functional components such as the SIP Core, Primary Rate Interface (PRI) Gateway, Clients, Media Application Server (MAS), IP Deskphone telephones, IP Clients (soft clients), and Integrated Analog Devices (IAD). It can be deployed as a standalone turnkey system or be integrated into the Public Switched Telephone Network/Private Branch Exchange (PSTN/PBX) network, interoperating with the existing Time Division Multiplex (TDM) clients before migrating them to next generation SIP network. The Application Server 5300 solution is a collection of network elements (see Figure 1: Application Server 5300 network elements on page 16) that can be grouped into the following categories: • SIP Core: AS 5300 Session Manager, AS 5300 System Manager and Fault Performance Manager (FPM), Accounting Manager, Database Manager, Provisioning Manager, System Management Console, Provisioning Client, IP Client Manager (optional for non-Department of Defence deployments) • Media Server: Avaya Media Application Server • PRI Gateway: AudioCodes Mediant Gateway 1000 (MG1000) and 3000 (MG3000) • AudioCodes EMS: Mediant 1000, Mediant 3000, and MP IADs console • Access clients: Avaya 1120E IP Deskphone, Avaya 1140E IP Deskphone, Avaya Aura® Application Server 5300 UC Client, Avaya Aura® Application Server 5300 Office Client, and AudioCodes MP-112, MP-124, and MP-500 IADs Depending on the network requirements, these Application Server 5300 network elements can be configured as a standalone system for Federal Civilian (Non DoD) deployments. The Non DoD systems can be configured to interwork with the external TDM users via PRI and SIP trunking connections. Application Server 5300 can also be configured for Federal DoD deployments as a PBX1 system, or a LSC only system, a combined LSC+SS system or an SS only system. The DoD systems can be configured to interwork with the external TDM users using PRI gateways. For Federal DoD deployments, Application Server 5300 provides product solutions consistent with the Federal Real Time Services (RTS) architecture. The Federal RTS architecture specifies a secure, robust, and predictable communication framework for both the normal and degraded network conditions. In
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 15 Application Server 5300 overview
addition to complying with UCR 2008, STIGs, GR-815 and FIPS 140-2 cryptographic compliance requirements supported in previous releases, Application Server 5300 provides: • Platform upgrade using IBM x3550 M3 as the based reference server • Evolution of AS5300 PBX1 to a functional Local Session Controller (LSC) with compliance to the Department of Defense (DoD) Unified Capabilities Requirements (UCR) 2008 Specification. • Softswitch (SS) capabilities for a functional Multi-Functional Softswtich (MFSS) as per the Department of Defense (DoD) Unified Capabilities Requirements (UCR) 2008 Specification. • Multiple SS and LSC SESM support for DoD capacity scaling • IPv6 Dual-Stack support for required deployments • Layer 2 Geo Redundancy protects the seamless and continuous operations in the event of a natural disaster or other emergencies • Optimized routing for costs reduction • SIP trunking to SIP enabled TDM networks
Figure 1: Application Server 5300 network elements Although Application Server 5300 can be deployed in both DoD and Non DoD environments, not all Application Server 5300 features and services are applicable for both. In this document, the DoD specific features, services, and devices will be marked as “DoD Only” and the Non DoD specific features, services, and devices will be marked as “Non DoD”. Other non-marked information will be applicable to both.
SIP Core components
The SIP Core components provide the SIP call processing engine and service coordination for SIP services within the Application Server 5300 infrastructure. It also manages processes
16 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] SIP Core components
within the SIP Core, provisioning of system and subscriber information, translation, and accounting services. • AS 5300 Session Manager on page 17 • System Management Console on page 19 • AS 5300 System Manager and Fault Performance Manager on page 20 • Database Manager on page 20 • Accounting Manager on page 20 • Provisioning Manager and Personal Agent Manager on page 21 • Provisioning Client on page 21
AS 5300 Session Manager
The AS 5300 Session Manager (SESM) is the Application Server 5300 call processing engine. It processes SIP signaling messages, handles SIP sessions, and provides the core services that facilitate communication between SIP clients. The AS 5300 Session Manager provides services based on the provisioned subscriber and domain data and generates performance statistics, accounting records, logs, and alarms. There can be multiple AS 5300 Session Manager pairs in Application Server 5300 depending on the service requirements. The Application Server 5300 supports two types of SESM: the regular Non DoD SESM and the DoD enhanced SESM. The regular Non DoD SESM is developed for the environment such as Federal Civilian and commercial enterprises that do not require the DoD specific features. The Non DoD SESM offers feature rich unified communication services to the local and converged desktop subscribers and limited unified communication services to TDM users via PRI and SIP trunking. The DoD SESM offers three variations: the PBX1 SESM, the LSC SESM, and the SS SESM. The PBX1 SESM, available since Application Server 5300 Release 1.0, provides interworking with DSN (Defense Switched Network) using PRI gateways. Based on the work done for the PBX1 SESM, the Application Server 5300 LSC SESM provides additional AS-SIP Trunking to DoD RTS (Real Time Services) network. The LSC SESM and SS SESM implements the DoD ARTS architecture based on a two-tier hierarchical LSC and SS routing model (see Figure 2: Application Server 5300 LSC and MFSS two tier hierarchical routing solution on page 19). The LSC SESM performs local call control within the campus or enclave and depends on the SS SESM to perform intercampus or enclave translations and routing (that is, routing between different campuses or enclaves) across the Defense Information System Network (DISN) Core. The functions provided by an Application Server 5300 LSC SESM are: • Session Control and Signaling (SCS)
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 17 Application Server 5300 overview
- Intraenclave signaling, session management, routing of all hosted End Instruments (EI) - Maintains “Service Profiles” for hosted subscribers - Routing and translations to gateways and SS SESMs - Call screening • Subscriber Authentication and Registration • Subscriber Presence Management • Gateway Controller (GWC) functions • Policy Based Network Management - Open Loop Assured Service Admission Control (ASAC) function that allows only a “budgeted” number of sessions (by media type) to concurrently utilize Access Network facilities to or from a particular campus or enclave - End instrument session origination/destination control • Information Assurance (IA) functions • User features and services The Application Server 5300 LSC Greenfield solution is based on a standalone Application Server 5300 LSC system to support all SIP endpoints within the enclave. All inter-enclave SIP communications are routed through an SS SESM that the Application Server 5300 LSC system is subtended to. All Time Division Multiplex (TDM) trunking is still routed through the PRI gateways within the enclave. An existing Application Server 5300 LSC system can easily be enhanced to an Application Server 5300 MFSS SS system by simply adding one of more pair of active/standby SS SESMs to the system. Implementing the ARTS MFSS architecture, the Avaya MFSS+LSC solution consists of three functional components: Communication Server 2100 (CS 2100) Multifunction Switch (MFS) component, Application Server 5300 Soft Switch (SS) component, and the Application Server 5300 LSC component. The Application Server 5300 SS SESM implements the MFSS Soft Switch (SS) functions and serves as a SIP intermediary in all inbound and outbound signaling messages to or from its hosted LSCs. The functions provided by an Application Server 5300 MFSS SS Session Manager are: • Hierarchical intercampus or enclave routing functions • Media gateway controller functions • Tracks state of Real Time System (RTS) Wide Area Network (WAN) sessions • Tracks precedence of WAN level sessions • Polices ASAC compliance by hosted LSCs • Performs session blocking or preemption as needed The Application Server 5300 SS SESM polices the ASAC compliance of each of its hosted LSC SESMs. To ensure the Quality of Service (QoS) and availability of Access Network bandwidth for mission critical sessions, it regulates Access Network utilization using an
18 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] SIP Core components
engineered, threshold-based Call Admission Control (CAC) mechanism based on the associated media type (voice only, video only, or voice and video) and the precedence of the associate request (ROUTINE, PRIORITY, IMMEDIATE, FLASH, or FLASH OVERRIDE).
Figure 2: Application Server 5300 LSC and MFSS two tier hierarchical routing solution
Application Server 5300 also supports WAN SS and WAN SS+LSC solutions, where the CS 2100 MFS is not provided from the DSN side as with the MFSS solution. Application Server 5300 WAN SS+LSC is functionally identical to Application Server 5300 MFSS with embedded LSC, except any applicable DSN switch may be connected via PRI. Depending on the configuration (medium or large) and the type (MFSS, WAN SS, WAN SS, or WAN SS+LSC), the maximum number of Application Server SS SESM changes. The Application Server LSC SESM used in such configurations are local LSC components and considered as a single subtended LSC on the SS. However, there can be more subtended LSCs that are not local to the SS system. These local Application Server 5300 SESM support rated subscribers on the Application Server 5300 system for LSC, which are also handled in the same fashion as subtended LSC subscribers from other non-local LSCs (that could be other Application Server 5300 LSCs deployed in the network or any other vendor LSC).
System Management Console
The System Management Console, a JAVA application that operates on a Windows-based PC, provides the interface to key AS 5300 System Manager Management functions. The System Management Console is used to deploy software loads, to configure AS 5300 components, and display maintenance (OAM) information from various components.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 19 Application Server 5300 overview
AS 5300 System Manager and Fault Performance Manager
The AS 5300 System Manager (SM) is responsible for the configuration, monitoring and maintenance of all Application Server 5300 Network Elements (NE). There is only one SM in an Application Server 5300 system and is the first NE brought into service. It maintains connectivity to all the running NEs in the network in order to enable management activities. It handles all client-initiated configuration changes (additions, updates, and deletes), which result in changes to the database where all configuration data is stored. Maintenance transactions are also handled by the AS 5300 System Manager. In these transactions, the AS 5300 System Manager routes the request to the appropriate NEs for processing and then routes the response back to the client that initiated it. Finally, the AS 5300 System Manager maintains an alarm summary of all the network elements in the network. This summary, accessible through the System Management Console, contains the counts of critical, major, and minor alarms by alarm family. The Fault Performance Manager (FPM), deployed as a part of the AS 5300 System Manager, is responsible for formatting, storing, and optionally forwarding fault, performance data, specifically Operational Measurements (OM), and logs from associated Network Elements. Alarms, a subset of faults, are formatted into Simple Network Management Protocol (SNMP) traps (using the Avaya Reliable Management Information Base [MIB]) and forwarded to configured SNMP agents. Raw OM streams are formatted into Comma Separated Value (CSV) format, stored on disk, and forwarded to all configured Operation Support System (OSS) clients. Raw log streams are formatted into Switching Control Center 2 (SCC2), Standard, or Multimedia Communications Portfolio (MCP) format, then stored on disk and forwarded to all configured OSS clients.
Database Manager
The Database Manager includes a database and interfacing software for storing subscriber, provisioning, and configuration data associated with the AS 5300 system. Network-based call logs are also stored in the database. The primary function of the Database Manager is to provide data storage and retrieval capability to support subscriber services. AS 5300 System Manager, Provisioning Manager, and Personal Agent Manager are responsible for the majority of the data written to the database. All network elements read configuration and optionally provisioning data out of the database during the boot process.
Accounting Manager
The Accounting Manager is responsible for formatting, storing, and forwarding billing data from its associated Session Managers. It provides storage and enables flexible and extensible formatting of accounting files into the Internet Protocol Detail Record (IPDR) format. It enables
20 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] SIP Core components
the transport of accounting information from the AS 5300 system to a back-end billing system.
IP Client Manager (Non DoD)
The IP Client Manager (IPCM) performs SIP-Unistim (Unified Network IP Stimulus) protocol conversion for 1120E IP Deskphone and 1140E IP Deskphone. The IP Client Manager sends all outgoing SIP messages such as INVITE and BYE to the Session Manager. The Session Manager forwards the information to the destination. The IP Client Manager provides all services required by the IP Deskphones, including instructing the IP Deskphones to play a tone and initiating requests. The IP Client Manager also provides all the call features for the IP Deskphones such as transfer, second call indication, call hold, and mute. The soft keys on the phone are controlled by the IP Client Manager. For the Federal DoD systems, after upgrading an existing PBX1 to an LSC, the 1120E IP Deskphone and 1140E IP Deskphone phones are migrated to use SIP. The Unistim-based IPCMs can be removed after the migration is completed. For the Non DoD systems, the 1120E IP Deskphone and 1140E IP Deskphone phones migration is optional. IPCMs are still required for supporting Unistim-based phones.
Provisioning Manager and Personal Agent Manager
The Provisioning Manager provides the administrators with a secure Web interface to the Database Manager for provisioning system, domains, devices, gateway, translations and routing, user accounts, and services related information. It provides a logical view of service data that hides complex internal relational database structures. Using logical views simplifies the provisioning tasks for the administrators. The Personal Agent Manager, deployed as a part of the Provisioning Manager, provides a secure Web interface to the database to access or update subscriber specific service settings (for example, call routing and screening, user pictures, presence, directory, personal, mailbox, conference information). In addition, the Personal Agent Manager provides Avaya Aura AS 5300 UC Client with the ability to download Calling Picture IDs, address book, and automatic software updates (ASU).
Provisioning Client
The Provisioning Client provides a user-friendly interface to the Provisioning Manager for administrators to perform daily administrative tasks. It uses a Web-based interface for service providers to create and set security, access, and permissions for the components and roles of the AS 5300 user framework. Data entered at the provisioning client is propagated to all appropriate components in the system (for example, the Session Manager) as necessary. The
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 21 Application Server 5300 overview
Provisioning Manager is also responsible for real time query processing from components in the system.
Media Server
The Media Application Server (MAS) provides the following services: • Ad hoc and Meet Me conferencing services for two or more parties that use the Application Server 5300 clients such as the Avaya Aura AS 5300 UC Client, 1120E IP Deskphone and 1140E IP Deskphone. The MAS provides functions that manage creation, modification, addition, and removal of parties for conference calls. MAS Ad Hoc and Meet Me conferencing support both audio and video conferencing, as well as Multilevel Precedence and Preemption (MLPP). • Music on Hold service allows the subscriber who receives a call to play music for a caller who is put on hold. • Announcement/Tone service allows the administrators to provide various notifications to callers, such as call status, network situation, or greetings. • Unified Communications service provides subscribers integrated access to their voice mail messages from a preferred device. • IM Chat (non DoD only) service allows a user to send instant messages to multiple users in one chat room invite other people to join the chat room, browse online chat rooms or select a specific chat room to join.
Gateways
Application Server 5300 supports the following gateways: • PRI Gateway on page 22 • Integrated Access Device on page 23
PRI Gateway
The AudioCodes Mediant Gateway 1000 (MG1000) and Mediant Gateway 3000 (MG3000) provide the signaling interface between the SIP-based Application Server 5300 and the systems that use ISDN Primary Rate Interface (PRI) protocol. It also converts between packet- based and circuit-based voice streams. The MG1000 supports multiples of 1, 2, or 4 T1 spans for connecting the PSTN/PBX to the IP network and is best suited for small-to-medium sized (SME) enterprises and branch offices. The MG3000 is comprised of a Carrier Grade chassis
22 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] AudioCodes EMS
and supports 8, 12, 16, 21, and 42 T1 and OC3 configurations. The actual number of T1s and OC3s needed will be determined based on the traffic. The Application Server 5300 MFSS solution uses the MG3000 T1/OC3 configuration and the Application Server 5300 PBX1 and LSC solutions use the MG1000 or MG3000 T1 only configuration.
Integrated Access Device
The AudioCodes Media Pack (MP) series MP-112, MP-124, and MP-500 devices are third- party Integrated Access Devices (IAD) for Application Server 5300 solution. The AudioCodes IADs are analog VoIP gateways for connecting legacy phones and faxes to Application Server 5300. They provide protocol conversion between SIP (Session Initiation Protocol) and the phone or fax analog signal and converts between packet-based and circuit-based voice streams. The IAD interfaces with the SIP Core servers, PRI gateways, and the MAS servers using SIP Transport Layer Security (TLS) and Secure Real Time Protocol (SRTP) for signaling and bearer streams. The MP112 device can connect up to a maximum of two analog phones, while the MP124 device can connect up to a maximum of 24 analog phones. MP500 IAD, an IPv6 capable device, has 4 FXS and 4 FXO ports. Application Server 5300 deployments use only 4 FXS port configuration. Each phone represents a unique subscriber to the Application Server 5300. The MP-500 is IPv6 capable and should be the default for use in Federal deployments.
AudioCodes EMS
The Element Management Server (EMS) provides the Operation, Administration, Management, and Provisioning (OAMP) support for the PRI Gateway and the IADs. The OAMP monitors system information such as faults, configuration, and performance. The EMS server interacts with the EMS client, installed on the management workstation, using SSL and with the PRI Gateway and IADs using Internet Protocol Security (IPSec). For security reasons, there will be one EMS per enclave. The AudioCodes EMS uses a Sun Netra T2000 server.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 23 Application Server 5300 overview
Access clients
Application Server 5300 supports the following access clients. • IP Phones on page 24 • Avaya Aura AS 5300 UC Client on page 24 • Avaya Aura AS 5300 Personal Agent on page 25
IP Phones
Application Server 5300 supports the UNIStim-based Avaya 1120E IP Deskphone, Avaya 1140E IP Deskphone, and Avaya IP Phone 2004, and SIP-based 1120E IP Deskphone and 1140E IP Deskphone. The 1140E IP Deskphone has a larger display than the 1120E IP Deskphone. The 1100 Series IP Deskphone supports DHCP. When enabled, the telephone receives the IP address, gateway address and mask, and optionally the voice VLAN ID from a DHCP server. An Avaya-SIP-Phone-aware DHCP server is needed for Full DHCP mode. If disabled, default values are taken from the configuration files. IP phones must obtain licensing tokens before communicating with the AS 5300 Session Managers. Although Application Server 5300 supports both UNIStim and SIP based clients, the Federal DoD deployment supports only SIP based clients. The existing UNIStim-based 1120E IP Deskphones and 1140E IP Deskphones are upgraded to use SIP protocols for communication with AS 5300 Session Managers.
Avaya Aura AS 5300 UC Client
The Avaya Aura AS 5300 UC Client is a Microsoft Windows-based application built with multimedia technologies. It is an intelligent SIP endpoint that is installed on the personal computer (PC). The Avaya Aura AS 5300 UC Client provides advanced IP telephony features, many of which are unavailable in a traditional Public Switched Telephone Network (PSTN). With the use of the Avaya Aura AS 5300 UC Client, subscribers can access the services provided by the Application Server 5300 system over an IP network using a PC. Avaya Aura® Application Server 5300 UC Client Set allows an Avaya Aura AS 5300 UC Client to be configured to control a SIP-based 1120E IP Deskphone or 1140E IP Deskphone. In this mode of operation, the controlled IP phone provides the audio capabilities while the Avaya Aura AS 5300 UC Client provides the video, collaboration and instant messaging functions. Avaya Aura® Application Server 5300 Web Client is the light-weight version of the Avaya Aura AS 5300 UC Client. The Avaya Aura AS 5300 Web Client is a Web-based client that uses a Web browser on a Microsoft Windows PC platform. The Web-based client allows people to access various Application Server 5300 features from locations where their usual workstations
24 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Third-party network appliances
are not readily accessible. It is easy to deploy new services as they become available. Note that Avaya Aura AS 5300 Web Client does not support the control of an IP Phone like the Avaya Aura AS 5300 UC Client does. Application Server 5300 Converged Desktop Service and Communication Server 1000 (CS 1000) blends TDM voice and Application Server 5300 multimedia services for the Converged Desktop subscribers. With the Converged Desktop Service, Avaya Aura AS 5300 Converged Desktop Client, based on Avaya Aura AS 5300 UC Client, allows users to use their PCs for the multimedia (for example, Instant Messaging, Auto Presence, Video, Inbound and Outbound call log, and Click to Call) communication, while using their existing telephony system for voice conversation. Application Server 5300 supports the communications between two Converged Desktop users, between a TDM user and a Converged Desktop user, and between a SIP user and a Converged Desktop user. When a TDM switch receives a call for a Converged Desktop user, the TDM switching system sends a call indication (SIP INVITE) to the Application Server 5300. Application Server 5300 processes the call information and pops up a window on the user’s PC. The user is then able to initiate a separate multimedia session to the other multimedia capable party. For full Converged Desktop functionality, both the originator and terminator must reside on the same Application Server 5300 system. They can, however, reside on different TDM systems.
Avaya Aura AS 5300 Personal Agent
The Avaya Aura® Application Server 5300 Personal Agent is a Web-based tool that allows end- users to configure personal call screening and routing preferences, store a picture, sign up for multimedia services, manage passwords, and check network call logs. The Web interface allows users to manage their preferences from any location with no software installation required.
Third-party network appliances
In addition to the network elements described above, Application Server 5300 has also integrated with a third-party Edge Boundary Controller (EBC) and a third-party Switch Expert into the solution to enhance the QoS and management functions. Note that there can only be one EBC and one Switch Controller per system. • Edge Boundary Controller on page 26 • Real-Time Monitors (RTMI) Switch Expert on page 26
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 25 Application Server 5300 overview
Edge Boundary Controller
The RTS architecture defines an network appliance called the Edge Boundary Controller (EBC) located at the edge of a campus or enclave network. Figure 2: Application Server 5300 LSC and MFSS two tier hierarchical routing solution on page 19 illustrates how EBCs are logically paired with their local MFSS and LSC SEMSs within the enclaves. The EBC used in Application Server 5300 is a third-party component paired with an SS SESM or an LSC SESM to manage its fronting access link. The EBC performs the Customer Edge Router (CE-R) and the Border Controller (BC) functions. The CE-R executes the Diffserv border router functions for the associated campus or enclave to ensure the traffic is in compliance with Service Level Agreements (SLA) for the border. The BC functions as a SIP intermediary providing signaling and media relay functions for the media sessions traversing through the campus/enclave network boundary. Application Server 5300 implements a threshold-based Call Admission Control (CAC) mechanism to ensure that the access link resources between the Customer Provider Edge (CPE) router and the Provider Edge router (PE-R) have sufficient capacity to support Quality of Service (QoS) and bandwidth required for the mission critical sessions. The system administrator must provision EBCs as a trusted node so that it can be exempted from the Application Server 5300 Denial of Service (DoS) filtering.
Real-Time Monitors (RTMI) Switch Expert
Switch Expert (SE) is a management application that collects, compiles and stores Operational Measurements (OM), System Events (Logs), and Call Detail Recording (CDR) and provides System Alarm Notifications. SE interworks with Application Server 5300 to: • Pull Logs, Alarms, billing information and traffic measurements from Application Server 5300 products. • Launch management consoles (System Management Console, Provisioning Client, MAS Element Manager, EMS management console). • Monitor the topology and status of every network element in the Application Server 5300. • Utilize management operations through Application Server 5300 OMI interface. • Utilize provisioning operations through Application Server 5300 OPI interface. The usage of SE component in different configurations are:
26 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Federal DoD Application Server 5300 Release 1.0 PBX1 migration path
• RTMI SE is mandatory for MFSS, if used as a part in CS 2100 related management • RTMI SE is optional but recommended for WAN SS as a US DoD RTS Core switch (with or without the LSC component) • RTMI SE is optional but recommended for LSC or E-LSC SE periodically checks the connectivity with Application Server 5300 network elements. When there is any communication errors, SE reestablishes the TCP connections and transfers any untransferred data from the previously disconnected network elements.
Federal DoD Application Server 5300 Release 1.0 PBX1 migration path
Application Server 5300 Release 2.0 Federal DoD deployment supports the standalone Application Server 5300 LSC solution as well as the combined Application Server 5300 LSC/ SS solution. To migrate an existing Application Server 5300 Release 1.0 PBX1 system to a standalone Application Server 5300 LSC system (Figure 3: Application Server 5300 Release 1.0 migration path on page 27), the administrators must take the following steps: • Upgrade Application Server 5300 Release 1.0 PBX1 to Application Server 5300 Release 2.0 PBX1. The site may remain as a PBX1 also. • Migrate Unistim 1100 Series IP Deskphone clients to SIP-based 1100 Series IP Deskphone clients and decommission IP Client Manager. This step is required for PBX1 and LSC in Application Server 5300 Release 2.0. • Migrate Application Server 5300 Release 2.0 PBX1 to LSC configuration which provides SIP interworking with other SIP systems through the ARTS DISN QoS IP Core network • Migrate Audiocodes MP IADs to IPv6 capable IADs when applicable
Figure 3: Application Server 5300 Release 1.0 migration path Finally, the administrators can enhance an Application Server 5300 LSC system to an Application Server 5300 WAN SS+LSC system by adding one or more pairs of SS SESMs
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 27 Application Server 5300 overview
and, if needed, to an Application Server 5300 MFS SS+LSC system by adding MG3000 OC3 interfaces to a CS2100 system (Figure 4: Enhancing Application Server 5300 LSC to Application Server 5300 MFS SS+LSC on page 28).
Figure 4: Enhancing Application Server 5300 LSC to Application Server 5300 MFS SS+LSC
28 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Chapter 4: Application Server 5300 hardware and configurations
This chapter describes the Application Server 5300 reference hardware platform, supported system, Voice Local Area Network (VLAN) configurations, and server IP addressing information. Navigation
• Hardware on page 29 • System configuration on page 32 • VLAN and MultiSubnet on page 41 • IP addressing on page 45
Hardware
Application Server 5300 continues to support the existing installations based on the IBM 3550 servers. Application Server 5300 Release 2.0 introduces a new IBM x3550 M3 reference server platform (Figure 5: IBM x3550 M3 server on page 30). The term "platform" refers to the server's operating system (Red Hat Enterprise Linux, RHEL, version 5.4) and Avaya-provided scripting, binaries, customizations and configuration, used to produce an environment for higher-layer Application Server 5300 application software. The x3550 M3 will be used for deploying new Application Server 5300 systems or providing scaling for x3550-based systems after they are upgraded to Application Server 5300 Release 2.0.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 29 Application Server 5300 hardware and configurations
Figure 5: IBM x3550 M3 server
The IBM x3550 M3 hardware characteristics are described in Table 1: IBM x3550 M3 reference hardware characteristics on page 30. Table 1: IBM x3550 M3 reference hardware characteristics
Item Description Form Factor Height: 1U, rack mount Server Identification x3550 M3, Model 7944-AC1 CPU Single (low-end) or dual (high-end) Quad-Core Intel Xeon 5540 4C (2.53 GHz 8MB L3 Cache 1066 MHz 80w) Memory 8 GB (4 x 2GB) DDR3-1333MHz 2Rx8 LP RDIMM Disk 2 IBM 146 GB 15K 6Gbps SAS 2.5" SFF Slim-HS HDD (hot swap). RAID Controller Integrated ServeRAID-LSI BR10i SAS/SATA Controller (RAID-0/1/10) A/C Power Single (low-end) or dual (high-end) Hot-Swap/redundant 670W (~92%efficient) D/C Power Single (low-end) or dual (high-end) Hot-Swap/redundant 670W (~92%efficient) Integrated Management Second generation IBM server management technology; Module (IMM) oversees system health, operates LEDs, system event log, boot sequences, and remote management (Not supported by AS5300).
30 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Hardware
Item Description Remote Management Available via IMM—IPMI version 2.0 (IPMI shell, serial over LAN) and optional "remote presence"--remote Keyboard, Video, Mouse (KVM) and virtual remote media (CD-ROM). Not used for AS5300 Release 2.0. Optical Drive 1 CD-RW/DVD Combo (24X/24X/24X/8X, in dedicated 5.25" UltraBay) Cooling Hot swap, redundant fans (3 dual packs for total of 6) USB 2 front, 2 rear (mouse, keyboard interface) Video 1 front, 1 rear Networking 2 x 10/100/1000 Mbps Serial COM1, DB-9
Application Server 5300 uses a low-end x3550 M3 server for small to medium deployments and a high end x3550 M3 server for medium to large deployments. The server uses dual quad core (8 CPUs), and comes with two (redundant) power modules. Application Server 5300 core servers support RAID-1 (mirrored) disk redundancy mechanism, which places the requirement for two physical disk drives to be present. Although the x3550 M3 can host 6 physical disks, the Application Server 5300 reference server limits the number of physical disks to 2. The x3550 M3 server hardware RAID capability allows the Linux kernel only sees the one (logical) disk drive. The server has two Ethernet 10/100/1000 ports. These ports are configured to run in redundant mode where one of the ports is active and the other is standby. These ports are used for supporting Application Server 5300 OAMP functions and subscriber services. The COM1 serial port provides a serial console access using an industry standard DB-9 RS-232 serial cable. It is typically connected to either a terminal server such as the MRV Models LX-40XX or can be attached to a serial port on another computer using a null modem cable. If attached to another computer, such as a Windows-based computer, a program such as HyperTerminal can be used to establish a login session over the serial connection. The serial port has the following characteristics: • 7-bit characters with even, odd, none, or space parity, and 8-bit characters with no parity are supported • VT100Terminal emulation • 9600 or 19,200 baud rate To provide the physical KVM console, one can connect a physical monitor to the video port and a USB keyboard to one of the USB ports or, alternatively, connect a KVM switch (preferred) to the server. The server has two redundant A/C power modules which must be attached to redundant power sources.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 31 Application Server 5300 hardware and configurations
The x3550 M3 comes with an Integrated Management Module (IMM) which implements many server management functions on a single chip. However, Application Server 5300 does not support remote access and control using IMM due to security requirements. • AS5 300 2.0 product installation is performed via a physical CD-ROM where physical access to the machine is required. Once installed, access to the machine will be available as follows: • Through secure shell (ssh) over the server's main network interfaces. • Via the COM1 DB-9 serial console connector attached to either a secure terminal server or a locally attached computer with communications software such as HyperTerminal. • Via a locally attached keyboard and monitor, or KVM switch.
System configuration
Application Server 5300 supports both DoD and Non DoD environments. Application Server 5300 performs regular enterprise Softswitch functions when deployed in a Non DoD environment such as the Federal Civilian or commercial enterprises. It can also be deployed in the Federal DoD environment where the AS 5300 Session Manager functions as a Multifunction Softswitch (MFSS) or as a Local Session Controller (LSC) or as a PBX1 switch. Application Server 5300 supports three scalable configurations – small, medium, and large configurations. The Application Server 5300 small configuration is designed to provide minimum footprint while maintaining quality and capacity for the smaller sites which have fewer subscribers. As the network continues to grow, the medium and large configurations can scale the system configurations with the required redundancy, capacity, and reliability. All configuration models contain the following functional components: • AS 5300 Session Manager (SESM) • Application Server 5300 Database Manager (DB) • Application Server 5300 Accounting Manager (AM) • Application Server 5300 System/Fault Performance Manager (SM/FPM) • Application Server 5300 Provisioning/Personal Agent Manager (PROV/PA) • Application Server 5300 IP Client Manager (IPCM, optional, Non-DoD Only) • Audiocodes Media Gateway 1000 and 3000 PRI Gateway (optional) • Media Application Server (Ad-hoc and Ann/Tone are required, others optional)
32 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System configuration
See the following sections for configuration descriptions: • Small configuration on page 33 • Medium configuration on page 34 • Large configuration on page 36
Small configuration
The small configuration, suitable for product demo or smaller DoD and Non DoD sites, has a few system configuration variants: simplex (without server redundancy), simplex dual quad core (8 CPU), duplex (with server redundancy), and duplex dual quad core. The small simplex configuration (Figure 6: Application Server 5300 Small simplex and duplex configurations on page 33) is made of one SIP core servers for the signaling and OAMP functions and one optional servers for the MAS services. The small duplex configuration is made of two SIP core servers for the signaling and OAMP functions and two optional servers for the MAS services. The MAS servers are scaled independently based on the services requirements. Note that IPCM is not supported in new Application Server 5300 DoD systems. For the existing Release 1.0 systems, it is only supported for DoD deployments until IP Clients SIP migration is completed. The small (simplex/duplex) configuration can support up to 5,000 subscribers per system. The small configuration supports several SESM types that include regular Non DoD SESM, DoD PBX1 SESM, DoD LSC SESM. Note that the small configuration does not support DoD SS SESM type.
Figure 6: Application Server 5300 Small simplex and duplex configurations
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 33 Application Server 5300 hardware and configurations
Medium configuration
The medium configuration supports only duplex mode using dual quad core (DQC) servers. The medium configuration is suitable for medium to large DoD and Non DoD sites. The basic medium Non DoD configuration (Figure 7: Application Server 5300 Medium Non DoD configuration on page 34) starts with four SIP core servers for the signaling and OAMP functions and four optional servers for the MAS services. The basic medium Non DoD configuration supports up to 25,000 subscribers. The system can be scaled to support up to 75,000 subscribers by adding two additional pair of SESM servers. The MAS servers are scaled independently based on the services requirements. Additional FPM and PA can be added to meet increasing service demands.
Figure 7: Application Server 5300 Medium Non DoD configuration
The basic medium DoD PBX1 configuration (Figure 8: Application Server 5300 Medium DoD PBX1 configuration on page 35) starts with four SIP core servers for the signaling and OAMP functions and four optional servers for the MAS services. The basic medium DoD PBX1 configuration supports up to 25,000 subscribers. The system can add two additional pair of SESM servers to support up to 75,000 subscribers. The MAS servers are scaled independently based on the services requirements.
34 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System configuration
Figure 8: Application Server 5300 Medium DoD PBX1 configuration
The basic medium DoD LSC configuration (Figure 9: Application Server 5300 Medium DoD LSC configuration on page 35) has four (Master and Slave) LSC servers for the signaling, two OAMP servers, and four optional MAS servers. The basic medium DoD LSC configuration supports up to 25,000 subscribers. The Master LSC, does not support local subscribers, performs the inter-enclave routing functions for all Slave LSCs in the system. The system can scale to support up to 50,000 subscribers by adding additional pair of Slave LSC SESM servers. The MAS servers are scaled independently based on the services requirements.
Figure 9: Application Server 5300 Medium DoD LSC configuration
The basic medium DoD LSC+ SS configuration (Figure 10: Application Server 5300 Medium DoD LSC+SS configuration on page 36) has four LSC servers and two SS servers for the signaling, two OAMP servers, and four optional MAS servers. The basic medium DoD LSC +SS configuration supports up to 25,000 subscribers. The system can be scaled with one additional pair of LSC SESM servers to support up to 50,000 subscribers. The MAS servers are scaled independently based on the services requirements.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 35 Application Server 5300 hardware and configurations
Figure 10: Application Server 5300 Medium DoD LSC+SS configuration The SS Only configuration supports DoD WAN SS solution performing RTS core routing. The basic medium DoD SS Only configuration (Figure 11: Application Server 5300 Medium DoD SS Only configuration on page 36) starts with four SIP core servers for the signaling and OAMP functions. The basic medium DoD SS configuration does support subscribers and MAS services. The system can be scaled by adding one additional pair of SS SESM servers to support more inter-site traffic.
Figure 11: Application Server 5300 Medium DoD SS Only configuration For MFSS, WAN SS or WAN SS+LSC and WAN SS, only Medium and Large configurations are supported, and the Soft-switch (SS) component must be deployed on a server with no other components resident in it. A single Application Server 5300 SS SESM can support up to 200 subtended LSCs with up to 300,000 subscribers spread among them. If required, additional Application Server 5300 SS SESM can be deployed. In a Medium Configuration, one Application Server 5300 SS SESM for MFSS or Application Server 5300 WAN SS+LSC is supported with two Application Server 5300 SS SESMs for WAN SS without an LSC. A pure WAN SS without an LSC can support 400 subtended LSCs with 600,000 total subscribers by using 2 Application Server 5300 SS SESM instances. For more information on capacity planning, see tables in section SIP Core server configuration summary on page 41.
Large configuration
The large configurations supports only duplex mode on DQC servers. The large configuration is suitable for very large sites. The basic large Non DoD configuration (Figure 12: Application
36 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System configuration
Server 5300 Large Non DoD configuration on page 37) can start with eight SIP core servers for the signaling and OAMP functions and four optional servers for the MAS services. The basic large configuration supports up to 25,000 subscribers and can be scaled to support up to 150,000 subscribers with additional five pair of SESM servers. When required, additional server pairs for FPM (Fault Performance Manager), AM (Accounting Manager), PA (Personal Agent Manager), and IPCM (IP Client Manager) can be added to support more subscribers and services. The MAS servers are scaled independently based on the services requirements. For the large configuration, it is recommended that all MAS servers be deployed on their own servers for ease of capacity scaling and management.
Figure 12: Application Server 5300 Large Non DoD configuration
The basic large DoD PBX1 configuration (Figure 13: Application Server 5300 Large DoD PBX1 configuration on page 38) can start with eight SIP core servers for the signaling and OAMP functions and four optional servers for the MAS services. The basic large DoD PBX1 configuration supports up to 25,000 subscribers and is scalable to 150,000 subscribers with additional five pairs of SESM servers. Additional server pairs for FPM (Fault Performance Manager), AM (Accounting Manager), and PA (Personal Agent Manager) can be added to support more subscribers and services when required. The MAS servers are scaled independently based on the services requirements. For the large configuration, it is recommended that all MAS servers be deployed on their own servers for both scaling and management simplicity.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 37 Application Server 5300 hardware and configurations
Figure 13: Application Server 5300 Large DoD PBX1 configuration
The basic large DoD LSC configuration (Figure 14: Large DoD LSC configuration on page 39) has four (2 Master and 2 Slave LSC) SIP signaling servers, six OAMP servers, and four optional servers for the MAS services. The basic large DoD LSC configuration supports up to 25,000 subscribers and is scalable to 125,000 subscribers with additional four pair of Slave LSC SESM servers. Additional server pairs for FPM (Fault Performance Manager), AM (Accounting Manager), and PA (Personal Agent Manager) can be added to support more subscribers and services when required. The MAS servers are scaled independently based on the services requirements. For the large configuration, it is recommended that MAS services are deployed on their own servers for ease of management and scaling.
38 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System configuration
Figure 14: Large DoD LSC configuration
The basic large DoD LSC+SS configuration (Figure 15: Large DoD LSC+SS configuration on page 40) has six (2 Master LSC, 2 Slave LSC, and 2 SS) SIP signaling servers, six OAMP servers, and four optional servers for the MAS services. The basic large DoD LSC+SS configuration supports up to 25,000 subscribers and is scalable to 125,000 subscribers with additional four pair of Slave LSC SESM servers. Additional server pairs for FPM (Fault Performance Manager), AM (Accounting Manager), PA (Personal Agent Manager), and SS SESM can be added to support more subscribers and services when required. The MAS servers are scaled independently based on the service requirements. For large configurations, it is recommended that MAS services are deployed on their own servers for ease of management and scaling.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 39 Application Server 5300 hardware and configurations
Figure 15: Large DoD LSC+SS configuration
The SS Only configuration supports DoD WAN SS solution performing RTS core routing. The basic large DoD SS Only configuration (Figure 16: Large DoD SS configuration on page 40) starts with four SIP core servers for the signaling and OAMP functions. The DoD DQC SS configuration does not support subscribers and MAS services. The system can be scaled with two additional pair of SS SESM servers to support more inter-site traffic.
Figure 16: Large DoD SS configuration
In a Large Configuration, two Application Server 5300 SS SESM for MFSS or Application Server 5300 WAN SS/LSC are supported. An MFSS and WAN SS with LSC can support 400 subtended LSCs with 600,000 total subscribers by using two Application Server 5300 SS SESM instances with three Application Server 5300 SS SESM for WAN SS (with no LSC). A pure WAN SS without an LSC can support 600 subtended LSCs with 900,000 total subscribers by using three Application Server 5300 SS SESM instances. For more information on capacity planning, see tables in section SIP Core server configuration summary on page 41.
40 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] VLAN and MultiSubnet
SIP Core server configuration summary
The following tables summarize the Application Server 5300 supported SIP core server configurations described in the previous sections. Table 2: Subscriber capacity
Entries: Subs per SESM / Small Small Medium Duplex Large Duplex Subs per System Simplex Duplex Server Server Server Server Non DoD 5K/5K 5K/5K 25K/75K 25K/150K DoD LSC 5K/5K 5K/5K 25K/50K 25K/125K DoD PBX1 5K/5K 5K/5K 25K/75K 25K/150K DoD MFSS/ LSC n/a n/a 25K/50K 25K/125K DoD WAN SS/LSC n/a n/a 25K/50K 25K/125K DoD WAN SS n/a n/a 0/0 0/0
Table 3: SESM active server count
Entries: (active) Max Small Simplex Small Duplex Medium Large Duplex (Non DoD, LSC) SESM / Server Server Duplex Server Server Max SS SESM Non DoD 1/0 1/0 3/0 6/0 DoD LSC 1/0 1/0 3/0 6/0 DoD PBX1 1/0 1/0 3/0 6/0 DoD MFSS/LSC n/a n/a 3/1 6/2 DoD WAN SS/LSC n/a n/a 3/1 6/2 DoD SS Only n/a n/a 0/2 0/3
VLAN and MultiSubnet
Application Server 5300 server platform supports the configuration of single or multiple “bonded” network interfaces. Each bonded interface consists of two physical Ethernet network interfaces operating in active/standby mode. The multiple bonded interfaces are supported on platforms with at least four physical Ethernet Network Interfaces. Application Server 5300 supports single and multiple subnets with or without VLAN tagging. The default configuration is single subnet without VLAN tagging. With the default configuration,
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 41 Application Server 5300 hardware and configurations
the server sends and receives frames without tagging a VLAN ID. The server attaches to only one subnet and uses only one server IP address for the bond0 interface. Application Server 5300 supports the configuration of multiple IPv4 addresses in one subnet. The following diagram shows the server Linux channel bonding kernel module is configured to bind the physical eth0 and eth1 interfaces into a single bond0 interface for active/standby operation. One server IP address is assigned to the bond0 interface. An additional Service IP address A is configured for the Application A. The Application B does not have its own Service IP configured and will use the Server IP address X. When the bonding driver detects the failure of the active interface, it switches to the standby interface transparently to the applications.
Figure 17: Single subnet without VLAN tagged configuration
The bonding driver re-programs the eth1 MAC address to be the same as the eth0 MAC address. During the interface failover, the driver sends a gratuitous ARP (GARP) message on the attached network to update the MAC-PORT mapping table of the attached network equipment so that frames can be routed correctly to the newly active physical link as shown in the following figure.
42 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] VLAN and MultiSubnet
Figure 18: Active connection failover
The steps to configure Server and, optionally, Service IP addresses on a bonded interface are listed below: • Configure active-standby bonded network interfaces on a server • Configure IPv4 subnets associated with the bond0 interface • Configure the server address and, optionally, the Service Addresses within the subnet for used by the (Network Element) application software The second supported Application Server 5300 option is the configuration of multisubnet without tagging configuration on a bonded interface. The following diagram shows a MultiSubnet without VLAN Tagged Configuration example. In this example, there are two subnets; X and Y. Each subnet is configured with its own Server and Service IP addresses. Note that although the multi-subnet configuration supports multiple traffic types through the bonded interface but the traffic is not tagged.
Figure 19: MultiSubnet without VLAN Tagged configuration
The third supported option is enabling VLAN tagging on bonded interface with single or multi- subnet configured on it. The following diagram shows a Multi-Subnet with VLAN Tagged Configuration example. In this example, there are two VLANs configured on the top of bond0 interface. Two subnets, X and Y, are configured on the top of these VLANs.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 43 Application Server 5300 hardware and configurations
Figure 20: MultiSubnet with VLAN Tagged configuration
In the VLAN tagged configuration example shown above, the 8021q VLAN module implements one logical interface per VLAN on top of the "bond0" interface with the following naming syntax:
Traffic Type Description Internal OAMP Intra-OAMP traffic between the system functional components (for example, SM to NE, SM Console to SM, SM/PROV to Local OSS [for example,. Switch Expert]) External OAMP Inter OAMP traffic between SM/PROV and an External OSS (for example, ADIMSS, SM Console to SM) Signaling SESM SIP and PA signaling
The steps to enable VLAN tagging on an interface are listed below: • Configure active-standby network interfaces on a server • Configure one or more VLAN network interfaces on top the active-standby network interfaces for enabling VLAN tagging
44 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP addressing
• Configure IPv4 subnets associated with these VLANs • Configure the server addresses and, optionally, the (floating) service addresses within these subnets for used by the (Network Element) application software
IP addressing
This section describes the following types of IP addressing: • IPv4 addressing on page 45 • IPv6 addressing on page 46
IPv4 addressing
The requirements for planning single subnet Application Server 5300 SIP core elements IP addresses are summarized in the following table, where ‘A’ stands for an active NE and ‘S’ represents a standby NE. The server addresses can be shared by all NEs co-located on the same server (for example, a small configuration SIP core server), but all services addresses must be unique for the specific network element type (for example, SESM, SM). They are not shared among different network elements. Table 5: IP addressing single subnet requirements
Network Elements Server Address OAM Service Signaling Service Address Address SESM (A) yes yes SESM (S) yes SM (A) yes yes SM (S) yes FPM (S) yes yes FPM (S) yes DB (A) yes DB (S) yes AM (A) yes yes AM (S) yes PROV yes PA yes
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 45 Application Server 5300 hardware and configurations
The IP addressing requirements for the MultiSubnet configuration are shown in the following table. Table 6: Multisubnet server IP addressing
Network Internal External Signaling Internal External Signaling Elements OAM OAM Server OAM OAM Service Server Server Address Service Service Address Address Address Address Address SESM (A) yes yes yes SESM (S) yes yes SM (A) yes yes yes yes SM (S) yes yes FPM (S) yes yes yes yes FPM (S) yes yes DB (A) yes DB (S) yes AM (A) yes yes yes yes AM (S) yes yes PROV yes yes yes PA yes yes
IPv6 addressing
Application Server 5300 provides IPv6 communications on the SIP and Media interfaces that communicate with end clients. The OAMP interfaces for all Application Server 5300 network elements remain IPv4 only. Currently, only AS 5300 Session Manager (SESM) supports IPv6 SIP Signaling. The MAS and PRI GW only support IPv6 for media. Signaling between SESMs and the MAS and PRI GW is over IPv4 transport, but the SIP SDP Media lines grouped using ANAT (Alternative Network Address Types) semantics provide alternative IPv4 and IPv6 network addresses types for negotiating a media stream address type. The preference for IPv6 or IPv4 media is controlled by either placing IPv6 or IPv4 first in SDP ANAT field. If an IPv4 media stream is preferred, the IPv4 should appear first in the SDP ANAT field. Table 7: Application Server 5300 IPv4 and IPv6 support
Signaling Media OAMP SESM IPv4, IPv6 IPv4 Only SM IPv4 Only
46 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP addressing
Signaling Media OAMP FPM IPv4 Only DB IPv4 Only AM IPv4 Only PROV IPv4 Only PA IPv4 Only PRI GW IPv4 Only IPv4, IPv6 IPv4 Only MAS IPv4 Only IPv4, IPv6 IPv4 Only 1120E IP Deskphone IPv4, IPv6 IPv4, IPv6 IPv4 Only 1140E IP Deskphone Audiocodes MP500 IPv4, IPv6 IPv4, IPv6 IPv4 Only AS 5300 UC Client IPv4 Only IPv4 Only IPv4 Only
Because some clients do not support IPv6 SDP ANAT extension, Application Server 5300 SESM first checks the SIP profile of the terminating client when the SDP contains ANAT header for IPv6. If the terminating client SIP profile does not support SDP ANAT, SESM assumes this client is incapable to process IPv6/SPD ANAT. The SDP ANAT header in SIP INVITE will be removed and only IPv4 media will be set in SDP. When 200 OK is received from IPv4 only client, SESM will add the SDP IPv6 ANAT header back to the SDP when sending it back to the originating client. If SDP ANAT support of the client SIP profile is set to true, but a 420 response received from the terminating client, SESM assumes that the terminating client does not support SDP ANAT for IPv6. Because MAS and Media Gateway does not resend INVITE upon failing to setup call with an IPv6 SDP ANAT capable client, SESM will resend INVITE that contains IPv4 only SDP. The default setting of SDP ANAT is false for all client SIP profile, which means the client does not support SDP ANAT. The administrator can modify the client SIP profile setting using AS 5300 System Manager Console GUI, if the client supports SDP ANAT. IPv6 configuration for Application Server 5300 server and SESM service address need to be performed after the system is fully installed. For each IPv6 server there needs to be an IPv6 server address configured and for each active SESM there needs to be an IPv6 service address configured. The server address allows debugging of the IPv6 network and is not used for signaling. The IPv6 service address is used for SIP signaling. IPv6 uses the same port numbers configured for IPv4 for IPv6 SIP transport. The configuration of these addresses is accomplished by running the ‘ipv6Config’ script as opposed to using AS 5300 System Manager Console GUI for IPv4 address configuration. Application Server 5300 controls the availability of IPv6 through a license key. IPv4/IPv6 Dual- Stack feature must be enabled using the license key for a SESM to bring up IPv6 service address for signaling. If the feature is not enabled, an IPv6 SESM Service Address is not
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 47 Application Server 5300 hardware and configurations
brought up regardless of configuration. The detail configuration procedure is described in a separate document.
48 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Chapter 5: Deployment planning
This chapter describes the Application Server 5300 logical hierarchy concept and its use in site resources planning. The Application Server 5300 logical hierarchy offers a structure view for the system deployment. The steps for planning phase of an Application Server 5300 system deployment in a large service network will also be described in the chapter. Navigation • Logical hierarchy on page 49 • Application Server 5300 deployment planning on page 53
Logical hierarchy
In a large IP network, there may be tens, hundreds, or even thousands of sites interconnected by private and public IP networks. For example, a large service provider may have hundreds of Point of Presence (PoP) connecting tens of thousands of customer sites worldwide to form intranets and extranets, and to connect them to the Internet. A large bank is another example, typically having several large regional offices (hubs) connecting tens of small branches in the region to its regional resources. Depending on the subscriber population distribution, service needs, and networks at these sites, the Application Server 5300 signaling and media resources that can be deployed differently for different customers. The IP networks are inherently flat and all the Application Server 5300 functional components can communicate with each other directly over the IP networks. However, for the purpose of site preparation, these components are organized into multiple levels of functional categories (Figure 21: Application Server 5300 logical hierarchy for site planning on page 50) to assist the on-site resource planning processes. Levels in the logical hierarchy represent different levels of allocation (or concentration) for media, signaling, and management resources. The Application Server 5300 hierarchy concept is therefore different from the TDM class-based switching concept, which is primarily designed for the purpose of traffic aggregation. Using the hierarchical model, the network planners can make a better decision as to what and where Application Server 5300 functional components should be positioned at different levels of the hierarchy so that the media, signaling and management functions are better structured for efficient communications over the underneath IP networks. It helps the network planners to optimize the allocation of precious Application Server 5300 resources for the purposes of redundancy, reliability, and quality of communications. The Application Server 5300 logical hierarchy provides a consistent methodology for deploying Application Server 5300 in a large network. Although there are five levels in the Application Server 5300 hierarchy, these levels can be flexibly combined in different ways suitable for
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 49 Deployment planning
different types of Application Server 5300 deployments. For example, L5 and L4 can be merged into a single level at a data center location and L3 and L2 can be merged into a single level at a media center location.
Figure 21: Application Server 5300 logical hierarchy for site planning
L5 Network Control Center
The Network Control Center (NCC) hosts the OAMP resources such as AS 5300 System Manager, the Accounting Manager, the Fault Performance Manager, Provisioning/Personal Agent Manager, and the Database Manager. The location for the NCC is mainly determined by the administrative considerations such as ease of access, the headquarters locations, and costs.
L4 Network Signaling Center
The Network Signaling Center (NSC) hosts the signaling resources such as Session Managers. For the signaling components to operate properly, the availability of fast and reliable connections to the Database Manager are critical. The following factors should be considered when choosing sites for hosting the NSC: • high transport network availability • low transport network latency • site diversity considerations
50 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] L1 Customer Application Server 5300 Client Site
• physical site security • Redundant power sources availability Depending on the size of an Application Server 5300 service network, there can be multiple NSCs distributed in the network to meet the desired reliability and to support the signaling traffic loads.
L3 Media Concentration Center
The Media Concentration Center (MCC) hosts the Media Application Servers. It can also host some Level-2 resources such as the Mediant Gateway 3000. The Level-3 sites carry significant volumes of media traffic. The locations chosen must match the topology of IP transport that can provide sufficient bandwidth and low latency for media traffic to/from subscriber populations. Level-3 sites should be positioned close to or collocated with major Level-2 Points of Presence (PoP) to shorten the media paths.
L2 Local Point-of-Presence
The Points-of-Presence (PoPs) host the AudioCodes Mediant Gateway. The gateway provides a Primary Rate Interface (PRI) interface from the SIP-based IP network to a circuit-based switching network, such as PSTN or PBX. To ensure good voice quality, the Level-2 PoPs should be closer to the large SIP client population. Like Level-3 sites, the Level-2 locations should closely match the underlying IP network topology, offer ample bandwidth and very low latency for the media traffic, and offer PSTN and Enterprise PRI access.
L1 Customer Application Server 5300 Client Site
The Application Server 5300 client site hosts Application Server 5300 clients such as Avaya 1120E IP Deskphone and Avaya 1120E IP Deskphone, Avaya Aura AS 5300 UC Clients, and IADs. These sites should be closer to the existing Level-3 and Level-2 locations for better voice quality.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 51 Deployment planning
52 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Chapter 6: Application Server 5300 deployment planning
The Application Server 5300 system supports a localized presence of media gateways and servers to eliminate the need for backhauling the media traffic to a central location. Careful planning of Application Server 5300 prior to deployment is important for the efficient use of the network resources and providing optimal quality for services offered. Local media presence reduces the bandwidth demands on the IP core networks because most media traffic can be handled locally. However, the realization of the full advantages of the Application Server 5300 system requires careful planning of domains and subdomains, location infrastructure, Routability Groups, RTP Media Portal Groups, and MAS services so that the traffic demands can be met by the resources deployed at the local locations. When planning for the Application Server 5300 deployment, network planners should consider the following steps during the planning phases. In the following discussion, the terms “site” and “location” are used interchangeably.
Step 1: Data collection for site planning
The first step of the planning process is to collect information related to the user population, PSTN interworking, site locations, existing traffic flows, VLAN and IP network topology. The user population should include the total Application Server 5300 user population, Avaya Aura AS 5300 UC Client penetration, Avaya 1120E IP Deskphone and Avaya 1120E IP Deskphone client penetration, Personal Agent client penetration, IAD client penetration, and the existing TDM user information related to Application Server 5300 client penetration against circuit switched telephones. The site information includes the locations of existing PoPs hosting other networking equipment, the preferred new L2/L3 sites, and the preferred locations of higher-level L4/L5 sites in the Application Server 5300 logical hierarchy. When deployed in a multi-VLAN network, the VLAN information should include the VLAN topology, VLAD IDs available for Application Server 5300 deployment, the (redundant) L2 switches of connecting the Application 5300 VLANs, and the (redundant) routers of terminating these VLANs. The IP network topology should include detailed information such as bandwidth, physical and logical connections, and IP routing design. With these inputs, the planner should be able to determine the L1 to L5 sites for various functional components and to visualize the additional signaling and media flows of the entire Application Server 5300 service network (Figure 22: Logical Application Server 5300 service network on page 54) overlay on the top of the existing IP networks.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 53 Application Server 5300 deployment planning
Figure 22: Logical Application Server 5300 service network
For Non DoD (for example, Federal Civilian) deployment, Application Server 5300 L1-L5 components are distributed throughout the entire enterprise main campuses and the remote branch offices. Application Server 5300 supports a full suite of unified communication services to the local Application Server 5300 subscribers. The Application Server 5300 Converged Desktop Service and CS 1000 (Communication Server 1000) blends a TDM phone and Avaya Aura AS 5300 UC Client for complete unified communication experience of the Converged Desktop subscribers. For the external PBX subscribers, Application Server 5300 provide the Meet Me and Unified Messaging using both PRI and (CS1000 and CS2100) SIP trunking connections. All L5/L4 servers are collocated in a secure data center or split into two centers where L2 Geographic Redundancy is required. The L3/L2 media servers and gateways can be deployed in the local and/or remote media centers closer to where the Application Server 5300 clients are (Figure 23: Application Server 5300 Logical Hierarchies for non-DoD system on page 55). More Application Server 5300 L2 Geogrraphic Redundancy information can be found in Avaya Aura® Application Server 5300 High Availability Fundamentals, NN42040-115.
54 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 1: Data collection for site planning
Figure 23: Application Server 5300 Logical Hierarchies for non-DoD system
For the Federal DoD PBX1 deployment, all Application Server 5300 L1-L5 components are deployed to support subscribers of a campus/enclave. All L5 and L4 servers are collocated in a secure data center for Geo Redundant deployment. The L3/L2 media servers and gateways can be deployed over the campus network closer to the supported Application Server 5300 clients. (Figure 24: Application Server 5300 logical hierarchies for PBX1 on page 56) shows the Application Server 5300 logical hierarchy for a PBX1-only system. The DoD PBX1 sites connect to DSN (Defense Switch Network) via PRI gateways. They do not provide AS-SIP trunking to the RTS network. For the external DSN users, Application Server 5300 provides the Meet Me and Unified Messaging services using only PRI gateways.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 55 Application Server 5300 deployment planning
Figure 24: Application Server 5300 logical hierarchies for PBX1
In addition to using PRI trunking for communications with DSN, Application Server 5300 Federal DoD LSC configuration also adds AS-SIP trunking to the RTS (Real Time Services) network. In addition to providing interworking with DSN clients, Application Server 5300 LSC SESM also provides DoD UC (Unified Capabilities) services for the local RTS clients. The DoD UC defines the integration of voice, video and data services delivered ubiquitously across a secure and highly available RTS network. Figure 25: Application Server 5300 logical hierarchy for LSC on page 57 shows the Application Server 5300 logical hierarchy for an LSC system. As shown in the diagram, the LSC site communicates with DSN (Defense Switch Network) subscribers via PRI gateways and communicates with RTS subscribers using AS-SIP trunking. Application Server 5300 L1-L5 components are deployed to support local and external DSN subscribers. All L5/L4 servers are collocated in a secure data center for Non Geographic Redundant deployment or split into two secure data centers for L2 Geographic Redundant deployment.
56 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 1: Data collection for site planning
Figure 25: Application Server 5300 logical hierarchy for LSC Figure 26: Application Server 5300 logical hierarchy for combined LSC and MFSS on page 57 shows the logical hierarchy for a combined LSC+MFSS system. The addition of an Application Server 5300 SS component allows the system to perform interenclave SIP traffic routing for the CS2100 MFS domain. It also provides Legacy DSN MFS to RTS MFSS migration strategies. All L5/L4 servers are collocated in a secure data center for a Non L2 Geographic Redundant deployment or deployed at two secure data centers for a L2 Geographic Redundant deployment
Figure 26: Application Server 5300 logical hierarchy for combined LSC and MFSS Application Server 5300 supports WAN SS+LSC configuration which is a subset of MFS SS +LSC configuration. The WAN SS+LSC subset continues to provide inter-enclave SIP messages routing via WAN SS, but no longer requires interworking with CS2100 MFS system. As shown in the (Figure 27: Application Server 5300 Logical Hierarchies for WAN SS+LSC configuration on page 58), the support of LSC, MAS, PRI, and Clients is optional (that is a standalone WAN SS). The WAN SS without LSC configuration provides only RTS core routing
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 57 Application Server 5300 deployment planning
functions. LSCs can be added a later time to support local LSC subscribers or external users via PRI gateways.
Figure 27: Application Server 5300 Logical Hierarchies for WAN SS+LSC configuration
Step 2: Domain trees planning
Application Server 5300 uses SIP domains as the control mechanism for subscribers, services, devices, routing, and translations. The Application Server 5300 system uses domain and subdomain structures to manage subscribers and control services available to the subscribers. The schemes for domain and subdomain naming and the criteria for setting up domains and subdomains are two major considerations that must be addressed for planning the domain trees. There are two types of domains used in Application Server 5300: the System domain and the subscriber (Non-System) domain. The System domain is created automatically when an Application Server 5300 system is first initialized and is used by the System Administrator to manage and control system resources (seeStep 3: Location trees planning on page 65 for more details). The subscriber domains are created by the Application Server 5300 system planners, based on the needs and requirements developed in Step 1: Data collection for site planning on page 53. A total of 1 000 domains and subdomains are supported for a pair of active/standby SESMs.
58 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 2: Domain trees planning
Figure 28: Application Server 5300 domain hierarchy example
There are many ways to devise a domain and subdomain naming scheme. Assigning domain names based on the locations at higher level domain hierarchies tends to go well with the Application Server 5300 location-based framework and is also easier to understand (Figure 28: Application Server 5300 domain hierarchy example on page 59). For example, the system planners of a service provider might want to create a top (SIP) domain for each of the enterprise customers (for example, xyz.com, abc.com) and then let the enterprise domain administrators manage and define their own domain spaces. Within an enterprise domain, the enterprise system planners could create, at the higher level, multilevel subdomain trees representing different geographic locations (for example, campus1.dallas.tx.us.xyz.com) and then define, at the lower level, a multilevel subdomain tree representing functional units of a particular location (callcenter.support.campus1.dallas.tx.us.xyz.com). Criteria that could influence the decision on creation of domains and subdomains are described below: • Domain management on page 59 • Subscriber load distribution on page 60 • Localized pooled entities for traffic and services optimization on page 61 • Routing translation considerations on page 63
Domain management
Application Server 5300 allows the administrators to share various management responsibilities (that is, users, devices, services, pooled entities, gateways, telephony routes, voice mail servers) at the domain and subdomain levels. For example, a large enterprise Application Server 5300 System Administrator can create additional top-level domain
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 59 Application Server 5300 deployment planning
administrators and delegate domain management responsibilities to them. Each domain administrator is provisioned with the management rights of one or more domains, but is restricted access to any other domains. The domain administrators can then delegate the management responsibilities of subdomains to other administrators. The Application Server 5300 system planners might want to take advantage of this feature when planning the domain and subdomain trees (Figure 29: Domains for administration on page 60).
Figure 29: Domains for administration
Subscriber load distribution
Application Server 5300 allows one of more domain and subdomains homed to a single server. However, a server can only handle service requests from a limited number of subscribers; the actual number may vary depending on the loads of different types of services mix. When planning the domain trees, the planners need to make sure that the subscribers of these domains and subdomains do not overload the server to which they are homing. When this situation happens, more servers will be needed to accommodate the loads. As shown in the figure (Figure 30: Subscriber load distribution on page 61), a subdomain “ny.us.na.xyz.com” is created and re-homed to the “SESM 2” to reduce the loads on “SESM 1”, which has enough capacity to handle them.
60 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 2: Domain trees planning
Figure 30: Subscriber load distribution
Localized pooled entities for traffic and services optimization
Application Server 5300 groups various physical media server resources into a logical pool. The MAS resource pools (such as Music on Hold, Branding, Announcement, Meet Me Conferencing, Ad hoc Conferencing, Unified Communications, Colorful Ringback Tones, and IM Chat) are provisioned at the system level and are assigned to the domains and subdomains for use (Figure 31: Pooled entities domain allocation on page 62). The weights are assigned to the pooled server resources for load balancing, failover, or route advanced if servers in the pool are locked, down or overloaded.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 61 Application Server 5300 deployment planning
Figure 31: Pooled entities domain allocation
The type of Media Application Server (MAS) services requested affects how the Application Server 5300 system routes these requests, as follows: • For Music on Hold (MoH) services, the system selects servers based on the subdomain of the call terminator, the shortest distance to called party. • For Announcements, the system selects the servers based on the subdomain of the call originator, the shortest distance to calling party. • For Colorful Ringback, the system selects the servers based upon the subdomain of the call terminator. • For Branding, the system selects the servers are based on the subdomain of the call terminator. • For IM Chat, the system selects the servers based on the subdomain of the IM chat originator. • For Ad hoc conferencing, the system determines the conference server by checking for the location of the Ad hoc conference initiator. • For Meet Me conferencing, service requests are routed based on the bridge number provided by the chairperson. A Meet Me pool is associated with subdomains. A chairperson determines (using the Personal Agent) their bridge number based upon the Meet Me pool associated with their subdomain. • For Unified Communication, services requests are routed directly to the server provisioned against the subscriber. There is no single way to determine the Media Application Server locations for service routing. The following table summarizes the server selection rules of various MAS services.
62 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 2: Domain trees planning
Table 8: MAS server selection rules MAS Services Server Selection Criteria Music on Hold Terminator’s subdomain Branding Terminator’s subdomain Announcement Originator’s subdomain Colorful Ringback Tone Originator’s subdomain IM Chat Originator’s subdomain Meet Me Initiator’s subdomain Ad hoc Initiator selected or provisioned location Unified Communication Provisioned server To find an Announcements server, Application Server 5300 searches the originating user’s subdomain for a provisioned server and routes the call to the provisioned server. Similarly, to find a MoH server, Application Server 5300 searches the terminating user’s subdomain for a provisioned server and routes the call to the provisioned server. If no server is provisioned (or mapped) at user’s subdomain level, the next higher subdomain will be consulted. The user’s sub-domain tree will be traversed upward until an appropriate server is found. Otherwise, a “Server not found” error is returned. The Application Server 5300 system does not enforce geographic mapping of resources to subdomains. It is up to the system planners to design the entity-subdomain mappings in a geographically sensible manner that optimizes network performance. Therefore, Avaya recommends that the subdomains should be geographically sensitive and that the pooled entities are assigned in a manner that minimizes long distance backhaul (that is, localizing pooled entities for traffic and services optimization). Both service quality and the costs of delivering the MAS services can be significantly improved in a carefully planned Application Server 5300 domain and subdomain infrastructure because users will always be routed to servers close to them.
Important: The Colorful Ringback Tone services is not supported in Application Server 5300 Release 2.0.
Routing translation considerations
Application Server 5300 telephony routing provides the means of processing a request URI to locate a subscriber, a domain, or a gateway to another network. The digit translation and routing rules can be set up for any Application Server 5300 domain and subdomain to support the local dialing requirements. The Application Server 5300 system supports three types of routes for telephony-style dialing: private route, SIP route, and gateway route. Private routes are used to reach subscribers in a private network. Private routing is used widely in the enterprise PBX environment because it supports abbreviated telephony-style digit dial
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 63 Application Server 5300 deployment planning
plans. By supporting private routes, Application Server 5300 allows a subscriber to dial another subscriber’s extension number rather than using that subscriber's URL. For example, all Application Server 5300 subscribers in dallas.tx.us.xyz.com are assigned aliases of “972-68x- yyyy”. The administrator can set up private routing for the subdomain to allow subscribers to call each other by dialing “5-yyyy”. SIP routing emulates internal routing from one domain to another without necessarily forwarding the request to another server. For instance, there are two top-level domains A and B. SIP routes can be used to quickly verify if a number dialed by a user in domain A is the alias of a user in domain B. SIP routes are limited in their applicability in most traditional dialing plans because they do not cause any telephony routing to occur in the target domain. SIP routes perform only one-time lookups. Gateway routes provide a mechanism to select the correct point and facility to use when terminating outside the SIP network such as routing a call from a SIP client out to a PSTN gateway. For example, the gateway routing can translate the URI “[email protected]” to “[email protected];norteldevice=pri;norteltrkgrp=cs_tx_trunk;user=phone;maddr= 23.23.23.23” Application Server 5300 allows a different dial plan and Class of Service (CoS) to be provisioned for each domain and subdomain. The dial plan, a set of telephony routes (or a routing table), is used for processing (that is, prepend, remove, and match) the dialed digits of the incoming calls and forwarding the calls to their destinations. The domain-based dial plan giving the administrators the control of digit translations should be applied when processing calls; that is, private routes for intra-(sub)domain calls, SIP routes for inter-(sub)domain calls, and gateway routes for PSTN calls. Allowing access to a translation table implies permission to access the resources reachable through the table. CoS provides a mechanism for screening and restricting users from accessing certain telephony routes provisioned for a domain or a subdomain. It only comes into play when a request URI contains a telephony digit stream. If a call can be completed without translating digits, there are no CoS restrictions applied to that call. The administrators can assign a single CoS value to a route list, domain, subdomain, or subscriber. The route list allows the administrators to group one or multiple routes through multiple (or the same) gateways that are used for the same purpose. For instance, if the customer needed the ability to send local calls out through multiple gateways due to the high volume of these types of calls, then multiple routes could be combined in this route list to provide the functionality. Before the system starts the process of translating digits, it first checks the CoS that the calling party will use, and then determines the set of translation and routing rules (or dial plan) that
64 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 3: Location trees planning
should be used for processing the call. The Application Server 5300 system uses the following rules to determine the class of service and dial plan to be used for a particular call: • When calling within the same domain and if the originating party is a subscriber of the domain, the CoS of the originator and the dial plan of the originator’s domain are used for processing the call. • When calling within the same domain and if the originating party is not a subscriber within that domain, such as a caller behind a PBX, the default CoS and the dial plan of the domain is used for processing the call. • When calling across different domains, the default CoS and dial plan of the terminating domain is used for processing the call. • If the request has been redirected, the redirecting party is considered to be the originator of the redirected call. • If the request has been transferred, the transferring party is considered to be the originator of the transferred call. • If the call is originated from a Communication Server 2000, the domain matching the Communication Server 2000 profile is used as the originator’s domain. • If the call contains additional network-asserted information regarding the originator’s true identity through P-Asserted-ID or Remote-Party-ID, the network-asserted information is used as the originator’s identity. After determining the dial plan, the Application Server 5300 system compares the CoS of the route list with the calling party’s CoS. If the CoS of the route list exceeds the calling party’s CoS, that route list is excluded from the translations process. Therefore, the calling party is not permitted to access the resources accessible through the route list. By properly provisioning CoS against subscribers, subdomains, domains, and route lists, the administrator can restrict a subscriber in the subdomain to access routes in the parent and other subdomains. As a result, the administrator can customize the manner in which a call may be routed. For example, a lobby phone may have a very low CoS, and the only route available would route to an operator. On the other hand, the owner of a business may have a very high CoS and be able to make expensive international calls. When there are multiple Session Managers, it is important that the gateways and Media Application Servers are homed to the Session Manager responsible for servicing the subdomains associated with those gateways and MAS resources. Without doing so, it will result in additional interSESM Traffic.
Step 3: Location trees planning
Application Server 5300 uses domains as a way to partition subscribers, resources, and services along some logical boundaries. These boundaries do not necessarily have any relationship to the geographic areas being served. In order to provide the system with a view into the geography of the service area, the Application Server 5300 allows the administrators
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 65 Application Server 5300 deployment planning
to create a logical location infrastructure for describing the topology of a virtual service network. The virtual service network topology provides a means of mapping system entities (domains, subscribers, IP phones, PRI gateways, MAS) to logical geographical locations. Through the association of system resources with locations, the system gains a topological view of how the system resources are concentrated and distributed across a service area. Locations are defined at the root level of a domain. Locations can be selected at the subdomain level from what are defined at the root domain. Whenever a root SIP domain is created, a default location named “Other” is automatically created. While the Other location exists in every domain, each instance is unique and is meaningful only in that domain. The domain’s default location can also be changed to a desired location after the creation of the domain’s location trees. The default location is useful for call processing to allocate proper gateway or pooled resources when no specific location information is available to guide the call processing.
Figure 32: Location tree example Locations are organized into a tree-like structure. Every location has a name that must be unique within the defined domain. A location name of a domain is specific within the domain. Location trees of different domains are independent of each other. The same location name in different domains may not necessarily represent the same geographic location. All locations provisioned in a system are fully qualified by their domain and location name. The location infrastructure enables the system administrators to build a set of domain-specific location trees providing a virtual representation of the geographical areas serviced by the domain. As shown in Figure 32: Location tree example on page 66, three location trees are created in the company.com domain to form a hierarchical representation of the three service areas supported in the domain. The location hierarchy is organized into a tree structure with branches and leaves. Branches are locations that contain other locations. Leaves are locations that do not contain other locations. For example, under location Santa Clara, there are one branch and two leaves called Building 1 (Bldg. 1), Building 2 (Bldg. 2), and Building 3 (Bldg. 3). The Branch Building 1 contains two leaves called First Floor (1st Floor) and Lab. Through the
66 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 3: Location trees planning
provisioning of a location hierarchy for a domain, a virtual representation of the geographic area serviced by the domain can be created.
Figure 33: Application Server 5300 domain tree example
In addition to regular subscriber domains and their corresponding location hierarchies, there also exists a special system domain. The system domain is automatically created for a system. The system domain is used to manage and control system resources. The system domain allows the system administrator to associate system resources such as gateways with locations. Foreign domains are also included in the location infrastructure, but in a more limited fashion. Foreign domains only have one location: “Other”. Figure 33: Application Server 5300 domain tree example on page 67 shows the location infrastructure defined for a system. The figure shows the location trees for System domain, two regular service domains (partner and enterprise) and a foreign domain. Note that there is an “Other” location created for each domain, including the foreign domain (other SIP domains not managed by the current Application Server 5300 system). The diagram shows that a virtual representation of the geographic area serviced by a domain can be represented by the location trees for the domain. Furthermore, the geographic area serviced by an entire system is represented by the location trees of all domains provisioned in the system. Application Server 5300 logical and physical elements can be deployed at multiple physical locations to meet a broad set of service requirements. Although domain trees are independent of location trees, the planner could use the previously designed domain trees as the starting point to design the domain’s location trees. This can be done by converting the (sub) domain trees into corresponding location trees (Figure 34: Domain tree location tree transformation on page 68).
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 67 Application Server 5300 deployment planning
Figure 34: Domain tree location tree transformation
The System domain location trees are first to be considered when planning location trees because these locations represent the system’s resources (that is, pooled entities, media portals, and gateways) that need to be deployed to deliver the desired service targets to the subscribers of the non-System domains. In addition to considering locations for system resources, the planner must also consider the nearest Public Safety Access Point (PSAP) locations for emergency services. In general, when adding a location to the System location trees, the planner should consider the following factors: • Is this location needed to identify a Routability group? • Is this location needed to offer location based routing for emergency calls? • Is this location needed for deploying system resources such as gateways, pooled entities, or media portals? Other locations the planner can also consider are the locations of the existing facility PoPs and the network control centers, where are also ideal for deploying Application Server 5300 L2 to L4 system resources as well (Figure 35: System location planning example on page 69).
68 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 3: Location trees planning
Figure 35: System location planning example
For a non-System domain, the domain planner can model the System location trees and, where applicable, add new locations to the tree to represent the subscriber and device concentrations at the new locations. This will ensure the domain location definitions are consistent with those defined in the System domain. The following factors need to be considered when adding locations to a non-System domain: • Is this location needed to identify a Routability group? • Is this location needed to correctly identify emergency response location (ERL) of the emergency caller required by law? • Is this location needed for accessing system resources such as gateways, pooled entities, or media portals? Media portals are not supported in Application Server 5300 Release 2.0. • Is this location needed to ensure clients getting the correct location representation? The Application Server 5300 system creates a single “Other” location when it initialize a domain. Care must be taken to ensure the “Other” location is properly handled. Figure 36: Non- system domain location planning example on page 70 shows the planned locations of xyz.com properly mapped to its own domain hierarchy and the facility locations of the System domain.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 69 Application Server 5300 deployment planning
Figure 36: Non-system domain location planning example
All locations defined are logical locations. Application Server 5300 does not enforce geographic mapping of resources and clients to these locations. It is up to the planner to implement the entity-location mappings through provisioning. It is possible that a single location is mapped to an enclave service area and all resources are mapped to the same location.
Step 4: Routability groups planning
Application Server 5300 allows the administrators to provision a set of locations that have direct IP routing visibility between them using Routability Group. All endpoints belonging to the same Routability Group are directly routable to one another. The endpoints that do not have direct IP routing visibility (for example, behind Network Address and Port Translation [NAPT] devices), they are assigned to different Routability groups. Calls within the same Routability Group do not require the assistance of a Border Control Point (BCP), also known as RTP Media Portal. Calls that extend beyond the group will cause a BCP to be inserted between the endpoints to anchor the calls.
70 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 4: Routability groups planning
Figure 37: Routability Group example
Based on the location infrastructure defined in the previous step, Routability Groups can be defined to include locations that can directly route packets between each other. An example of Routability Groups is shown in Figure 37: Routability Group example on page 71. In this example, there are five Routability Groups defined that overlay the location tree. Locations enclosed in the same color area belong to the same Routability Group. Endpoints at “Richardson” and “Galatyn C” belong to the same Routability Group. Therefore, no BCP is required for calls between these two locations. Using the location trees created previously and the detail IP network diagrams collected, the system planners should be able to identify the IP routability between any pair of locations. All locations that can route packets directly to each other must be included in the same routability group. As shown in Figure 38: Routability Group planning example on page 72, all service provider locations belong to a single routability group. All xyz sites are placed in their own routability group because the company has installed firewall/NAPT devices at every site for protection and address/port translation of the IP traffic. Notice that not every location needs to belong to a routability group. Only the locations that have associated SIP endpoints need to be assigned to the routability groups. The locations that do not have any SIP endpoints subscribed to would not have to belong to any routability groups. For example, the “tx” and “us” locations of xyz.com do not belong to any routability groups, and are there to mimic the provider’s location tree and to glue the sites with SIP endpoints together. The “Other” location of xyz.com, used for mobile users, also does not belong to any routability group. It allows Application Server 5300 to insert a RTP media portal into the media path for communications with the mobile users; and even among the mobile users themselves.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 71 Application Server 5300 deployment planning
Figure 38: Routability Group planning example
By default, the AS 5300 Session Manager inserts an RTP Media Portal into every call unless there is a Routability Group provisioned to include the originating and terminating clients’ locations. There are three special cases: • If a location is not a member of Routability Group, a BCP will always be inserted even between callers at the same location. • If there is no Routability Group defined for the system and the new location-based Border Control Point Insertion rules have been enabled, the AS 5300 Session Manager will insert a BCP in all calls by default. • If there is only one Routability Group containing only the Other location and all endpoints are associated with the Other location, the AS 5300 Session Manager will not insert an BCP by default. The accuracy of the Routability grouping impacts greatly on both the success of establishing calls and media sessions with or without BCP resources. Detailed IP network information is required to define the Routability Groups by determining where direct IP routing paths exist between the endpoints participating in the calls. Therefore, it is essential that the administrators work closely with the IP network administrators to ensure that Routability Groups and associated locations are correctly configured so that direct routing paths exist within the same Routability Group. The Routability Group information is stored in the Database Manager and is cached on the AS 5300 Session Manager for rapid access during runtime call processing. Using the Routability Groups, the BCP insertion rules become a simple test of group membership of the endpoints.
72 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 5: RTP Media Portal Groups planning
All endpoints within an campus/enclave should have direct IP routing visibility of each other. The NAPT and BCP devices are not required in an enclave. All enclave locations belong to the same Routability group.
Step 5: RTP Media Portal Groups planning
The media traffic between endpoints of different routability groups must traverse the RTP Media Portal. Using the completed location infrastructure and routability group charts, the Application Server 5300 planner can determine the number and the locations of the RTP Media Portal groups required to support the interroutability group communications of the SIP endpoints.
Important: This step can be skipped for the Federal solution because Application Server 5300 Release 2.0 does not require an RTP Media Portal. This step is included for future use. By configuring “Ignorempules” to true (using the AS 5300 System Manager Console), the AS 5300 Session Manager will not insert a portal in any call. As shown in Figure 39: RTP Media Portal Group planning example on page 73, the system planner has decided to install RTP Media Portals in the Dallas ‘east’, ‘west’, and ‘dallas’ PoPs to support SIP endpoints located in the building1 and building2 of campus1 and campus2. A ‘blue’ media portal group is planned for the locations of ‘building1’, ‘building2’, ‘campus1’, and Dallas ‘east’ PoP. A ‘red’ media portal group is planned for the locations of ‘campus2’, and Dallas ‘west’ PoP. This plan allows the SIP endpoints on the campus1 to use the closest RTP media portals located in the Dallas ‘east’ PoP and the SIP endpoints on the campus2 to use the closest RTP media portals located in the Dallas ‘west’ PoP.
Figure 39: RTP Media Portal Group planning example
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 73 Application Server 5300 deployment planning
Step 6: Subscriber services planning
Application Server 5300 offers a rich set of VoIP and multimedia services to its subscribers. This makes engineering a sound Application Server 5300 solution more challenging. The system planners must understand and carefully plan the subscriber services that will meet the enterprise’s business and communications needs. Numerous issues come to mind when planning Application Server 5300 services, but at the minimum, the planners must fully understand the following questions at the service planning phase: • How many (current and future) sites? • How many users for each site? • What is the planned subscriber growth rate for each site? • What types of Application Server 5300 clients are planned for each site? • What types of audio and video Codecs will be supported for each site? • How many simultaneous clients per subscriber will be logging on? • What Application Server 5300 services will be offered? How many users will be given these services? • What is a typical subscriber’s Application Server 5300 usage profile? This profile can include the following parameter values: - calls per busy hour - average call hold time - the percentage of intrasite (intraenclave) call is between the SIP Clients - the percentage of intersite (interenclave) call (that is the calls will be forwarded to/ received from outside of the local site) - the percentage of intrasite PRI calls - the percentage of intersite PRI calls - the percentage of video calls - the percentage of Ad hoc conference calls - the percentage of Meet Me conference calls - the percentage of subscribers having the presence service - the size of a friend list - the number of terminations per simultaneous ring list - the percentage of subscribers having the Instant Messaging (IM) service
74 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 6: Subscriber services planning
- the number of IM message sent per subscriber per busy hour - the percentage of subscribers having the network call log service The following tables are provided to assist the service planners collecting the subscriber and service related parameters for purpose of engineering an Application Server 5300 system. The default parameters of the tables can be changed to meet specific service requirements. Table 9: Application Server 5300 general inputs
Total Number of Subscriber (Large Model) 25 000.00 Total Number of Subscriber (Small Model) 5 000.00 Clients per Sub 1.0 Session Manager Server Capacity Utilization (%) 80%
Table 10: Application Server 5300 advanced services inputs
Personal Agent default values Subscribers with PA Service (%) 100% PA Routes to Multiple Destinations (%) 10% Average Number of PA Legs (#) 3 PA Gateway Calls /BH (%) 66%
Presence default values Subscribers with Presence Service (%) 80% Average Friends per Subscriber (#) 20 Idle Capable Clients w/Idle Presence Enabled (%) 10% Times Client Goes Idle /BH (#) 4 Manual Presence Changes /BH (#) 0.083 Clients with auto on the phone presence (%) 10% Avg # of Client Periodical Presence Subscription/BH (#) 1 Client Registrations/BH (#) 0.042
Instant Messaging (IM) default values Subscribers with IM Service (%) 100% Average Subscriber IM's /BH/Sub (#) 5 Average Subscriber IM's /BH/Client (#) 5 Converged Mobility Clients Supporting IM (%) 100% Third Party Clients Supporting IM (%) 100%
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 75 Application Server 5300 deployment planning
Video Services default values Subscribers with Video Service (%) 10% Video Calls /BH (%) 5% On-Demand Video Calls (%) 5%
MLPP Services default values Subscribers with MLPP Service (%) 100% % of MLPP priority call origination 20% % of MLPP successful priority call 14% % of MLPP Priority call diversion 4% % of MLPP rejected priority call 2% % of MLPP call require MAS 100% MLPP tone duration (sec) 10
Table 11: MAS service inputs
General MAS Hardware Selection x3550 M3
Ad hoc Conferencing default values Subscribers with Ad hoc Service (%) 100% Ad hoc Calls /BH (%) 1% Ad hoc Calls w/ Video Sessions (%) 5% Participants from PSTN in Ad hoc Call (%) 15% Participants from other Enclave in Ad hoc Call (%) 15% Average Ad hoc Participants (#) 3 Average Ad hoc Call Hold Time (min) 15 Ad hoc Media Redundancy Ratio (%) 10%
Meet Me Conferencing default values Subscribers with Meet Me Service (%) 100% Meet Me Calls /BH (%) 2% Meet Me Calls w/ Video Sessions (%) 5% Meet Me Calls w/ Premium Conferencing (%) 100% Participants from PSTN in Meet Me Call (%) 20%
76 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 6: Subscriber services planning
Participants from other Enclave in Meet Me Call (%) 30% Average Meet Me Participants (#) 6 Average Meet Me Call Hold Time (min) 30 Meet Me Media Redundancy Ratio (%) 20%
Announcement or Music on Hold (MoH) default values Calls with Announcement Treatment (%) 1% Average Announcement Time (sec) 20 Subscribers with MoH Service (%) 100% Calls with Music on Hold Treatment (%) 5% Average Music on Hold Time (sec) 30 Ann/MoH Media Over Engineering Ratio (%) 20%
Unified Communications (UC) or Voice Mail default values Subscribers with UC Service (%) 100% Incoming Forwards to Voice Mail (%) 2% Voice Mail Retrievals /BH (#) 0.25 Voice Mail Retrievals /BH/Client (#) 0.23 Voice Mail Retrievals From PSTN (%) 20% Average Voice Mail Message Time (sec) 40 Average Mailbox Storage Size (min) 8 UC Media Redundancy Ratio (%) 10%
Table 12: Gateway and Border Control Point inputs
Media Gateway 3000 default values Type of Circuit T1 Circuit Over Engineering Ratio (%) 10%
Table 13: Engineering parameters
Client maintenance traffic parameter default values TLS/TCP? (Y/N) Yes Application Server 5300 Client Registrations /BH (#) 0.083 Application Server 5300 Client Pings /BH (#) 24
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 77 Application Server 5300 deployment planning
Application Server 5300 IAD SIP Option Keepalive message/BH (#) 60 Avaya Aura AS 5300 UC Clients CRLF Keepalive/BH (#) 240 Application Server 5300 SIP phone Keepalive/BH (#) 60
System engineering parameters default values Inbound Call Ratio (%) 50% Outbound Call Ratio (%) 50% Inbound IM Ratio (%) 50% Inbound Notification Ratio (%) 50% Inbound Presence Subscription Ratio (%) 50% Blocking Factor / GOS (P-value) P01 Blocking Factor / GOS (%) 1.00%
Call parameters default values Calls /BH/Sub (#) 6 Calls /BH/Client (#) 6 Average Call Hold Time (sec) 180 SIP-to-SIP Intracite (Intraenclave) /BH (%) 70% SIP-to-SIP Inter-enclave Traffic using SS SESM /BH (%) 20% SIP-to-PRI Calls /BH (%) 10% Intra-Server Call (%) 100% G.711 Calls (%) 100% G.729 Calls (%) 0% G.711 Packetization Time (milliseconds) 20 G.729 Packetization Time (milliseconds) 20
Step 7: Service quality planning
The following issues must be resolved to ensure the delivery of high quality services. • User support mechanisms are in place: An integrated TDM-Application Server 5300-Data service support team must be organized and trained for quick service problem resolution. The TDM-Application Server 5300-Data problems escalation and resolution procedures
78 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Step 7: Service quality planning
must be established to provide a single service contact window for subscribers. A quick start user training course and user documentation should be accessible online. • Service quality expectations are very well understood: The expected service quality targets for services such as voice, video, and interactive (IM) applications are established and understood. The planners might use the ITU-T G.1010 and Y.1541as the starting points to develop the service quality requirements. • IP Network quality is consistent with the service expectation: Avaya recommends that a full network health check be performed prior to the deployment to ensure that all network issues that can have negative impacts to the Application Server 5300 services are identified and resolved. When the network services are provided by another organization, the Application Server 5300 service planner must ensure the existing service level agreement meets the needs. • Security policies and procedures for Application Server 5300 deployment are established: The existing security policy must be enhanced for new services. This should include establishing - the acceptable use policy for the users - the policies for attaching the clients, gateways, and servers to the IP network - the filter policy for firewalling - the procedure for auditing and analyzing all devices for security violation/compliancy - the procedure for regular network scanning and analysis to ensure only needed UDP/TCP ports are open for the permitted services • All administrator roles are defined: All administrators and their roles in performing OAMP functions must be identified: - Names, organizations, locations, and contact information - Roles, rights and privileges for the OAMP functions performed More details on this topic can be found in Avaya Aura® Application Server 5300 Using the Provisioning Client, NN42040-112, Avaya Aura® Application Server 5300 Administration, NN42040-600, and Avaya Aura® Application Server 5300 Security, NN42040-601. • Services availability requirements are well defined: It can include the following: - Permissible down time - Time to repair - Device redundancy and spare parts - Vendor service contact information - Problem resolution and escalation procedures
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 79 Application Server 5300 deployment planning
80 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Chapter 7: System capacity planning
After completing the desired subscriber service plan, the system planners must calculate the expected resource demands in terms of busy-hour transactions and circuit (or port) count for the expected number of total subscribers. This chapter describes the SIP weighted transaction model concept and its use in engineering the AS 5300 Session Manager capacity. The engineering methods for determining MAS services and PRI gateway capacity will also be described in this chapter. Navigation
• Weighted transaction model on page 81 • System capacity engineering on page 83
Weighted transaction model
The most common metric used for sizing a legacy telephony switch is Busy Hour Call Attempts (BHCA). The Application Server 5300 system provides a new breed of services and functionality that legacy telephony does not provide. In order to implement these new services and features, a new weighted SIP transaction model based on Busy Hour SIP Transaction Attempts (BHSTA) metric is adopted to calculate system capacity. A SIP transaction is defined as a Request followed by a Response. For example, a SIP REGISTER request followed by a 200 OK response is considered a SIP transaction. Different types of service types are comprised of one-to-many SIP transactions. The type of SIP transaction will also dictate how much processing the Session Manager will need to accomplish in order to complete the transaction. The amount of SIP transaction traffic that can be sustained is highly dependent on the SIP transaction type. Some transactions require significantly more processing and bandwidth than others. For example, the cost of completing a SIP-SIP call is more than the cost of sending a SIP Instant Message (IM). The following table describes various types of SIP transactions. Table 14: SIP transaction types
SIP Transaction Type Additional Description Instant Message Basic IMs from one SIP client to another SIP client Basic SIP-SIP calls Basic call from one SIP client to another SIP client. Client registrations REGISTER, Registers a client with the SIP Application Module. The cost of this transaction is larger than the cost of presence state change REGISTERs.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 81 System capacity planning
SIP Transaction Type Additional Description Presence state change PUBLISH, This transaction does not include corresponding NOTIFY messages and requires less processing. SIP Ping A ping message in SIP (not to be confused with ICMP ping) Forking One subscriber has multiple clients registered when a call or IM comes in. All registered clients ring or receive IMs. Forking should not be confused with Personal Agent based sequential ringing or simultaneous ringing where translation logic must be traversed for each address. Presence subscription SUBSCRIBE, This transaction does not include corresponding NOTIFY messages that are sent out from the SIP Application Module to the client Service notification NOTIFY, Usually sent by Session Manager. Address book subscription SUBSCRIBE, Subscribes to the Address Book service after which the client proceeds to download the address book from the Provisioning Module. Service package subscribe SUBSCRIBE, Subscribes to the service package assigned to the subscriber after which the client proceeds to download the service package from the Provisioning Module. Basic SIP-PSTN Calls Calls that require the Session Manager to find a route using translations for the requested destination address.
In order to keep numbers and calculations consistent, a baseline is established from which all other transactions derive their weight. A Weighted SIP Transaction Cost Model is introduced to describe performance capacity of a Session Manager for a particular software release (for example, Application Server 5300 Release 2.0) on a particular hardware platform (for example, x3550). In the weighted model, each transaction type is assigned a weight relative to the cost of processing an unauthenticated IM, where the processing of an unauthenticated IM has a weight of one and all other transitions have weights either higher or lower than one. When a server is rated for a certain number of transactions, it indicates that the server can process that amount of unauthenticated instant messages. To determine the maximum number of non-IM transactions the system can support, the rated capacity must be divided by the Weighted SIP Transaction Cost of the transaction in question. For example, if a system is rated at 1 000 000 transactions an hour and one wants to determine the maximum number of SIP- SIP calls can be processed, then 1 000 000 is divided by the weighted cost of processing a SIP-SIP call. As already mentioned, the processing of a SIP-SIP call has a higher weight cost than the processing of an unauthenticated instant message therefore the maximum rated capacity measured in SIP-SIP calls will be less than 1 000 000. On the other hand, the processing of a SIP Keepalive message requires very little resources so the maximum rated capacity for processing SIP PING messages would be much greater than 1 000 000. The maximum weighted capacity of an x3550 Session Manager for the small configuration (S) is 2 500 000 BHSTA, is 3 000 000 BHSTA for the medium configuration (M), and is 2 600 000
82 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
BHSTA for the large configuration (L). The weighted transaction cost model of various SIP transaction types is shown in the following table. Table 15: x3550 weighted transactions
SIP TRANSACTION x3550 S x3550 S X3550 M x3550 M X3550 L X3550 L Auth TYPES Auth Auth Instant Message 1 0.43 1 0.72 1 0.73 Basic SIP-SIP Calls 3.33 0.24 2.5 1.25 2.6 0.65 Client Registrations 0.63 0.37 1.2 0 1.04 0 Presence State 0.63 0.62 0.86 0.48 0.74 0.74 Changes (Publish) SIP Ping 0.03 NA 0.03 NA 0.03 NA IAD Keepalive (SIP 0.03 NA 0.03 NA 0.03 NA Option Message) Personal 0.03 NA 0.03 NA 0.03 NA Communicator Client CR/LF Keepalive SIP phone 0.03 NA 0.03 NA 0.03 NA Keepalive Client Call Forking 2.92 NA 1.25 NA 0.65 NA Presence 1 0.43 1 1 0.95 0.79 Subscription Service Notification 0.21 NA 0.34 NA 0.12 NA Address Book 1 0.67 1 0.82 1 0.49 Subscription Service Package 0.83 0.59 0.55 0.31 1 0.49 Subscription Basic SIP-PSTN 3.33 0.24 2.5 1.25 2.6 0.65 Calls
System capacity engineering
The system planners have completed a detail system deployment and subscriber usage profile analysis. The system planners can start to engineer the system capacity of all functional components to support the desired subscribers and services.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 83 System capacity planning
AS 5300 Session Manager engineering
The most complex part of Application Server 5300 SIP Core engineering is to engineer the capacity of the AS 5300 Session Managers. Application Server 5300 supports two categories of SESMs. The first category, providing comprehensive UC services to local subscribers, includes Non DoD SESM, DoD PBX1 SESM, and DoD Slave LSC SESM. Because the possible subscriber UC service sets are very large, to help understanding the engineering process using weighted transaction model, it is easier to just use several familiar examples to illustrate the key engineering steps for calculating the SESM capacity requirements. These examples are calculated based on an example weighted transaction cost model (Table 16: Application Server 5300 weighted transaction cost example on page 84) and a sample subscriber service usage model (Table 17: Subscriber Usage values on page 85). The second category of SESMs, including DoD Master LSC SESM, and DoD SS SESM, does not support local subscribers. The capacity engineering process for these types of SESM are more straightforward because only routing functions for subtended SESMs and foreign systems need to be considered in calculations. We will discuss them later. Table 16: Application Server 5300 weighted transaction cost example
Weighted SIP x3550 S x3550 S Auth x3550 L x3550 L Auth transaction costs Instant Message 1 0.49 1 0.38 Basic SIP-SIP 2.98 0.71 3.1 0.33 calls Client 0.74 0.23 0.76 0.16 registrations Presence state 0.86 0.43 0.96 0.41 changes SIP Ping 0.12 0 0.15 0 Client call 0.89 NA 1.03 NA forking Presence 0.86 0.43 0.96 0.41 subscription Service 0.21 NA 0.3 NA notification Address Book 0.57 0.2 0.76 0.36 subscription Service 0.55 0.15 0.84 0.24 Package subscription
84 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
Weighted SIP x3550 S x3550 S Auth x3550 L x3550 L Auth transaction costs Basic SIP-PSTN 2.98 0.71 3.1 0.33 calls
Table 17: Subscriber Usage values
Subscriber Usage Profile Values A. Total number of active subscribers 3000 B. Active AS 5300 UC Clients 800 D. Active Avaya 1120E IP Deskphone and Avaya 1140E IP 2000 Deskphone clients E. Active IAD clients 200 F. Concurrent registered clients per subscriber 1 G Call origination rate per busy hour per subscriber 5 H. Registrations per 24 hour day per client 2 I. Percent conferencing calls 5% J. Percent SIP-SIP calls 80% L. Percent PSTN/PBX (E.164) calls 15% M. subscriber subscribe to Meet Me service 10% N. Average number of parties in Meet Me audio conference 6 O. Number of friends per subscriber 20 P. IMs sent per subscriber 5 Q. Maximum engineered capacity 80% R. Manual presence changes per day per client 2 S. Number of times PC goes idle during busy hour 2 T. Auto presence “On the Phone” penetration 100% U. Auto presence “Idle” penetration 15%
For simplicity, all calculations below are based upon the SIP messages occurring during the busy hour using the non-authenticated cost value. The calculations will be presented in the form of formulas utilizing the reference letters (A-U) from Subscriber usage values and the values of “x3550 S” column in the Application Server 5300 weighted transaction cost example table. 1. Instant Messages TransactionsFromIMs = (B+D) x P
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 85 System capacity planning
To find the number of transactions generated by IMs, the number of IM capable clients is multiplied by the number of IMs sent by each subscriber. The IAD clients don’t support sending IMs. The weighted cost for processing IMs is TransactionsFromIMsCost = TransactionsFromIMs x Cost of Processing an IM Based on Table 16: Application Server 5300 weighted transaction cost example on page 84 and Table 17: Subscriber Usage values on page 85, the weighted transaction cost of processing IMs is TransactionsFromIMsCost = (800 + 2000) x 5 x 1 = 14,000 2. Basic SIP-SIP Calls TransactionsFromSIPcalls = A x G x´ J To find the number of transactions generated by SIP-SIP Calls, the number of subscribers is multiplied by the subscriber’s call rate per hour and then multiplied by the percentage of all calls that are SIP-SIP. Note that basic SIP-SIP calls are defined as using SIP addressing such as [email protected] while E.164 addressing such as 123-456-7891 has a different cost associated with it and should be calculated separately. The weighted cost for processing SIP basic calls is TransactionsFromSIPcallsCost = TransactionsFromSIPcalls x Cost of Processing a Basic SIP call Based on Table 16: Application Server 5300 weighted transaction cost example on page 84 and Table 17: Subscriber Usage values on page 85, the weighted transaction cost of processing basic SIP calls is TransactionsFromSIPcallsCost = 3000 x 5 x 0.8 x 2.98 = 35,760 3. Client Registrations
Figure 40: Subscriber registration TransactionsFromClientRegistrations = A x F x (H / 24) To find the number of transactions generated by Client Registrations during a busy hour, the number of subscribers is multiplied by the number of concurrently registered clients per
86 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
subscriber and by the number of times a client registers per 24 hour period. The weighted cost for processing client registrations is: TransactionsFromClientRegistrationsCost = TransactionsFromClientRegistrations x Cost of Processing a Registration Based on Table 16: Application Server 5300 weighted transaction cost example on page 84 and Table 17: Subscriber Usage values on page 85, the weighted transaction cost of processing registrations is TransactionsFromClientRegistrationsCost = 3000 x 1 x (2 / 24) x 0.74 = 185 4. Presence State Change generated PUBLISH transactions TransactionsFromStateChangePUBLISHs = ((B+D) x F x (R/24)) + ((B+D) x F x G x T x 2) + (B x S x U x 2) The formula for calculating the number of PUBLISH transactions from presence state changes is composed of three parts. 1. Transactions from manual state changes per day per client 2. Transactions from auto presence “On the phone” changes 3. Transactions from auto presence “Idle” changes The first section takes the number of subscribers and multiplies it by the number of concurrently registered clients per subscriber. Then the result is multiplied by the number of manual presence state changes per day per client and divided by 24 to arrive at the number of transactions per hour. Note the IAD clients do not presence subscription and update functions.
Figure 41: Manual state change notifications
The second section takes the number of subscribers and multiplies it by the number of concurrently registered clients per subscriber then by the total call rate per busy hour and auto presence “On the phone” penetration. Note that this calculation only applies to Avaya clients because auto presence is only supported on Avaya clients. The last step is to multiply by 2
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 87 System capacity planning
since each phone call with auto presence enabled generates two state changes (that is, “On the phone”, “Active Available”).
Figure 42: On the phone state change
The third section takes the number of Avaya Aura AS 5300 UC Clients, which are the only clients that support “Idle” presence, and multiplies it by the number of times PC goes idle during busy hour and then by auto presence “Idle” penetration. The last step is to multiply by 2 since each state change to “Idle” will usually be accompanied by a corresponding state change to “Active Available”.
Figure 43: Idle presence update
All three sections are added together to arrive at the final number of REGISTER transactions from presence state changes. In some situations presence state changes from connecting and disconnecting devices to a network can also add a significant number of presence state change transactions to the calculation, one can add its cost as a fourth component of the formula.
88 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
Based on Table 16: Application Server 5300 weighted transaction cost example on page 84 and Table 17: Subscriber Usage values on page 85, the weighted transaction cost of processing presence state changes is: TransactionsFromStateChangePUBLISHsCost = TransactionsFromStateChangePUBLISHs x Cost of Processing a Presence State Change TransactionsFromStateChangePUBLISHsCost = [(2800 x 1 x 2/24) + (2800 x 1 x 5 x 1 x 2) + (800 x 2 x 0.15 x 2)] x 0.86 = (233 + 28,000 + 960) x 0.86 = 25,106 5. Presence Subscription Transactions TransactionsFromPresenceSUBSCRIBEs = (B+D) x (H / 24) x O Presence subscription transactions take place at the same time as the client registrations. Both the AS 5300 UC clients and the i1120E/1140E clients subscribe for presence information automatically when they first register with the system. The number of presence subscriptions will be equal to the number of Multimedia clients registration multiplied by the number of friends per subscriber. Based on Table 16: Application Server 5300 weighted transaction cost example on page 84 and Table 17: Subscriber Usage values on page 85, the weighted transaction cost of processing presence state changes is: TransactionsFromPresenceSUBSCRIBEsCost = TransactionsFromPresenceSUBSCRIBEs ´ Cost of Processing a Presence State Subscription TransactionsFromPresenceSUBSCRIBEsCost = (2800 x 2/24 x20) x 0.86 = 4,667x 0.86 = 4,014 6. Presence Notify Transactions TransactionsFromPresenceNOTIFYs = ((B+D) x (O + 1) x (R / 24)) + ((B+D) x F x G x T x (O + 1) x 2)+ (B x S x U x (O + 1) x 2) Calculating the number of Presence Notify transactions is not a trivial exercise as can be seen from the size of the formula. There are three components that comprise this calculation as in the Presence State Change PUBLISH transaction calculation. The similarity exists because NOTIFY messages are sent once a client sends in a Presence State Change PUBLISH message. The three sections of the formula are listed below and they an each part is added to the next to form the complete formula. 1. Transactions from manual state changes per day per client 2. Transactions from auto presence “On the phone” changes 3. Transactions from auto presence “Idle” changes The first section takes the number of subscribers and multiplies it by the number of concurrently registered clients per subscriber. One is added to the number of friends per subscriber to account for the fact each client subscribes to its own state. Then the result is multiplied by the number of manual presence state changes per day per client and divided by 24 hours to arrive at the number of transactions per hour.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 89 System capacity planning
The second section takes the number of subscribers and multiplies it by the number of concurrently registered clients per subscriber then by the total call rate per busy hour and auto presence “On the phone” penetration. One is added to the number of friends per subscriber to account for the fact each client subscribes to its own state and then the result is multiplied by 2 because most of the time a client that changes state to “On the phone” will change back to the original state once the phone call is completed. The third section takes the number of Avaya Aura AS 5300 UC Clients, which are the only clients that support “Idle” presence, and multiplies it by the number of times PC goes idle during busy hour and then by auto presence “Idle” penetration. The last step is to multiply by 2 since each state change to “Idle” will usually be accompanied by a corresponding state change to “Active Available”. One is added to the number of friends per subscriber to account for the fact each client subscribes to its own state and then the result is multiplied by 2 because most of the time a client that changes state to “On the phone” will change back to the original state once the phone call is completed. Based on Table 16: Application Server 5300 weighted transaction cost example on page 84 and Table 17: Subscriber Usage values on page 85, the weighted transaction cost of processing presence state notifications is: TransactionsFromPresenceNOTIFYsCost = TransactionsFromPresenceNOTIFYs ´ Cost of Processing of a Notification TransactionsFromPresenceNOTIFYsCost = [(2800 x (20 + 1) x (2/24)) + (2800 x 1 x 5 x 1 x (20 + 1) x 2) + (800 x 2 x 0.15 x (20 + 1) x 2)] x 0.21 = (4900 + 588000 + 10080) x 0.21 = 90,447 7. Address Book Transactions TransactionsFromAddressBook = TransactionsFromClientRegistrations Since Address Book subscriptions almost always occur during client registration the number of Address Book subscription transactions is approximately equal to the number of Client Registration transactions. Note that address book subscribe transactions only apply to AS5300 clients. Based on Table 16: Application Server 5300 weighted transaction cost example on page 84, the weighted transaction cost of processing addressbook is: TransactionsFromAddressBookCost = TransactionsFromAddressBook ´ Cost of Processing of a Addressbook Subscription TransactionsFromAddressBookCost = 250 x 0.57 = 143 8. Service Package Subscription Transactions TransactionsFromServicePackSubs = TransactionsFromClientRegistrations Since Service Package subscriptions almost always occur during client registration the number of Service Package subscription transactions is approximately equal to the number of Client Registration transactions. Note that service package subscription transactions only apply to AS5300 clients.
90 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
Based on Table 16: Application Server 5300 weighted transaction cost example on page 84, the weighted transaction cost of processing service package is: TransactionsFromServicePackSubsCost = TransactionsFromServicePackSubs x Cost of Processing of a Service Package Subscription TransactionsFromServicePackSubsCost = 250 x 0.55 = 138 9. Gateway Call Transactions TransactionsFromGatewayCalls = A x L x G The number of transactions generated by Gateway calls is calculated by multiplying the number of subscribers by the PSTN/PBX call percentage. The result is multiplied by the busy hour call rate to arrive at the final number of transactions from Gateway calls. The weighted cost for processing PSTN/PBX calls is: TransactionsFromGatewayCallsCost = TransactionsFromGatewayCalls x Cost of Processing a PSTN/PBX call Based on Table 16: Application Server 5300 weighted transaction cost example on page 84 and Table 17: Subscriber Usage values on page 85, the weighted transaction cost of processing PSTN/PBX calls is: TransactionsFromSIPcallsCost = 3000 x 5 x 0.15 x 2.98 = 6,705 10. Meet Me Call Transactions TransactionsFromMeetMeCalls = A x I x G x M x N The number of conference meetings per busy hour generated by Meet Me calls is calculated by multiplying the number of subscribers by the Meet Me conference call percentage, the busy hour call rate, and the percentage of subscribers subscribing to Meet Me service. The result is multiplied by the average number of parties in Meet Me audio conference to arrive at the final number of transactions from Meet Me calls. The weighted cost for processing Meet Me calls is: TransactionsFromMeetMeCallsCost = TransactionsFromMeetMeCalls x (3 x Cost of Processing a Basic SIP call) Based on Table 16: Application Server 5300 weighted transaction cost example on page 84 and Table 17: Subscriber Usage values on page 85, the weighted transaction cost of processing Meet Me calls is TransactionsFromMeetMeCallsCost = (3000 x 0.05 x 5 x 0.1 x 6) x 3 x 2.98 = 450 x 3 x 2.98 = 4023 11. Calculating the Total Transaction Cost The sum of costs calculated from steps 1 to 10 is the total cost of offering services to subscribers. The following table shows the calculation of the total cost using results provided in the previous steps.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 91 System capacity planning
Table 18: Total cost calculation
Service Types Cost Instant Message 14 000 SIP basic call 35 760 Registration 185 Presence state change 25 106 Presence subscription 4 014 Presence notification 90 447 Address book subscription 143 Service Package subscription 138 PSTN/PBX call 6 705 Meet Me call 4 023 Total 180 521
Assume the maximum weighted capacity of an LSC AS 5300 Session Manager is 1,000,000. One can calculate the percentage of utilization using the following formula: Percent Utilization = (Calculated Cost / Rated Capacity) X 100 = (180,521 / 1,000,000) x 100 =18% 18% is less than 80%, the recommended Maximum Engineered Capacity. Therefore, one can conclude that one AS 5300 Session Manager server will be sufficient to handle the planned processing load. An additional AS 5300 Session Manager is required if the percent utilization is exceed the target utilization. Depending on the site traffic behaviours, the planners should consider reserving 20 to 40% of server capacity reserved for handling traffic surges. We have used a simple service example to illustrate the complexity of engineering SESM capacity requirements using weighted transaction cost model. To perform more detail calculations requires the system planners to identify the types of transactions generated by more complex service models. An example of such model is shown in Step 6: Subscriber services planning on page 74.
Master LSC SESM Engineering (DoD Only)
Depending on the types of processor and modes of operation, Application Server 5300 Small Configuration supports only one or one pair of LSC SESM(s). The total weighted LSC transaction processing costs is the sum of the local subscriber transaction processing costs and the weighted transaction processing costs for DSN/PSTN transit and MAS services calls. As shown in Figure 44: Small configuration Master LSC on page 93, the DSN/PSTN transit and MAS calls do not communicate with the local LSC subscribers. These are additional traffic
92 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
Master LSC processed for the DSN/PSTN users, and hence must be considered separately from the local LSC subscriber processing costs. MasterLSCTransactionsProcessingCost (Small) = Local LSC Subscriber Weighted Transaction Processing Costs + MAS&TransitDSN/PSTNTransactionProcessingCost Based on the site specific service models, using the steps previously described, the system planners can calculate the weighted processing costs for the local LSC subscribers. To calculate the additional DSN/PSTN transaction processing demands for MAS and Transit calls, the system planners need to estimate the following traffic parameters: • TotalSupportedDSN/PSTNSubscribers • CallsPerBusyHourPerDSN/PSTNSubscriber • %ofLSCSubscriberCall MAS&TransitDSN/PSTNTransactionProcessingCost = SIP-PSTNcallTransactionCost x CallsPerBusyHourPerDSN/PSTNSubscriber x (1 - %ofLSCSubscriberCall) x TotalSupportedDSN/PSTNSubscribers Note that the equation has excluded the processing costs for calls communicating with the local LSC subscribers because it is part of local LSC subscriber transaction cost calculation. Depending on the sites, there should be 20 to 40% of system capacity reserved for traffic surges. Hence, the total LSC processing costs should not exceed 60-80% of server capacity.
Figure 44: Small configuration Master LSC Application Server 5300 Medium and Large Configurations allow multiple pair of SESMs in a system to function either as an SS type or as a LSC type (seeApplication Server 5300 hardware and configurations on page 29 for more details). For a LSC-only enclave, the Medium Configuration supports up to three pairs of LSC SESMs and the Large Configuration supports
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 93 System capacity planning
up to six pairs of LSC SESMs. For both Medium and Large Configurations, only one pair of LSC is configured as Master LSC and all other LSCs are configured as Slave LSCs. All enclave subscribers are provisioned on the Slave LSCs. The Master LSC does not host any local subscribers and only processes all inter-enclave IMs and calls to/from the Slave LSCs. The PRI gateways must be configured to send incoming calls to Master LSC for processing (Figure 45: Medium/Large LSC-Only Master LSC on page 94). Assured Service Admission Control (ASAC) service is enabled only on the Master LSC and disabled on Slave LSCs. If there is EBC fronting the enclave, the EBC must be configured to route all incoming calls to the Master LSC, which then routes the calls to the Slave LSC subscribers or DSN/ PSTN subscribers.
Figure 45: Medium/Large LSC-Only Master LSC
The traffic of a Slave LSC subscriber can be divided into three categories: intra-enclave, inter- enclave, and SIP-PRI. For the intra-enclave traffic, both endpoints (that is, senders and receivers) are home to the same or different Slave LSC of an Application Server 5300 system. For the inter-enclave traffic, one of the endpoints locates in a different enclave. For the SIP- PRI traffic, one of the endpoints is a PRI gateway. While the outgoing PRI calls are sent directly to the PRI gateway from the Slave LSCs, the incoming PRI calls must be routed through the Master LSC. The system planners can follow the steps described previously to size the capacity requirements for the slave LSCs. There is no subscriber provisioned on the Master LSC. The Master LSC processes all inter- enclave IMs and calls to/from the Slave LSCs, the incoming PRI calls for all the subtending Slave LSC subscribers, and the DSN/PSTN MAS and transit calls. To calculate the Master LSC transaction processing demand, the system planners need to estimate the following traffic parameters: • % of Inter-enclave traffic • CallsPerBusyHourPerLSCSubscriber • % of PRI Call
94 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
• % of Incoming PRI traffic to LSC Subscribers • IMsPerBusyHourPerLSCSubscriber • TotalSupportedLSCSubscribers • TotalSupportedDSN/PSTNSubscribers • CallsPerBusyHourPerDSN/PSTNSubscriber • %ofLSCSubscriberCall MasterLSCTransactionsProcessingCost = SIP Call Inter-enclave Message Processing Cost + IM Inter-enclave Message Processing Cost + DSN/PSTN to LSC Subscriber Incoming PRI Call Processing Cost + MAS&TransitDSN/PSTNTransactionProcessingCost = (SIPCallTransactionCost x CallsPerBusyHourPerLSCSubscriber + IMTransactionCost x IMPerBusyHourPerLSCSubscriber) x % of Inter-enclave traffic x TotalSubscribersPerSystem + SIP-PSTNcallTransactionCost x CallsPerBusyHourPerSubscriber x % of PRI x % of Incoming PRI traffic to LSC Subscribers + SIP-PSTNcallTransactionCost x CallsPerBusyHourPerDSN/PSTNSubscriber x (1 - %ofLSCSubscriberCall) x TotalSupportedDSN/PSTNSubscribers Depending on the sites, there should be 20 to 40% of server capacity reserved for handling traffic surges. Hence, the value of “MasterLSCTransactionsProcessingCost” should not exceed the maximum LSC weighted capacity minus the reserved capacity.
SS SESM engineering (DoD Only)
Application Server 5300 implements the DoD ARTS architecture based on a two-tier hierarchical LSC and SS routing model. Each Master LSC is associated with one serving SS. All inter-enclave traffic traverses the Master LSC and its serving SS. A secondary SS, if exists, can be configured to backup the primary SS when it is down or unreachable. The PRI gateways must be configured to route calls to a local SS and it does not matter which one if there are multiple SSes. The SS AS 5300 Session Managers do not directly host local subscribers. Rather, it performs the routing functions for the local, remote, and backup LSC sites, the local PRI gateways, and the MFS TDM switches. SSTransactionsProcessingCost = ∑ (MasterLSCTransactionsProcessingCosti – DSN/PSTN MAS services Call Processing Costi) + ∑ (Backup LSC Sites MasterLSCTransactionsProcessingCosti - DSN/PSTN MAS Services Call Processing Costi) + PRI Call Processing Cost + MFS Call Processing Cost The steps for calculating “SSTransactionsProcessingCost“ have been discussed earlier and will not be repeated here. The equation excludes the processing cost of DSN/PSTN MAS Service Call from each LSC site because the MAS calls are not forwarded to SS for processing. Note that the equation has included the costs of the backup sites in the calculation. The figure (Figure 46: SS SESM processing on page 96) shows the SS SESM 1 is configured as the
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 95 System capacity planning
backup/secondary SS SESM for LSC sites m+1 to n and the SS SESM 2 is the backup SS for LSC sites 1 to m. The system planners should reserve 20 to 40% of server capacity for handling busty traffic.
Figure 46: SS SESM processing Finally, the engineering of non-SESM Application Server 5300 SIP core component is relatively straight forward. The engineering rules of the non-AS 5300 Session Manager components are summarized below: • AS 5300 System Manager (SM): Only one pair of active/standby AS 5300 System Managers is required for a system. The embedded FPM supports up to 50 Network Elements. • Database Manager (DB): there can be only one pair of active/standby Database Managers per system • Accounting Manager (AM): one active Accounting Manager can support up to four active AS 5300 Session Managers. Additional pair of AMs can be added when needed. • Fault Performance Manager (FPM): Additional pair of FPMs can be added when needed. • Provisioning Manager (PROV): Only one pair of active/active Provisioning Managers is required for a system • Personal Agent Manager (PA): Only one pair of active/active Personal Agent Managers is required for a system initially. Additional PAs can be added when needed.
Understanding Presence impact on system capacity
Automatic presence state changes do not require a conscious effort by the subscriber to modify their state. Presence updates can cause significant network traffic and transaction stress for
96 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
the AS 5300 Session Manager. From the previous example, roughly 60% of the AS 5300 Session Manager resource is consumed by supporting presence services. The continuous updates as a result of autopresence to a large group of friends are very expensive to the system. As shown in Figure 47: SIP Notify message processing model on page 97, the costs of processing SIP Notify messages increases rapidly as the number of friends increases.
Figure 47: SIP Notify message processing model
All other things being constant, the maximum number of subscribers supported with autopresence activated decreases with a corresponding increase in the number of friends allowed per subscriber (see vertical lines in the chart). To allow sufficient system resources for call processing, the system planners need to carefully manage the assignment of presence services and the size of the buddy list for subscribers.
Erlang
We will start to explain the Erlang concept because understanding it is important for the subsequent capacity planning for the MAS and PRI gateway servers. An Erlang is a unit measurement of traffic intensity representing the occupation of one voice circuit (or port) during a busy hour. For example, if a subscriber made 6 calls in one hour, and each call has average call duration of 3 minutes, then the traffic produced by the subscriber is 0.3 Erlang (that is, 180 sec * 6 calls / 3600 sec). Similarly, the traffic for 1000 subscribers is 300 Erlang (that is, 1000 * 0.3 Erlang/ subscriber). In a PSTN/PBX network, the service planners calculate the anticipated Erlang traffic intensity to engineer the circuits required for handling the subscriber’s voice calls. Erlang B is the most commonly used traffic model. It is used to calculate how many lines are required for a given traffic intensity represented in Erlang. For example, using an Erlang B calculator (http://
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 97 System capacity planning
personal.telefonica.terra.es/web/vr/erlang/eng/cerlangb.htm), one can calculate the total number of circuits required to support 300 Erlang is 324.
Figure 48: Circuit planning for gateway circuits
Using the service profile developed previously, the Application Server 5300 system planners can calculate the Erlang traffic and use it to size the capacity of MAS and PRI gateway (Figure 48: Circuit planning for gateway circuits on page 98).
MAS capacity planning
The Media Application Server (MAS) is a generic media processing platform designed to use commercial hardware platforms and common operating systems without the presence of hardware-based DSP resources. The system exploits the advantages of multimedia protocols and the IP environment to achieve respectable performance comparable to more expensive DSP-based TDM solutions. The software-only approach to media processing is the natural evolution of existing TDM centric voice processing platforms as multimedia and data networks continue to converge. The MAS is an optional network element for Application Server 5300 deployment but is required to provide network services such as Call transfer, Meet Me Conferencing, Ad hoc Conferencing, Unified Communications, Music on Hold (MoH), and Announcements. Application Server 5300 supports both standalone and combo configurations for MAS services. There are two types of MAS combo configurations: the first type of combo configuration (Type 1) supports all services on the same server and the second type of configuration (Type 2) supports the Meet Me service on its own dedicated server and all other services on the second server. For the new systems, Application Server 5300 supports only the IBM x3550 M2 servers for MAS services. To engineer the MAS service capacity, the planners compute the service traffic loads for each supported MAS service (for example, Ad hoc, Meet Me). After the traffic loads are known, the planners can calculate the required MAS servers. The objective is to find the required number of servers to handle the MAS services. We will use the previous example to show how to size a Meet Me service. In this exercise, we assume the average meeting time is 30 minutes. Based on Table 17: Subscriber Usage values on page 85, we can calculate the traffic load for the Meet Me service as follows:
98 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
Meet Me traffic load (Erlang) = TransactionsFromMeetMeCalls x Meeting time / 3600 Meet Me traffic load (Erlang) = (3000 x 0.05 x 5 x 0.1 x 6) x1800 / 3600 = 225 Assuming the blocking factor is 1%, using the Erlang B calculator the required MAS Meet Me port per busy hour is 247. Assuming one MAS server can support 600 ports, we will need one MAS server to support the Meet Me calls.
Figure 49: Meet Me traffic load
Using a similar method, the planners can compute the traffic loads for Ad hoc, Music on Hold, Announcement, and Unified Communication services. As an example, based on the MAS service profile described in Step 6: Subscriber services planning on page 74, one can calculate the number of port required for each of the MAS services for different subscriber population distribution. The services are over-engineered, given the unpredictable usage patterns The results are summarized in the following table. Table 19: MAS services port engineering example
Sub- Meet Me Meet Me Ad hoc Ad hoc Ann/ Ann/ MoH UC scriber Audio Video Audio Video Tone w/ Tone w/ o MLPP MLPP 1000 242 24 37 6 4 8 8 11 2000 462 36 64 9 5 10 10 17 3000 681 48 92 12 5 14 11 22 4000 898 60 118 15 5 16 14 28 5000 1115 72 145 18 6 18 16 33 10000 2195 132 272 24 8 29 26 59 20000 4344 246 524 42 11 51 44 106 25000 5417 300 649 48 12 60 52 129
By summing the number of ports of required for these services, the planners can calculate the required servers for supporting all services. For example, for the redundant configuration, the system planners need one pair of Type 2 Meet Me servers and one pair of Type 2 Ann/Adhoc/ UC/MoH Combo server to support 3 000 subscribers.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 99 System capacity planning
The Ad-hoc and Meet Me Audio and Video Conferencing services have no built-in limitations on how many simultaneous conferences can exist on the system. The maximum number of participants in a single conference is limited only by the number of channel licenses purchased for a given server and/or the capacity of the server, which may vary based upon factors such as hardware and operating system. Conferences have no explicit guaranteed minimum or maximum port limits. Ports are allocated on a first-come, first-served basis until the license keys for a server are exhausted or the available capacity is exceeded. Application Server 5300 MAS services can be scaled from a small single-machine combo solution to a large standalone multi-machine cluster. To meet increasing capacity requirements, the system planners can either add new servers to an existing pool forming a pool of MAS service instances or to create multiple pools for the services with each pool consisting of one or more MAS servers. For the Meet Me service, there can be eight service instances added in a pool. For the UC, MoH, and Announcement/Tone services, up to two service instances for each service type can be added in a pool. For the Ad-hoc service, there is no limit on the number of service instances added in a pool. Application Server 5300 supports IM Chat service for Non-DoD deployments that do not use MLPP. For the current release, the simplex architecture with only one server running the IM Chat service for a root domain is supported. Multiple root domains may use a common MAS server. With SIP-TLS, all chat messages are proxied through the SESM. Depending on the volume of messages, the IM Chat service can have significant performance impact on SESM because the chat service will generate N-1 messages for each message it receives; where N is the number of participants in a chat room. Systems that use IM Chat may require an additional, non-redundant MAS server to support chat traffic. More MAS Services Capacity, Scaling, and Configuration information can be found in Avaya Media Application Server Planning and Engineering, NN44474-200.
Voice mail server capacity
When the MAS server is used only for Unified Communications, use the following calculation to estimate the disk space available for voice messages, in gigabytes (GB). Available GB of disk space = (LS – S) / (1+0.74*N) Where: • LS is the sum of the sizes of the MAS server logical disks, in GB • N is the number of MAS backup files stored on the MAS server. This value must be 1 or higher. • 0.74 is the backup scaling factor • S is the disk space used by static content. This value must be either 26 GB (if LS < 200 GB)) or 53 GB (if LS >= 200 GB)
100 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
Each GB of available disk space can store 36.41 hours of voice messages, using the G.711 codec. The following table shows examples of voice mail capacity. Table 20: Voice mail server capacity examples
LS (Logical size of N (Number of MAS Available GB of disk Number of hours the disk, in GB) server backups) space that can be recorded, using the G.711 codec 73 1 27.01 983 146 1 68.97 2 511 300 1 141.95 5 168 600 1 314.37 11 446 73 2 18.95 690 146 2 48.,39 1 762 300 2 99.60 3 626 600 2 220.56 8 031
Media gateway capacity planning
The AudioCodes Mediant Gateway is a SIP-based Voice-over-IP (VoIP) media gateway offering integrated voice gateway functionality over IP networks. Application Server 5300 uses the AudioCodes PRI gateways for interworking with the PSTN/PBX networks (Figure 50: PRI Gateway for PSTN/PBX communications on page 102).
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 101 System capacity planning
Figure 50: PRI Gateway for PSTN/PBX communications
The MG1000 supports multiples of 1, 2, or 4 T1 spans and the MG3000 supports 8, 12, 16, 21, 42, and 84 T1 spans configurations for connecting the PSTN/PBX to the IP network. To properly engineer the gateway capacity, the planners compute the traffic intensity for the PSTN/ PBX traffic loads. After getting the traffic intensity value, the planners can calculate the required circuits or ports. The objective is to find the required number of T1 circuit for handling the PSTN/ PBX traffic. We will use the previous example to illustrate engineering the gateway capacity. Based on Table 17: Subscriber Usage values on page 85, there are 15% PSTN/TDM calls. One can calculate the traffic intensity for the gateway as follow: Gateway PSTN/PBX call traffic load (Erlang) = TransactionsFromGatewayCalls x Avg. Call Hold Time / 3600 Assuming the average call hold time is 180 seconds, Gateway PSTN/PBX call traffic load (Erlang) = (3000 x 5 x 0.15 x 180) / 3600 = 112.5 Assuming the incoming call volume fro the PSTN/PBX network is the same as the outgoing call volume, the total traffic intensity for the gateway is 225 (that is, 2 x 112.5) Erlang. To make it more interesting, we further assume 50% of conference callers are from the PSTN/ PBX network. Therefore the traffic intensity as result of Meet Me conference calls is MG3000 Meet Me call traffic load (Erlang) = (3000 x 0.05 x 5 x 0.1) x 3 x 1800 / 3600 = 112.5 Erlang Summing the inbound/outbound Gateway PSTN/PBX call traffic load (Erlang) and Meet Me call traffic load (Erlang), the Total traffic intensity is 337.5 Erlang.
102 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] System capacity engineering
Assuming the blocking factor is 1%, using the Erlang B calculator the required circuits are 362.
Figure 51: Media Gateway traffic load
Using the calling profile described in Step 6: Subscriber services planning on page 74, one can calculate the number of circuits required for gateway supporting various services for different subscriber population distribution. The results are summarized in the following table. Table 21: Gateway circuits engineering example
Subscriber PSTN/PBX Meet Me Ad hoc Announce MoH UC Total 1000 42 48 9 3 3 4 109 2000 75 88 14 4 3 4 188 3000 107 126 18 4 4 5 264 4000 138 163 22 4 4 6 337 5000 170 201 26 4 5 6 412 10000 324 385 46 6 6 9 776 20000 628 748 83 8 8 14 1489 25000 779 929 101 9 9 16 1843
Depending on the sites, the system planners should apply 10-20% over engineering factor to handle bursty traffic. After applying 10% over engineering factor on the “Total” circuit column, the system planners can determine, for example, that a site needs 20 T1 spans to handle the traffic loads generated by 5000 subscribers. With this requirement, the system planners can determine to choose either using one MG3000 21 span gateway or using more reliable two MG3000 12 span gateways solution for the site.
Media gateway V.150.1 traffic planning
The MG3000 gateway supports V.150.1 protocol for secure conversation with the Secure Terminal Equipment (STE) phones used in DoD environment. The following table provides the
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 103 System capacity planning
V.150.1 port capacity of various MG3000 configurations. As shown in the table, only the type B spans support V.150.1 protocol. Table 22: MG3000 V.150 port
Configuration Max B Channel Max V.150.1 Channel 84 Span-A 1932 0 42 Span-A 966 0 42 Span-B 966 264 21 Span-A 483 0 16 Span-A 368 0 16 Span-B 368 96 12 Span-A 276 0 12 Span-B 276 96 8 Span-A 184 0 8 Span-B 184 96 4 Span-B 92 96 1 OC3-A 1998 0 1 OC3-B 942 264
To determine the correct configuration a specific application, the system planners must determine the maximum V.150.1 ports must be supported for the system. This is done by estimating the percentage of PSTN/PBX V.150.1 traffic through MG3000. For example, the planner could assume that 10% of (say 25 000) subscriber communicates with STE devices using MG3000. Using Table 21: Gateway circuits engineering example on page 103, the planner can calculate that 78 (10% of 779) V.150.1 ports must be supported. Using Table 22: MG3000 V.150 port on page 104, the planner can calculate that 78 (10% of 779) V.150.1 ports must be supported. Using MG3000 V.150 port, the planner can then determine one 4-Spans B (supporting 96 V.150.1 port) is required to support the secure V.150.1 communication. Finally, it is clear from the previous discussions that detailed system capacity engineering is a very complex process and should be done by professionals with good understanding of the system architecture and subscriber applications. The discussions and illustrations contained in this chapter are not intended to replace a rigorous engineering process, but are provided as a starting point for the understanding of the system engineering process.
104 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Chapter 8: Application Server 5300 IP service network planning
Typically, IP networks provide only best-effort packets delivery which is unsuitable for supporting real-time services which require packet delivery to be time bounded. Application Server 5300 support a range of voice and video services over IP networks. However, IP networks introduce impairments higher level than traditional voice networks. Therefore, it is essential that the target IP network infrastructure be carefully planned and evaluated to ensure that the network quality is suitable for deploying Application Server 5300 services. In this chapter, we will first describe the VoIP QoS (Quality of Services) performance parameters and their requirements for a real-time IP service network. We will then provide recommendations for planning and engineering Application Server 5300 real-time services in an enterprise reference network. For DoD deployments, the Defense Information Systems Network (DISN) DoD Assured Services Converged Local Area Network Generic System Requirements (ASCLAN GSR ) and Real Time Services (RTS) Requirements specify the requirements for IP networks that transport of IP signaling and media (voice and video) traffic. Note that the term “Assured service” does not mean 100 percent service 100 percent of the time. Rather, it means that all functions required for service will be holistically managed to ensure the most critical users and services receive the highest priority. The DoD Real Time Services include Interactive Voice (for example, IP telephony), Interactive Video (for example, Video conferencing between N users), Streaming Video (for example live video from a surveillance system), Command and Telemetry (for example the control information from a Predator that is used to command it and determine it location, altitude, and heading, Circuit Emulation (a closed IP path that is used to packetize serial data streams for transmission across an IP WAN). These requirements will be referenced throughout this chapter when applicable. Navigation
• VoIP anatomy on page 106 • IP QoS parameters on page 107 • Assessing voice quality on page 119 • IP network planning on page 124 • QoS recommendations on page 145 • Application Server 5300 QoS support on page 152 • IP addressing and routing recommendations on page 160 • IP network services requirements on page 163
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 105 Application Server 5300 IP service network planning
VoIP anatomy
Voice undergoes a number of transformations when traveling through an IP network from the talker's mouth to the listener's ear. An example (Figure 52: VoIP anatomy on page 106) is used to illustrate the steps involved in transmitting a simple call from an IP phone to a TDM phone through a PRI gateway. In the diagram, a caller’s voice is encoded by an A/D (analog- to-digital) converter into a synchronous digital bit stream (eight-bit G.711 64 kb/s). The bit stream passes through an Echo Canceller (ECAN) and optionally through the encoder of a low bit-rate codec. The output of the encoder (or the G.711 bits, if no compression codec is used) is packetized by adding the necessary L2 and L3 headers and stored in the outgoing packet buffer.
Figure 52: VoIP anatomy
The packets are sent across an IP network to a PRI gateway. The gateway stores the packets in the jitter buffer. The data must be fed to the decoder at a constant rate. Variation in packet arrival times is smoothed out by the jitter buffer, which applies a short delay to the data to ensure that a steady stream of data can be sent to the decoder. Packets are decoded into a synchronous stream. The output of this process is handed over to the TDM network. The TDM network converts the bit stream back to an analog signal and sends it over the local line to a TDM telephone. The echo canceller shown is a network canceller which is essential at the interface between an IP network and a TDM network where analog access lines may be in use. A loss pad at the output may be needed to match the loss plan of the packet network to that of the TDM network. Two optional advanced features are included in the diagram. Speech Activity Detection (SAD) provides a silence suppression function, which detects silence in the speech and sends only data containing speech to the network. Packet Loss Concealment (PLC) can smooth over the gaps caused by any missing data packets.
106 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP QoS parameters
IP QoS parameters
As described previously, VoIP introduces many intermediate steps into a voice conversation, which can potentially degrade the voice quality. In this section, we will examine the following QoS parameters (Figure 53: VoIP QoS parameters on page 107) that can impact a system’s usability: • Delay on page 107 • Jitter on page 111 • Packet loss on page 112 • Codec on page 114 • Echo on page 116
Figure 53: VoIP QoS parameters
Delay
Delay (or latency), in the context of VoIP, is defined as the amount of time it takes for a packet to travel from the speaker’s mouth to the listener’s ear. The factors that impact delay includes DSP processing, packetization, propagation, queuing, routing/switching, jitter buffering, and TDM switching and transmission (Figure 54: VoIP delay factors on page 108). End-to-end delay is the total of all delays in the voice path.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 107 Application Server 5300 IP service network planning
Figure 54: VoIP delay factors
DSP processing and packetization delay is the result of time taken for speech to accumulate so that it can be put into a packet, loaded, and transmitted. Where speech compression is used, the time needed for coding is added as well. Serialization delay is determined by the channel speed (bits/sec) and the number of bits in the packet. On high speed links, serialization delay becomes negligible. Queuing delay is the latency accumulated at the input/output buffers of various network nodes (that is, routers and switches) across the network. Congestion can increase packet waiting times in buffers. Propagation delay is the time taken for the signal to travel through a transport medium (for example, cable, fiber or wireless). These delay factors can be either fixed or variable types of delay. Fixed delay types include coder-processing at source and destination (G.711, G.729, G.723), packetization at the source (depending on the voice packet size and compression algorithm used), and propagation delay (depending on the link speed and distance traversed, Table 23: ITU G.114 propagation delay on page 108). Types of variable delays include queuing delay (ingress, backbone, egress), nodal processing delay (from inbound queue to outbound queue), and jitter buffer delay. The total end-to-end delay would be equal to the fixed delay plus the variable delay. Table 23: ITU G.114 propagation delay
Transmission or One-way transmission time Remarks processing system Terrestrial coaxial cable or 4 µs/km Allows for delay in repeaters radio-relay system: FDM and and regenerators digital transmission Optical fiber cable system, 5 µs/km digital transmission Submarine coaxial cable 6 µs/km system Submarine optical fiber Worst case • 13 ms system: • 10 ms
108 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP QoS parameters
Transmission or One-way transmission time Remarks processing system
• transmit terminal • receive terminal
Satellite system: Propagation through space • 12 ms only (between earth stations) • 400 km altitude • 110 ms • 14 000 km altitude • 260 ms • 36 000 km altitude
FDM channel modulator or 0.75 ms demodulator Public Land Mobile System 80–110 ms (PLMS) • objective 40ms
Delay can introduce issues with voice transport such as breaking the dynamics of a conversation (talk and back off at the same time in a conversation), and degrading the quality of the conversation (introduce reluctance in a positive response, echoes). Figure 55: Delay impact on voice quality on page 110 shows a scaled graph of user satisfaction against one- way delay. When one-way delay exceeds 150ms mouth to ear, the voice quality is dropped into the “satisfactory” region from the “very satisfactory” region, and if one-way delay exceeds 250ms mouth to ear, the voice quality becomes dissatisfactory for some users. Delay can also contribute to echo impairment when the total delay becomes sufficiently high. ITU Rec. G.114 provides guidance on the range of delay for acceptable service quality. G.114 suggests that delay be kept below about 250 ms to avoid noticeable impairment; this will provide essentially transparent interactivity for voice and multimedia applications where conversational voice is a component.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 109 Application Server 5300 IP service network planning
Figure 55: Delay impact on voice quality • For DoD Deployments, the Defense Information Systems Network (DISN) DoD Assured Services Converged Local Area Network Generic System Requirements (ASCLAN GSR ) and Real Time Services (RTS) Requirements specify the following delay requirements for transporting of signaling and media (voice and video) traffic over IP networks. The ASCLAN transports voice IP packets, media and signaling, with no more than 6 ms (2 ms [access device] + 2ms [distribution device] + 2ms [core device]) latency and transports video IP packets with no more than 30 ms latency across the ASCLAN as measured over any 5-minute period under congested conditions. Latency is increased over voice IP packets because of the the larger size video packets. Congested condition is defined as 100 percent of link capacity. • The End-to-End Network System (Figure 68: Application Server 5300 DoD reference network on page 128) supporting RTS shall ensure that the one-way end-to-end network latency (handset to handset) for Fixed-Fixed locations is 220 milliseconds (ms) or less for RTS sessions between theaters (Intertheater) and 150 ms or less for RTS sessions within a theater (intratheater) as averaged over any 5-minute period. • The Edge System supporting RTS shall ensure that the one-way latency from the IP handset to the CE-R within the Edge Segment is 35 ms or less (44 ms or less if the CE- R is collocated with a PE-R) for RTS sessions as averaged over any five minute or period. • The WAN System supporting RTS shall ensure that the one-way latency from the PE-R to PE-R (Provider Edge Router) across the WAN for F-F nodes is 130 ms or less for RTS sessions between theaters (Inter-theater) and is 60 ms or less for RTS sessions within a theater (Intra-theater) as averaged over any five minute period. • The WAN System supporting RTS shall ensure that the one-way latency from the CE-R to CE-R across the WAN for F-F nodes is 150 ms or less (132 ms or less if the CE-R is collocated with a PE-R) for RTS sessions between theaters (Inter-theater) and is 80 ms or less (62 ms or less if the CE-R is collocated with a PE-R) for RTS sessions within a theater (Intra-theater) as averaged over any five minute period. • The End-to-End Network System supporting RTS shall be engineered for a one-way end- to-end latency (handset to handset) for F-T and T-T (Tactical-Tactical) locations of 300
110 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP QoS parameters
ms or less for RTS sessions between theaters (Inter-theater) or within theaters (Intra- theater) as averaged over any five minute period. • It is assumed that the serialization and switching delay increases associated with larger IPv6 packets in comparison to IPv4 packets is insignificant and that the latency calculations are the same for IPv4 and IPv6 implementations.
Jitter
Variation in delay, caused by differences in the time taken for packets to traverse a network, is called jitter. Jitter is caused by packets being queued in various shared resources (for example, links, switches, gateways) along the transmission path, and is hard to predict. Jitter can have a serious effect on a user’s access network upstream connection which often has less bandwidth. With increasing data traffic, the probability of a large data packet being put onto the wire increases. A voice packet must wait until the serialization of the current data packet is complete before it can be sent. The slower the link, the more jitter occurs. Removing jitter requires collecting packets and holding them at the buffer of the receiving device so that they can be played with correct order and spacing (Figure 56: Jitter buffer for transmission rate adaptation on page 111). The jitter buffer adds extra delay to the audio stream. A jitter buffer is usually on the order of a few tens of milliseconds long. It is designed to provide a “resynchronization” of the far end audio stream with the local audio device. Excessive jitter in a media stream can exceed a media endpoint’s maximum jitter buffer size. When this occurs, the packets exceeding the jitter tolerance of the endpoint are discarded. These discarded packets impact the end user experience the same as when packet loss occurs. The end user will experience “choppy” voice or video. Network jitter must be kept within bounds to maintain service quality.
Figure 56: Jitter buffer for transmission rate adaptation
Depending upon the endpoint, a jitter buffer size may be fixed, provisionable, or adaptive. A provisionable jitter buffer allows the selection of a buffer size that matches the amount of jitter that could be experienced in the network. An adaptive buffer can dynamically adjust buffer size based on the network delay.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 111 Application Server 5300 IP service network planning
For DoD deployments, the jitter requirements are: • The ASCLAN transports voice IP packets end-to-end with no more than 6 ms of jitter and to transport video IP packets end-to-end with no more than 30 ms of jitter over any 5- minute measured period under congested conditions. • The End-to-End Network System supporting RTS shall ensure that the end-to-end network jitter (handset to handset) for F-F locations is 30 milliseconds (ms) or less for RTS sessions between theaters (Inter-theater) and 25 ms or less for RTS sessions within a theater (Intra-theater) as averaged over any 5-minute period. • The WAN System supporting RTS shall ensure that the jitter from the PE-R to PE- across the WAN for F-F nodes is 10 ms or less for RTS sessions between theaters (Intertheater) and 5 ms or less for RTS sessions within a theater (Intratheater) as averaged over any five minute period. • The WAN System supporting RTS shall ensure that the jitter from the CE-R to CE-R across the WAN for F-F nodes is 20 ms or less (10 ms or less if the CE-R is collocated with a PE-R) for RTS sessions between theaters (Intertheater) and 15 ms or less (5 ms or less if the CE-R is collocated with a PE-R) for RTS sessions within a theater (Intratheater) as averaged over any five minute period. • The Edge System supporting RTS shall ensure that the one-way jitter between handset and CE-R within the Edge Segment is 5 ms or less (10 ms or less if the CE-R is collocated with a PE-R) for RTS sessions as averaged over any five minute period.
Packet loss
Packet loss can occur due to errors introduced by the physical transmission medium, and can also occur when congested network nodes drop packets. Over an Ethernet segment, one common problem contributing to packet loss is Ethernet duplex mismatch. An Ethernet duplex mismatch condition occurs when two endpoints for a given link do not agree on a duplex mode of operation—one device operates in full duplex while the other operates in half duplex. The problem is the device that is operating in full duplex mode is not detecting packet collisions nor is it capable of retransmitting the packet when a collision has occurred. Thus, the packet is lost.
112 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP QoS parameters
Figure 57: Packet loss impact on voice quality
Most observed packet loss is bursty in nature, that is, experiencing occasional long losses, rather than random or frequent short losses. Some factors that may contribute to bursty packet losses are: network routing convergence, lower level topology restoration, improperly designed network, and inadequate provisioned bandwidth. Modeling establishes that as networks approach 90% utilization there are more congestion losses, which tends to be bursty. Packet loss degrades voice quality. It creates gaps and causes clicks in the speech. Packet Loss Concealment (PLC) improves voice quality by removing noises created by packet loss (Figure 57: Packet loss impact on voice quality on page 113). Techniques range from simply by repeating previous frames to very complex methods that can restore the quality to almost the equivalent of the original speech. However, even the best techniques can not repair speech gaps of more than about 60–80 ms. When a burst of lost packets exceeds this range, the PLC will mute the output, which can result in temporal clipping and missing words. IP Telephony requires supporting voice band data (analog FAX and modem) calls which are particularly susceptible to packet loss. The PLC techniques are ineffective at repairing voice band data signals. Packet loss rates between 10–6 and 10–3 show increasing impairment to voice band data performance. For FAX, packet loss is generally resulted in a failed FAX handshake. Modem calls can have similar setup difficulties, and may be subject to reduced data rate or call drop during data transfer. For DoD Deployments, the packet loss requirements are: • The ASCLAN can transport voice IP packets end-to-end with no more than 0.03% packet loss over any 5-minute measured period under congested conditions. The ASCLAN can transport video IP packets end-to-end with no more than 0.05 % packet loss and a bit
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 113 Application Server 5300 IP service network planning
error rate of no more than 3 bit errors in 106 bits over any 5-minute measured period under congested conditions. • The End-to-End Network System supporting RTS shall ensure that the end-to-end packet loss (handset to handset) for F-F locations is 0.5% or less for RTS sessions as averaged over any 5-minute period. • The WAN System supporting RTS shall ensure that the one-way packet loss from the PE- R to PE-R across the WAN for F-F nodes is 0.03% or less for RTS sessions between theaters (Intertheater) and 0.01% or less for RTS sessions within a theater (Intratheater) as averaged over any five minute period. • The WAN System supporting RTS shall ensure that the packet loss from the CE-R to CE- R across the WAN for F-F nodes is 0.4% or less (0.03% or less if the CE-R is collocated with a PE-R) for RTS sessions between theaters (Intertheater) and 0.4% or less (0.01% or less if the CE-R is collocated with a PE-R) for RTS sessions within a theater (Intratheater)as averaged over any five minute period. • The Edge System supporting RTS shall ensure that the one-way packet loss between the handset and CE-R is 0.05 % or less for RTS sessions as averaged over any five minute period.
Codec
Codecs use sophisticated algorithms to compress and convert voice to digital data to minimize bandwidth requirements (Table 24: ITU G.114 Codecs on page 114). Some codecs are more tolerant to delays and packet loss than other, but require greater bandwidth. G.711 and G.726 are waveform-based codecs. They do not use frames in processing. The main source of delay with these codecs is to collect digital samples for the payload. These codecs do not have built- in packet loss concealment and silence suppression functions, which have to be added externally when needed. Avaya recommends that packet loss concealment is used in conjunction with waveform codecs. Both G.723.1 and G.729/G.729A are frame-based codecs. G.729 uses a 10-ms frame and G.723.1 uses a 30-ms frame. Both have built-in packet loss concealment function. The G.723.1 baseline voice quality and the large codec processing delay makes it inadequate for VoIP applications. G.729 has generally overtaken G.723.1 as the codec of choice where compression is needed. Table 24: ITU G.114 Codecs
Encoding/Compression Bit rate Frame size Look Quality Algorithm ahead ITU G.711 — PCM (Pulse Code 64 Kbps NA 0 toll quality Modulation, u-law, a-law) ITU G.726 ADPCM (Adaptive 40, 32, 24, NA 0 very good Differential PCM) 16 kbps
114 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP QoS parameters
Encoding/Compression Bit rate Frame size Look Quality Algorithm ahead ITU G.723.1 - ACELP (Algebraic 5.3 kbps 30 ms 7.5 ms good Code-Excited Linear Prediction) ITU G.723.2 - MP-MLQ 6.3 kbps 20 ms 7.5 ms good (Multipulse Maximum Likelihood Quantization) ITU G.729 - CS-ACELP 8 kbps 10 ms 5 ms very good (Conjugate Structure Algebraic Code Excited Linear Prediction) ITU G.729a - CS-ACELP Annex 8 kbps 10 ms 7 ms very good A (low complexity)
A codec processing delay consists of sampling delay, look-ahead delay, and processing delay (Figure 58: G.729 codec processing delay on page 115). The sampling delay is the time required to collect a voice sample (for example, a 10 ms G.729 frame) to be processed by the voice codec. The look-ahead delay, applicable only to non-waveform-based processing algorithms, is introduced into the processing when looking into a portion of the next frame to guide the compressing analysis of the current frame. Finally the processing delay includes the process of first encoding/compressing and then packetizing the samples into a packet which varies depending on the DSP processing power and the complexity of the algorithm. The processing delay for G.711 is very small (that is, about 2 msec).
Figure 58: G.729 codec processing delay
When multiple frames per packet are used, the packetization delay will increase according to the number of frames that must be collected. Figure 58: G.729 codec processing delay on page 115 shows the total delay for packaging two 10 msec G.729 frames into a single IP packet. The calculation assumes the processing delay is 10 ms for a G.729 codec. Different codecs use different bit rates, which affect the bandwidth required for calls. The choices for codecs should be made by considering both the overall network capacity and the
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 115 Application Server 5300 IP service network planning
desired voice quality of the VoIP networks. It is possible to compromise between the choice of a codec (therefore bandwidth) and the end-to-end delay budget, and still getting acceptable overall voice quality. As shown in Figure 59: Codec choice versus delay tolerance on page 116, a G.729A codec with 130 ms delay achieves the same satisfactory quality as a G.711 codec with 250 ms delay. Avaya recommends that G.711 (A-law) be included as an available codec to ensure interoperability when other preferred codecs are not supported by both terminals. The DISN RTS preferred codec used for end-to-end fixed-to-fixed voice sessions is G.711 Pulse-Code Modulation (PCM) codec (Uncompressed) with 20 ms samples.
Figure 59: Codec choice versus delay tolerance
Echo
Echo is a distorted and attenuated version of the taker's transmission. With echo on a line, a talker can hear a delayed version of his own voice. Echo is an undesirable phenomenon because it distracts the talker in the conversation. Echo is caused by coupling between the send and receive paths. This coupling can happen in the acoustic signal (hands-free phone, headset), electrically in the terminal (cross talk in the curly cord or in the audio circuit), or electrically in the analog portion of the TDM network (two-to-four-wire hybrids). Typically, hybrids are the main source of echo in TDM networks (Figure 60: Echo signal on page 117).
116 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP QoS parameters
Figure 60: Echo signal
The network delay is another important factor that impacts the effect of echo. The reflected signal is not a problem when the delay is small. However, when the network round-trip delay exceeds 30 ms, the voice quality degradation as result of echo becomes noticeable. As the delay increases, the quality of the transmission becomes worse. As shown in Figure 61: Echo impairment versus delay on page 118 (based on ITU-T G.131), the green area shrinks as the delay increases. In the figure, the distances of local, short haul, long haul, and international are 100 km, 2 800 km, 5 000 km, and 14 000 km respectively. Due to the delays associated with the codec processing and jitter buffering, VoIP networks tend to have longer delays compared with traditional PSTN networks. With the long delay, any level of echo could become increasingly audible over a VoIP network. Because of the increased delay compared to circuit-switched networks, echo control is essential for IP networks. The echo amplitude level is characterized as a signal loss because it is lower than the original signal, that is, the reduction in loudness relative to the sent signal. This loss is referred to as the Talker Echo Loudness Rating (TELR) which is represented in decibel (dB). DB is a unit of logarithmic measurement of relative strength between two signals representing power gain or loss (dB = 10 * log (power A / power B). TELR represents the listening level of an echo after it returns to the talker. The dB values tell how much softer the echo is than the original signal. In the extent of echo control, the magnitude of TELR also indicates whether the echo is under control.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 117 Application Server 5300 IP service network planning
Figure 61: Echo impairment versus delay
There are two basic techniques for eliminating echoes in long distance connections: echo suppression and echo cancellation. Echo Suppressor suppresses echo by allowing conversations to proceed in only one direction at a time (that is, half-duplex operation). It does this by inserting a large loss into the transmission path when it detects a signal on the receive path. Echo suppressors, while reducing echo, impair the quality of the speech. For this reason, they have been replaced by Echo Cancellers. Echo Cancellers (ECAN) tracks the forward voice signal and the returning echo and builds an adaptive filter matching the echo characteristics. The filter is used to create a matching echo and is subtracted from the returning signal to remove the echo. Unlike Echo Suppressors, they allow full duplex operation and the attenuators that diminish the volume of the received signal are not needed in the transmission path. The process of developing a model of the echo and then using it in a subtractive estimation process is called “convergence”. In packet networks, convergence is an ongoing adaptive process because delay may change from packet to packet due to nodal buffering and routing changes. It is therefore important that the echo canceller converges quickly on the new delay to minimize interference with the conversation. G.165 defines that the convergence time shall be no longer than 500ms for a white noise test signal. In practice though, real speech signals can take up to 10 times this amount for the Echo Canceller to converge. The effect of this is for echo to be heard during the first few seconds of a conversation.
118 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Assessing voice quality
Figure 62: Gateway echo cancellation Location of the ECAN requires closeness to the far end echo source to avoid the delay introduced by the VoIP network. When engineering an integrated IP-TDM network for voice, one must consider the location of TDM echo sources and the longest delay in the IP networks. For calls between an IP phone and a traditional PSTN phone, the echo control applied in the traditional network may not be sufficient. The VoIP-TDM gateway ECAN must cancel echoes that are originated but not completely cancelled by the ECAN in the TDM network. These will be calls that have delays up to the point where the TDM network puts cancellers on the trunks. An ECAN with sufficient echo control (that is, must be able to support an echo tail to the echo source and back) must be placed at the correct point in a VoIP network to prevent these echoes from reaching the VoIP terminals (Figure 62: Gateway echo cancellation on page 119).
Assessing voice quality
Voice quality scores have been measured by the telecom industry for decades. The standard by which networks have been judged is the Mean Opinion Score (MOS). Although MOS testing is unarguably the only real measure of voice quality, the effort and expense of performing this test has limited its practicality. To make voice quality testing more manageable, the industry has constantly been developing and evolving a number of test algorithms implementable in measurement systems for voice quality testing automation. Currently, the voice quality measurement systems are based primarily on two different methods: Perceptual Evaluation of Speech Quality (PESQ) and E-model. PESQ is specified by ITU-T recommendation P.862. The test involves playing an audio file into one end of the call and recording the receive audio at the other end. The PESQ algorithm then compares the two audio files and produces a score between -0.5 and 4.5 where larger scores correspond to better voice quality. It is in essence a one-way channel distortion test and is very good at detecting changes in the speech channel caused by codec distortion, drop outs, and channel noise that may impact the quality of the received audio. Since the PESQ algorithm is a one-way test tool, it cannot measure the return path voice impairments such as echo return loss, echo canceller performance, or side tone. The algorithm also ignores the effects of transmission delay and path loss or gain. These limitations make PESQ unsuitable for voice quality testing over IP networks. Unlike PESQ, the E-model was developed as a transmission planning tool for assessing the combined effects of variations in several transmission parameters that affect conversational
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 119 Application Server 5300 IP service network planning
quality. Therefore, E-model is more applicable for VoIP quality assessment. We have discussed the parameters that impact voice quality. In this section we will explain Mean Opinion Score (MOS) and ITU-E model R-values and their use to assess voice quality. • Voice quality rating: MOS on page 120 • Voice quality rating: R-values on page 122
Voice quality rating: MOS
Based on ITU-T P.800 recommendation, Mean Opinion Scores (MOS) ratings provide a subjective quality score averaged over a large number of speakers, utterances, and listeners. To determine a MOS value, a series of spoken sentences are transmitted to listeners using a repeatable speech sample under scrutiny. For each sentence, the listeners must allocate a number from 1 to 5. The numerical average of the results from all the listeners is then used to provide a MOS score for the particular speech sample. The following table indicates the value of MOS and the respective quality rating. Table 25: MOS ratings
MOS Quality Impairment 5 Excellent Imperceptible 4 Good Perceptible but not annoying 3 Fair Slightly annoying 2 Poor Annoying 1 Bad Very annoying
The table below shows the MOS ranges and their applicable voice quality. Table 26: Voice quality MOS ratings
MOS Range Quality 5.0 – 4.0 Toll quality, Good-to-Better (GoB) 4.0 – 3.0 Communication quality Less than 3.0 Synthetic quality, Poor-to-Worse (PoW)
The following table shows the MOS ratings for various codecs.
120 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Assessing voice quality
Table 27: Codec MOS ratings
Codec Bit rate MOS G.711 PCM 64 kb/s 4.3 G.726 ADPCM 32 kb/s 3.8 G.729 CS-ACELP 8 kb/s 3.9 G.729A CS-ACELP 8 kb/s 3.7 G.723.1 MP-MLQ 6.4 kb/s 3.9 G.723.1 ACELP 5.3 kb/s 3.65 GSM-EFR 12.2 kb/s 3.8 GSM-FR ACELP 12.2 kb/s 3.5 AMR 12.2 kb/s 4.14 IS-127 EVRC RCELP 8.55 kb/s 3.8
When the codec choice, packet loss, end-to-end delay, and jitter values are known, one can use a MOS calculator (http://davidwall.com/MOSCalc.htm) to calculate the MOS rating. Figure 63: MOS rating example on page 121 shows the calculator tool user interface.
Figure 63: MOS rating example
The end-to-end performance requirement for voice systems used in the Defense Information Systems Network (DISN) is that at least 95 percent of the calls shall have a mean opinion score (MOS) of 4.0 (3.6 for Tactical) or better in accordance with commercial and DoD mandated standards.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 121 Application Server 5300 IP service network planning
Voice quality rating: R-values
The R-value ratings are based upon the ITU-T E-model (ITU-T G.107 The E-model, a computational model for use in transmission planning). E-Model results are calculated using the Impairment Factor method in which impairment values along the speech path (such as loss, distortion, echo, delay, noise) are combined to obtain an overall transmission rating “R”. The advantage of the E-model is that it is an objective evaluation of speech quality as compared to a subjective MOS evaluation. Also its standardization allows for greater consistency in voice quality ratings among carriers and vendors. The E-Model accounts for all the impairments which influence user satisfaction with conversation quality, including signal level, circuit noise, sidetone, echo, delay, codec distortion, and so on. The E-model (Figure 64: E-model impairments on page 122) uses the formula R = Ro - Is - Id - Ie +A to predict the speech communication quality through a transmission network.
Figure 64: E-model impairments
In the E-model equation,
•Ro is the basic signal-to-noise ratio based on send and receive loudness ratings and the circuit and room noise.
•Is is the sum of real-time or simultaneous speech transmission impairments, for example, loudness levels, sidetone, and pulse code modulation (PCM) quantizing distortion.
•Id is the sum of delayed impairments relative to the speech signal, for example, talker echo, listener echo and absolute delay.
•Ie is the equipment impairment factor for codec (Table 28: Codec impairment (Ie) on page 123), packet loss, jitter, delay. • A is the Advantage factor added to the total. It improves R for new services, like satellite phones, to take into account the advantage of having the service (where the alternative might be no service) and to reflect acceptance of lower quality by users for such services. The Advantage factor for VoIP is 0 (that is, no advantage for VoIP).
122 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Assessing voice quality
Table 28: Codec impairment (Ie)
Codec Impairment (Ie) G.711 0 G.729 11 G.726 7 G.723.1 MP-MLQ 15 G.723.1 ACELP 17 GSM 6.10 13 kbps, Full rate 20
Overall Transmission Quality Rating given by E-model is referred to as the R-value. R lies in the range 0-100 and can be mapped to MOS (Figure 65: R-value versus MOS value on page 123) per ITU G.113. The R-value cannot be used to accurately predict the absolute opinion of an individual user. However, for a large number of users, the results are sufficiently accurate for transmission planning purposes.
Figure 65: R-value versus MOS value
A handy E-model calculator can be found at http://www.itu.int/ITU-T/studygroups/com12/ emodelv1/auditool.htm. The E-model calculator is useful to predict the effects of various transmission path choices upon the voice quality. For instance, the effect of changing loss plan, adding delay, substitution of Codecs, or variations in phone characteristics can be predicted. The MOS and E-Model calculators are provided for illustration purposes. These tools are not endorsed by Avaya.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 123 Application Server 5300 IP service network planning
IP network planning
A typical connection-oriented TDM network offers subscribers with fixed delay, no jitter, zero loss, dedicated circuit bandwidth, and guaranteed delivery to assure high service quality. A connectionless IP network behaves exactly the opposite. It offers subscribers uneven delay, irregular jitter, random or burst packet loss, no bandwidth guarantee (over a number of alternate IP routing paths of varying capabilities), and only “best-effort” delivery. As such, the IP traffic usually experiences unpredictable amount of delay, loss, or jitter in the network, which causes undesirable service quality for subscribers. To contain these undesirable problems, we will provide in this section a set of recommendations to help the planners to plan and engineer a high performance IP network for deploying real-time Application Server 5300 services. • Application Server 5300 reference networks on page 124 • Network qualification on page 128 • Traffic engineering on page 130 • Manage end-to-end impairment budgets on page 140
Application Server 5300 reference networks
There can be large number of IP network topologies for Application Server 5300 deployments. It is not possible to discuss all possible scenarios. We will focus the discussions using the following reference networks: • Single campus reference network on page 124 • Large multisite Enterprise network on page 125
Single campus reference network
The single campus reference network illustrates Application Server 5300 deployments at small sites consisting of one or several buildings. Typically, it is the smaller Application Server 5300 systems with all L1 to L5 components are deployed at these sites. The campus IP network is used to provide Application Server 5300 converged voice, video, and data services to the users. Application Server 5300 integrates the existing TDM PSTN/PBX network using smaller PRI gateways (for example, Audiocodes MG1000). The reference network is divided into three sections—a core network section, one protected service network section, and one or more subscriber access network sections (Figure 66: Single campus reference network on page 125). The core network interconnects the protected service network and the subscriber access networks into one large Application Server 5300 service network. Two redundant high performance IP switching devices (or routers) are used to connect between any two sections of the enterprise network. The protected service network
124 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network planning
is protected by redundant stateful firewalls or high-performance packet filtering devices to filter out undesired traffic. Application Server 5300 is deployed within the protected enterprise service network. Within the protected service network, Application Server 5300 SIP core servers/console, PRI gateways/console, and media servers/console can be deployed at their own separate VLANs if the separation of media, OAMP, and signaling traffic is required. Application Server 5300 clients are deployed at the campus access networks. The single campus reference network is comparable to the DoD ASCLAN reference network, where DoD PBX1 or LSC systems are deployed.
Figure 66: Single campus reference network
Large multisite Enterprise network
The large multi-site enterprise reference network depicts the medium to large enterprises network architecture. The network consists of main campus networks, regional campus networks, branch office networks, and IP core WAN networks (Figure 67: Application Server 5300 large multisite Enterprise reference network on page 126). The enterprise campus and branch office networks are interconnected via the core IP WAN network(s). There can be more than one core WAN networks used for enterprise connections. The core WAN networks can be managed by the enterprise internal IT teams or outsourced to national service providers (NSP), or both. When two independently managed WAN networks are used, the redundant core networks ensure the IP backbone traffic will continue when one of them fails to operate properly. A minimum of two redundant high performance IP edge routers (ER) are used to connect the campus and branch networks to the core WAN aggregation routers (AR). The edge routers perform QoS differentiated classes of service management for IP traffic. The aggregation routers police the traffic according to the SLA contract. All Application Server 5300 L1-L5 components are deployed at the main campus sites. Within the signaling center, Application Server 5300 SIP core servers and management consoles can be deployed at separate VLANs to protect internal OAMP traffic from the external signaling
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 125 Application Server 5300 IP service network planning
traffic. The MAS and PRI gateway media resources can be deployed at separate media centers to further segregate the media traffic from the SIP core internal traffic. For mission critical environments, Application Server 5300 Geo-Redundant Split SIP core architecture allows enterprises to establish two signaling centers to ensure that the critical services will continue when one of the signaling centers becomes inoperable. At regional campus sites, Application Server 5300 L1-L3 components are deployed. Depending on the locations, some of the regional campuses are also good for deploying regional media centers. The regional media centers provide media resources to the campus’s own subscribers and the subtending branch office subscribers. The regional media centers allow the regional media traffic can now stay local. Localizing media traffic improves service quality for the regional subscribers because it eliminates the long delay as result of sending media traffic through the main campus sites. Without the regional media traffic in and out of the main campus sites, the enterprises also reduce the costs and performance (switching, routing, bandwidth, and cost) impacts on the core WAN and campus networks. The regional media centers also make it easier to scale the media resources for the regional subscribers. At branch offices, Application Server 5300 L1 clients are deployed. These clients access Application Server 5300 services using the signaling and media resources of the main and regional campuses. The signaling traffic will traverse to the main campus signaling center, the media traffic will only traverse to the regional media centers. The home office and road warrior clients are connected to the campus/branch networks using the secure IP Virtual Private Network (IPVPN) tunnels. All remote clients can be segregated into separate subscriber IPVPN networks for security protections.
Figure 67: Application Server 5300 large multisite Enterprise reference network
126 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network planning
Application Server 5300 DoD reference network
Application Server 5300 DoD reference network is based on the DoD RTS architecture. It is divided into three segments: Edge, Access, and Core. The Edge Segment is associated with a Campus Area Network (CAN) at a particular Base/ Camp/Post/Station. The boundary for the Edge Segment is the customer edge router (CE‑R), which is owned and maintained by the campus network. The Access Segment connects the Edge Segment to the Core Segment via an Unclassified Provider Edge Router (PE‑R). The Core Segment is composed primarily of a high speed optical network starts and terminates at the PE-R. PE‑Rs are connected by the core Provider Routers (PR). Collectively the Access and Core segments are referred to as the WAN (Wide Area Network). The ARTS FY2008 Architecture the Access and Core segments are referred to as the DISN (Defense Information System Network) WAN. WAN is also categorized as Fixed-to-Fixed (F- F), Fixed-to-Tactical (F-T), and Tactical-to-Tactical (T-T). The DISN Core and the Edge segments are considered to be “non-blocking” environments. However, the Access Network segments are expected to be resource constrained. Application Server 5300 LSC and SS SESMs implement the DoD ARTS two-tier hierarchical call routing architecture. The LSC SESM performs local call controls within the campus or enclave and depends on the Application Server 5300 SS SESM to perform intercampus or enclave translations and routing across the Defense Information System Network (DISN) Core. Application Server 5300 DoD reference network connects multiple LSC and MFSS campus networks into a large Application Server 5300 service network. When subscribers of two campuses need to communicate, Application Server 5300 establishes the connections via the core WAN network as shown in the following figure.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 127 Application Server 5300 IP service network planning
Figure 68: Application Server 5300 DoD reference network
Network qualification
Not all IP networks are ready to support VoIP implementation. Network qualification is an assessment of an existing network’s ability to support VoIP implementation. If a network cannot meet expectations, the results of a network qualification process will indicate why and what can be done to meet those expectations. The assessment results can be used later to determine the scope of work for a VoIP network redesign project. To qualify a network for an Application Server 5300 implementation, the network planner must do a thorough network assessment of the current IP network and evaluate what modifications or additions need to be made in order to support VoIP and other Application Server 5300 applications. The first step in qualifying a network is to perform an audit for the existing IP network. The objectives are to understand the current topology, performance of the network, and the impact of adding voice traffic to the existing data traffic. The following summarizes the major network audit tasks: • Understand network topology: understand the existing network which, at minimum, must include the operating characteristics of all the links (interface, link type, link speed, and duplex mode), VLAN configurations, IP VPNs, the switching/routing capacities of all the L2/L3 switches/routers, QoS configurations, network diagrams (show the enterprise core, distribution, and access networks and their L2 and L3 network convergence time), the
128 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network planning
existing and future network expansion plans, and finally, the key support contacts information. • Collect performance statistics: gather information such as propagation delay, jitter, packet loss, link utilization performance statistics of all the important links/paths identified previously. If QoS is implemented in the network, the above performance statistics must be collected for all supported service classes. The performance data must be collected multiple times during the peak business hours (for example, 10 a.m. and 2 p.m.) of a day and for multiple days to validate the consistency of the performance statistics of the peak hours of a typical day. • Understand the data traffic requirements: identify applications with heavy sustained traffic like scheduled file transfers or interactive imaging processing applications, which can affect voice quality by increasing delay and jitter. Assess the potential impacts of the existing data applications (especially the mission critical ones) on voice traffic and vice versa. Note that Application Server 5300 requires a minimum of 10 mb/s bandwidth be reserved for supporting regular OAMP activities between various Application Server 5300 network elements. This is to assure the successful completion of all large file download operations to the remote PoPs. After a thorough network audit, the planners can begin network qualification testing using a commercially available VoIP network qualification tool. These qualification tools (for example, NetIQ Chariot with VoIP module, Viola Networks NetAlly, Brix Networks Brixcall) can help the planners to identify any factors that can adversely impact the network performance and to ensure the expected SLAs can be met.
Figure 69: VoIP network qualification testing Network qualification testing simulates voice traffic by injecting calls into a live network, collecting the VoIP traffic performance statistics, and producing VoIP QoS analysis reports. As shown in Figure 69: VoIP network qualification testing on page 129, the VoIP qualification console sends endpoint 1 a test script (1), which describes the test procedures (that is, the type and amount of data to send and receive, when to connect and disconnect). Endpoint 1 keeps its half of the test and sends the other half (2) to its partner endpoint 2. The endpoints then run the tests. At the end of the tests, endpoint 1 sends the test results back to the console (3). The console then uses that data to determine the performance of the network (4). Be aware that the tools themselves can only pinpoint the network problems, but will not solve the problems. A good test and verification method is essential to accurately pinpoint the problem areas in the IP network. Any changes that are suggested as a result of the
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 129 Application Server 5300 IP service network planning
investigation should be thoroughly examined before implementing. Also, it may be necessary to provide evidence that problems are fixed after changes are made in the IP network. After numerous network assessment and problem solving sessions at VoIP sites, it could explicitly be said that “Ethernet duplex mismatch” is the biggest problem found in many VoIP installations. The duplex mismatch causes a large number of packet losses, which severely impact voice quality. For a device carrying a single VoIP call, this is not catastrophic, but for any device carrying a concentration of calls, like a PRI gateway or a MAS server, mismatch can cause terrible voice quality for a large number of users!
Figure 70: Ethernet duplex mismatch problem
The Primary cause of this problem is when a LAN Switch is hard configured to either 10/100/1000 Mb/Full Duplex and the attached devices set to auto-negotiation. If one side is not configured for Autonegotiate, the Autonegotiating device will not receive fast link pulse (FLP) bursts and will default to Half Duplex operation (for more information on FLP, see http:// www.dell.com/content/topics/global.aspx/power/en/ps1q01_hernan). If the provisioned side is “forced” to Full Duplex, duplex mismatch results.
Traffic engineering
From the results of the previous network audit and qualification processes, we can identify major traffic concentration points and potential bottlenecks for traffic capacity engineering exercises (Figure 71: Key locations for traffic engineering on page 131). Failure to engineer sufficient bandwidth at these key locations will severely limit the usability of an Application Server 5300 system and place a huge burden on the network infrastructure. This is because a network with insufficient bandwidth can cause excessive delay, jitter, and packet loss in the network. Traffic engineering is a very important step of ensuring a high quality service network for deployment.
130 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network planning
Figure 71: Key locations for traffic engineering
Voice traffic
The IP network bandwidth consumed by a voice channel depends on the speech codec, the packetization time, and network overheads. Table 29: VoIP over Ethernet on page 131 shows the VoIP bandwidth requirements for various voice Codecs and packetization times over a non- VLAN Ethernet. Table 29: VoIP over Ethernet
Codec Codec Samplin Ether/ Total IPv4 Ether/ Total IPv6 bit rate g rate IPv4/ packet band- IPv6/ packet band- in kbps UDP/ size width UDP/ size width RTP RTP over- over- head head (bytes) (bytes) G.711 64 10 ms/s 78 158 126.4 98 178 142.4 G.711 64 20 ms/s 78 238 95.2 98 258 103.2 G.711 64 30 ms/s 78 318 84.8 98 338 90.1 G.729 8 10 ms/s 78 88 70.4 98 108 86.4 G.729 8 20 ms/s 78 98 39.2 98 118 47.2 G.729 8 30 ms/s 78 108 28.8 98 128 34.1
The table below shows the VoIP bandwidth requirements for various voice Codecs and packetization times over a VLAN-tagged Ethernet.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 131 Application Server 5300 IP service network planning
Table 30: VoIP bandwidth over VLAN-tagged Ethernet
Codec kbps Samplin Ether/ Total IPv4 Ether/ Total IPv6 g rate VLAN/ packet band- VLAN/ Packet band- IPv4/ size width IPv6/ size width UDP/ UDP/ RTP RTP over- over- head head (bytes) (bytes) G.711 64 10 ms/s 82 162 129.6 102 182 145.6 G.711 64 20 ms/s 82 242 96.8 102 262 104.8 G.711 64 30 ms/s 82 322 85.9 102 342 91.2 G.729 8 10 ms/s 82 92 73.6 102 112 89.6 G.729 8 20 ms/s 82 102 40.8 102 122 48.8 G.729 8 30 ms/s 82 112 29.8 102 132 35.2
The following table shows the VoIP bandwidth requirements for various voice Codecs and packetization times over a Frame Relay link. Table 31: VoIP bandwidth over a Frame Relay link
Codec kbps Sampling Fr/ IPv4/ Total IPv4 Fr/ IPv6/ Total IPv6 rate UDP/ packet band- UDP/ packet band- RTP size width RTP size width over- over- head head (bytes) (bytes) G.711 64 10 ms/s 47 127 101.6 67 147 117.6 G.711 64 20 ms/s 47 207 82.8 67 227 90.8 G.711 64 30 ms/s 47 287 76.5 67 307 81.9 G.729 8 10 ms/s 47 57 45.6 67 77 61.6 G.729 8 20 ms/s 47 67 26.8 67 87 34.8 G.729 8 30 ms/s 47 77 20.5 67 97 25.8
The following table shows the VoIP bandwidth requirements for various voice Codecs and packetization times over a PPP link.
132 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network planning
Table 32: VoIP bandwidth over a PPP link
Codec kbps Samplin PPP/ Total IPv4 PPP/ Total IPv6 g rate IPv4/ packet band- IPv6/ packet band- UDP/ size width UDP/ size width RTP RTP over- over- head head (bytes) (bytes) G.711 64 10 ms/s 49 129 103.2 69 149 119.2 G.711 64 20 ms/s 49 209 83.6 69 229 91.6 G.711 64 30 ms/s 49 289 77.1 69 309 82.4 G.729 8 10 ms/s 49 59 47.2 69 79 63.2 G.729 8 20 ms/s 49 69 27.6 69 89 35.6 G.729 8 30 ms/s 49 79 21 69 99 26.4
The Layer-4 and Layer-3 headers add 40 bytes of overhead to each voice sample packet using IPv4 header. IPv6 adds an additional 20 bytes to the IP header for each voice packet. Different Layer-2 technologies also add different amounts of Layer-2 overhead to each voice packet (Figure 72: Packet header overheads on page 133). Notice that, after adding the transport overheads, the 8-to-1 G.729 versus G.711 data reduction ratio is reduced to 2.45-to-1 for a 20ms VoIP packet.
Figure 72: Packet header overheads
Media bandwidth can be calculated based upon the type and number of expected media flows over a given point in the network. For each media type, multiply the number of flows by the bandwidth required for a single flow. The steps for calculating the bandwidth for a link are summarized as follow: • Determine the traffic flows over the link, using the example in Figure 73: Calculating total Erlang on page 134. - Calculate the total Erlang value of these flows as follows: Erlang P2P call per site = (Erlang P2P call per user * % intersite call + Erlang MAS call per user + Erlang PSTN call per user) * # of users per site
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 133 Application Server 5300 IP service network planning
- Convert the Erlang value to its equivalent number of voice circuits using an Erlang B formula (http://personal.telefonica.terra.es/web/vr/erlang/eng/cerlangb.htm) • Determine the codec and packetization time and select the appropriate line rate from one of Table 29: VoIP over Ethernet on page 131, Table 30: VoIP bandwidth over VLAN-tagged Ethernet on page 132, Table 31: VoIP bandwidth over a Frame Relay link on page 132, or Table 32: VoIP bandwidth over a PPP link on page 133. • Multiply the selected line rate by the number of circuit count. For example, if the total Erlang is 5, with a 1% blocking factor, the number of circuit is 11. Using the G.711 10ms codec, the total bandwidth required for an Ethernet link is ~ 1.4 mb/s (11 * 126.4 kb/s). • • Multiply 10-30 % for an over-engineering factor to handle bursty traffic. In some cases, you will probably need to double the bandwidth to handle the failover traffic. The End-to-End Network System supporting RTS shall assume the use of G.711 (20 ms) for calculating bandwidth budgets within the fixed network even if compressed codecs are used. Since no assumption can be made regarding whether the traffic is IPv4 or IPv6, the worst case scenario is targeted (IPv6). Based on G.711 (20 ms) with IPv6/UDP/RTP overhead, the bandwidth required for a session is approximately 102 Kbps and with Voice over IP (VoIP) signaling (2 Kbps) included.
Figure 73: Calculating total Erlang
Similarly, the switching capacity (packet/s) required for a link can be calculated using this formula. Required switching capacity (packet/s) = # of packets per second of the selected packetization time * # of circuits * 2 (that is, full duplex flows) Using the same example, the required switching capacity is 2,200 packets per second (that is, 100 packet/s per circuit * 11 * 2).
134 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network planning
Bandwidth in the ASCLAN shall be engineered so that the following stipulations are met: • Voice IP subscribers do not exceed more than 25 per cent of available bandwidth. • No single point of failure within the ASCLAN can cause a voice service outage to more than 64 users.
Video traffic
Avaya Aura AS 5300 UC Clients support the DivX and H.263 video codecs. Subscribers can use these video Codecs only when those Codecs are explicitly enabled in their service packages. If both Codecs are available, H.263 video is preferred over the DivX video. Additionally, the Avaya Aura AS 5300 UC Clients support the MAS based audio and video conferencing services (Ad hoc and Meet Me), if enabled in the subscribers service package and MAS servers. The following table shows the DivX and H.263 video bandwidth requirements for various video qualities. The estimated Ethernet/IP overheads are also shown in the table. Table 33: DivX and H.263 video bandwidth requirements
Video quality DivX configuration H.263 configuration Ethernet/IP overhead Very low 2 Frames per second 2 Frames per second 8 kbps 160x120 resolution 128x96 (SQCIF) 10–20 Kpbs Key resolution 10 Kpbs Key frame interval = 8 frame interval = 10 Low 10 Frames per 10 Frames per second 32 kbps second 160x120 176x144 (QCIF) resolution 60–120 resolution 64 Kpbs Key Kpbs Key frame frame interval = 10 interval = 8 Medium 10 Frames per 10 Frames per second 96 kbps second 320x240 352x288 (CIF) resolution resolution 150–300 192 Kpbs Key frame Kpbs Key frame interval = 10 interval = 8 High 15 Frames per 15 Frames per second 256 kbps second 352x288 352x288 (CIF) resolution resolution 400–800 512 Kpbs Key frame Kpbs Key frame interval = 10 interval = 8 Very high Up to 30 Frames per Up to 30 Frames per 1 mbps second up to second up to 352x288 352x288 resolution resolution video media unlimited video bandwidth up to 2000
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 135 Application Server 5300 IP service network planning
Video quality DivX configuration H.263 configuration Ethernet/IP overhead media bandwidth Key Kpbs Key frame interval frame interval up to 300 unlimited
In the same audio/video session, the video media stream follows the same path as the voice media stream. The video capacity required for a link can be calculated using the formula: Required video capacity = video codec bandwidth * # of circuits Using the same example, the required video capacity for H.263 medium resolution codec is 3,168 kb/s (that is, 192+96 kb/s per circuit * 11). The total bandwidth required for 11 concurrent audio/video sessions is ~ 4.5 mb/s (that is, 3.1 mb (video) + 1.4 mb (audio)). After adding the audited data bandwidth and applying appropriate over engineering factor, the planner can obtain the total bandwidth required for audio, video, and data. ASCLAN recommends engineering a ratio of 25 percent voice, 25 percent video, and 50 percent data for campus traffic. Data traffic can burst up to the full link capacity if voice and video are not present.
Signaling traffic
Compared to voice and video traffic, signaling traffic is relatively small. One can usually approximate it using 1% of the regular media traffic. However, it is desirable sometime to size the amount of signaling traffic more accurately, for example, for sizing the amount of signaling traffic across metro- and/or wide-area networks for normal as well as failover traffic flows. SIP uses text-based messages that vary in sizes depending on subscriber and domain naming conventions, applications, and vendor implementations. To help estimating the bandwidth requirements for various traffic types, the system planners must capture and analyze signaling messages using network analyzer tools. The following table shows various SIP messages captured in a lab environment. The “To SESM” column contains the bit rates for traffic sent to SESM and “From SESM” column contains the bit rates for traffic returned from SESM. Table 34: Signaling bandwidth example
Traffic Type To SESM (bits/sec) From SESM (bits/sec) Ping/Keep-alive 3,200 2,800 Register (Initial) 60,520 129,720 Register (Refresh) 8,800 8,160 Subscribe 7,600 7,600 Notify 6,560 12,000
136 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network planning
Traffic Type To SESM (bits/sec) From SESM (bits/sec) Publish 12,000 7,840 Send Instant Message 8,000 9,600 Receive Instant Message 3,200 10,000 Incoming Call (basic) 23,520 28,800 Outgoing Call (basic) 31,760 40,160 Meet Me (Chair) 50,880 84,400 Meet Me (Participant) 33,600 37,360 Ad-hoc (3-party) 252,000 290,960 Blind Transfer 60,560 69,360 Consultative Transfer 110,320 122,720
Using the signaling traffic table and a subscriber usage profile, the system planners can now estimate the signaling traffic bandwidth requirement for a subscriber. As an example, let us assume each subscriber has one SIP client, ten friends, and auto-presence enabled. After the initial login in, the system planner estimate the bandwidth requirement for a subscriber having the service usage profile shown in the following table. Note that the calculation also includes the state change signaling traffic caused by calls and registers. If there are 5,000 subscribers at a particular site, the system planner can estimate the average bandwidth for the site toward SESM is ~ 2.9 mb/sec and the bandwidth from SESM is ~ 4 mb/ s. Depending on the sites, these numbers can be doubled or tripled to handle bursty traffic. Table 35: Subscriber sample usage profile
Subscriber Usage Parameter value To SESM From SESM Profile # of keep-alive 60 192,000 168,000 messages per SIP client Register /BH 1 8,800 8,160 Register Notify n/a 144,320 264,000 (offline, online) # of incoming calls / 3 70,560 86,400 BH Incoming call Notify n/a 432,960 792,000 (busy, available) # of outgoing calls / 2 63,520 80,320 BH
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 137 Application Server 5300 IP service network planning
Subscriber Usage Parameter value To SESM From SESM Profile Outgoing call Notify n/a 288,640 528,000 (busy, available) # of incoming IMs / 3 9,600 30,000 BH # of outgoing IMs /BH 2 16,000 19,200 # of 3-party ad-hoc 1 252,000 290,960 calls / BH 3-party Ad-hoc Notify n/a 432,960 792,000 (busy, available) # of friend list 1 76,000 76,000 subscription / BH # of friend notify / BH 10 65,600 120,000 Total Bandwidth / BH n/a 2,027,360 2,809,840 Total Bandwidth / n/a 564 781 Sec
Low speed link
The low speed IPVPN access tunnels (Figure 67: Application Server 5300 large multisite Enterprise reference network on page 126) from remote IP VPN clients can be problematic in that they may become congested when running multiple applications over the access links (for example, file download, web browsing, voice/video calls). Figure 74: Packet transmission delay on page 139 shows packet transmission delay for different links with speeds in milliseconds. As shown in the table, even in a noncongested condition, a large packet can present a long delay for all packets on a slow link. As a result, it may cause the delay exceeding the acceptable end-to-end delay budget.
138 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network planning
Figure 74: Packet transmission delay
To avoid excessive transmission delay, the planner should consider the followings for the remote IPVPN clients • Provide at least 512 kb/s (both upstream and downstream) for a voice/data user. • Provide at least 1 mb/s (both upstream and downstream) for a voice/data/video user. • Shape downstream traffic at hub to avoid saturating the client site. • Keep jitter under 15 ms over the low-speed links by limiting MTU size at the remote clients. • Use queuing techniques that give preference and priority to voice traffic over video and data when congested. • Keep the packet size smaller than 512 bytes using link fragmentation (for example, PPP multi-class extensions, FRF.12) to minimize jitter delay. Allow large data frames to be fragmented and interleaved with smaller voice frames. Avoid serialization delays of large data packets (Figure 75: Link fragmentation on page 139).
Figure 75: Link fragmentation
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 139 Application Server 5300 IP service network planning
Manage end-to-end impairment budgets
This section contains the following examples • An Intra-Campus/Enclave example on page 140 • An Inter-Campus/Enclave example on page 142
An Intra-Campus/Enclave example
To keep the end-to-end impairment budgets within bound for the intracampus or enclave traffic (Figure 76: Managing intraenclave impairment budgets example on page 141), the impairment budgets must be carefully managed based upon the network topology and the endpoints’ capabilities (for example, speed, audio codec, video codec, resolutions, data applications). The steps for managing the impairments budgets within a large enterprise are summarized below: • Identify the end-to-end delay, jitter, and packet loss impairment budgets for a specific QoS requirement (determined from the Deployment planning on page 49) • From the previous network audit information - Identify the longest path between two endpoints and the (primary and alternate) routing/switching paths between them. - Identify the propagation delays of all the network sections including the PSTN/TDM network . - Identify all switching and routing devices along the identified paths and their delay, jitter, packet loss performance characteristics. - Identify the endpoints and their performance characteristics. • Total all the delay, jitter, and loss impairment values along the send path and receive path at both endpoints. • Ensure the impairment values are within the limit determined previously. If not, either loosen the QoS expectations or add more capacity to the network
140 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network planning
Figure 76: Managing intraenclave impairment budgets example
Figure 77: Impairment budget chart for the intraenclave longest path example on page 142 shows the breakdown of sending and receiving impairment budget plans of the longest path shown in Figure 76: Managing intraenclave impairment budgets example on page 141.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 141 Application Server 5300 IP service network planning
Figure 77: Impairment budget chart for the intraenclave longest path example
The MOS scores shown are calculated using the previously mentioned MOS calculator with the assumption that the path is echo free. In this example, the echo cancellation might need to be turned on in the gateway if the echo were not fully cancelled in the TDM network.
An Inter-Campus/Enclave example
As shown in Figure 78: Managing intercampus or enclave impairment budgets example on page 143, the intercampus/enclave traffic flows traverse through the local campus, the DISN Access networks, the DISN Core network, and the remote campus/enclave network. To keep the end-to-end impairment budgets within bound for the intercampus/enclave traffic, the network planner must not only manage the impairments budgets of the local campus/enclave but must also obtain or estimate the impairments budgets outside of the campus/enclave.
142 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network planning
Figure 78: Managing intercampus or enclave impairment budgets example
When the impairments budgets are unavailable for the external networks, for the purposes of managing the impairments budgets outside of a campus/enclave, the network planners can use the DoD impairments budget requirements for estimating the impairments budgets of various real-time services (RTS) network segments. The end-to-end delay (in ms) budget requirements are summarized in the following table. Table 36: RTS network End-to-End delay budget
Edge (CE-R) [1] Access WAN [3] Access Edge (CE- E2E (PE-R) [2] (PE-R) R) Delay Intra 35 10 60 10 35 150 Theater Inter 35 10 130 10 35 220 Theater [1] from an IP handset to a CE-R within the Edge Segment (that is, a campus/ enclave network) [2] from a CE-R to a
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 143 Application Server 5300 IP service network planning
Edge (CE-R) [1] Access WAN [3] Access Edge (CE- E2E (PE-R) [2] (PE-R) R) Delay PE-R using a Metropolit an Area Network (MAN) or circuit within the Access Segment [3] from a PE-R to a PE-R within the Core Segment
The End-to-End jitter budget (in ms) requirements for various RTS network segments are summarized in the following table. Table 37: RTS network End-to-End jitter budget
Edge (CE-R) Access WAN Access Edge (CE- E2E (PE-R) (PE-R) R) Delay Intra 5 5 5 5 5 25 Theater Inter 5 5 10 5 5 30 Theater
The End-to-End packet loss rate budget requirements for various RTS (real-time services) network segments are summarized in the following table. Table 38: RTS network End-to-End packet loss budget
Edge+Acess (CE-R WAN Edge+Access E2E Delay +PE-R) (CE-R + PE-R) Intra Theater 0.05% 0.40% 0.05% 0.50% Inter Theater 0.05% 0.40% 0.05% 0.50%
Using these impairments budget tables, the network planners can apply the steps, described previously for managing intracampus/enclave impairments budgets, to manage the intercampus/enclave impairments budgets (Figure 79: Impairment budget chart for the interenclave longest path example on page 145). The endpoint’s jitter buffer must be large enough to accommodate the end-to-end jitter delays.
144 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] QoS recommendations
Figure 79: Impairment budget chart for the interenclave longest path example
QoS recommendations
Quality of Service (QoS) is a set of network-enforced mechanisms providing differentiated classes of service for IP traffic to support various types of time sensitive applications. It provides a certain level of assurance for applications to meet their service expectations even when a network is experiencing congestion. Since a regular IP network does not guarantee timely data delivery, the network-based QoS mechanisms are highly recommended when running voice/ video applications over the network. In the remainder of this section, we will describe the Ethernet 802.1p/q and IP Diffserv QoS mechanisms that can be used in an Application Server 5300 network to achieve IP network performance close to what is expected by end users in a TDM-based network. Note that these mechanisms enable a network to give priority delivery of voice/video traffic over the data traffic, but by themselves, they can not guarantee bandwidth and speedy delivery unless sufficient bandwidth is provisioned for the real-time traffic classes. • Ethernet 802.1q/p on page 145 • IP Differentiated Services on page 146 • QoS queue mappings on page 149
Ethernet 802.1q/p
The IEEE Ethernet 802.1q/p standard adds 4 additional bytes to the Ethernet header (Figure 80: 802.1 p/q frame format on page 146). Within those 4 bytes are 2 fields of interest for Ethernet QoS, namely, the three 802.1p user priority bits and the 820.1q 12-bit VLAN ID. The
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 145 Application Server 5300 IP service network planning
three 802.1 bits can be used to create 8 classes of service over Ethernet with 802.1p value of ‘7’ being the highest priority and ‘0’ being the lowest priority. The VLAN ID is used for traffic separation and can be used to group traffic with similar types of requirements.
Figure 80: 802.1 p/q frame format
802.1p capable Ethernet switches use the 802.1p bits to prioritize Ethernet packets. Using 802.1p/q, network managers can configure priority values to VLAN switch ports as either “default” or based on some configured policy filters. This value becomes the user priority for the frame. Arriving frames that are not prioritized get their three-bit 802.1p priority based on the value assigned to the VLAN port.
IP Differentiated Services
Ethernet VLAN prioritization is useful for forwarding traffic between LAN segments within an Ethernet switch, but it does not provide end-to-end QoS support for real-time traffic. Successful Application Server 5300 deployment requires the IP network to support end-to-end quality of services (QoS). The IP Differentiated Services (DiffServ) defines an architecture that addresses end-to-end QoS needs using the Differential Services Code Points (DSCP) encoded in the IPv4 headers (Figure 81: IPv4 DiffServ Packet Format on page 147). For IPv6 packets, RFC2474 specifies the use of IPv6 header 1-byte traffic class field to encode the DSCP code points.
146 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] QoS recommendations
Figure 81: IPv4 DiffServ Packet Format
The DiffServ model (Figure 82: DiffServ QoS model on page 147) enables QoS provisioning within a network domain by applying classification, marking, and policing rules to create/shape traffic aggregates at the network edges and coupling each of these with a specific forwarding treatment (that is, queuing and scheduling) in the domain through consistent use of a set of predefined DSCP values. The core routers enforce consistent QoS forwarding treatments based on the DSCP values.
Figure 82: DiffServ QoS model
The RTS IA architecture defines an appliance called the Edge Boundary Controller (EBC) that is located at the boundary of a campus/enclave. In the context of Differentiated Services, it functions as the DiffServ (DS) ingress boundary router for the associated enclave. An EBC applies the appropriate PHB, based upon the corresponding packet marking and provides traffic policing/shaping of outbound traffic to ensure compliance with Service Level Agreements (SLAs) for the enclave. To provide consistent QoS behaviors end-to-end, Table 39: Recommended Application Server 5300 DiffServ markings on page 148 shows a set of recommended DSCP values for applicable to Application Server 5300 applications.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 147 Application Server 5300 IP service network planning
Table 39: Recommended Application Server 5300 DiffServ markings
Aggregated Granular Priority or DSCP DSCP binary DSCP Base 8 service class service class Precedence Base10 Network Network 48 110 000 60 control signaling (for example, OSPF, BGP) Inelastic User 40 101 000 50 signaling (for example, AS SIP, H.323) Voice FO 41 101 001 51 F 42 101 010 52 I 43 101 011 53 P 45 101 101 55 R 46 101 110 56 Interactive FO 33 100 001 41 VTC includes all sessions F 34 100 010 42 associated I 35 100 011 43 with VTP (voice, video, P 37 100 101 45 and data) R 38 100 110 46 Preferred Multimedia FO 25 011 001 31 elastic streaming F 27 011 011 33 I 29 011 101 35 P 31 011 111 37 R 26 011 010 32 Low-latency 18 010 010 22 data OAM (for example, SNMP, Telnet, SSHv2) High 16 010 000 20 throughput data OAM (for example, Syslog files, CDR)
148 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] QoS recommendations
Aggregated Granular Priority or DSCP DSCP binary DSCP Base 8 service class service class Precedence Base10 Elastic Best effort 0 000 000 0 Scavenger 8 001 000 10 In the Defense Switched Network (DSN), the Precedence Levels that are used to initiate calls are as follows in order of low precedence to high precedence: ROUTINE (R), PRIORITY (P), IMMEDIATE (I), FLASH (F), and FLASH OVERRIDE (FO).
QoS queue mappings
Different devices may have a different number of queues for different type of interfaces. Depending on the number of queues, the mappings of DSCP values to these queues will vary. The following table shows recommended settings for a four-queue device. Table 40: Four queue device QoS mappings
Aggregated Granular Priority or DSCP Queue PHB service class service class Precedence Base10 Control Network 48 3 EF signaling (for example, OSPF, IS-IS)
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 149 Application Server 5300 IP service network planning
Aggregated Granular Priority or DSCP Queue PHB service class service class Precedence Base10 Inelastic real User 40 3 EF time signaling Voice FO 41 3 EF F 42 I 43 P 45 R 46 Interactive FO 33 2 AF41 VTC F 34 I 35 P 37 R 38 Preferred Multimedia FO 25 2 AF42 elastic streaming F 27 I 29 P 31 R 26 Low-latency FO 17 1 AF31 data (OAM) F 19 I 21 P 23 R 18 High FO 9 1 AF32 throughput data F 11 I 13 P 15 R 10 OAM R 16 1 AF32 Elastic Default 0 0 Default Scavenger 8
150 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] QoS recommendations
Table 41: Eight queue device QoS mappings on page 151 shows recommended settings for a eight-queue device. Table 41: Eight queue device QoS mappings
Aggregated Granular Priority or DSCP Queue PHB service class service class Precedence Base10 Control Network 48 3 EF signaling Inelastic User 40 3 EF signaling Voice FO 41 7 EF F 42 I 43 P 45 R 46 Interactive FO 33 6 AF41 VTC F 34 I 35 P 37 R 38 Preferred Multimedia FO 25 5 AF31 elastic streaming F 27 I 29 P 31 R 26 AF32 Low-latency FO 17 1 AF11 data F 19 I 21 P 23 OAM R 18 AF12 High FO 9 2 AF21 throughput data F 11 I 13 P 15
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 151 Application Server 5300 IP service network planning
Aggregated Granular Priority or DSCP Queue PHB service class service class Precedence Base10 OAM R 10 2 AF22 Elastic Default 0 0 Default Scavenger 8 1
The planners are free to use different QoS queue mapping strategies. However, it is highly recommended to map voice traffic to a priority queue to minimize jitter and delay. The minimum RTS queuing requirement is the 4-queue model. The 8-queue model is preferred.
Application Server 5300 QoS support
This section describes the following aspects of QoS support. • End-to-end QoS support on page 152 • Assured Real-Time Services (DoD only) on page 152 • Application Server 5300 ASAC configurations on page 154 • Determine Interenclave ASAC voice-only budget on page 155 • Determine Interenclave ASAC video budget on page 157 • QoS accounting services on page 158 • Global IP Sound NetEQ on page 159
End-to-end QoS support
As previously discussed, Application Server 5300 allows the administrators to configure different DSCP values associated with the different traffic types: • Call signaling • Media flow (Audio/video) • OAMP The DSCP marked IP packets enable each of the routers between the two endpoints to apply the appropriate bandwidth and priority treatments based on the network policy.
Assured Real-Time Services (DoD only)
The DoD Assured Real-Time Services (ARTS) Architecture consists of three network layers: the Edge layer, Access layer, and DISN Core layer (Figure 83: ARTS example on page 153).
152 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Application Server 5300 QoS support
The Edge Layer is associated with the local Campus Area Network at a particular Base/Camp/ Post/Station. The DISN Core is the DoD wide area backbone network. The Access Layer consists of network facilities that connect the Edge Layer to the DISN Core. Although the DSN Wide Area Network (WAN) is considered to be bandwidth unlimited, the access link bandwidth between the Customer Edge router (CE-R) and the Provider Edge (PE) router (PE-R) is resource constrained. To ensure the Quality of Service (QoS) and availability of Access Network bandwidth for mission critical (that is, Command and Control related) sessions, the Application Server 5300 Assured Services Admission Control (ASAC) implements a threshold-based Call Admission Control (CAC) mechanism to control the voice or video access link bandwidth utilization.
Figure 83: ARTS example
The Application Server 5300 ASAC budget must be preengineered and provisioned for the access link that used by interenclave calls. To ensure the proper interenclave calls setup, the administrators must provision sufficient voice and video call count budget for the corresponding access links to prevent unintended call blocking. The budget can either be bidirectional (that is, shared by both incoming and outgoing calls) or it can be directional where there is separate budget for incoming and outgoing calls (Figure 84: Call Admission Control on page 154). As shown in Figure 84: Call Admission Control on page 154, the Application Server 5300 SS SESM provides policing function. The LSC SESM is responsible for enforcing the budget. The LSC/SS SESM keeps track of all interenclave active calls as well as calls in the set up state. If there is enough call count budget, the call is allowed to continue. If the budget is exceeded and there is no lower priority call to preempt, the new calls are rejected. If there is lower priority call to preempt, the lower priority call is preempted, allowing the new precedence call to
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 153 Application Server 5300 IP service network planning
complete. A call can only preempt other lower priority calls that share the same budget. For directional budget, a call can only preempt other lower priority calls in the same direction. All ASAC budget information and active call information is maintained in the inactive side. In the case of a failover of an active session manager (LSC or MFSS), the inactive side will resume the ASAC policy control.
Figure 84: Call Admission Control
Application Server 5300 ASAC configurations
Application Server 5300 supports the following configurations supporting ASAC functions: • For an enclave that only has LSCs (Campuses 3 and 4 in Figure 83: ARTS example on page 153) - One SESM must be configured as a Master LSC. - All other SESMs must be configured as Slave LSCs. - ASAC must be enabled on the Master LSC and disabled on Slave LSCs. - Each LSC must have a unique CCA-ID (Call Control Agent ID). - All interenclave calls must traverse the Master LSC. - If there is EBC fronting the enclave, the EBC must be configured to route all incoming calls to the Master LSC.
154 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Application Server 5300 QoS support
- The PRI gateway must be configured to route calls to Master LSC. • For enclave that has combined LSCs and SSes (Campus 1 in Figure 83: ARTS example on page 153) - One SESM must be configured as a Master LSC. - One or more SESMs must be configured as an SS. - All remaining SESMs must be configured as Slave LSCs. - The Master LSC is associated with one local SS. - Each LSC must have a unique CCA-ID. - Each SS must have a unique CCA-ID. - Each SS must be associated with all of the subtending LSCs it serves. - All interenclave calls will traverse the Master LSC and its serving SS. - All interenclave calls from the subtending enclaves will traverse their serving SSes. - The PRI gateway must be configured to route calls to a local SS (it does not matter which one if there are multiple SSes) • For enclave that has only SSes (Campus 2 Figure 83: ARTS example on page 153) - One or more SESMs must be configured as an SS. - Each SS must have a unique CCA-ID. - Each SS must be associated with all of the subtending LSCs it serves. - All interenclave calls from the subtending enclaves will traverse their serving SSes. - The PRI gateway must be configured to route calls to a local SS (it does not matter which one if there are multiple SSes). The unique CCA-ID is used to look up the ASAC budget of the corresponding LSC or MFSS SESM.
Determine Interenclave ASAC voice-only budget
The steps for engineering an LSC ASAC budget of interenclave voice only call are summarized below: • Determine the following traffic factors for the access link - Percentage of interenclave call (default 20%) - Percentage of incoming versus outgoing call across the link (default 50/50 percent) - # of call per Busy hour per subscriber (default 6 calls /BH) - Average call hold time (default 180 sec)
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 155 Application Server 5300 IP service network planning
- Percentage of video call (default 5%) (Note: voice call is always 100%) - Ad hoc calls per busy hour (default 1%) - Average Ad hoc call hold time (default 15 min) - Percent of Participant from other enclave in an Ad hoc call (default 33%) - Percent of Meet Me calls per busy hour (default 2%) - Average Meet Me call hold time (default 30 min) - Percent of Participant from other enclave in a Meet Me call (default 50 %) - Bursty traffic factor (default 20%) • Calculate the total Erlang value of the subscriber calls Subscriber Traffic Erlang/BH = [(# of Calls /BH * Average call hold time (sec)] / 3600 Erlang per enclave = Subscriber Traffic Erlang/BH * # of Subscribers per enclave • Convert the Erlang value to its equivalent circuit count using the Erlang B formula (http:// personal.telefonica.terra.es/web/vr/erlang/eng/cerlangb.htm) • Calculate ASAC voice budgets for subscriber calls Outgoing ASAC Voice Count Budget = Circuit count * % of interenclave call * % of outgoing call * ( 1 - % of video call) Incoming ASAC Voice Count Budget = Circuit count * % of interenclave call * % of Incoming call * ( 1 - % of video call) Bi-directional ASAC Voice Count Budget = Outgoing ASAC Voice Count Budget + Incoming ASAC Voice Count Budget • Calculate Incoming Interenclave Meet Me and Ad hoc call Erlang Interenclave Meet Me call Erlang = # of Calls /BH * % of Meet Me calls/BH * Average # of Meet Me Participants * (Average Meet Me call hold time / 3600) * % of interenclave call Interenclave Ad hoc call Erlang = # of Calls /BH * % of Ad hoc calls/BH * Average # of Ad hoc Participants * (Average Ad hoc call hold time / 3600) * % of interenclave cal • Convert the Meet Me and Ad hoc Erlang values to their equivalent number of circuits using an Erlang B formula • Calculate ASAC voice budgets for Incoming MAS voice calls Incoming MAS voice count budget = (Meet Me circuit count + Ad hoc circuit count) * % of Incoming call * ( 1 - % of video call) • Calculate ASAC voice budgets for Outgoing MAS voice calls Outgoing MAS voice count budget = (Meet Me circuit count + Ad hoc circuit count) * % of Outgoing call * ( 1 - % of video call) • Calculate Total ASAC Voice Budget Total Incoming ASAC Voice Count Budget = (Incoming ASAC Voice Count Budget + Incoming MAS voice count budget) * Bursty traffic factor Total Outgoing ASAC Voice Count Budget = (Outgoing ASAC Voice Count Budget + Outgoing MAS voice count
156 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Application Server 5300 QoS support
budget) * Bursty traffic factor Total Bi-directional ASAC Voice Count Budget = Total Incoming ASAC Voice Count Budget + Total Outgoing ASAC Voice Count Budget
Determine Interenclave ASAC video budget
The steps for engineering an LSC ASAC budget of interenclave video call are summarized below: • Calculate the total Erlang value of the subscriber calls Subscriber Traffic Erlang/BH = [(# of Calls /BH * Average call hold time (sec)] / 3600 Erlang per enclave = Subscriber Traffic Erlang/BH * # of Subscribers per enclave • Convert the Erlang value to its equivalent circuit count using the Erlang B formula (http:// personal.telefonica.terra.es/web/vr/erlang/eng/cerlangb.htm) • Calculate ASAC Video budgets for subscriber calls Outgoing ASAC Video Count Budget = Circuit count * % of interenclave call * % of outgoing call * % of video call Incoming ASAC Video Count Budget = Circuit count * % of interenclave call * % of Incoming call * % of video call Bidirectional ASAC Video Count Budget = Outgoing ASAC Video Count Budget + Incoming ASAC Video Count Budget • Calculate Incoming Interenclave Meet Me and Ad hoc call Erlang Interenclave Meet Me call Erlang = # of Calls /BH * % of Meet Me calls/BH * Average # of Meet Me Participants * (Average Meet Me call hold time / 3600) * % of interenclave call Interenclave Ad hoc call Erlang = # of Calls /BH * % of Ad hoc calls/BH * Average # of Ad hoc Participants * (Average Ad hoc call hold time / 3600) * % of interenclave call • Convert the Meet Me and Ad hoc Erlang values to their equivalent number of circuits using an Erlang B formula • Calculate ASAC voice budgets for Incoming MAS Video calls Incoming MAS Video count budget = (Meet Me circuit count + Ad hoc circuit count) * % of Incoming call * % of video call • Calculate ASAC Video budgets for Outgoing MAS Video calls Outgoing MAS voice count budget = (Meet Me circuit count + Ad hoc circuit count) * % of Outgoing call * % of video call • Calculate Total ASAC Video Budget Total Incoming ASAC Video Count Budget = (Incoming ASAC Video Count Budget + Incoming MAS Video count budget) * Bursty traffic factor Total Outgoing ASAC Video Count Budget = (Outgoing ASAC Video Count Budget + Outgoing MAS Video count budget) * Bursty traffic factor Total Bidirectional ASAC Video Count Budget = Total Incoming ASAC Video Count Budget + Total Outgoing ASAC Video Count Budget
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 157 Application Server 5300 IP service network planning
Using the default values, the table below shows the voice and video budgets for various subscriber distributions: Table 42: Sample audio and video budgets
Subscribe Incoming Outgoing Bi- Incoming Outgoing Bi- r Voice Voice directional Video Video directional Budget Budget Voice Budget Budget Video Budget Budget 500 58 58 116 5 5 5 1 000 98 98 196 8 8 16 2 000 167 167 334 11 11 22 3 000 233 233 466 15 15 30 4 000 299 299 598 18 18 36 5 000 364 364 728 21 21 42 7 500 522 522 1 044 29 29 58 10 000 677 677 1 354 39 39 78 15 000 987 987 1 974 54 54 108 20 000 1 292 1 292 2 584 70 70 140 25 000 1 593 1 593 3 186 87 87 174 30 000 1 894 1 894 3 788 102 102 204 35 000 2 193 2 193 4 386 118 118 236 40 000 2 490 2 490 4 980 132 132 264
QoS accounting services
The Application Server 5300 QoS Accounting Service enables QoS reporting capable endpoints to report QoS statistics to their hosted Session Managers (SESM). Each QoS reporting enabled endpoint calculates the metrics (that is, RTCP XR statistics) and creates a QoS report. Then, the endpoint sends that report within the body of a PUBLISH message to the hosted SESM periodically and after the call ends. Finally, SESM and Accounting Manager (AM) record the reported QoS data in IPDRs. QoS accounting provides the source data for monitoring quality of all calls in the network. The analysis of the recorded QoS data allows network administrators to detect quality issues and pinpoint the causes of these issues and gives the network administrators the opportunity to take action before serious quality issues occur.
158 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Application Server 5300 QoS support
The following Application Server 5300 SIP endpoints support RTP Control Protocol Extended Reports (RTCP XR) exchange according to RFC3611: • AudioCodes PRI GW • AudioCodes IAD • Media Application Server (MAS) • Avaya Aura AS 5300 UC Client • 1120E IP Deskphone and 1140E IP Deskphone
Global IP Sound NetEQ
Application Server 5300 uses the advanced NetEQ audio processing technology (Figure 85: NetEQ GIPS audio processing on page 159) from Global IP Sound (GIPS) in its IP products, including the Avaya Aura AS 5300 UC Client and Media Application Server Meet Me Audio Conferencing service (premium conferencing). The NetEQ application provides delay management, adaptive jitter buffer control, and a packet loss concealment algorithm. These capabilities help maintain quality voice communication by reducing the effects of packet loss and delay inherent in IP networks. The NetEQ application is only integrated into the receive side of the audio stream. NetEQ does not require any special preprocessing of the transmitted audio at the originating end of a voice session. Consequently, it does not change the bandwidth requirement of the network.
Figure 85: NetEQ GIPS audio processing
The following benefits of using the NetEQ technology have been observed: • reduces delay by 20 ms to 70 ms while maintaining voice quality • increases packet loss robustness by 100% to 400% • increases significantly voice quality for G.711 under poor IP network performance conditions • increases voice quality for G.729 under poor IP network performance conditions
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 159 Application Server 5300 IP service network planning
Additional information related to the NetEQ is available from the Global IP Sound web site at: http://www.globalipsound.com/. Finally, to ensure that real-time traffic receives consistent treatment within a network, the service planners must make sure a consistent QoS policy (that is, L2/L3 markings and mappings, traffic policing and shaping) is enforced from end to end across the entire network (Figure 86: Consistent L2/L3 QoS policy on page 160).
Figure 86: Consistent L2/L3 QoS policy
IP addressing and routing recommendations
A simple, stable, and scalable IP network environment is essential for deploying Application Server 5300 services to a large subscriber population. In this section we will describe the recommendations and considerations pertaining to IP addressing, IP routing, and IP over the WAN. • IP addressing recommendations on page 161 • IP routing recommendations on page 161 • IP over WAN recommendations on page 163
160 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP addressing and routing recommendations
IP addressing recommendations
The following are IP addressing considerations to take into account when planning an Application Server 5300 network: • To avoid having to readdress the network due to future network expansion, an adequate number of IP addresses should be allocated during the initial planning stages. • For ease of management, IP addresses should be distributed where applicable to be handled by the regional, departmental, or local network administrators. • IP address summarization and allocating IP addresses in meaningful ways such as by region/area or geographical boundary can further simplify network management. Within the boundary, the address spaces can be reserved for some special applications such as IP phones and IADs. • Use variable length subnet masks (VLSM) for efficient use of address space. Only use public IP addresses for devices that need to be accessible from the Internet or Extranet. Avaya recommends that a consistent IP address allocation scheme be used across the enterprise. DHCP can be used for allocating IP addresses for clients’ systems such as PCs, IP Phones, and IADs. Static addresses should be given to devices such as Application Server 5300 core servers, MAS servers, and PRI gateways. When DHCP servers are used, they should synchronize currently allocated IP addresses with a Domain Name System (DNS) database. Avaya NetID provides enterprise-wide DHCP and DNS services with dynamic DNS name synchronization between DHCP and DNS.
IP routing recommendations
It is critical that the IP routing environment is simple and stable, offers quick convergence, and minimizes bandwidth consumption for routing updates. The following are the IP routing considerations to take into account for an Application Server 5300 network deployment: • Use multilink technologies (for example, 802.3ad) to provide the bandwidth scalability, minimize downtime, and speed up fault recovery. • Use Virtual Router Redundancy Protocol (VRRP) to increase network resiliency for the attached hosts. It is particularly useful for the LAN segments where Application Server 5300 servers and gateways are located. VRRP, defined in RFC2338, operates transparently to the end users and requires no special configuration on host devices. It uses the concept of a virtual IP address shared between two or more routers connecting a subnet to the enterprise network. Using the virtual IP address as the default gateway on end hosts, VRRP provides dynamic default gateway redundancy in the event of a failure. • Select routers and switches for backbone and other high traffic areas.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 161 Application Server 5300 IP service network planning
• Use high performance wire-speed layer-2 or layer-3 switches or routers to minimize end- to-end delays in the network. • Use static/default routes over low-speed access links to provide more route stability without consuming bandwidth for routing updates. • Understand the media and signaling IP network convergence impacts and requirements for Application Server 5300 application and use link state based routing protocols for fast network convergence. • Identify the alternate routing paths and the potential bandwidth oversubscription impacts to Application Server 5300 applications as result of major links and switches/routers failures. • Develop a consistent routing model for connecting campus, branch, and Carrier or ISP networks. • Use OSPF or BGP address summarization policies to minimize routing advertisements and to maximize routing stability. • Understand the network growth requirements for users, services, and traffic. These requirements must be converted into the requirements for the network transports, switching capacities, port speeds, port density, routing capacities, and IP address spaces. • Understand the administrative boundaries for permitted traffic types (that is, only allow certain traffic types where explicitly permitted) and their SLA requirements. • Use routing policies to control how Application Server 5300 traffic enters and leaves a routing domain. • Use route policies to control how routes are learned from and advertised to other routers for creating a predictable routing environment. • Prevent the learning of routes from unauthorized sources. • Control the traffic in and out of a routing area or a domain by adjusting the routing metric. • Control how much details that you want to advertise to your neighbors to influence their forwarding path. No segment of the End-to-End Network system shall use split cost metric routing for RTS traffic. This is to avoid jitter caused by packets associated with a single stream taking two separate (that is, asymmetric) paths through the WAN.
162 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network services requirements
IP over WAN recommendations
WANs enable an enterprise to provide Application Server 5300 services to a large population of subscribers. The following are considerations for WAN connections: • Ensure the QoS parameters of the primary and alternate route paths meet the Application Server 5300 requirements. • Enable rapid error detection for quick convergence. • Establish Service Level Agreements (SLA) over the service-provider managed networks. • Ensure delay/latency is within the total end-to-end delay budget. • Ensure jitter introduced by other non-real-time traffic is within the acceptable limit. • Use a separate VC (virtual circuit) for Application Server 5300 traffic (if possible) when ATM or Frame Relay is used to manage QoS for real-time traffic. • Ensure that the proper “holes” are opened through firewalls or NAT devices to support Application Server 5300 traffic. • Ensure consistent Layer-2 and Layer-3 DiffServ mappings for end-to-end QoS support.
IP network services requirements
Certain IP network services are required for supporting Application Server 5300 operations. This section describes the functions provided by each of these IP network services and describes which Application Server 5300 components use these services. • Firewall on page 164 • DHCP on page 165 • DNS on page 166 • Network Time Protocol on page 167
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 163 Application Server 5300 IP service network planning
Firewall
The Application Server 5300 overall strategy for network protection is based on the following architectural design elements: • Authentication/authorization to ensure only officially authorized clients can access the network resources. • Packet filter/firewall: A packet filter, a firewall, or both protect the Application Server 5300 Service Protected Network. • Hardened server Operating System (OS) for better system protection. • Provide UNIStim security for 1120E IP Deskphone and 1140E IP Deskphone. • Hiding the source IP addresses in SIP signaling messages. • Provides Denial of Service (DoS) protection against malicious SIP and HTTP traffic. • Securing the OAMP traffic using SSL/TLS transport. • Protection of valuable services and system resources by controlling service availability through the enhanced service package framework. Avaya recommends that all traffic in and out of the Protected Service Network (Figure 66: Single campus reference network on page 125) is routed through a firewall for protection. Firewall policies (packet filters) must be configured to limit the client communications to Application Server 5300. The traffic filter rules for Application Server 5300 are summarized in Table 43: Application Server 5300 traffic filters on page 164. Note the values for these ports are configurable; what shown are the default values. If the firewall has the ability to protect the network from Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks, Avaya recommends that this functionality be activated. Application Server 5300 AS 5300 Session Managers, Provisioning Managers, and Personal Agent Managers provide a level of (DoS) protection. External DDoS should be enabled to save processing power on the Application Server 5300. Table 43: Application Server 5300 traffic filters
Client IP Client Port Server IP Server Port Use Any UDP > 1023 SESM Service UDP 5060 SIP IP Any UDP > 1023 SESM Service TCP 5061 Secure SIP IP Any UDP > 1023 IPCM Server UDP 5000 Secure IP UNISTIM Any TCP > 1023 Prov Server IP TCP 8080 or HTTP or 8443 Secure HTTP
164 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network services requirements
Client IP Client Port Server IP Server Port Use Any TCP > 1023 PA Server IP TCP 80 or 443 HTTP or Secure HTTP Any UDP > 1023 Mediant UDP > 6000 RTP media Gateway IP Any UDP > 1023 MAS IP UDP 53500 to RTP media 59999
DHCP
Dynamic Host Configuration Protocol (DHCP) is a communications protocol that lets network administrators manage and automate the assignment of IP addresses in an organization’s network. DHCP uses the concept of a "lease" or amount of time that a given IP address will be valid for a computer. The lease time can vary depending on how long a user is likely to require the Internet connection at a particular location. DHCP lets a network administrator supervise and distribute IP addresses from a central point and automatically sends a new IP address when a computer is plugged into a different place in the network. Without DHCP, the IP address must be entered manually at each computer and, if computers move to another location in another part of the network, a new IP address must be entered. DHCP uses User Datagram Protocol (UDP) encapsulated in IP to transmit its request. For more detailed information on DHCP, refer to RFC2131. Within an enterprise, there should be multiple DHCP servers placed at optimum locations (can be placed within the Service Protected Network) for client access. Some of the benefits of using DHCP to assign IP addresses are: • Less configuration required (plug-and-play) • Ease of manageability for IP clients • Less room for configuration errors • Allows for more efficient use of IP addresses. The network administrators must also implement sufficient security protection for DHCP servers to ensure that these services are protected from malicious attacks. UNIStim 1120E IP Deskphone and UNIStim 1140E IP deskphone support the configuration of VLAN parameters through manual configuration or full DHCP. However, the underlying network switches must be configured to filter on VLAN IDs for the VLAN parameters to work properly. Application Server 5300 servers and gateways should not use DHCP; instead they should be provisioned with static IP addresses.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 165 Application Server 5300 IP service network planning
DNS
Domain Name Server (DNS) is a mechanism used in the Internet to translate Fully Qualified Domain Names (FQDN) into IP addresses. A domain name is a meaningful and an easy-to- remember “handle” for an Internet address. Because maintaining a central list of domain name/ IP address correspondences would be impractical, the lists of domain names and IP addresses are distributed throughout the Internet in a hierarchy of authority. If one DNS server does not know how to translate a particular domain name, it asks another DNS server, until the correct IP address is returned. Application Server 5300 provides the capability to perform an asynchronous query to a DNS server to resolve to an IP Address for the FQDN in the Request-URI, Contact, Route, and Record-Route headers. During call processing, the FQDN resolution function is performed by the SESM. The DNS query is executed in the order of DNS -srv for TCP, DNS -srv for UDP, and DNS -A until a matching result is found. The SESM caches the DNS results locally for the subsequent uses. Avaya Aura AS 5300 UC Clients can also be configured either manually or through DHCP with primary and secondary, or tertiary, DNS servers. Access to the Personal Agent Manager is distributed across multiple Personal Agent Manager Servers through DNS Round Robin. The DNS servers are configured to provide a list of Personal Agent Manager Server IP addresses. Each DNS subsequent request should provide the list of IP addresses in a different order than the previous request. It is not recommended that clients register with an FQDN Contact header as it impacts SESM performance and memory capacity Within an enterprise, there should be multiple DNS servers placed at optimum locations (can be placed within the Service Protected Network) for client access. The DNS servers must share their data to ensure consistent operations. The network administrators must ensure the DNS servers are protected from malicious attacks.
LDAP
Lightweight Directory Access Protocol (LDAP) directory is based on the X.500 directory standards and defines a standard manner of organizing directory hierarchies and a standard interface for clients to access directory services. LDAP is a client-server based protocol for accessing directory services of LDAP servers. Application Server 5300 system does not provide LDAP server, but relies on third party LDAP servers supplied by customers to provide LDAP services. The LDAP server should be accessible from all SESMs and PROVs in the network. Customers are responsible for planning, engineering, and support of the LDAP servers. Avaya recommends the LDAP DB supports the following minimal criteria: • LDAPv3 • TLSv1
166 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network services requirements
• SIMPLE Authentication • Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA • Updates via LDIF file Application Server 5300 Commercial Cost Avoidance (CCA) and Hybrid Routing (HR) functions query LDAP server for finding the least cost route to the called party. A CCA call can be initiated from either an IP or a TDM originator by dialing a predefined prefix followed by a called party’s public number. When the call comes into the LSC SESM, the feature prefix activates the CCA service, which then queries LDAP for the called party’s private number. If one exists, the call is routed through the DoD private network, otherwise, the call is routed through the public PSTN networks. When receiving a call from the Multi-Functional Switch (MFS), Application Server 5300 SS SESM Hybrid Routing function queries the LDAP DB to determine whether to route the call via the IP Network or the TDM network. If the caller party is an IP user, the call is routed to the next LSC or Soft Switch (SS) route via the IP network. Otherwise, the call isl be sent back via the SIP trunk to the MFS switch, re-route the call to the TDM network. Application Server 5300 allows a root domain to be shared across multiple AS 3500 sites using LDAP servers. Such a domain is called a “multisite” domain. When new users are added to the multisite domain, the user information is stored in the Application Server 5300 DB and an external LDAP server. The fields stored in the LDAP DB for the HR and CCA functions are: • Username (Subscriber username, part of LDAP DN) • Alias (Public number, required for CCA) • Directory Number (Private number, required for CCA) • LSC CCA-ID (required for HR) • SS CCA-ID (required for HR)
Network Time Protocol
Network Time Protocol (NTP) is a protocol that is used to synchronize computer clock times (Time of Day) in a network of computers. NTP is now an Internet standard that uses Universal Time Coordinated (UTC) to synchronize computer clock times to a millisecond and sometimes to fractions of a millisecond. UTC time is obtained using several different methods, including radio and satellite systems. Specialized receivers are available for high-level services such as Global Positioning Systems (GPS) and the governments of some nations. However, it is not practical or cost-effective to equip every computer with one of these receivers. Instead, computers designated as “primary time servers” are outfitted with the receivers. The servers use protocols such as NTP to synchronize the clock times of network-connected computers. Degrees of separation from the UTC source are defined as strata. The term NTP applies to both the protocol and the client/server programs that run on computing devices. In basic terms, the NTP client initiates a time request exchange with the time server. As a result of this
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 167 Application Server 5300 IP service network planning
exchange, the client is able to calculate the link delay and local offset and adjust its local clock to match the clock at the server. As a rule, six exchanges over a period of about five to 10 minutes are required to initially set the clock. Once synchronized, the client updates the clock about once every 10 minutes, usually requiring only a single message exchange. Redundant servers and varied network paths are used to ensure reliability and accuracy. In addition to client/server synchronization, NTP also supports broadcast synchronization of peer computer clocks. NTP is designed to be highly fault-tolerant and scalable. For more detailed information on NTP, refer to RFC1305 or the Network Time Protocol web site located at http://www.ntp.org. The Application Server 5300 system is shipped with a default configuration where the servers hosting the AS 5300 System Manager use their local hardware clock as the preferred reference. The local hardware clock is undisciplined and drifts. For this reason, the default configuration should be modified as soon as the Application Server 5300 is up and has access to a disciplined source of time. The only way to ensure that the Application Server 5300 system is synchronized to UTC is to use a reliable, low-stratum time server or an external clock connected directly to the servers for AS 5300 System Manager. The recommended NTP subnet configuration for the Application Server 5300 system is as follows: • Both active and standby AS 5300 System Manager servers should obtain NTP service from at least two different sources of synchronization, which should both exist at the same stratum level. • Both servers should peer with each other. • Both servers should also peer with one other source at their own stratum level (optional). • Other servers should obtain NTP service from both servers
Figure 87: Recommended Application Server 5300 NTP configuration This configuration, as shown in Figure 87: Recommended Application Server 5300 NTP configuration on page 168, has a total of four outside synchronization sources, that is, two sources at the lowest stratum level plus two other sources at the same stratum as the servers for AS 5300 System Manager. An outside source is one that is not part of the Application
168 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IP network services requirements
Server 5300; neither a server for the AS 5300 System Manager nor a server for other Application Server 5300 component. Ideally, each path shown in the diagram should use a different physical network path to minimize a single point of failure.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 169 Application Server 5300 IP service network planning
170 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Chapter 9: Reliability and robustness
A service network is considered to be highly available if, when failure occurs, the network continues to provide services without interruption, although possibly at a reduced rate. A service network is considered to be highly robust if the network performs well not only under ordinary conditions but continues to perform well under stressful conditions when traffic volume exceeds the engineered capacity. In this chapter, we will describe the Application Server 5300 built-in fault resilient capabilities for handling various fault conditions and the overload prevention and overload control mechanisms to mitigate unexpected traffic volumes and ensure service continuity. Navigation
• Server platform redundancy on page 171 • Network and power redundancy on page 172 • SIP Core component reliability on page 172 • Media Application Server on page 177 • Media Gateway on page 178 • Access Client reliability on page 179 • Overload control on page 181 • Denial of Service mitigation on page 184
Server platform redundancy
Application Server 5300 server reliability is achieved by using a robust operating system, redundant servers, and redundant hardware within a server. The IBM x3550 M3 server is used as the server platform for both Application Server 5300 SIP Core server and the MAS server. The server provides built-in redundancy including dual 73 GB 10K RPM Hot Swap SAS Disks, hot-swap redundant power supplies, hot-swap redundant fans, and dual integrated 10/100/1000 Mbps Ethernet Interface Cards (NICs). Application Server 5300 server runs the RedHat Enterprise Linux version 5 (RHEL5). The Red Hat Enterprise Linux binds the dual integrated Ethernet interfaces into a single channel. The channel bonding protects the server from a single point of network interface or network link failure. When the bonding driver detects failure of the active interface, it switches to the standby interface transparently to the applications running on the server. The MAS server runs the RHEL5 operating system. All MAS applications are deployed on top of the RHEL5 operating system. The dual integrated Ethernet links are configured for
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 171 Reliability and robustness
redundancy using port bonding. When the bonding driver detects failure of the active interface, it switches to the standby interface transparently to the applications running on the server.
Network and power redundancy
In addition to supporting redundant servers, Avaya recommends that the servers are connected to separate protected power sources and network switching devices for more protection (Figure 88: Separate L2 switch and power connections for more protection on page 172).
Figure 88: Separate L2 switch and power connections for more protection
SIP Core component reliability
Application Server 5300 uses various software and hardware fault protection and recovery strategies for the SIP core components to ensure the maximum system availability. These strategies include software auto-restart when a function component (the term functional component is equivalent to the term Network Element) exits unexpectedly, 1:1 auto-failover to a hot-standby server when a real-time service component fails to function, and 1:1 manual failover when a non real-time service component fails. The choice of strategy for a particular
172 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] SIP Core component reliability
functional component is balanced between the time to recover and the downtime service impacts. • AS 5300 Session Manager reliability on page 173 • Database Manager reliability on page 175 • Accounting Manager reliability on page 175 • AS 5300 System Manager and Fault Performance Manager reliability on page 175 • Provisioning Manager and Personal Agent Manager reliability on page 176
AS 5300 Session Manager reliability
The AS 5300 Session Manager (SESM) is the Application Server 5300 call processing engine. It processes SIP signalling messages, handles SIP sessions, and provides the core services that facilitate communication between SIP clients. The Application Server 5300 SESM supports a 1-to-1 redundancy autofailover mechanism. To speed up the autofailover process, both active and standby AS 5300 Session Managers are preloaded into their in-memory cache with the information required for execution from the database during the power-up initialization cycle. During execution, runtime information is also transferred (that is, checkpointed) from the active SESM to the standby SESM to maintain service integrity after the autofailover. The runtime information checkpointed from the active SESM for each subscriber includes subscription for services, service package, address book, assistant, presence, and call state information. This checkpointing feature allows all existing calls to proceed normally on the newly active SESM without interruption. Furthermore, all media flows of the existing active calls will remain active after failover.
Figure 89: AS 5300 Session Manager heartbeat and checkpointing
To determine the health of the active SESM, the standby SESM monitors the active SESM by periodically sending heartbeat messages to the active SESM (Figure 89: AS 5300 Session Manager heartbeat and checkpointing on page 173). If a SESM fails to receive a heartbeat message from its mate, it sends it a series of query messages, each requiring an immediate response. If the active SESM fails to answer, then the standby SESM presumes it has failed. This mechanism results in a failure detection time between 3.5 and 4.0 seconds for halting failures. The standby SESM assumes the call processing responsibilities and begins to service requests. The transition of a standby SESM to an active state takes less than 5 seconds to complete, which is similar to an IP network routing convergence time. This allows the new active SESM ready for call processing after the network convergence is complete. For those
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 173 Reliability and robustness
requests dropped during transition, the endpoint SIP agents assume packet loss and retransmit. To detect network isolation, a SESM periodically monitors the layer 2 link status of its redundant Ethernet interfaces. A SESM considers itself network isolated if both of its Ethernet interfaces are down. While the active SESM remains active when detecting a network isolation condition, the standby SESM shuts itself down upon detecting such condition. An average network isolation detection time is less than 2 second. Since a network isolation is detected before detecting its mate failure (that is, 2 < 3.5), the Standby SESM will shut itself down when detecting network isolation before attempting to activate. However, when the network failure is recovered, an active SESM that has previously detected network isolation yields control to its active mate. To provide failover transparency, the active SESM uses an interface- independent floating service logical IP address to communicate with all SIP endpoints including clients, gateways, and media servers. The standby SESM, once active will take over the service logical IP address during the auto-failover process. To protect the SIP session level robustness and integrity, the Application Server 5300 SESM implements a Session Timer feature to monitor the health of all active SIP sessions running on the SESM, The Session Timers of the active sessions are periodically refreshed by UPDATE requests (or re-INVITES for the clients that don’t support UPDATE). When a Session Timer is expired for a session, the AS 5300 Session Manager terminates the session by sending BYE to the endpoints, removes the associated call state, and frees the resources associated with the call. The Session Timer value is configurable with the minimum value of 90 seconds. The recommended value is 1800 seconds (30 minutes). The Session Timer is also supported by all services that trigger mid-call UPDATE/re-INVITE/ REFER request messages due to hold/retrieve or transfer scenarios. These include services that involve session manager in third call party call control scenarios (for example, MAS services such as Ad hoc, Meet Me, Announcement, MOH). When the AS 5300 Session Manager receives these mid-call messages, it restarts the Session Timer for the dialog. To maintain the integrity of all active sessions even after the Active AS 5300 Session Manager Failover, the Session Timer is checkpointed to its pairing Standby AS 5300 Session Manager. The Session Timer on the standby is started after the create checkpoint takes place, and is restarted whenever the interval expires. To make sure mid-call refreshes are not lost during the failover, the session interval on the standby is the double time amount of the active side. Finally, to maintain the robustness of interenclave call sessions, the LSC SESM monitors the call setup return status to see if the connection to MFSS SS SESM is down. If the returned status is 480 Temporary unavailable with the reason of ‘Address Unresolvable’, it indicates the connection to the remote node is down. The SESM raises an alarm indicating the TLS connection is down and sends an OPTIONS message with a one-minute timer started for the message. When two consecutive 200 OK responses are successfully received, the SESM clears the alarm and re-establishes the TLS connection with the remote SESM.
174 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] SIP Core component reliability
Database Manager reliability
The Database Manager operates in a redundant active-hot standby configuration. Within a Database Manager, the database is fully protected by using internally mirrored disk drives for physical data store. The active and standby Database Managers also use Master-Master replication for data synchronization between two servers. The autofailover is handled by the database clients (for example, SESM, PROV). The clients use Avaya Transparent Application Failover (TAF), a process that allows client applications to switch over to a backup database when the main database fails. Halting failure of the active Database Manager server is detected between 10 and 70 seconds after the failure. However, the SESM continues to provide service with cached subscriber data in the interim before it detects this. Once detected, failover to the standby Database Manager is immediate. Since both active and backup databases have the consistent data, the Application Server 5300 applications can continue to operate normally using the backup database in the event of a failed active database.
Accounting Manager reliability
The Accounting Manager (AM) is responsible for formatting, storing, and forwarding billing data from its associated Session Managers. It formats accounting files into the IPDR (Internet Protocol Detail Record) format. It enables the transport of accounting information from the Application Server 5300 system to a back-end billing system. The Accounting Manager is deployed in pairs operating in an active-hot standby redundant configuration. All Session Managers are configured with the AM's Service IP address. When the active AM fails, the standby AM will take over the Service IP address and start to provide service Additionally, the Session Manager has the capacity to store up to 24 hours worth of Accounting Records. The accounting records are preserved during the SESM failover.
AS 5300 System Manager and Fault Performance Manager reliability
The AS 5300 System Manager (SM) is responsible for the configuration, monitoring and maintenance of all Application Server 5300 Network Elements (NE) (for example, SESM, Database). The Fault-Performance Manager (FPM), deployed as a part of the AS 5300 System Manager, is responsible for formatting, storing, and optionally forwarding fault, performance data (specifically Operational Measurements [OMs]), and logs from associated Network Elements. Additional FPM servers can be deployed when the total number of NEs exceeds 50.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 175 Reliability and robustness
Application Server 5300 requires the Network Element Daemon (NED) be installed on every server. The NED acts as a AS 5300 System Manager proxy, performing tasks such as retrieving files from the AS 5300 System Manager for deployment to the server, creating and maintaining the network element file structure on the server, and acting as watchdog for network element Java Virtual Machine processes and restarting them if they unexpectedly exit. SM maintains connectivity using the Network Element Daemons (NEDs) to all the running NEs in the network in order to enable management activities. The NED running on a server takes commands from the SM to deploy, start, and stop NE instances. It also monitors the health of the NEs running on the server and restarts any NE that exited unexpectedly. A pair of servers is used for the SM/FPM running in an active-hot standby redundant configuration. If the server for the primary AS 5300 System Manager fails, the secondary server will automatically become active and provide AS 5300 System Manager functions. No state information is required to be maintained for failover. The SM/FPM has its own service logical IP address that can “float” to the standby server during failover. This facilitates a speedy reconnection after a failover for the northbound (OM, Log, SNMP) traffic to the backend Operation Support System (OSS).
Provisioning Manager and Personal Agent Manager reliability
The Provisioning Manager (Prov) provides the administrators secure interface to the Database Manager (DB) for provisioning system, domains, devices, gateways, translations and routing, subscribers, and services-related information. The Personal Agent Manager (PA), deployed as a part of the Provisioning Manager, provides secure interface to the database to access or update the subscriber specific service settings (for example, call routing and screening, user pictures, presence, directory, personal, mailbox, and conference information). In addition, the Personal Agent Manager allows the Avaya Aura AS 5300 UC Clients to download Calling Picture IDs, address book, and automatic software updates (ASU). Prov, SM, and DB work together to ensure the changes made on Prov during the runtime are reliably propagated to all NEs using the information. This is achieved using the Application Server 5300 reliable internal event framework. As shown in Figure 90: Reliable configuration updates on page 177, Prov sends change events to the SM after changes are made during the runtime. The SM stores the events to the DB and sends the event notifications to the SESM. The SESM downloads the updated information from DB and acknowledges the event notifications. The SM only clears the event DB journal after receiving the positive acknowledgement from the SESM. The event DB journal guarantees the delivery of the events to the SESM in the correct order even in the unlikely situation of the active SM crashing. A pair of servers can be used for the Prov/PA running in an active-active redundant configuration. The DNS system should be provisioned with all the Prov/PA IP addresses for the dispatching of DNS requests in a round-robin fashion. The Personal Agent Client, Avaya Aura AS 5300 UC Client, and Provisioning Client use fully qualified hostnames in the URL. If the client cannot connect to the primary IP address provided in the DNS response, it will attempt
176 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Media Application Server
to connect to the secondary (and tertiary if configured and necessary). This ensures service availability in the event of the failure of a Prov/PA Manager.
Figure 90: Reliable configuration updates
Media Application Server
The reliability of MAS services are provided by grouping the server resources in a logical pool, which allows the servers in the pool to act as one logical service instance (Figure 91: Redundant MAS server pool on page 178). The server pools are provisioned with the services they provide: Ad hoc, Meet Me, Music on Hold, Announcement, and Unified Communications. Application Server 5300 will distribute the requests over the MAS servers in a pool in a round robin or weighted distribution fashion. Should one MAS server fail, the remaining servers will continue to handle the requests. In addition, additional pools of MAS services can be added at any location to improve the quality of local services. The pools are created at the domain level and accessible throughout the domain tree. When determining how to route a request for service, Application Server 5300 uses the user’s subdomain information to determine proper routing for the service. If there is a local pool assigned to the subdomain for the service, the request is routed to a server of the pool. If there is no local server pool, the availability of the server pool in the parent domain is consulted. The user’s subdomain tree is traversed upward until an appropriate server-to-service mapping is encountered. If no server is available, an error “Server not found” is returned. When redundant MAS servers are used for reliability, Avaya recommends that they are connected to separate protected power sources and network switching devices for more protection. They should also be engineered to operate at 50% of their capacity to handle the extra traffic after the failover condition occurs.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 177 Reliability and robustness
Figure 91: Redundant MAS server pool
Media Gateway
The Mediant Gateway provides the signalling interface between the SIP-based Application Server 5300 and the systems that use ISDN Primary Rate Interface (PRI) protocol. For High Availability (HA), the MG3000 hardware design contains redundant modules for every part of the system, including redundant Gigabit Ethernet connections, redundant power nodules, redundant fans, and redundant VoIP gateway blades capable of supporting up to 2,016 simultaneous voice channels. All modules (that is blades, power supplies, and fans) are hot- swappable, allowing component replacement with no disruption to service. Each blade has its own local IP address used for loading the software by TFTP. The system, however, has only one global IP address used by the active blade at run time. Upon detection of a blade failure, the redundant standby gateway blade issues a switch-over operation and takes over the call processing activities. The MG1000 offers a lower cost model of PRI gateways for the small enterprises or branch offices. The device supports Ethernet redundancy by providing two Ethernet ports, located on the CPU module. By default, the Ethernet port redundancy feature is disenabled and can be enabled using the ini file parameter MIIRedundancyEnable. When redundancy is enabled, one Ethernet port is active and the other is redundant. If an Ethernet connection failure is detected, the CPU module switches over to the redundant Ethernet port. The CPU issues a Major alarm notifying of the failed physical port. If the first Ethernet port connection is restored, the Major alarm is cleared. The first physical port now
178 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Access Client reliability
becomes the redundant Ethernet port in case of failure with the active physical port (which is currently the second physical port). At the service level, Application Server 5300 can be provisioned with additional gateways to support more reliable call routing services. Application Server 5300 SESMs distribute the calls over the available gateways in a round robin fashion. Should one gateway fail, the remaining gateways will handle the calls. In addition, additional gateways can be added at any location to improve the local services. In a carefully planned network, users can be routed to servers in physical proximity to the user's location to minimize expensive communications backhaul to the central site. When redundant gateways are used for reliability, Avaya recommends that they are connected to separate protected power sources and network switching devices for more protection (Figure 88: Separate L2 switch and power connections for more protection on page 172).
Access Client reliability
This section discusses the following clients • IP Deskphone reliability on page 179 • Avaya Aura AS 5300 UC Client reliability on page 180 • Personal Agent reliability on page 180 • Integrated Audio Device reliability on page 181
IP Deskphone reliability
The SIP 1120E IP Deskphone and SIP 1140E IP Deskphone support SIP over UDP and TLS/ TCP protocols. When TLS/TCP is used, the phone will establish and maintain a persistent connection with the home Session Manager (SESM) Service IP address. Once this connection is established, the SIP phone will send and receive all SIP messages over this persistent connection. Reusing the persistent connection also solves the firewall problem because the firewall does not allow the SESM to create a new connection to the client. The SIP IP Deskphones use CRLF Keep-alive mechanism to monitor the health of the TCP/ TLS connection with the SESM. The phones will periodically (default 15 seconds) send a packet (containing CRLF) to the SESM to ensure the server is alive. The SIP phones can also be configured to use a light weight TCP keep-alive mechanism to monitor the health of TCP connection. When detecting a connection failure, the phone will wait a default of 30 seconds (configurable) before attempting to reregister with the SESM. The UNIStim 1120E IP Deskphone and UNIStim 1140E IP Deskphone support one primary IP Client Manager and one secondary IP Client Manager. The health of the active IPCM is monitored by a Keep-Alive mechanism. There is a configurable Keep-Alive timer on both IPCM and IP Deskphone. The Keep-Alive message sent by the IPCM to the UNIStim IP Deskphone
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 179 Reliability and robustness
contains a value for the Keep-Alive Phone timer. When the UNIStim IP Deskphone receives the Keep-Alive message, it sets its Keep-Alive Phone timer to the value (default 30 seconds) provided in the message. Each time the Keep-Alive message arrives at the UNIStim IP Deskphone, the Keep-Alive Phone timer is reset. If the timer expires before a new Keep-Alive message is received, the UNIStim IP Deskphone assumes that there is a problem. At this point, the IP Deskphone switches to the pre-configured secondary IPCM. The secondary IPCM assumes the responsibilities of managing the UNIStim IP Deskphones and begins processing SIP and UNIStim messages for the phones. The switchover time is less than 5 seconds. The IP Client Manager only communicates with the UNIStim IP Deskphone in the signaling plane. Voice media are not sent between the IP Client Manager and the UNIStim IP Deskphones. If a call is active when the primary IP Client Manager goes down, the call will remain active for the UNIStim IP Deskphone. When a call is established on a UNIStim IP Deskphone, the IPCM begin sending a reset timer value of 10 hours. This prevents the phone from resetting while a call is in progress in the event of a loss of signaling to the IP Deskphone. Upon completion of the call, the reset timer transmitted to the IP Deskphone is once again 30 seconds. In the event of loss of signaling while a call is in progress, the phone will reset if a button is pressed on the IP Deskphone.
Avaya Aura AS 5300 UC Client reliability
Avaya Aura AS 5300 UC Client is a Microsoft Windows-based application built with multimedia technologies. It is an intelligent SIP endpoint that is installed on a personal computer (PC). The Avaya Aura AS 5300 UC Client provides advanced IP telephony features, many of which are unavailable in a traditional Public Switched Telephone Network. With the use of the Avaya Aura AS 5300 UC Client, subscribers can access the services provided by the Application Server 5300 system over an IP network using a PC. The Avaya Aura AS 5300 UC Client supports SIP over a UDP or TLS/TCP connection. It monitors the health of the TCP/TLS connection by sending CR/LF keep-alive messages at the application layer every 15 seconds. When detecting a connection failure, it will reestablish a new TCP connection and perform the TLS handshake as required. The default interval of 15 seconds is chosen as result of balancing the speed of detecting a broken connection (that is, SESM failover) and the amount of overhead traffic. The keep-alive message interval is configurable.
Personal Agent reliability
Personal Agent is a Web-based tool. It allows users to manage their communication preferences from any location with no software installation required. When multiple Prov/PA Manager servers are deployed in a system, the Personal Agent clients query the DNS for the server address. If the client cannot connect to the primary IP address
180 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Overload control
provided in the DNS response, it will attempt to connect to the secondary (and tertiary if configured and necessary).
Integrated Audio Device reliability
The AudioCodes IADs are analog VoIP gateways for connecting legacy telephones to Application Server 5300. The IADs use TCP/TLS Secure SIP messages to communicate with their SESMs. It provides protocol conversion between Session Initiation Protocol (SIP) and the phone’s analog signal. It also converts between packet-based and circuit-based voice streams. The IAD is responsible for maintaining the TCP/TLS connection with the SESM. The IAD send keep-alive traffic to monitor the TCP/TLS connection. When detecting a connection failure, it will reestablish a new TCP connection and perform the TLS handshake as required. For example, after the SESM switchover, the IAD will detect the broken TCP/TLS connection to the failed SESM, and will reestablish a new TCP/TLS connection with the new active SESM. The client will also perform a new SIP registration with the active SESM.
Overload control
The goal of Application Server 5300 overload control is to ensure the system remains up and running under very heavy traffic and recovers autonomously once the traffic subsides. To that end, Application Server 5300 supports three levels of overload control: Minor, Major and Critical. The following table summarizes the behaviors of these controls. Table 44: Overload level behaviors
Overload Level Behavior Minor Presence Notifies are blocked Major All Notifies, Subscribes, IMs, Registers blocked Critical New INVITEs (calls) are blocked. However the RE- INVITES, INFO and OPTIONS are still allowed. All 911 calls (Invites) are allowed.
To prevent the standby AS 5300 Session Manager being overloaded after becoming active, the overload control is disabled for around one minute after failover. Figure 92: Minor Overload behavior on page 182 depicts the behavior of Minor Overload over a period of time. In minor overload, only Notifies are blocked. It is important to note that a AS 5300 Session Manager goes into a particular overload condition only when the overload condition persists beyond the engineered threshold for 70 seconds (rolling average). This helps preventing the system from quickly overreacting to a transient traffic spike.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 181 Reliability and robustness
Figure 92: Minor Overload behavior
Figure 93: Major Overload behavior on page 182 depicts the behavior of Major Overload over a period of time. In major overload, only INVITEs (calls) are allowed.
Figure 93: Major Overload behavior
Figure 94: Critical Overload behavior on page 183 depicts the behavior of Critical Overload over a period of time. In critical overload, only emergency calls are allowed.
182 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Overload control
Figure 94: Critical Overload behavior
After entering a particular level of overload, the system starts to respond with SIP 503 messages to the new requests. Since no new requests will be processed, it allows the system to exit a particular overload level and continue to process the new requests again. The overload control is based on the maximum transaction rate possible of a particular transaction type at a given overload control level. The maximum rate of various transaction types at different overload control levels is described in the following table. Table 45: Maximum call rates before critical overload
Max call rate (INVITES) Max rate before the critical overload Max IM rate Max rate before the Major overload Max Presence Subscribe rate Max rate before the Major overload Max Presence Update rate Max rate before the Major overload Max Presence Notify rate Max rate before the Minor overload
The Application Server 5300 overload controls have been properly engineered to ensure that the system continues to achieve the maximum call rate under various heavy traffic conditions (for example, large volume of IM traffic). However, the actual maximum completed call rate varies depending on the actual traffic mix (Figure 95: Maximum transaction rates of two different traffic mixes on page 184).
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 183 Reliability and robustness
Figure 95: Maximum transaction rates of two different traffic mixes
The diagram shows the distribution maximum rates of different transaction types running under a 30% overload condition. The overload is caused by running tests of a traffic mix that consumes 30% over the maximum weighted transaction capacity. As shown in the figure, the success rate for SIP calls is always higher than all other transaction types. However, the transaction success rates tends to be better with the IM centric traffic mix (call approximately 98%, IM approximately 79%, registration approximately 78%, presence subscription approximately 79%, presence update approximately 79%) than the Call Centric traffic mix (call approximately 84%, IM approximately 71%, registration approximately 70%, presence subscription approximately 71%, presence update approximately 71%). The lab test results show that the transaction completion rates depend more on the type of traffic mix than just on the total number of transactions.
Denial of Service mitigation
Application Server 5300 implements a Denial of Service Mitigation mechanism to protect the Session Manager, Provisioning Manager, and Personal Agent Manager against Denial of Service (DoS) attacks. This is done by temporarily blocking SIP and HTTP/HTTPS requests from a particular source when an abnormal rate of requests is detected. In conjunction with the network firewalling and packet filtering mechanisms in place, the Denial of Service Mitigation adds another layer of service protection to improve the system robustness against various malicious DoS attacks and faulty babbling SIP user agents. The DoS detection mechanism uses a token bucket algorithm to mitigate the rate of traffic. Each traffic source is assigned a token bucket with limited capacity, which allows the source to send a burst of traffic up to the bucket’s limits. A number of tokens are added to each bucket at a predefined interval. The mitigation algorithm subtracts one token for each new transaction. When the bucket becomes empty, the detection mechanism triggers a lockout condition and places the source in a lockout state. The DoS mitigation mechanism will cleanup the last transaction and drops all subsequent packets from the source. To prevent a source from being permanently locked out, the DoS mitigation mechanism does a periodical mark and sweep
184 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Denial of Service mitigation
audit, which automatically clears the lock out condition after a specified interval. After the alarm is cleared, the endpoint is removed from the “lock out” list and the regular traffic resumes. Network elements such as the MAS can generate significant amount of SIP messaging traffic. To avoid locking out legitimate traffic, Application Server 5300 automatically adds all managed and monitored network elements to the trusted node list. For additional trusted elements such as the PRI gateways, the System Administrator can provision them as trusted elements. Trusted elements are exempt from the DoS mitigation filtering. Denial of Service Mitigation can be enabled and disabled per Network Element instance using the System Management Console. By default this feature is disabled. In summary, the DoS mitigation provides the following functions: • Detect and report (alarm) excessive SIP and HTTP/HTTPS traffic. • Discard packets from the traffic source (identified by IP address and port) that exceeds the permitted traffic rate. • Clear the lockout condition automatically after 60 seconds to free the administrators from manually unlocking the blocked sources. • Permit the provisioning of a list of “trusted nodes”, from which the traffic is exempted from this filtering mechanism. • Exempt the traffic between Application Server 5300 Network Elements automatically The DoS Mitigation engineering parameters and their associated default values are shown in the table below. The Denial of Service Mitigation parameters have been engineered in anticipation of the maximum number of normal attempts from various SIP clients. Avaya recommends that you do not change these parameters without the assistance of Avaya support personnel. Table 46: DoS Mitigation engineering parameters
Session Manager MaxNumLockouts 10 000 LockoutAuditDuration (sec) 60 SIPTrans_MaxNumSuspects 1000 AlarmThresholds (percentage) 10, 50, 100 SIPTrans_MaxAttemptsPerInterval 20 SIPTrans_SampleInterval (sec) 5 SIPTrans_BucketCapacityFactor 108
• MaxNumLockouts defines the maximum number of endpoints that can be locked out at a given time. • LockoutAuditDuration defines the mark and sweep audit interval in seconds.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 185 Reliability and robustness
• SIPTrans_MaxNumSuspects defines the maximum number of source IP addresses that can be monitored at a given time. • SIPTrans_MaxAttemptsPerInterval specifies the maximum number of transaction requests per SIPTrans_SampleInterval sample interval. The token bucket size is determined by multiplying the SIPTrans_BucketCapacityFactor value by the SIPTrans_MaxAttemptsPerInterval value. • AlarmThresholds, expressed in percentage of the MaxNumLockout value, defines the minor, major, and critical alarm thresholds indicating the percentages of endpoints that are currently locked out. For the Session Manager, the default behavior is to temporarily block out all SIP requests from a source IP after exceeding a sustained rate of 4 SIP transactions per second (that is, MaxAttemptsPerInterval / SampleInterval). A mark and sweep audit will automatically remove the lockout out condition. This mark and sweep audit runs every 60 seconds, which translates to a lockout out duration of 60 to 120 seconds. The system will detect and block up to 10 000 sources, based on the source IP address and port. A log will be generated each time a source IP address and port is locked. Individual SIP requests that are dropped during the lockout period will not be logged. A minor alarm will be generated when a threshold of 100 nodes (10%) are blocked, a major alarm at 5 000 nodes (50%), and critical alarm at 10 000 nodes (100%). EBCs are Application Server 5300 external nodes that can generate a large amount of traffic. The system administrator must provision the EBCs as trusted nodes so that they can be exempted from the Application Server 5300 DoS filtering.
Layer 2 Geo-redundant network architecture
As previously described, Application Server 5300 provided several software and hardware fault protection and recovery mechanisms to ensure the maximum system availability. However, when all Application Server 5300 service components are deployed at a single location, the system could still be vulnerable to the single site failure as result of a natural disaster or other emergencies. To support a high availability network for mission critical communications, the Application Server 5300 L2 geo-redundant network architecture extends the protection and recovery mechanisms beyond a single site boundary. The L2 geo-redundant architecture splits an Application Server 5300 system between 2 separate sites connected by common high performance VLANs. The active and standby servers work together over common VLANs protecting the subscriber services from the single data center failures. To assure the seamless and continuous operations, Application Server 5300 assumes the connections between the primary and secondary sites must meet L2 Geo site link/VLAN/delay characteristics of maximum supported distance. Additionally, the enterprise network must ensure no single point of failure between any Application Server 5300 components and must
186 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Layer 2 Geo-redundant network architecture
recover quickly from its own failures (for example, links and L2/L3 switches) to allow Application Server 5300 operates seamlessly over the network. The details of Application Server 5300 L2 geo-redundant network architecture and requirements are provided in Avaya Aura® Application Server 5300 High Availability Fundamentals, NN42040-115.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 187 Reliability and robustness
188 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Chapter 10: Performance monitoring
After the initial deployment, the system planners must continue to monitor and collect system performance data to better understand subscriber service usage profiles. This ensures that 1. The service usage assumptions made in the planning stage are still valid (that is, no significant changes of the subscriber count and usage behaviors). 2. The performance targets are consistent with the initial design and operate within the designed capacity range. In this chapter, we will discuss the use of Application Server 5300 Internet Protocol Detail Record (IPDR) accounting records for subscriber and service usage profiling and the use of Application Server 5300 Operational Measurements (OM) for performance and capacity analysis. These types of analyses provide the service planners with the insight necessary for running a smooth operation and foresight needed for long term planning. Navigation • Subscriber and service usage profiling on page 189 • Performance analysis on page 192 • Calculating SESM capacity utilization using OMs on page 202 • Understanding bursty traffic on page 208 • Other performance impacting events on page 210
Subscriber and service usage profiling
The Application Server 5300 accounting framework consists of a Record Transfer Agent (RTA) running on the AS 5300 Session Manager and the Accounting Manager (AM). The RTA collects raw accounting records from active sessions and transports blocks of them to the AM over the primary data stream in near real-time. RTA stores raw account files in the “/var/mcp/spool/acct” directory. When the primary stream is disrupted due to communication problems, the RTA will temporarily store the accounting records on the AS 5300 Session Manager’s local disk for up to 24 hours. When the communication path is restored, the RTA will resume the primary data stream and will also establish a secondary recovery data stream to send previously stored records to AM in lower priority. To ensure that no data is lost from the RTA to the AM, the RTA will not remove accounting data sent to the AM until it receives confirmation that the data has been successfully processed by the AM. The AM is responsible for receiving the raw accounting records from an RTA, converting them to IPDR (configurable 2.0 or 3.5) format, saving them to the local file storage, and sending an
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 189 Performance monitoring
acknowledgement to the RTA to indicate that the received data has been successfully processed. The AM can simultaneously receive accounting data from multiple RTAs. For each connected RTA, the AM supports reception of both a primary and a recovery accounting data stream. Based on the primary or secondary stream where the raw accounting records were received, these formatted records are stored to a file within different directories on disk. The AM will retain the processed accounting data on the disk for a default of 7 days. Accounting files more than 7 days old are deleted by an audit process in the AM. The AM stores the accounting files in the “/var/mcp/oss/acct/” directory. The formatted accounting records can be pushed toward the back-end OSS using FTP or pulled by the OSS using SFTP. A formatted record file becomes a candidate for pushing to the OSS once it has been closed, when it is no longer being written by the recording system. If no FTP push is configured, it is assumed that records will be retrieved by SFTP pull. Application Server 5300 uses an event-based accounting system to record session events generated by originating and terminating call models. Accounting records are generated for each of the events. The account records of a particular session are correlated using the SIP Correlation ID field. Network Time Protocol (NTP) is used to ensure that timestamps are synchronized for all accounting records. The size and number of accounting records depends upon the event and type of sessions being recorded. As an example, for a simple SIP call, there are four accounting records (one originating ingress record, one originating egress record, one terminating ingress record, and one terminating egress record). An IPDR describes an event between a Service Consumer (SC) and a Service Element (SE). The Service Session (SS) element groups the Service Consumer and Service Element information. Details of the event are contained in the Usage Entry (UE) elements. All IPDRs have a time indicating when the event occurred. An IPDR record records the call related information such as subscribers, SIP user agents, codecs, gateways, MASs, calling patterns, type of calls, call start/stop times, originating/terminating addresses, call duration, disconnect reason. For more detailed information, see Avaya Aura® Application Server 5300 Accounting Records Reference, NN42040-501. This information is very useful for profiling subscriber system resources usage behaviors, studying calling patterns, and analyzing service and resource consumption. It allows the planners to analyze service and resource usage metrics and perform system capacity and trend analysis. The following are some of the useful usage information that can be obtained through analyzing the IPDR records: • How many subscribers actively use the system (or a particular AS 5300 Session Manager) during a busy hour? • How services are used by a subscriber (an average of all subscribers) during a busy hour? - number of IMs sent - number of IMs received - number of calls without video - number of calls with video - number of Ad hoc calls initiated without video
190 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Subscriber and service usage profiling
- number of Ad hoc calls initiated with video - number of Meet Me calls initiated without video - number of Meet Me calls initiated with video - number of Music on Hold calls - number of Announcement calls - number of Multi-Level Priority Preemption (MLPP) calls - number of Unified Communication message deposited - number of Unified Communication messages retrieved - number of PSTN calls • Where are the service requests (for example, calls, IMs) coming from and going to (average for all subscribers)? - originated and terminated on the same SESM - originated on one SESM and terminated on another SESM - originated from and terminated in another SIP domain - originated from and terminated in PSTN network • What is the average hold time (an average of all subscribers) for - regular calls - Ad hoc calls - Meet Me calls - Music on Hold calls - Announcement calls - Unified Communication calls • What is the percentage of video calls (an average of all subscribers) for - regular calls - Ad hoc calls - Meet Me calls - Music on Hold calls - Announcement calls • How audio and video codecs are used (% usage distribution for all subscribers) for - regular calls - Ad hoc calls - Meet Me calls - Music on Hold calls
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 191 Performance monitoring
- Announcement calls • How long does it take (average and maximum) to set up a call? - regular calls - Ad hoc calls - Meet Me calls - Music on Hold calls - Announcement calls • What is the average and maximum number meeting participants (average for all meetings) for - Ad hoc call - Meet Me call There are commercial tools available for calls and traffic analysis reporting using IPDR records (for example, Avotus Call Accounting, Traffic Reporting, and Usage Management tools, http:// avotus.com/callaccounting/CA_main.asp).
Performance analysis
Application Server 5300 uses Operational Measurements (OM) to provide statistical information on server operation and performance. OMs are organized into OM groups, which contain registers (counters and gauges) that provide network element-specific performance data. The AS 5300 System Manager/Fault Performance Manager (SM/FPM) scans OM Group registers at configured intervals. There are two types of OMs: active and holding. The active OMs are displayed as they are reported by the managed/monitored network elements to the SM/FPM. The holding OMs have already been archived to files on the AS 5300 System Manager. The OM scan cycle is configurable using the OAM configuration options available in the System Management Console. OM scan cycles are configured for each Network Element (NE). The Application Server 5300 system will retain OM data on the SM/FPM for 7 days. This is not configurable and cannot be turned off. OM files more than seven days old are deleted by an audit process in the SM/FPM. If the connectivity between the SM/FPM and its monitored network elements is lost for any extended period of time, the raw OM files are written to local disk. There is enough disk space allocated on the local drives to store up to 1 day’s worth of OM files. When communication with the SM/FPM is restored, these records will be sent to the SM/FPM for processing. When a network element instance connects to an SM/FPM, it first sends all spooled OMs in the order in which they were generated. As long as an instance is not out of communication with a SM/ FPM for more than 1 day, no OMs will be lost. OSS network systems can pull the archived OM files from the server using SFTP. FTP Push can be configured for formatted OMs.
192 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Performance analysis
NEs write unformatted performance data under /var/mcp/spool/om directory and write CSV (Comma Separated Value) formatted records under the /var/mcp/oss/om directory. The administrator can configure the active accounting OM rotation interval and file size at the System Management Console. The default file rotation parameters for OMs are 60 minutes or 1000K bytes. The threshold that is exceeded first will cause the current file to be closed and a new file to be opened. The comma-delimited file may be viewed and analyzed using standard text processing and spreadsheet software (Figure 96: An OM CSV file imported in Excel on page 193).
Figure 96: An OM CSV file imported in Excel
By regularly analyzing OM reports, the planners will be able to do what-if analysis of the following performance related questions and make plan for the system expansion if required. • What is the utilization rate on various system components? Is the utilization rate within bound? • Does the system or a particular system component (that is, SESM, DB, and IPCM) have enough capacity? • Does the system/component give any indication that its capacity has exhausted? Is the system healthy? • Are any of the system components showing signs of overloaded? Which component? When and how often does this happen? • Is the overload condition caused by lack of CPU or memory or both? • Can subscribers be homed to a different server to mitigate the overload condition without adding extra servers? • How many service (for example, call, IM) attempts are blocked due to lack of resources? Does the system still meet its service requirements? • How many more subscribers can be added to the system without adding more servers? • What is the subscriber growth rate? With the current growth rate, when will a new SESM or a new system be needed? • What will be the impact to the system (or a system component) if a new service is added to the system? • When will a new SESM server or a system be added with the current trend of utilization?
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 193 Performance monitoring
Application Server 5300 System Management Console provides the OM browser tool to view OMs (see Avaya Aura® Application Server 5300 Configuration, NN42040-500 for more details). The OM browser is launched against a specific network element instance from the system tree, logical view, or physical view. The tool displays OM reports in tabular form. The types of OM reports available are different, depending on the network elements (for example, AS 5300 Session Manager, Provisioning Manager, Database Manager). These OM reports can be transferred using secure FTP to the external OSS system for archiving. The administrator can use these reports to establish baseline system performance for both regular and busy hour operations. Furthermore the administrator can conduct additional comprehensive trending analyses using the results of baseline performance analyses produced regularlly (for example, once a week). The OM reports useful for baselining and benchmarking the AS 5300 Session Manager performance are SIP_Delay_Report, Presence_Event_Report, SIP_Inbound_Response_Report, SIP_Outbound_Response_Report, and SIP_Transaction_Report. Other OM reports are useful for performance trending include: • CPCheckpoint OM group tracks the number of calls that the inactive AS 5300 Session Manager is checkpointing. • Publish OM group provides counters for the use of the PUBLISH service. • Registration OM group tracks the usage and outcome for authentication requests. • IPCM OMs are used for IP Client Manager (IPCM)-specific OMs. • DBPRFM OM group provides performance data regarding the amount of (elapsed) time required to perform database queries and updates. • OPI OM group creates an OM row for every Open Provisioning Interface (OPI) method that is invoked on the server by an OPI client. • ServerCpuAndMemory OM group captures the CPU Occupancy and Memory Usage statistics for the server. • ServerInterface OM group captures bandwidth utilization information and other statistics for each configured physical interface of the Server. For detail information on the reports, see Avaya Aura® Application Server 5300 Operational Measurements, NN42040-702. The following reports are frequently used: • SIP_Delay_Report on page 195 • SIP Presence report on page 196 • SIP Inbound and Outbound Response reports on page 198 • SIP_Transaction_Report on page 200
194 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Performance analysis
SIP_Delay_Report
The SIP_Delay_Report OM group provides a set of counts of measured delays from initiation of SIP transaction to conclusion of transaction in the form of a histogram with a range from 25 milliseconds to 32000 milliseconds. All the Inbound and Outbound transactions are from the perspective of a AS 5300 Session Manager. All inbound transactions are logged in the inbound column and all outbound transactions are logged in the outbound column. The delay reported in the SIP_Delay_Report OM Group is measured from the time a message leaves the AS 5300 Session Manager to the time the AS 5300 Session Manager sends out a reply as illustrated in Figure 97: How SESM measures delay on page 195.
Figure 97: How SESM measures delay
The SIP_Delay_Report OM group consists of a row of counters, where each row corresponds to a SIP method and each counter provides one interval of a histogram of transaction delays for the corresponding SIP as shown in Figure 98: SIP Delay Report on page 195.
Figure 98: SIP Delay Report
The SIP_Delay_Report is very useful for estimating the delays of various applications (for example, call setup delay, IM messaging delay) that users might experience using the AS 5300
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 195 Performance monitoring
Session Manager. For example, the administrator can use the values of the INVITE row to estimate the post-dial delay, which is the time interval between sending the last digit of a called number and the application of audible ring-back at the calling party. Also, the sum of the ACK and INVITE rows is useful for estimating the call setup delay, which is the time interval between sending the last digit of called number and the establishing of a two-way media path (Figure 99: Call post-dial and setup delays on page 196).
Figure 99: Call post-dial and setup delays
When analyzing system performance it is important to understand what role delay plays in determining quality of user experience. The SIP standard specifies a 500ms retransmission timer for messages. The 500ms retransmission timer is started when a message is sent out and stops when an appropriate response is received. This means that messages for which a response has not been received in 500ms will be retransmitted. Under normal operation with acceptable network latency, the number of retransmissions is minimal. However if network conditions are not favorable there is a potential for message retransmission to significantly affect system performance and end user experience. The SIP delay report can also be used for monitoring symptoms of long network delay. While it is not possible to pinpoint the cause of the delay just by examining this OM group, it is possible to monitor overall network delay as seen by a particular AS 5300 Session Manager that performed the delay measurements. Excessive delay numbers should be followed up on and further network performance investigation should be conducted to determine the root causes.
SIP Presence report
The Presence_Event_Report OM group tracks the behavior of the various presence events that are processed by the AS 5300 Session Manager. As explained in System capacity planning on page 81, presence related transactions can have a significant impact on system capacity. The Presence_Event_Report OM group (Figure 100: Presence Event report on page 197) records a number of important presence related events.
196 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Performance analysis
Figure 100: Presence Event report
The following is a brief description of the various presence events and Table 47: Presence register descriptions on page 197 describes the registers associated with each event: • Activity: A client has indicated that it has detected user keyboard/mouse activity. • End Call: A client has ended a call (excludes collaboration sessions). • Inactive: A client has indicated that it has not detected user activity (keyboard/mouse) for an extended period of time. • Login: A client has logged into the SESM. • Logout: A client has logged out from the SESM. • Manual: A client has indicated a presence state change through manual intervention (user interaction with the client interface). • New Call: A client has entered into a stable call (excludes collaboration sessions). Table 47: Presence register descriptions
Register Name Type Description Created Counter The number of events of that type that have been created in the system. This gives the operator an idea of the relative frequency of occurrence for that presence event type. Processed Counter The number of events of that type that have been processed by the presence event processor. Just because a presence event is created does not mean that it is guaranteed to ever be processed. It may be eliminated from consideration because of an opposing presence event (see Optimized register). Optimized Counter The number of events of that type that have been optimized by the presence event processor. An event is optimized when an opposing presence event is processed that nullifies the presence event
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 197 Performance monitoring
Register Name Type Description change that would have taken place. For instance, if a new call event is processed and the presence event processor sees that there is an opposing end call event in the queue or parked, then there is no further point in processing either event. The two events cancel each other out. Queued Usage The number of events that are currently in the presence event processor queue waiting to be processed. This OM represents a snapshot view of the current presence event queue depth. Parked Usage The number of events that have been initially processed, but must wait for the presence guard timer to expire before being processed. These events are "parked" waiting for the guard timer to expire. When the guard timer expires, they reenter the presence event queue (which does not cause a second pegging of the processed counter for that event).
SIP Inbound and Outbound Response reports
The SIP_Inbound_Response_Report OM group provides a set of registers which report counts of different (2xx, 3xx, 4xx, 5xx, 6xx) response types received in response to transactions initiated by SEMS’s outgoing SIP request messages (Figure 101: Inbound and Outbound reports on page 198).
Figure 101: Inbound and Outbound reports
The group consists of a set of rows of counters, where each row corresponds to the SIP method of an outgoing request message and each column corresponds to the SIP response type of an incoming response (Figure 102: SIP Inbound Response report on page 199). The inbound response report is helpful for analyzing the call completion rate and the reasons for failures.
198 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Performance analysis
Figure 102: SIP Inbound Response report
The SIP_Outbound_Response_Report OM group provides a set of registers which report counts of different (2xx, 3xx, 4xx, 5xx, 6xx) response types sent in response to transactions initiated by incoming SIP request messages (received from the originating endpoint). The group consists of a set of rows of counters, where each row corresponds to the SIP method of an incoming request message and each column corresponds to the SIP response type of an outgoing response (Figure 103: SIP Outbound Response report on page 199). The outbound response report is helpful for providing indications whether the server had capacity exhaustion for message processing and for determining if the system is still healthy.
Figure 103: SIP Outbound Response report
The SIP inbound and outbound reports are useful for determining the successful session processing rate against the session failure rate for each transaction type as well as the overall session success rate of the entire system. Together with the alarm and log reports (shown in the alarm and log browsers), these response reports should help the administrator to determine the causes (misconfiguration versus lack of resources) and the nature (transient versus permanent) for these failures and to take proper actions afterward.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 199 Performance monitoring
A summary of responses are listed below. For more message details, see SIP response messages on page 211. • 2xx responses indicate that the AS 5300 Session Manager has successfully processed the request. • 3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call. For example, the 301 response message indicates to the message recipient that the subscriber can no longer be found at the address in the Request-URI, and that the recipient should retry at the new address given by the Contact header field in the message. • 4xx responses are failure responses from a particular server. For example, the 407 response indicates that the client must first authenticate itself with the proxy. • 5xx responses are failure responses when the server itself has problem fulfilling the request. For example, the 503 response indicates that the server is temporarily unable to process the request due to a temporary overloading or maintenance of the server and the client should retry the request after waiting the time provided in a Retry-After header field. • 6xx responses indicate that the AS 5300 Session Manager has the information about a particular user and knows the request will fail wherever it is tried. Therefore, the request should not be sent to other locations. For example, the 603 response indicates that the callee has been successfully contacted but the user explicitly does not wish to take the call. Grade of service (GoS)is the percentage of a request being blocked as a result of heavy traffic loads (congestion) on the system. Figure 104: Outbound Response report for GoS calculation on page 200 is an example illustrating the use of SIP outbound response report to calculate a SESM’s GoS value.
Figure 104: Outbound Response report for GoS calculation
SIP_Transaction_Report
The SIP_Transaction_Report OM group provides a set of counts of inbound, outbound, and active transactions by the type of SIP request method which initiated the transactions (Figure 105: SIP Transaction report on page 201). Each time transaction processing is initiated on receipt of an incoming request message, the Inbound counter for that transaction type is incremented. Each time a transaction is initiated using an outgoing request message, the
200 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Performance analysis
Outbound counter for that transaction type is incremented. When processing of a transaction is initiated, the Active counter is incremented and when transaction processing is concluded, the Active watermark-register is decremented.
Figure 105: SIP Transaction report
The SIP_Transaction_Report is very useful for baselining various SIP transactions processed during the regular and busy hours, which helps determine how system resources are utilized during those times. By trending the transaction usage reports, the administrator can predict when the server/system will be overloaded and take a more proactive action beforehand (Figure 106: A sample SIP message trending chart on page 201).
Figure 106: A sample SIP message trending chart
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 201 Performance monitoring
Calculating SESM capacity utilization using OMs
This section describes using Operational Measurements (OM) to calculate AS 5300 Session Manager (SESM) capacity usage. • OM transaction to SIP weighted transaction mappings on page 202 • Authentication cost on page 204 Use the information from the above sections in Performing the calculations on page 205. The capacity of an Application Server 5300 system is measured by the number of Weighted Transactions that can be processed in one busy hour. To understand the current utilization level of an existing system, it is not enough to look at bandwidth or CPU utilization. The SIP_Transaction_Report table reports the raw internal transaction count of all message types. The number of SIP transactions reported by OM groups does not reflect SIP Weighted Transaction costs. Since system capacity is measured in SIP Weighted Transactions, the total transaction costs must be calculated based on the sum of the costs of all transaction types placed on the system. The following table shows the OM transaction types useful for analyzing system capacity. Table 48: OM transaction types
Message Name 1. INVITE 2. SUBSCRIBE 3. NOTIFY 4. MESSAGE 5. REGISTER 6. PUBLISH 7. PING
OM transaction to SIP weighted transaction mappings
In System capacity planning on page 81, we have discussed the use of SIP weighted transaction model for SESM capacity planning. Table 49: List of weighted SIP transaction types on page 203 summarizes a list of Weighted SIP transactions used in the Weighted Transaction Model.
202 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Calculating SESM capacity utilization using OMs
Table 49: List of weighted SIP transaction types
SIP transaction type Additional description 1. Instant Message Basic IM from SIP client to SIP client 2. Basic SIP-SIP calls Basic call from SIP client to SIP client 3. Client registrations Uses REGISTER messages. This type of transaction accounts for a client registration with the AS 5300 Session Manager. The cost of this type of transaction is larger than the cost of presence state change REGISTERs. 4. Presence state change Uses REGISTER messages. This type of transaction does not include corresponding NOTIFY messages and requires less processing than the client registration REGISTER message. 5. SIP Ping A PING message in SIP (Not to be confused with ICMP PING) 6. Forking Calls One subscriber has multiple clients registered when a call or IM comes in. All registered clients ring or receive IMs. Forking should not be confused with Personal Agent- based sequential ringing or simultaneous ringing where translation logic must be traversed for each address. 7. Presence subscription Uses SUBSCRIBE messages. This type of transaction does not include corresponding NOTIFY messages that are sent from the AS 5300 Session Manager to the client. 8. Presence notification Uses NOTIFY messages. This type of transaction is sent by the AS 5300 Session Manager. 9. Address book Uses SUBSCRIBE messages. This type of transaction subscription subscribes to the Address Book service. The AS 5300 Session Manager also sends a NOTIFY message to the client. This cost is NOT included in the cost of this SIP transaction type. The cost of this NOTIFY message is equal to the Presence notification. After subscribing to the Address Book service, clients proceed to download the address book from the Provisioning Module. 10. Service package Uses SUBSCRIBE messages: This type of transaction subscription accounts for service package subscriptions. The AS 5300 Session Manager also sends a NOTIFY message to the client. This cost is NOT included in the cost of this SIP transaction type. The cost of this NOTIFY message is equal to the Presence notification. After subscribing to their service package, clients proceed to download the service package from the Provisioning Module.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 203 Performance monitoring
SIP transaction type Additional description 11. Gateway calls (E.164 Calls that require the AS 5300 Session Manager to find a translations) route using E.164 translations for the requested destination address.
The first step of calculating the SESM utilization rate is to identify which transaction weight to use for each message type available in OM transaction reports. Table 50: Correlation of SIP Messages and SIP Weighted Transactions on page 204 shows the OM transaction message types and their corresponding SIP Weighted Transactions. Table 50: Correlation of SIP Messages and SIP Weighted Transactions
Message name Corresponding SIP Weighted Transaction type 1. INVITE Basic SIP-SIP calls Forking calls Basic SIP-PSTN Calls 2. SUBSCRIBE Presence subscription Address book subscription Service package subscription 3. NOTIFY Presence notification 4. MESSAGE Instant Messages 5. REGISTER Client registrations 6. PUBLISH Presence state change 7. PING SIP Ping
Authentication cost
The AS 5300 Session Manager performs user authentication when the server receives an incoming SIP request. The AS 5300 Session Manager supports the challenge-based Digest method for SIP Client-to-Proxy authentication. In Digest authentication, the AS 5300 Session Manager challenges a client when a SIP request is received. The SIP Client re-sends a SIP request with a valid password and user name attached. The request types to be authenticated are configurable. Application Server 5300 multimedia clients are able to cache authentication credentials and may not need to go through the challenge-response based authentication while the cached credentials are valid. In addition, requests coming from “Trusted” nodes are also not authenticated. Additional information on authentication and how to provision “Trusted” nodes can be obtained from Avaya Aura® Application Server 5300 Configuration, NN42040-500. It is important to remember that SIP Weighted Transaction costs correspond to SIP Transaction Types and not to simple SIP Messages. An authenticated request generates two SIP
204 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Performing the calculations
messages. The first one is rejected for lack of credentials and the second one is accepted because it has the requested credentials. The total impact of these two SIP messages is considered as one event for the purposes of calculating a SIP Weighted Transaction cost. It is for this reason that the number of 407 and 401 responses must be considered.
Performing the calculations
By looking at the message counts, it is possible to calculate the number of SIP Weighted Transactions that took place in the observed time window. A simple example will be used illustrate the steps of calculating the total weighted transaction costs based on a sample OM transaction report (Table 51: Sample OM transactions on page 205) and a sample weighed transaction cost table (Table 52: Sample Weighted Transaction Cost table on page 205). Table 51: Sample OM transactions
Message name Count A. INVITE 113 B. REGISTER 87 C. SUBSCRIBE 717 D. NOTIFY 1008 E. MESSAGE 75 F. PING 46 G. 407 and 401 response to INVITE 10 H. 407 and 401 response to 26 REGISTER I. 407 and 401 response to 39 SUBSCRIBE J. 407 and 401 response to 6 MESSAGE
Table 52: Sample Weighted Transaction Cost table
SIP Weighted Transaction type Cost Additional cost for authentication Basic SIP-SIP calls 2.3 0.89 Forking calls 0.49 0 Gateway calls (E.164 translations) 2.674 0.89 SUBSCRIBE 1.25 0.219 NOTIFY 0.19 0
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 205 Performance monitoring
SIP Weighted Transaction type Cost Additional cost for authentication MESSAGE 1 0.095 REGISTER 1.67 0.48 PING 0.046 0
Step 1: Calculating authenticated and untenanted requests
A 407 or 401 message is sent in response to a request when authentication credentials are required. This means that the number of 407 and 401 responses sent out by the AS 5300 Session Manager is equal to the number of authenticated requests. Consequently the number of unauthenticated requests is equal to the total number of messages minus twice the number of 407 and 401 responses. Authenticated call = 2 x G = 2 x 10 = 20 Unauthenticated call = 113 – 20 = 93 Authenticated register = 2 x H = 2 x 26 = 52 Unauthenticated register = 87 – 52 = 35 Authenticated subscribe = 2 x I = 2 x 39 = 78 Unauthenticated subscribe = 717 – 78 = 639 Authenticated message = 2 x J = 2 x 6 = 12 Unauthenticated message = 75 – 12 = 63
Step 2: Calculating mixed-call cost
In this example, we will assume each subscriber has registered only one client. We therefore do not need to concern ourselves with the forking cost. Based on the IPDR records, we also determine 90% of all unauthenticated calls are Gateway calls and only 10% are Basic SIP-SIP calls. Thus, the mixed-call cost could be expressed by the following equation. (0.90 X 2.674) + (0.10 X 2.30) = 2.64
Step 3: Calculating total SIP weighted transactions
Once the message counts are identified and representative SIP Weighted Transaction costs are chosen, it is time to perform the necessary calculations. Since unauthenticated and authenticated transactions have different SIP Weighted Transaction costs, the totals are first calculated separately as shown in the following two tables.
206 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Performing the calculations
Table 53: Total Unauthenticated Cost Calculation
Name # unauthenticated SIP Weighted Total SIP Transaction Weighted cost Transactions 1. INVITE 93 x 2.64 245.52 2. SUBSCRIBE 639 x 1.25 798.75 3. NOTIFY 1008 x 0.19 191.52 4. MESSAGE 63 x 1 63 5. REGISTER 35 x 1.67 58.45 6. PING 46 x 0.046 2.116 Total: 1359.4
Table 54: Total Authenticated Calculations
Name # authenticated SIP Total SIP Weighted Weighted Transactio Transactio n cost ns 1. INVITE 10 x 3.564 35.64 2. SUBSCRIBE 39 x 1.469 57.291 3. NOTIFY 0 x 0.19 0 4. MESSAGE 6 x 1.095 6.57 5. REGISTER 26 x 2.15 55.9 6. PING 0 x 0.046 0 Total: 155.401
To find the total number of SIP Weighted Transactions that occurred during the example two minute window in question, the unauthenticated total and the authenticated total must be added together. 1359.4 + 155.401 = 1514.8 SIP Weighted Transactions
Step 4: Calculating SESM server utilization
Assuming the total weighted capacity per busy hour is 200,000, the 2-min server capacity is 6666. The server utilization rate is calculated below. (1518 / 6666) x 100 = 22.77% System Utilization
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 207 Performance monitoring
Understanding bursty traffic
In this section, we will discuss how to use SIP transaction reports and IPDR records to investigate the causes of bursty traffic. Using a server’s SIP transaction report and the weighted transaction model, the planners can now plot a system’s daily workload distribution chart. The top chart of Figure 107: A sample server daily load distribution chart on page 208 shows the workload distribution of a system supporting residential subscribers and the bottom chart shows the workload distribution of a system supporting enterprise subscribers. As one can see the workload distribution of the enterprise subscriber system is much burstier than the residential subscriber system.
Figure 107: A sample server daily load distribution chart
To discover the root causes of these traffic spikes, one can start the investigation by examining the SIP transaction reports. Figure 108: Causes for traffic spikes on page 209 shows very large numbers of INVITE and IM messages are sent to the system at the beginning of each hour.
208 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Understanding bursty traffic
Figure 108: Causes for traffic spikes
Although, the SIP transaction report can tell what messages caused the spikes, it cannot tell which applications producing the spike traffics. To find out which applications generates these message spikes, one will need to correlate the findings with the collected IPDR records.
Figure 109: Typical Meet Me conference traffic pattern
The IPDR records indicate that a large number of Meet Me conferences are scheduled at the beginning of each hour (Figure 109: Typical Meet Me conference traffic pattern on page 209). The nature of Meet Me conference requires a system to service a large number of callers in
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 209 Performance monitoring
2-5 minute window. These Meet Me conferences generate a large number of INVITE messages for calling into the conference bridges, instant messages for notifying the chairpersons about who dialied into the bridges, and presence state change NOTIFY messages if the autopresence is activated for the callers. Bursty traffic can severely impact service quality if not carefully managed. The proper use of SIP transaction reports, SIP Weighted Transaction Model, and IPDR records means that the planners will be able to understand these bursty traffics and take proper steps to mitigate their impacts.
Other performance impacting events
Restarting and failover of any of the system components will temporarily put them out of service. When a SESM first comes online, it needs to load a large amount of subscriber and service data into its cache and update checkpointing information. The size of the system's configuration will impact the duration of this process. The AS 5300 Session Manager and the Database Manager are most affected by restarts and failovers. Invariably most systems will have a peak time for registrations. Usually this coincides with employees beginning their work day. During high registration periods the system is taxed more than during steady state operation. Even though the call volume may be low, the overall SIP Weighted Transactions consumed by the system may be close to capacity if a mass registration event occurs. Large scale database updates will also impact database performance and should be done in off-peak hours. There are many data structures that must be updated and synchronized when database updates take place and the additional hard disk access required by these operations will put a measurable load on the database. A large number of network call logs will be inserted into the database when the Network Call Log service is enabled for subscribers. The database also has to delete excess network call logs on a per subscriber basis. The work to analyze and purge call log records on per subscriber basis consumes database resources, namely disk I/O. In order to prevent this resource consumption from impacting other time-sensitive end user services, the number of subscribers with Network Call Logs should be limited. Network call logs should be seen as a premium service with an upper traffic limit of 30 000 call logs per hour. An Application Server 5300 system should limit the number of subscribers who have the Network Call Log service. The number of subscribers with the Network Call Log service multiplied by the planned number of (inbound+outbound) calls/subscriber/hour should not exceed 30 000 for the current release. Finally, backing up the database is also a performance-impacting event and should be done in off-peak hours.
210 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Appendix A: SIP response messages
This section describes the SIP response messages. All response definitions are directly quoted from RFC 3261. Any and all references to footnotes, other document numbers, or document sections were made in the context of RFC 3261 and should be followed up in that document which can be located at http://www.faqs.org. • Provisional 1xx on page 211 • Success 2xx on page 212 • Redirection 3xx on page 213 • Request Failure 4xx on page 214 • Server Failure 5xx on page 221 • Global Failures 6xx on page 222
Provisional 1xx
Provisional responses, also known as informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response. A server sends a 1xx response if it expects to take more than 200 ms to obtain a final response. Note that 1xx responses are not transmitted reliably. They never cause the client to send an ACK. Provisional (1xx) responses may contain message bodies, including session descriptions. • 100 Trying on page 211 • 180 Ringing on page 212 • 181 Call Is Being Forwarded on page 212 • 182 Queued on page 212 • 183 Session Progress on page 212
100 Trying
This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted). This response, like all other provisional responses, stops retransmissions of an INVITE by a UAC. The 100 (Trying) response is different from other provisional responses, in that it is never forwarded upstream by a stateful proxy.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 211 SIP response messages
180 Ringing
The UA receiving the INVITE is trying to alert the user. This response may be used to initiate local ringback.
181 Call Is Being Forwarded
A server may use this status code to indicate that the call is being forwarded to a different set of destinations.
182 Queued
The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, "5 calls queued; expected waiting time is 15 minutes". The server may issue several 182 (Queued) responses to update the caller about the status of the queued call.
183 Session Progress
The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body may be used to convey more details about the call progress.
Success 2xx
• 200 OK on page 212 • 202 Accepted on page 213
200 OK
The request has succeeded. The information returned with the response depends on the method used in the request.
212 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Redirection 3xx
202 Accepted
The 202 response is added to the "Success" header field definition. "202 Accepted" has the same meaning as that defined in HTTP/1.1 [3].
Redirection 3xx
3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call. • 300 Multiple Choices on page 213 • 301 Moved Permanently on page 213 • 302 Moved Temporarily on page 214 • 305 Use Proxy on page 214 • 380 Alternative Service on page 214
300 Multiple Choices
The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location. The response may include a message body containing a list of resource characteristics and locations from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field. However, no MIME types have been defined for this message body. The choices should also be listed as Contact fields (Section 20.10). Unlike HTTP, the SIP response may contain several Contact fields or a list of addresses in a Contact field. UAs may use the Contact header field value for automatic redirection or may ask the user to confirm a choice. However, this specification does not define any standard for such automatic selection. This status response is appropriate if the callee can be reached at several different locations and the server cannot or prefers not to proxy the request.
301 Moved Permanently
The user can no longer be found at the address in the Request-URI, and the requesting client should retry at the new address given by the Contact header field (Section 20.10). The
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 213 SIP response messages
requestor should update any local directories, address books, and user location caches with this new value and redirect future requests to the addresses listed.
302 Moved Temporarily
The requesting client should retry the request at the new address(es) given by the Contact header field (Section 20.10). The Request-URI of the new request uses the value of the Contact header field in the response. The duration of the validity of the Contact URI can be indicated through an Expires (Section 20.19) header field or an expires parameter in the Contact header field. Both proxies and UAs may cache this URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid once for recursing, and must not be cached for future transactions. If the URI cached from the Contact header field fails, the Request- URI from the redirected request may be tried again a single time. The temporary URI may have become out-of-date sooner than the expiration time, and a new temporary URI may be available.
305 Use Proxy
The requested resource ,ust be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request using the proxy. 305 (Use Proxy) responses must only be generated by UASs.
380 Alternative Service
The call was not successful, but alternative services are possible. The alternative services are described in the message body of the response. Formats for such bodies are not defined here, and may be the subject of future standardization.
Request Failure 4xx
4xx should not retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful. • 400 Bad Request on page 215 • 401 Unauthorized on page 215 • 402 Payment Required on page 216 • 403 Forbidden on page 216
214 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Request Failure 4xx
• 404 Not Found on page 216 • 405 Method Not Allowed on page 216 • 406 Not Acceptable on page 216 • 407 Proxy Authentication Required on page 216 • 408 Request Timeout on page 217 • 410 Gone on page 217 • 413 Request Entity Too Large on page 217 • 414 Request URI Too Long on page 217 • 415 Unsupported Media Type on page 217 • 416 Unsupported URI Scheme on page 217 • 420 Bad Extension on page 218 • 421 Extension Required on page 218 • 422 Session Interval Too Small on page 218 • 423 Interval Too Brief on page 218 • 480 Temporarily Unavailable on page 218 • 481 Call/Transaction Does Not Exist on page 219 • 482 Loop Detected on page 219 • 483 Too Many Hops on page 219 • 484 Address Incomplete on page 219 • 485 Ambiguous on page 219 • 486 Busy Here on page 220 • 487 Request Terminated on page 220 • 488 Not Acceptable Here on page 220 • 491 Request Pending on page 220 • 493 Undecipherable on page 220
400 Bad Request
The request could not be understood due to malformed syntax. The Reason-Phrase should identify the syntax problem in more detail, for example, "Missing Call-ID header field".
401 Unauthorized
The request requires user authentication. This response is issued by UASs and registrars, while 407 (Proxy Authentication Required) is used by proxy servers.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 215 SIP response messages
402 Payment Required
Reserved for future use.
403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request should not be repeated.
404 Not Found
The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.
405 Method Not Allowed
The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI. The response must include an Allow header field containing a list of valid methods for the indicated address.
406 Not Acceptable
The resource identified by the request is only capable of generating response entities that have content characteristics not acceptable according to the Accept header field sent in the request.
407 Proxy Authentication Required
This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy. SIP access authentication is explained in Sections 26 and 22.3 of the SIP Standard. This status code can be used for applications where access to the communication channel (for example, a telephony gateway) rather than the callee requires authentication.
216 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Request Failure 4xx
408 Request Timeout
The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time. The client may repeat the request without modifications at any later time.
410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) should be used instead.
413 Request Entity Too Large
The server is refusing to process a request because the request entity-body is larger than the server is willing or able to process. The server may close the connection to prevent the client from continuing the request. If the condition is temporary, the server should include a Retry- After header field to indicate that it is temporary and after what time the client may try again.
414 Request URI Too Long
The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret.
415 Unsupported Media Type
The server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server must return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. UAC processing of this response is described in Section 8.1.3.5 of the SIP Standard.
416 Unsupported URI Scheme
The server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server. Client processing of this response is described in Section 8.1.3.5.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 217 SIP response messages
420 Bad Extension
The server did not understand the protocol extension specified in a Proxy-Require (Section 20.29) or Require (Section 20.32) header field. The server must include a list of the unsupported extensions in an Unsupported header field in the response. UAC processing of this response is described in Section 8.1.3.5.
421 Extension Required
The UAS needs a particular extension to process the request, but this extension is not listed in a Supported header field in the request. Responses with this status code must contain a Require header field listing the required extensions. A UAS should not use this response unless it truly cannot provide any useful service to the client. Instead, if a desirable extension is not listed in the Supported header field, servers should process the request using baseline SIP capabilities and any extensions supported by the client.
422 Session Interval Too Small
It is generated when a request contains a Session-Expired header field with duration below the minimum timer for the server. The Session-Expired header conveys the session interval for a SIP session. The session interval is the maximum amount of time that can occur between session refresh requests in a dialog before the session is considered timed out. This header is used in INVITE, UPDATE request and 2xx response to an INVITE or UPDATE. The UAS or proxy that generates this message includes in the 422 response a Min-SE header indicating the minimum session value it accepts. Min-SE header indicates the minimum value for the session expiration. The UAC can retry the call with a larger session timer value.
423 Interval Too Brief
The server is rejecting the request because the expiration time of the resource refreshed by the request is too short. This response can be used by a registrar to reject a registration whose Contact header field expiration time was too small. The use of this response and the related Min-Expires header field are described in Sections 10.2.8, 10.3, and 20.23.
480 Temporarily Unavailable
The callee's end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the "do not disturb" feature). The response may indicate a better time to call
218 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Request Failure 4xx
in the Retry-After header field. The user could also be available elsewhere (unknown to this server). The reason phrase should indicate a more precise cause as to why the callee is unavailable. This value should be configurable by the UA. Status 486 (Busy Here) may be used to more precisely indicate a particular reason for the call failure. This status is also returned by a redirect or proxy server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user.
481 Call/Transaction Does Not Exist
This status indicates that the UAS received a request that does not match any existing dialog or transaction.
482 Loop Detected
The server has detected a loop (Section 16.3 Item 4).
483 Too Many Hops
The server received a request that contains a Max-Forwards (Section 20.22) header field with the value zero.
484 Address Incomplete
The server received a request with a Request-URI that was incomplete. Additional information should be provided in the reason phrase. This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a 484 (Address Incomplete) status response.
485 Ambiguous
The Request-URI was ambiguous. The response may contain a listing of possible unambiguous addresses in Contact header fields. Revealing alternatives can infringe on privacy of the user or the organization. It must be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices for ambiguous Request-URIs. Example response to a request with the Request-URI sip:[email protected]: SIP/2.0 485 Ambiguous Contact: Carol Lee
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 219 SIP response messages
Contact: Ping Lee Contact: Lee M. Foote Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is required for a 485 (Ambiguous) response.
486 Busy Here
The callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. The response may indicate a better time to call in the Retry-After header field. The user could also be available elsewhere, such as through a voice mail service. Status 600 (Busy Everywhere) should be used if the client knows that no other end system will be able to accept this call.
487 Request Terminated
The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself.
488 Not Acceptable Here
The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere. A message body containing a description of media capabilities may be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.
491 Request Pending
The request was received by a UAS that had a pending request within the same dialog. Section 14.2 describes how such "glare" situations are resolved.
493 Undecipherable
The request was received by a UAS that contained an encrypted MIME body for which the recipient does not possess or will not provide an appropriate decryption key. This response may have a single body containing an appropriate public key that should be used to encrypt
220 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Server Failure 5xx
MIME bodies sent to this UA. Details of the usage of this response code can be found in Section 23.2.
Server Failure 5xx
5xx responses are failure responses given when a server itself has erred. • 500 Server Internal Error on page 221 • 501 Not Implemented on page 221 • 502 Bad Gateway on page 221 • 503 Service Unavailable on page 222 • 504 Server Time-out on page 222 • 505 Version Not Supported on page 222 • 513 Message Too Large on page 222
500 Server Internal Error
The server encountered an unexpected condition that prevented it from fulfilling the request. The client may display the specific error condition and may retry the request after several seconds. If the condition is temporary, the server may indicate when the client may retry the request using the Retry-After header field.
501 Not Implemented
The server does not support the functionality required to fulfill the request. This is the appropriate response when a UAS does not recognize the request method and is not capable of supporting it for any user. (Proxies forward all requests regardless of method.) Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method is not allowed or supported.
502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from the downstream server it accessed in attempting to fulfill the request.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 221 SIP response messages
503 Service Unavailable
The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server may indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client must act as if it had received a 500 (Server Internal Error) response. A client (proxy or UAC) receiving a 503 (Service Unavailable) should attempt to forward the request to an alternate server. It should not forward any other requests to that server for the duration specified in the Retry-After header field, if present. Servers may refuse the connection or drop the request instead of responding with 503 (Service Unavailable).
504 Server Time-out
The server did not receive a timely response from an external server it accessed in attempting to process the request. 408 (Request Timeout) should be used instead if there was no response within the period specified in the Expires header field from the upstream server.
505 Version Not Supported
The server does not support, or refuses to support, the SIP protocol version that was used in the request. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message.
513 Message Too Large
The server was unable to process the request since the message length exceeded its capabilities.
Global Failures 6xx
6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI. • 600 Busy Everywhere on page 223 • 603 Decline on page 223
222 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Global Failures 6xx
• 604 Does Not Exist Anywhere on page 223 • 606 Not Acceptable on page 223
600 Busy Everywhere
The callee's end system was contacted successfully but the callee is busy and does not wish to take the call at this time. The response may indicate a better time to call in the Retry-After header field. If the callee does not wish to reveal the reason for declining the call, the callee uses status code 603 (Decline) instead. This status response is returned only if the client knows that no other end point (such as a voice mail system) will answer the request. Otherwise, 486 (Busy Here) should be returned.
603 Decline
The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response may indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request.
604 Does Not Exist Anywhere
The server has authoritative information that the user indicated in the Request-URI does not exist anywhere.
606 Not Acceptable
The user's agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable. A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately support the session described. The 606 (Not Acceptable) response may contain a list of reasons in a Warning header field describing why the session described cannot be supported. Warning reason codes are listed in Section 20.43. A message body containing a description of media capabilities may be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. It is hoped that negotiation will not frequently be needed, and when a new user is being invited to join an already existing conference, negotiation may not be possible. It is up to the invitation initiator to decide whether or not to act on a 606 (Not Acceptable) response. This status response is returned only if the client knows that no other end point will answer the request.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 223 SIP response messages
224 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Appendix B: Deployment checklist
This chapter contains checklists that planners may find useful.
Checklists
• Table 55: Customer Readiness Assessment Phase on page 225 • Table 56: Application Server 5300 Services Planning Phase on page 226 • Table 57: General Network Planning and Engineering Phase on page 229 • Table 58: Application Server 5300 Network Planning and Engineering Phase on page 231
Table 55: Customer Readiness Assessment Phase
Action item Recommendations Technical User Support mechanisms are in The customer’s (TDM and Data) technical place and service support teams are trained and problem escalation and resolution procedures are established before deployment The training resources and Quick Start User Guides are available for users. Application Server 5300 Services Quality The quality/service targets for voice, video, Expectations are well defined and interactive (for example, IM, Web push) applications are established and understood. Use the ITU-T G.1010 and Y.1541 as the basis to develop such service target requirements for Application Server 5300 services. Use the following guidelines for VoIP service: • PSTN quality (local call): the overall network must have less than 70 ms one- way delay and 0% packet loss mouth to ear. • Business quality (long distance): the overall network must have less than 150
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 225 Deployment checklist
Action item Recommendations
ms one-way delay and 1% less packet loss mouth to ear. • Acceptable quality (mobile phone): the overall network must have less than 250 ms one-way delay and less than 2% packet loss mouth to ear.
Network health is checked Perform Network Health Check to selected sites by qualified engineers prior to the deployment. The identified network issues of negative impact to the Application server 5300 deployment must be resolved. Collect up-to-date detailed physical and logical network diagrams to • Identify the longest path between two endpoints • Identify the propagation delays of all the network sections including the PSTN/TDM network • Identify all switching and routing devices along the identified paths and their delay, jitter, packet loss performance characteristics during the peak hours
Table 56: Application Server 5300 Services Planning Phase
Action Item Recommendations Define domain hierarchy Complete SIP Domain design for each Application Server 5300 system • Design top domain, sub-domains, and foreign domains, must consider the following: - Administrators and their roles, - User populations and communities, including identifying issues that might impact service delivery (for example, cultures, means of delivery such as WAN/VPN availability and capacity, populations, special services, legal) - Subscriber Services requirements - Service availability and access restrictions, including Codecs,
226 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Checklists
Action Item Recommendations
gateways/trunk groups, routes and translations, firewalls, NATs, MAS services - Geographical locations, including identifying issues that might impact service delivery (for example, Location vs. Domain trees mapping, Emergency Services, Signaling centers, Media Resource Centers, Client locations)
Define Administrators and Roles Identify all administrators and their roles in system configuration and provisioning • Names, organizations, locations, and contact information • Define rights and privileges that allow an administrator to perform various configuration and provisioning tasks (for example, domain management, user management, IPCM provisioning, device management, gateway routes, Telephony routes, and voice mail management) .
Define Services and availability • Define subscriber services requirements requirements for each domain • Define usage and service capacity requirements - Group services into various defined service packages, including defining service parameters for available services (for example, Ad hoc conference, Meet Me conference, voice, video, QoS, presence, screening, converged desktop, address book, voicemail, hot line) - Assign service packages to various domains - Identify emergency services - Application Server 5300 license key requirement • Define service availability requirements, for each service offered define the following - Permissible down time - Time to repair
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 227 Deployment checklist
Action Item Recommendations
- Device redundancy and spare parts - Service contact information for each region
Gateway, Routing, Translation • Define capacity and redundancy requirements • Ensure media resources are reachable from the application servers and clients and sufficient network bandwidth are provided • Define access permission and restrictions • Define translations, routes, and load balancing • Apply echo cancellation when required
Security policies and procedures for Adapt the existing security policies for Application Server 5300 deployment are Application Server 5300 services. This addressed should include policies for the acceptable use policy for the users and the network policies for the servers, clients, gateways, MAS, firewall rules, and traffic filters for L2/ L3 devices. Create procedures for regular • IP port scanning and analysis to ensure only legal UDP/TCP ports are open for the permitted services. • Network audit of all security logs for security violation/compliancy
QoS policies for Application Server 5300 Establish end-to-end QoS policies for all services are well defined for the entire Application Server 5300 applications. The network QoS policies should: • Establish an enterprise-wide network QoS services classification guideline for all applications • Enforce consistent L3-to-L2 mappings over various L2 transports • Specify the required SLAs (Service Level Agreements) for the section of networks managed by 3rd parties • Establish procedures for regular QoS and SLAs monitoring and validation on the network infrastructure • Establish end-to-end network impairment (delay, packet loss, jitter) budgets for
228 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Checklists
Action Item Recommendations
different portions of networks (that is, access, campus, branch, distribution, core, and ISP) that connecting user devices, gateways, and servers
Table 57: General Network Planning and Engineering Phase
Action Item Recommendations
LAN Readiness is checked • Use only Cat-5 or better grade cables for Ethernet connections. The cable length should not exceed 100 meters. • Use only L2/L3 switches for LAN • Enable Auto-negotiation on both the switch ports and the connecting devices to eliminate packet losses as result of duplex mismatches • Place DSCP “EF” and 802.1p “6” tagged packets in the priority queue • Use L2/L3 switches that can support minimum 4 queues with at least one queue is a priority queue
WAN Readiness is checked • Use WAN IO modules that can support minimum 4 queues with one of the queues being a priority queue • Place DSCP “EF” and 802.1p “6” tagged packets in the priority queue • Provision sufficient bandwidth to cover all traffic types and, on the average, no more than 30% of bandwidth should be used on the WAN links • Establish at least two (that is, primary/ backup or load share) physical/logical paths for network traffic • Utilize L2 link bundles (for example, MLPPP, Multiple VCs, MLT) and L1-L3 fast failover mechanisms (SONET, RPR, MPLS, ECMP) where appropriate to enhance network stability • Utilize Lower layer error detection mechanisms for quick L2/L3 failover. Examples are ATM F5 OAM loopback cell, Frame Relay A-bit, Ethernet FEFI (Far End Fault Indication)
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 229 Deployment checklist
Action Item Recommendations
• Fix and monitor physical layer timing and bit error rates • Limit delay, packet loss, and jitter performance for all WAN links (especially on WAN aggregation points and on WAN links slower than 384 kbps) based on the established end-to-end impairment budgets
IP Network readiness is checked • Use redundant network architecture to enhance the network resiliency and availability and to minimize L3 convergence - Use VRRP at the dual-homed network edges to provide default router redundancy to support real-time and critical network services - Use Avaya MLT (Multi-Link Trunking), Distributed MLT, Split MLT to increase network bandwidth and stability - Enable IP ECMP (Equal Cost Multi-Path) for load sharing and quick failover • Structure IP address spaces that - Meet the needs of new services - Support route summarization - Facilitate network management
IP Network readiness is checked (continued) • Use OSPF as the choice of routing protocol - Use more than one ABRs to provide the redundant paths - Use Area and External route summaries to reduce routing table and increase routing stability - Use Stub Area and NSSA where applicable to reduce routing table and increase routing stability - Limit the number areas supported by an ABR to “3” - Limit the number of adjacencies supported by the switch to what is recommended by the vendor
230 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Checklists
Action Item Recommendations
- Limit convergence time to a few seconds • Use RIP only in a very small network (less than 3 hops) - Trigger update must be enabled. - RIPv2 is recommended and RIPv1 is NOT recommended.
Table 58: Application Server 5300 Network Planning and Engineering Phase
Action Item Recommendations
Application Server 5300 Network Readiness • Follow Application Server 5300 is checked Hierarchical design methodology to design Application Server 5300 network • Provide at least two network paths between any pair of Application Server 5300 components (servers, gateways, and clients) • DO NOT use shared media devices such as Ethernet Hub devices for connecting Application Server 5300 servers and clients. • Wireless LANs should manage VoIP traffic on a given base stationas it is a shared medium. • Establish port based L2/L3 filters to tag the traffic from the application servers • Allocate IP address space to Application Server 5300 components that meet the current and future needs • Place standalone 1100 Series IP Deskphones in a separate VLAN when feasible • Place Application Server 5300 Server and Gateway components in separate OSPF (Stub or NSSA) areas when feasible • Place Application Server 5300 servers, gateways, and clients to locations with the following attributes - High availability - Sufficient link speed and bandwidth - Very low delay and packet loss rate
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 231 Deployment checklist
Action Item Recommendations
- Very minimum impact due to the routing changes - Security (logical and physical)
VPN Readiness is checked • Use L2/L3 VPN (for example, VC, MPLS, OE, IPsec tunnel) to maintain a single IP address space over geographically distributed locations to avoid the use of NAT devices. This ensures the media path between two clients in the same address space. • Use L2 VPN (VLAN over OE/ATM/MPLS) to support geographic redundancy of the Application Server 5300 server farm if required • Use IPSec tunnels (with sufficient performance) to support remote sites and mobile users
Application Server 5300 Network Security • Identify network boundary devices Readiness is checked - Physical and logical (VPN and Application Server 5300 domains) locations - Specify packet forwarding and bandwidth requirements - Specify Firewalls and packet filter rules - Open pinholes needed for Application Server 5300 communications on all Firewall devices - Set Firewall/NAT timers to be twice as large than Application Server 5300 Ping/ Keep-alive timers used on the servers and IPCMs - Close all un-used TCP and UDP ports on the servers and other security devices - Enhance the protection for Application Server 5300 server farm by implementing traffic filters on the L2 or L3 devices that are fronting the server/ gateway farm so that only the traffic from known sources/destinations are passed to the servers - Enable Application Server 5300 DoS protection to improve the system
232 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Checklists
Action Item Recommendations
robustness against various malicious DoS attacks and faulty babbling SIP user agents.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 233 Deployment checklist
234 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Appendix C: IPv6 overview
This section presents an overview of the Internet Protocol version 6 (IPv6) for those unfamiliar with the protocol. The section is based on the protocol specifications, and not on Application Server 5300 implementation. For detailed information about IPv6 support in Application Server 5300, contact Avaya. With the introduction of always-on broadband technology and large numbers of mobile devices, the Internet will need a very large address space to continue its growth. The Internet Protocol version 6 (IPv6) aims to eliminate the barriers to globally unique addressing and to complement the QoS and security features of Internet Protocol version 4 (IPv4) to deliver a secure mechanism to differentiate levels of service per user within the global Internet. IPv6 introduces a much larger 128-bit address space than the 32-bit addresses of IPv4. It is 64 billion times the size of the IPv4 address space. IPv6 introduces a complete replacement network layer for IP networks. The basics of IPv6 are described in the IETF standard Internet Protocol, Version 6 (IPv6) Specification (RFC2460). • IPv4 versus IPv6 on page 235 • ICMPv6 on page 237 • IPv6 addressing overview on page 240 • Upper layer protocols on page 250 • IPv6 migration on page 252
IPv4 versus IPv6
The following figure compares the IPv4 and IPv6 headers.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 235 IPv6 overview
Figure 110: Comparison of IPv4 and IPv6 headers The basic header of an IPv6 packet is 40-byte, which is twice the size of an IPv4 packet header. IPv6 does not uses the checksum found in IPv4 headers because the commonly used Layer 2 technologies provides a checksum for detecting corruption during transmission on each separate link and IP transport protocols provide checksum for end-to-end payload corruption detection. The considerable extra processing load needed to calculate the checksum at the sender and subsequent nodes is not justified and could be considered an added risk for corruption. To ensure that a transport layer checksum is provided in all cases, the UDP checksum is mandatory for IPv6, while it is optional for IPv4. All IPv6 nodes and links are required to handle packets up to 1280 octets long. IPv6 routers are no longer expected to fragment packets if the Maximum Transmission Unit (MTU) of the next link is too small for the size of packet. A host uses Path MTU Discovery (PMTUD) to find out what is the minimum MTU for the set of links on which a packet will traverse in reaching a destination. Hosts may still have to fragment large packets for transmission and reassemble them on receipt. Routers drop any that exceed the available MTU and report the error back to the source with an Internet Control Message Protocol (ICMP) ‘Packet Too Big’ error message. IPv4 packets allow a fixed maximum amount of space for optional fields. IPv4 packets carrying options are classed as special cases and diverted from the hardware supported ‘fast path’ in larger routers. The processing of packets with options carries a large performance penalty; as a result, IPv4 options are little used. By contrast, IPv6 is designed with an extensible header system that is intended to be flexible and future proof. The extension headers, when needed, are inserted between the basic header and the data payload. Multiple extension headers can be daisy-chained onto the basic IPv6 header. Each extension header is identified by the Next Header field in the preceding header. RFC2460 recommends the order of extension headers should be chained in an IPv6 packet: IPv6 main header, Hop-by-Hop Options header (supporting support of Jumbo-grams or the Router Alert), Destination Options header (supporting applications, processing by the first destination), Routing header (supporting source routing), Fragment header (supporting source packet fragmentation), Authentication header (RFC2402), Encapsulating Security Payload
236 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] ICMPv6
header (RFC 2406), Destination Options header (processing only by the final destination), Upper-layer header (UDP, TCP). The following table summarizes the differences between the two headers. Table 59: Comparison of IPv4 and IPv6 header fields
IPv4 IPv6 Twenty octet header Forty octet header Four octet (32 bit) addresses Sixteen octet (128 bit) addresses QoS Specification in Service Type octet QoS Specification in Flow Label and Traffic Class octet Limited options Extensible header extension Packet fragmentation in routers Packet fragmentation only at source Fragmentation information in main Fragmentation information in extension header—fields always present header—present only when needed Header has checksum No header checksum Protocol field identifies type of Packet Next Header field in main header and each extension identifies next component Time To Live field Hop Limit Total Length: combined length of header plus Payload Length: basic header is fixed payload length, extension headers each include length
ICMPv6
The Internet Control Message Protocol (ICMP) is an integral part of IPv6 protocol. The set of functions that ICMPv6 performs is essential for IPv6. ICMPv6 has been enhanced to include the Address Resolution Protocol (ARP), Reverse ARP, Internet Group Management Protocol (IGMP), Path MTU Discovery, and Neighbor Discovery for ‘plug and play’ connection to the network. The ICMPv6 functions are summarized below: • ICMP error messages return to the source if a packet could not be delivered (RFC 4443). See Table 60: IPv6 messages on page 238. • Echo Request and Echo Response Messages for monitoring connectivity through used by the ping and traceroute utilities (RFC 4443). • Neighbor Solicitation and Neighbor Advertisement Messages (RFC 2461) for - Link layer address resolution (equivalent to IPv4 ARP): finding neighbors connected to the same link and determines their IP and link layer addresses
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 237 IPv6 overview
- Neighbor Unreachability detection: ensures that neighbors remain reachable using the same IP and link layer address by applying Neighbor Unreachability Detection (NUD) and notifies neighbors changes of link layer addresses - Duplicate Address detection (RFC 2462): checking the uniqueness of any addresses that an interface proposes to use through Duplicate Address Detection (DAD). DAD can be turned off if the network administrator believes that the configuration method used is bound to generate unique addresses. • Router Solicitation and Router Advertisement Messages [RFC 2461] for - Finding routers and determining how to obtain IP addresses to join the subnets supported by the routers - Providing prefixes and other configuration information (including the link MTU and suggested hop count default) from routers to hosts if stateless autoconfiguration of hosts is enabled. Note with IPv6, routers relies on senders to fragment packets and do not fragment packets anymore - Supporting renumbering of networks by allowing the prefixes advertised by routers to be altered. RFC 4192 describes details of re-numbering process. - Providing support for some aspects of Mobile IPv6, especially dealing with the IPv6 Mobile Home Agent functionality provided in routers and needed to support a Mobile node homed on the link • Redirect Message [RFC 2461] informing a node - a more appropriate router on the local link for the destination address - the destination is a neighbor one the same link and a remote node • Multicast Listener Discovery [RFC 2710 MLDv1 and RFC 3810 MLDv2] based on IPv4 IGMPv2 [RFC 2236] and IGMPv3 [RFC 3376] for - Discovering which Multicast groups have listeners on a link (Multicast Listener Query) - Registering for a Multicast group membership (Multicast Listener Report) - De-registering for a Multicast group membership (Multicast Listener Done) Table 60: IPv6 messages
Type Meaning 1 Destination Unreachable 2 Packet Too Big 3 Time Exceeded 4 Parameter Problem
The following table is a list of IPv6 information messages.
238 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] ICMPv6
Table 61: ICMP information messages
Type Meaning 128 Echo Request (RFC 4443) 129 Echo Reply 130 Multicast Listener Query (RFC 2710) 131 Multicast Listener Report 132 Multicast Listener Done 133 Router Solicitation (RFC 2461) 134 Router Advertisement 135 Neighbor Solicitation 136 Neighbor Advertisement 137 Redirect 138 Router Renumbering (RFC 2894) 139 Node Information Query 140 Node Information Response 141 Inverse Neighbor Discovery Solicitation (RFC 3122) 142 Inverse Neighbor Advertisement 143 Multicast Listener Report v2 (RFC 3810) 144 Home Agent Address Discovery Request (RFC 3775) 145 Home Agent Address Discovery Reply 146 Mobile Prefix Solicitation (RFC 3971) 147 Mobile Prefix Advertisement 148 Certification Path Solicitation (RFC 3971) 149 Certification Path Advertisement 151 Multicast Router Advertisement (RFC 4286) 152 Multicast Router Solicitation 153 Multicast Router Termination 200-201 Private experimentation (RFC 4443) 255 Reserved
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 239 IPv6 overview
IPv6 addressing overview
IPv6 provides both Unicast and Multicast addressing as in IPv4. IPv6 also introduces a new variant of Unicast called ‘Anycast ’, which is a Unicast address assigned to multiple interfaces (typically belonging to different nodes). A packet sent to an Anycast address is only delivered to the closet Anycast interface. This is different from the Multicast packet delivery where the Router will deliver the packet to all Multicast interfaces. Anycast addresses are used to provide redundancy and load balancing where multiple servers provide the same services. It is also more efficient and more scalable to access the ‘nearest’ server depending on where the request is made from rather than accessing the centralized servers. At present, Anycast is only implemented on routers. The router is responsible for knowing the correct server corresponding to an Anycast address and forwarding the message accordingly. The IPv6 Addressing Architecture [RFC3879, RFC 4193, and RFC 4291] lists the various types and scopes for IPv6 addresses by using pre-assigned address prefix types (Table 62: IPv6 address types on page 240). Using well-known prefixes allow easy filtering at the scope boundaries. A large part of the address space is currently left unassigned. However, any address that does not fall into one of the assigned spaces should be assumed to be a global Unicast address. Table 62: IPv6 address types
Type Hex Notation Unspecified ::/128 Loopback ::1/128 Multicast FF00::/8 Link Local Unicast FE80::/10 Unique Local Unicast FC00::/7 Global Unicast 2000::/3
IPv6 introduced the concept of address scopes which do not allow addresses with a particular scope be propagated and used outside that scope. The link-local addresses (FE80::/10), assigned through autoconfiguration, are used on a single link and should never be routed. The Unique Local IPv6 Unicast addresses (FC00::/7) are globally unique but should not be routed to the global Internet [RFC4193]. The Unique Local IPv6 addresses are self-generated (without needing any central coordination or assignment) using a pseudo-random algorithm with a extremely high probability of being unique. The global Unicast addresses (2000::/3) are unique Unicast addresses and routable in the global Internet [RFC 4291]. The aggregatable global Unicast addresses are usually constructed by adding a 64 bit prefix to a 64 bit IID (Interface Identifier). Often the IID will be a globally unique number that can be
240 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Multicast
combined with any address prefix to make an address. The IID can be derived from the MAC address of the interface, manually configured or generated cryptographically [RFC3041]. At present, the address prefix would be delegated from a provider that would also provide routing of IPv6 traffic to and from nodes using this address prefix. This ‘provider addressing’ (PA) is designed to support the ‘strict aggregation’ policy of the Internet. • Multicast on page 241 • Address format on page 242 • Address prefix and subnet on page 243 • Stateless and stateful autoconfiguration on page 243 • Address resolution and caching on page 247 • IPv6 address management on page 248 • Multiple IP addresses per interface on page 249 • IPv6 routing on page 250
Multicast
The broadcast address available on each subnet in IPv4 has no analog in IPv6 because IPv6 does not use broadcast mechanisms at the IP layer at all. IP Multicast has a much more important role in IPv6 than it does in IPv4 because various link layer specific support protocols (for example, ARP, RARP) have been integrated into IPv6. Many of these functions rely on the ability to send messages to groups of interfaces on a link according to their roles (for example, to all nodes or to all routers) even before the sending interface knows what other nodes are attached to the link. As a result, IPv6 is heavily dependent on Multicast packet delivery at least at the level of one link. The “Solicited-node Multicast address” is a Multicast address that every node must join for every Unicast and Anycast address it is assigned. This address is formed by taking the lower- order 24 bits of an IP address and appending them to the well-known prefix FF02:0:0:0:0:1:FF00::/104. IPv4 broadcasts ARP messages to resolve an IP-MAC address mapping. IPv6 sends Neighbor Solicitation messages to the Solicited-node Multicast address to resolve the interface MAC address. As a result, only the nodes registered to this Multicast address will receive the messages. In order to optimize the delivery of Multicast, nodes have to inform routers about the Multicast groups to which they are listening (that is, the Multicast addresses for which they will accept packets). Routers then only need to propagate Multicast packets onto links where there is at least one listener. The information needed is maintained by exchanges using the Multicast Listener Discovery protocol (MLD v1 [RFC2710] or v2 [RFC3596]), which replaces the IGMP used for the same purpose in IPv4. Although Multicasting with the local link scope is needed for the correct operation of all IPv6 networks, but this operation does not require any dynamic Multicast routing protocols to be
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 241 IPv6 overview
deployed. However, the networks that use Multicast services beyond the link scope will need to deploy one or more of the Multicast routing protocols such as Protocol Independent Multicast —Dense Mode, Protocol Independent Multicast—Sparse Mode, Distance Vector Multicast Routing Protocol, Source-Specific Multicast for IP, and Border Gateway Multicast Protocol. The Multicast routing protocols are still mostly under development; refer to IETF Web site for more details. The following table is a partial list of well-known IPv6 multicast addresses that are registered with the Internet Assigned Numbers Authority (IANA). Table 63: IPv6 well-known prefixes
Address Description ff02::1 All nodes on the local network segment ff02::2 All routers on the local network segment ff05::1 All nodes on the local network site ff0x::fb Multicast DNS ff0x::108 Network Information Service ff05::1:3 All DHCP servers on the local network site
Address format
There are three conventional forms for representing IPv6 addresses as text strings. The preferred form of a fully expanded IPv6 128 address is written as a group of up to four hexadecimal digits, with the fields separated by colons (RFC2373, RFC3513). For example, a fully expanded IPv6 address might look like the following: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 When many of the fields of an address are all zeroes as shown below: 1080:0000:0000:0000:0008:0800:200C:417A The address can be shortened by removing leading zeroes from each field: 1080:0:0:0:8:800:200C:417A Care must be taken not to leave out trailing zeroes (for example 0800 :: 800). A further simplification can be achieved by leaving out a group of adjacent zeroes using a pair of colons “::”—1080::8:800:200C:417A. Therefore, the address 12AB: 0000:0000:CD30:0000:0000:0000:0000 can be represented as either ‘12AB::CD30:0:0:0:0’ or ‘12AB:0:0:CD30::’. Note, the "::" can only appear once in an address.
242 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Address prefix and subnet
In mixed IPv4 and IPv6 environments, an IPv4 address can sometimes be embedded as the last 32 bits of an IPv6 address (0:0:0:0:0:0: 32.12.65.122), using the “::” syntax, the address can be written as (::32.12.65.122). The IPv6 address prefixes are written in Class-less Interdomain Routing (CIDR) notation similar to the way IPv4 addresses prefixes. An IPv6 address prefix is represented by the “IPv6- address/prefix-length” notation, for example, 12AB::CD30:0:0:0:0/60. To use an IPv6 address in a URL, the address should be enclosed in "[" and "]" characters, as shown in the following examples: http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80, sip:u2@[2221:812:1::15]
Address prefix and subnet
In IPv4, the address is logically split into a ‘network part’ and a ‘host part’. In IPv6, each interface has an Interface Identifier (IID) replacing the ‘host part’. The rest of an IPv6 address is the Subnet Identifier corresponding to the IPv4 ‘network part’. As in IPv4, a contiguous set of bits starting from the left-hand end of the address is known as an (Address) Prefix. The count of significant bits in the Prefix is the Prefix Length. The same notation used in IPv4 CIDR (Classless Inter-Domain Routing) is used to specify prefixes (for example, 1080:0:0:2C0/58 indicates that the 58 (decimal) most significant bits make up the address prefix). A subnet in IPv6 is a set of interfaces that share a Subnet Identifier. An IPv6 node relies on information from the routers on the link to determine which Subnet Identifiers are ‘on link’.
Stateless and stateful autoconfiguration
IPv6 supports ‘plug and play’ autoconfiguration process using both stateless (using only routers) and stateful (using both router and DHCP servers) mechanisms described in [RFC2461] and [RFC2462]. When a network interface connects to a new network, IPv6 will normally create a Link Local address by combining the well-known link local subnet prefix FE80:: with the interface identifier (IID). The IID is just a 64 bit long pattern, intended to be unique to the interface within the scope of the link to which it is attached. The Link Local address is a ‘tentative address’ because it has not yet been shown to be unique. The node joins the all-nodes Multicast group (FF02::1) and the Solicited-node Multicast group for the tentative address. The Duplicate Address Detection (DAD) process then uses Neighbor Solicitation messages sent to this Solicited-node Multicast group to verify that no other node on the link is using this address. A node that is already using the tentative address will also be listening on this Multicast address and will respond with a Neighbor Advertisement message sent to the all-nodes Multicast address. The Neighbor Solicitations being used for DAD use the unspecified address (all zeros) as the IP source address.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 243 IPv6 overview
An IPv6 interface may use several addresses derived by combining a single IID with a number of different prefixes. The use of the solicited node Multicast group reduces the number of groups that the node has to join to monitor DAD solicitations and reduces the number of Neighbor Solicitations that need to be processed above the link layer. If no other node responds claiming prior rights on the address, it can be marked as a ‘preferred address’ and used for future communications of link scope. Up to this point, the process is the same for both hosts and routers. Newly connected routers now join the All-routers Multicast group (FF02::2) and send out unsolicited Multicast Router Advertisements to the All-nodes Multicast address (FF02::1) to let all connected hosts know that a new router is available. Newly connected hosts send out a Router Solicitation message to the all-routers Multicast group to find out what routers are connected to the link and what subnets they can join. Routers on the link reply to the host with a targeted Router Advertisement. The Router Advertisements contain the following information: • Router lifetime: nodes should not use routers that have not sent Router Advertisements for more than the lifetime • Managed (M) flag: If configured to 1, nodes on this link should use a management system such as DHCPv6 to obtain addresses rather than stateless auto-configuration. Zero means use stateless auto-configuration. • Other (O) flag: If configured to 1, nodes should use a management system such as DHCPv6 to obtain non-address related configuration information and should use stateless auto-configuration to get addresses. • Reachable Time: used by Neighbor Unreachability Detection algorithm, it indicates the time a host assumes that neighbors are reachable after receiving a Reachability confirmation from its neighbors. Zero means unspecified. • Retransmission Time: time between retransmissions of Neighbor Solicitation messages during address resolution and Unreachability detection • Link-layer address of the router interface from which the message was sent (optional) • MTU size for the link (optional) • Prefixes used on the link: router advertises all the prefixes and the advertising router that the node on the link needs to know. Each prefix has some associated information: - ‘A flag’: If configured, indicates that this prefix can be used for stateless (autonomous) address auto-configuration by nodes on the link. - ‘L flag’: If configured, indicates that addresses using this prefix are ‘on-link’ so that packets can be sent direct rather than through a router (it is possible that some of the addresses belonging to a prefix might be on-link and others off-link—for example, addresses used for Mobile IPv6 nodes would not be on-link unless the node was ‘at home’. Packets sent to a mobile node from another node connected to its home link need to go to the router to be redirected if the node is not at home. Consequently, the values of the A and L flags are completely independent.)
244 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Stateless and stateful autoconfiguration
- Lifetime, during which a prefix should be considered valid After a host has received Router Advertisements, the stateless and stateful auto-configuration processes diverge. If a Router Advertisement has the Managed (M) flag set, the host can use DHCPv6 to obtain addresses usable for communication beyond the local link. Otherwise, the host uses one or more prefixes, with the ‘A flag’ set, found in the Router Advertisement to build global or local use addresses by adding its IID. The host should use DAD to check the uniqueness of the created address again. But if the previous DAD checks made for the Link Local address using the same IID were successful, the new addresses can be assumed to be unique and used immediately for communications as preferred addresses. This process is known as ‘Stateless Auto-configuration’ (Figure 111: IPv6 autoconfiguration on page 246) because the router doesn't need to maintain any additional information about which hosts obtain configuration from the router. Stateful autoconfiguration emulates the current process for IPv4 using an updated version of DHCP. Using DHCP, a host can contact an on-link DHCPv6 server directly using a Multicast address, or an on-link router can provide a DHCPv6 relay function that allows DHCP information to be obtained from a server elsewhere on the same site. DHCPv6 can also be used to provide additional configuration when Neighbor Discovery and Stateless Auto- Configuration are used to set up addresses by setting the ‘Other’ (O) flag in the Router advertisements.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 245 IPv6 overview
Figure 111: IPv6 autoconfiguration
An autoconfigured address can be in one of the following states: • Tentative: the address is in the process of being verified as unique. • Preferred: the address has been verified as unique. • Deprecated: the address is still valid, but using it for new communication is discouraged. Existing sessions can continue to use a deprecated address. • Valid: this state covers both the preferred and deprecated states. The valid lifetime must be greater than or equal to the preferred lifetime. • Invalid: the address can no longer send Unicast traffic to or receive it from a node. An address enters this state after the valid lifetime expires. Autoconfigured addresses are almost always obtained on limited-lifetime leases. The length of the lease will be specified by means of a preferred and a valid lifetime when the prefix or address is obtained. Address leases can be extended either by Router Advertisements for stateless auto-configuration or through DHCPv6 for stateful autoconfiguration. The initial Link Local address has an infinite lifetime and never needs renewing.
246 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Address resolution and caching
Figure 112: Autoconfiguration address states
The network administrators can use both stateful and stateless autoconfiguration when needed. Stateful autoconfiguration is likely to be of continuing use in Enterprise networks where administrators will want to retain central control of configuration; whereas, stateless configuration will simplify the installation of small office and home networks.
Address resolution and caching
IPv4 uses the Address Resolution Protocol (ARP) to discover the link layer (MAC) addresses of other interfaces on the same link. IPv6 avoids the need for ARP by including an optional link layer address fields in the Neighbor and Router Solicitation and Advertisement messages which provide the link layer address mapping with the source IP address. Using the link address field, a host learns the link layer addresses of a router from the received Router Advertisement messages at the same time as it discovers its IP address and the available subnet prefixes. Routers learn the link layer addresses corresponding to host IPv6 addresses from Router Solicitation messages. Hosts can also learn the link layer addresses of other hosts on the link by exchanging Neighbor Solicitations and Neighbor Advertisements. Only a two-message exchange is needed for both parties to learn the mapping between link and IP addresses at both ends. Each node maintains four cache tables for sending packets: • Destination cache: Maps the destination IPv6 address to the corresponding address of the next-hop neighbor. • Neighbor cache: Maps IPv6 addresses to the corresponding neighbor's link-layer address. • Prefix list: Contains the list of on-link prefixes obtained by Router Advertisement messages. • Router list: Lists the IPv6 addresses of routers that have recently sent Router Advertisement messages. When a sender wants to transmit a packet, it first consults with the Destination Cache to find the next hop for the destination. The Destination Cache contains the destinations to which traffic has been sent recently. If it fails to find the destination in the cache, the sender performs
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 247 IPv6 overview
a longest prefix match against the Prefix List to determine whether the node is on-link or off- link. If the destination is on-link, the destination is the next hop. If the destination is off-link, the sender randomly selects a router from the Router List at random and uses it as the next hop for the destination. It also stores this router's IP address in the destination cache so that it can be used for the subsequent packets. The random selection of the next-hop router may not get the best router for the destination. In that case, the router may send an ICMPv6 Redirect message to inform the source that there is a better next-hop to the destination. Redirect messages are potentially a major security loophole. It is desirable that routers are configured to inform hosts about the on-link prefixes that are in use through Router Advertisements so that it is not necessary to send redirect messages relating to these prefixes (RFC4191). Once the next-hop address is determined, the sender checks the Neighbor cache for the corresponding link-layer address. If the address is not present in the cache, the sender then sends Neighbor or Router Solicitation message to discover the next-hop’s next-hop link-layer address. Once the next-hop link-layer address is known, the source can send the packet. IPv6 uses Neighbor and Destination caches to keep track of active and reachable destinations. The IPv6 Neighbor Cache, equivalent to IPv4 ARP Cache, maintains a list of neighbor entries containing Unicast address, MAC address, nodal type (host or router), Reachability information, and the next scheduled neighbor Unreachability detection event. If an address in the Neighbor Cache is not used for a time, the cache entry will become stale and the node will need to refresh the information by repeating the Address Resolution exchange. Router addresses will normally be refreshed by routers Multicasting of unsolicited Router Advertisements. The entries in Neighbor Caches will be removed when they become stale and there is no response to Neighbor Solicitations. When a node’s link layer address is changed, it can Multicast an unsolicited Neighbor Advertisement to refresh other on-link nodes’ Neighbor Cache.
IPv6 address management
IPv6 uses a Provider based ‘strict aggregation’ policy to facilitate route aggregation over the Internet. The basis of ‘strict aggregation’ is that a network should acquire address space for its network from a provider—Provider Addressing (PA). The provider delegates authority for this part of the address space to the customer and, in turn, will provide the default route for traffic to and from the customer using these addresses. The addresses come from a larger block delegated to the provider by a ‘larger’ provider who in turn will route traffic to and from all of their customer providers. Address delegation is repeated up to the point where the highest level providers get address space from the regional Internet Routing Registries such as APNIC, ARIN*, LACNIC and RIPE. These registries, in turn, have address space delegated to them by ICANN*/IANA.
248 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Multiple IP addresses per interface
To achieve global connectivity, a provider must be able to route traffic from his customers to any other destination in the Internet. This is accomplished by having all top-level providers connected through either a common Internet exchange points or private peering connections. All providers’ customers use a default connection through their parent provider to route traffic outside of their routing domains. Providers can build as many connections as they find economically and technically expedient between their networks and other providers at any level in the address delegation tree to carry traffic between their customers. With this scheme, the number of routes that a provider has to deal with will be limited by the number of providers that it peers with, rather than the number of customers who want to advertise individual routes, as now happens in IPv4. Strict aggregation seeks to prevent traffic for third parties being carried across links between provider peers: providers will normally filter incoming and outgoing traffic to eliminate packets that are not going to or from their customers. A detail discussion and IPv6 site address allocation recommendations can be found in RFC3177. IPv6 supports dynamic network renumbering by multicasting Router Advertisement messages. When an organization changes IP service provider, it acquires a new address block that can be routed through this new provider. During the transition, each node would expect to have addresses for each of the networks, one of which would be marked as deprecated to avoid its use for new communication sessions. The marking would be changed over between the new provider and the old provider after deployment of the new addresses was complete so as to direct traffic through the new provider. IPv6 provides a mechanism for a node to select the most appropriate source address from those it has available when transmitting a packet.
Multiple IP addresses per interface
Unlike IPv4 where the rule is strictly one Unicast address per interface, IPv6 allows every interface to have multiple Unicast IP addresses. All interfaces are required to have a Link Local address. This address connects the interface to the ‘link subnet’ that is used during initial configuration to contact local routers and information services on the same link. It might then acquire a local use address or one or more global Unicast addresses associated with the subnets to which it is attached. Therefore, it is expected that an IPv6-capable interface has a minimum of two addresses; a Link Local address, a Global or a Local Unique Unicast address depending on the scope of communication. With multiple interface IP addresses, the upper layer protocols and applications need to select the most appropriate destination and source addresses for a communication session. (RFC3484) specifies precedence rules and algorithms needed to handle the selection process. For examples, a host that has no global scope Unicast addresses cannot send to a global scope destination address and the preferred address should take precedence over a deprecated address. The socket layer has to check to make sure the source and destination addresses are compatible.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 249 IPv6 overview
IPv6 routing
The routing of IPv6 packets is the same as the IPv4 routing. Routers build a forwarding table based on routes received from a number of sources: • Local subnets implied by the prefixes of addresses assigned to interfaces on the node and information received from local routers • Static routes configured into the node directly or using DHCPv6 • Routes received through dynamic routing protocol sessions The IPv4 routing protocols used for Unicast routing have been adapted for use with IPv6: • Inter-domain routing BGP4 (MP-BGP4) (RFC2545) are identical IPv4, but the Network Layer Reachability Information (NLRI) records now carry IPv6 address prefixes as well or instead of IPv4 prefixes. • Integrated IS-IS is capable of handling multiple address families and does not assume that there is only one subnet per link. The extension to IPv6 is trivial, especially since the transports used for IS-IS are link layer protocols rather than IP (I-D.ietf-isis-ipv6). A network designer has the option to run just one instance of IS-IS to install routes for a network which can support both IPv4 and IPv6. • OSPFv3 [RFC2740] is the update of OSPFv2 to support IPv6 networks. The changes here are more significant because OSPFv2 assumes the one-to-one correspondence between subnets and links built into IPv4. OSPFv3 has to deal with the possibility that the interfaces on a link can belong to more than one subnet. OSPFv3 would need further modification to support IPv4 as well as IPv6. • RIPng (RFC2080) is a direct extension of RIPv2 for IPv4. It is still useful for small, simple networks.
Upper layer protocols
IPv6 is primarily a replacement for the IP Network Layer. All the existing IP transport protocols (including TCP, UDP) can be carried as payloads in an IPv6 datagram just as in IPv4. With IPv6, a node will discard a UDP packet if the checksum value is zero because the checksum computation is mandatory for IPv6. Many upper layer protocols can be used unchanged in networks with an IPv6 Network Layer. The only problems that are likely to arise stem from payloads that carry IP addresses in numeric
250 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] DNS
form (rather than using fully qualified domain names). Several common protocols are affected, including the control connection of FTP, SDP and SNMP. • DNS on page 251 • DHCP on page 251 • FTP on page 252 • SDP on page 252
DNS
Domain Name Services (DNS) has been extended so that multiple IPv6 and IPv4 addresses can be associated with a domain name. IPv6 addresses are held in new AAAA (quad-A) records (RFC3596), which are direct analogs of the A records for IPv4 addresses. A corresponding reverse lookup domain, IP6.INT, for mapping IPv6 addresses to domain names has been defined. Note the Reverse lookup can return both IPv4 and IPv6 addresses. The implementation of an IPv6 network is comparable to the implementation of an IPv4 network. In both cases address space needs to be obtained and the Domain Name System (DNS) and routing should be set up correctly. When an application invokes DNS to look up a destination domain name’s corresponding IP address, it must expect to receive a list of addresses. There is no guarantee that a destination will be reachable at that moment due to the network failure or renumbering activities. Be aware that cycling through the possible destination addresses may take significant time, due to the network round trips and timeouts involved in determining that an address is unreachable or unusable. To avoid its potential impact on the real-time services, any additional knowledge that can help overriding the default address selection procedure should be applied to speed up the communication process. For example, although the default rules would prefer the IPv6 addresses, if an application knows a certain host can only communicate using IPv4, it should use IPv4 address even though the host offers IPv6 addresses.
DHCP
With DHCPv4, clients are configured to use Dynamic Host Configuration Protocol (DHCP). With DHCPv6 (RFC 3315), clients are informed to use DHCP using Router Announcement messages. Autoconfiguration of an IPv6 interface will generally result in a need to dynamically update the DNS records for the node’s domain name. Dynamic DNS (DDNS) (RFC 2136), which was developed to support DHCP, provides the technical means to alter the DNS database.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 251 IPv6 overview
FTP
File Transfer Protocol (FTP) assumes 32 bits network addresses used in communication. RFC2428 (FTP Extensions for IPv6 and NATs) specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6.
SDP
Session Description Protocol (SDP) provides text format description of connection address for the session medias and optional attributes for establish one or more multimedia sessions between two endpoints. RFC3266 specifies the use of IPv6 addresses in SDP. A SIP User Agents (UA) may have an IPv6 address and an IPv4 address. Such a UA will typically be willing to use any of its addresses to establish a media session with a remote UA. The Alternative Network Address Types (ANAT) semantics [RFC 4091] of the SDP grouping framework allow UAs to offer alternative addresses of different types in an SDP session description. An IPv4/IPv6 dual-stack SIP UA can generate an offer grouping an IPv6 media line and an IPv4 media line using ANAT. Upon receipt of this offer, the answerer would accept one media line and reject the other. The entity generating a session description may have an order of preference for the alternative network address types offered. The identifiers of the media streams MUST be listed in order of preference in the group line.
IPv6 migration
A successful IPv6 transition must continuously maintain the interoperability with the large installed base of IPv4 hosts and routers while deploying IPv6. RFC 2893 defines a set of transition methods that all IPv6 hosts and routers can implement to remain compatible with the existing IPv4 hosts and routers. The IPv6/v4 dual stack is the most straightforward approach. It involves running IPv4 and IPv6 simultaneously on the same node (host or router). These nodes have the ability to interoperate with IPv4 nodes using IPv4 packets, and also directly interoperate with IPv6 nodes using IPv6 packets. The common dual-stack migration strategy will start from the network infrastructure (core routers, distribution/access routers, firewalls), then server farms, and finally the clients. The second approach is to use tunnels carrying one protocol inside another. While the IPv6 infrastructure is being deployed over time, the existing IPv4 routing infrastructures remain functional. The tunneling techniques provide ways to utilize an existing IPv4 routing
252 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] IPv6 migration
infrastructure to carry IPv6 traffic. Tunnels can be created to interconnect the isolated IPv6 islands over the existing IPv4 networks when required. These tunnels encapsulate IPv6 packets in IPv4 packets for forwarding across portions of the network that haven't yet been upgraded to IPv6. All tunnels are bidirectional. A tunnel provides a virtual point-to-point link to the IPv6 layer using IPv4 address at the lower layer. RFC 4213 discusses issues related to tunnel MTU size, Neighbor discovery over tunnels, fragmentation, and security. Tunnels can be created in a variety of ways: • Router-to-Router: IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. Tunnel spans one segment of the end-to-end path. • Host-to-Router: IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that is reachable using an IPv4 infrastructure. Tunnel spans the first segment of the end-to-end path • Host-to-Host: IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. The tunnel spans the entire end-to-end path. • Router-to-Host: IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/ IPv4 host. This tunnel spans only the last segment of the end-to-end path. A tunnel can be created either manually and dynamically. A manually configured IPv6 tunnel requires configuration at both ends of the tunnel. Manually configured tunnels are convenient for providing stable connections that require secure connections between two (router or host) endpoints, but the static tunnels require constantly be changed and monitored during the IPv6 transition period. The configuration and monitoring overheads can increase rapidly beyond manageable as more systems are added to the network. The static tunnel approach is more suitable for the Router-to-Router tunnel type, where the number of tunnels is small, remote addresses are known, and security is more critical than automation. The dynamic tunnels are created automatically based on the packet destination address and routing. It simplifies the maintenance of tunnels at the expense of losing the ability to track the communication over these transient tunnels since many firewalls will not inspect the traffic if it is in a tunnel and dynamic tunnel interfaces can not be monitored using SNMP. This allows an unknown host to send malicious traffic into the internal network using tunnels disrupting the network services. The dynamic tunnels can pose more security threats when internal routers communicate with external nonauthenticated routers. This allows the hosts of unknown networks to send forged traffic into the internal networks using the remote tunnel endpoints. Therefore, dynamic tunnels should only be used in a trust environment and migration plans should the use of dual stack wherever possible and minimize the use of tunneling. The third approach relies on the network address translation techniques to translate IPv6 packets into IPv4 packets. These translation techniques are more complicated than IPv4 NAT because the protocols have different header formats and should only be used as a last resort. Many of the translation techniques require complex adaptation for particular protocols incurring more security problems. Transition to IPv6 using translators also introduces significant protocol performance and troubleshooting problems and the use of translators should be avoided if possible.
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 253 IPv6 overview
It will be easier to try to run everything in a dual-stack mode first and then remove the IPv4 protocol over time. Currently there aren't many systems being developed for IPv6-only communications, but there are many systems that work in dual-stack mode.
254 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] Appendix D: Acronyms
Table 64: Acronyms
ADIMSS Advanced DSN Integrated Management Support System AEC Acoustic Echo Canceller AES Advanced Encryption Standard AGC Automatic Gain Control AIN Advanced Intelligent Network ALG Application Level Gateway ALI Automatic Location Information AM Accounting Manager API Application Programming Interface ARP Address Resolution Protocol ARTS Assured Real Time Services ARTS-AS Assured Real-Time Services Application Server AS Application Server ASAC Assured Services Admission Control ASCLAN Assured Services Converged Local Area Network ASLAN Assured Services Local Area Network ASU Automatic Software Upgrade BBUA Back-to-Back User Agent BCP Border Control Point BGP Border Gateway Protocol BHCA Busy Hour Call Attempt BHHCA Busy Hour Half Call Attempt BHSTA Busy Hour SIP Transaction Attempt BIP Breaker Interface Panel BPT Bulk Provisioning Tool CBC Cipher Block Chaining
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 255 Acronyms
CBR Constant Bit Rate CCM Counter with CBC-MAC CCS Centum Call Seconds CDP Coordinated Dialing Plan CE Customer Edge CIR Committed Information Rate CLAN Converged Local Area Network CLI Command Line Interface CODEC COder DEcoder CoS Class of Service CPE Customer Premise Equipment CPL Call Processing Language CPU Central Processing Unit CSV Comma Separated Value DB Database DDoS Distributed Denial of Service DHCP Dynamic Host Configuration Protocol DID Direct Inward Dialed DiffServ Differentiated Service DISN Defense Information System Agency DMLT Distributed Multi-Link Trunking DNS Domain Name System DoD Department of Defense DoS Denial of Service DSCP DiffServ Code Point DSL Digital Subscriber Line DSN Defense Switched Network DSP Digital Signal Processor DSPI Dynamic Stateful Packet Inspection DTMF Dual-Tone Multi-Frequency EF Expedited Forwarding ECMP Equal Cost Multi-Path
256 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] EMS Element Management Server E&M Ear and Mouth ERL Emergency Response Location ERS Ethernet Routing Switch FEFI Far End Fault Indication FIFO First-In First-Out FOIP Fax over Internet Protocol FXO Foreign Exchange Office FXS Foreign Exchange Station FW Firewall GB Gigabyte Gb Gigabit GIG Global Information Grid GIPS Global IP Sound GPS Global Positioning System GQoS Generic Quality of Service HTTP Hypertext Transfer Protocol IA Information Assurance IAD Integrated Access Devices IANA Internet Assigned Number Authority ICMP Internet Control Message Protocol IEMS Integrated Element Management System IGMP Internet Group Management Protocol IGP Interior Gateway Protocol IM Instant Messaging IP Internet Protocol IPCM Internet Protocol Client Manager IPDR Internet Protocol Detail Record IPSec Internet Protocol Security ISDN Integrated Services Digital Network IST Inter-Switch Trunk JDBC Java Database Connectivity
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 257 Acronyms
kbit/s Kilobits per second KVM Keyboard, Video, and Mouse LDAP Lightweight Directory Access Protocol LAN Local Area Network LCD Liquid Crystal Display LOM Lights Out Management LSC Local Session Controller MAN Metro Area Network MAS Media Application Server MB Megabyte Mbit/s Megabits per second MCP Multimedia Communication Portfolio ME Managed Element MFS Multifunction Switch MFSS Multifunction SoftSwitch MG Media Gateway MGw Media Gateway MGCP Media Gateway Control Protocol MHz Megahertz MIB Management Information Base MLT Multi-Link Trunking MLPP Multilevel Precedence and Premption MoH Music on Hold MOS Mean Opinion Score MPCP Media Portal Control Protocol MPLS Multi-Protocol Label Switching MWI Message Waiting Indicator NAPT Network Address and Port Translation NAT Network Address Translation NE Network Element NED Network Element Daemon NEI Network Element Interface
258 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] NES Network Energy Source NIC Network Interface Card NMS Network Management System NPI Numbering Plan Indication NSD Network Service Descriptor NSSA Not So Stubby Area NTP Network Time Protocol OAM&P Operation, Administration, Maintenance, and Provisioning OEM Oracle Enterprise Manager OM Operation Measurement OMI Open Management Interface ONT Optical Network Terminators OPI Open Provisioning Interface OS Operating System OSI Open Systems Interconnection OSN On Site Notification OSPF Open Shortest Path First OSS Operation Support System PAT Port Address Translation PBX Private Branch eXchange PCM Pulse Code Modulation PE Provider Edge PHB Per Hop Behavior PIR Point of Presence PRI Primary Rate Interface PSAP Public Safety Answering Point PSTN Public Switched Telephone Network PTE Physical Telecommunications Environment QoS Quality of Service RFC Request For Comments document RIP Routing Information Protocol RSA Rivest Shamir Adleman or RSA protocol
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 259 Acronyms
RSIP ReStart In Progress RTA Record Transfer Agent RTP Real-time Transport Protocol RTCP Real-time Transport Control Protocol RTS Real Time Services RU Recording Unit SATF Security Advisory Task Force SCC2 Switching Control Center 2 SC Service Consumer SDP Session Description Protocol SE Service Element SimRing Simultaneous Ringing SIP Session Initiation Protocol SIP-T Session Initiation Protocol for Telephones SLA Service Level Agreement SMDI Station Message Desk Interface SMLT Split Multi-Link Trunking SNMP Simple Network Management Protocol SOAP Simple Object Access Protocol SS Service Session SS7 Signaling System 7 SSH Secure Shell STIG Security Technical Implementation Guide SSL Secure Socket Layer STP Spanning Tree Protocol TAF Transparent Application Failover TCP Transmission Control Protocol TDM Time Division Multiplexing TLS Transport Layer Security TON Type of Number ToS Type of Service UA User Agent
260 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected] UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol UDP Universal Dialing Plan UE User Element UE Usage Entry UFTP UNIStim File Transfer Protocol UNIStim Unified Networks IP Stimulus Protocol UPS Uninterruptible Power Supply URI Universal Resource Indicator URL Universal Resource Locator USB Universal Serial Bus USP Universal Signaling Point UTC Universal Time Coordinated UTP Unshielded Twisted Pair VAD Voice Activity Detection VBR Variable Bit Rate VLAN Virtual Local Area Network VLSM Variable Length Subnet Masks VoIP Voice over Internet Protocol VPN Virtual Private Network VRRP Virtual Router Redundancy Protocol VTC Video Tele Conferencing WAN Wide Area Network WRED Weighted Random Early Discard
Avaya Aura® Application Server 5300 Planning and Engineering March 22, 2012 261 Acronyms
262 Avaya Aura ® Application Server 5300 Planning and Engineering March 22, 2012 Comments? [email protected]