PDF(78.2 KB) View with Adobe Reader on a variety of devices
ePub(83.1 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(69.7 KB) View on Kindle device or Kindle app on multiple devices
Updated:July 15, 2021
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document in about the Trivial File Transfer Protocol (TFTP) scale architecture feature implemented as a part of Cisco Unified Communication Manager (CUCM) version 11.5 the newest uplift to CUCM. This is purely a engineering feature in order to improve TFTP service with respect to memory usage and how it serves the configuration and static files. The business logic remains the same and there is no impact with respect to other services provided by TFTP.
Reasons why this improvement was required and incorporated
Problem with current Design
The logic of how TFTP serves the configuration files hasn’t been changed for a long time.
Pre 11.5, TFTP service builds the configuration files and caches all the configuration files in-memory.
With more capacity added to CUCM with respect to number of phones supported, the memory foot print of TFTP service linearly increased.
Future roadmaps have the requirement of additional capacity for phones in order to be implemented in CUCM.
Hence, address the increas of memory foot print of TFTP service becomes important.
Service start up time
In a medium to large deployments with 20k to 40k phones configured.
When a change is made that affects all the phones, TFTP builds all the affected configuration files and rebuilds it cache.
This increases the time taken for the TFTP service to start.
At the time when phones request for configuration file a busy response is sent to the phone.
The new feature implemented addresses the above two problems by a cache-less design and build the configuration file on-demand. When a request is sent from phone, the TFTP service builds the configuration file on the fly and serves it to the phone in real time. It won't cache the configuration file in-memory which in turn it reduce the service start time and the memory footprint of the TFTP service.
Design changes done fall under two categories namely 'Connection Management' and 'Configuration File Generation'. The below table details the changes done under each category.
Configuration File Generation
Framework added for on-demand build and signed configuration files
Network Service layer are designed to use SDL in order to handle all TCP connections
No changes where phones request the configuration files over UDP
Below are the performance improvements achived with implementation of this new feature.
Significant reduction in memory footprint of TFTP service
Memory footprint is around 600 MB for the TFTP service
Service start time is lesser since the files are not cached
The service start time is independent of the number of phones deployed in the system
No. of Phones
Time take in Pre 11.5 version
Time Taken in 11.5 version
Service Start Time
3 Minutes 38 Seconds
0 Minutes 19 Seconds
Files Served over HTTP
7 Minutes 24 Seconds
4 Minutes 06 Seconds
Files Served over TFTP
5 Minutes 36 Seconds
4 Minutes 11 Seconds
Note: The above numbers are not just from one test run but is a average of several test runs.