rmat used by the local host. An "octet" transfer treats the data as bytes without any visi- bility into, or interpretation of, the content of the data. In addition, CMS has file transfer APIs that conform to the IETF's RFC 1350. 11.2.11 Server Framework The framework services forms the nucleus of the CMS as various network manage- ment modules and applications can be built upon them (Table 11.4). High availability is a key component of carrier-class systems and so the server framework provides fail-over capability to a hot standby server. 42 CMS has two BE servers, one of which is designated primary and the other standby. The standby server takes over the workload when the primary server fails or is brought down by an attack or excessive load. The primary server may be brought down for reasons such as scheduled maintenance, system failure, power outage or the crash of a JVM. Fail-over is where the standby server assumes the workload of the primary server. When the primary server is running again, the workload is moved back to the primary server by a process called "failback". In the distributed architecture, fail-over support is provided when one BE server is down and the other takes over and continues to provide the service. The fail-over 42 Hot standby means that load can be transferred to the standby server without manual intervention and with almost no disruption to services. The reader may have heard the phrase "hot-swappable" in relation to network cards and other peripherals, similarly meaning that load can be transferred without disrup- tion to services: at the instant that one line card ceases to function, the other comes into operation. OSS for Telecom Networks Table 11.4 Server framework services. Framework service Description Scheduler Used to run tasks in the context of threads at a specified time. Using scheduler services, the maximum number of threads to run the tasks can be controlled Logging Used by modules and applications to print log and error messages. The printing of log messages to module-s