Network management

About: Network management is a research topic. Over the lifetime, 17859 publications have been published within this topic receiving 234520 citations. The topic is also known as: computer network management & NM.

Ultra-Low Latency (ULL) Networks: The IEEE TSN and IETF DetNet Standards and Related 5G ULL Research

Abstract: Many network applications, e.g., industrial control, demand Ultra-Low Latency (ULL). However, traditional packet networks can only reduce the end-to-end latencies to the order of tens of milliseconds. The IEEE 802.1 Time Sensitive Networking (TSN) standard and related research studies have sought to provide link layer support for ULL networking, while the emerging IETF Deterministic Networking (DetNet) standards seek to provide the complementary network layer ULL support. This article provides an up-to-date comprehensive survey of the IEEE TSN and IETF DetNet standards and the related research studies. The survey of these standards and research studies is organized according to the main categories of flow concept, flow synchronization, flow management, flow control, and flow integrity. ULL networking mechanisms play a critical role in the emerging fifth generation (5G) network access chain from wireless devices via access, backhaul, and core networks. We survey the studies that specifically target the support of ULL in 5G networks, with the main categories of fronthaul, backhaul, and network management. Throughout, we identify the pitfalls and limitations of the existing standards and research studies. This survey can thus serve as a basis for the development of standards enhancements and future ULL research studies that address the identified pitfalls and limitations.

Implementing a Generalized Tool for Network Monitoring

Abstract: Determining how you were attacked is essential to developing a response or countermeasure. Usually, a system or network manager presented with a successful intrusion has very little information with which to work: a possibly corrupted system log, a firewall log, and perhaps some tcpdump output. When hackers come up with a new technique for cracking a network, it often takes the security community a while to determine the method being used. In aviation, an aircraft’s ‘‘black box’’1 is used to analyze the details of a crash. We believe a similar capability is needed for networks. Being able to quickly learn how an attack works will shorten the effective useful lifetime of the attack. Additionally, the recovered attack records may be helpful in tracking or prosecuting the attacker. Since we’ve developed a general purpose statistics-gathering system, we believe it will be useful for more than just security. For example, a network manager may desire an historical record of the usage growth of certain applications, or details about the breakdown of types of traffic at different times of day. Such records will provide useful information for network managers in diagnosing performance problems or planning growth. This paper describes an architecture and toolkit for building network traffic analysis and statistical event records: The Network Flight Recorder. The NFR uses a promiscuous packet interface to pass visible traffic into an internally meta-programmed decision engine which routes information about packets and their contents into statistical or logging backends. In addition to packet analysis and collection, the NFR’s internal architecture permits network managers to sample interesting portions of network traffic for logging or statistical analysis. The NFR programming language is simple, but powerful enough that you can perform reasonable analysis on traffic before choosing to record it. For example, you might analyze SMTP transactions but only choose to record those relating to a user who is sending spam or abusive E-mail. The analysis language includes a capability for generating alert messages which the rest of the system queues, multiplexes, and delivers. A simplified hyper-query interface allows extensive browsing of the NFR’s stored datasets and statistics from any Java-enabled browser. The NFR is currently being deployed at a number of ISPs and commercial sites, and is available for download in source code form from www.nfr.net.2 Background and Motivation In 1990, one of the authors managed a rather chaotic network, including an embryonic firewall, using NNStat as a security tool. NNStat [1] was designed as a statistical analysis system for the NSFnet backbone, not as a security tool, but possessed several attractive properties: 1. It permits accurate and highly condensed summaries of an event on the network. 2. It permits flexible specification of types of events to record. 3. It permits flexible storage of information about the events that are observed. 1They are actually Safety Orange. 2Use of the NFR software is free for noncommercial and research purposes. A commercial release of the software is being developed. While NNStat’s authors were concerned about, for example, how much RIP traffic was crossing the network, a security conscious network manager could use NNStat to record all RIP traffic emanating from any systems that were not on an ‘‘approved list’’ of routers. Suddenly, NNStat was useful as a crude tool for mapping who and what, as well as for setting an alert to fire when something happened that the network manager believed should not. NNStat, wrapped with a bunch of quick and dirty shell scripts and cron jobs, served well as a poor man’s intrusion detection system. Other network managers have implemented similar systems using tcpdump, or more sophisticated special-purpose network watchers like ARPwatch [2], TCPwatch [3], Netman [4], clog [5], Netwatch [6], and Argus [7]. Other intrusion detection burglar alarms have focused on features of the host operating system, such as tcp_wrappers [8], klaxon [9], and tocsin [10]. Many of the monitoring systems implemen1997 LISA XI – October 26-31, 1997 – San Diego, CA 1 Implementing a Generalized Tool for Network Monitoring Ranum, et al. ted in the past contain features found in NFR. We believe that the new ground the NFR breaks is by making the filtering and analysis process internally programmed, rather than static-coded into the monitoring application. NFR is intellectually evolved from NNStat, but includes a more generalized and powerful filtering language, as well as the ability to trigger alerts and log complete packet information. A triggering specification lets data be selected from reassembled TCP sessions, providing a powerful capability for usage measurement as well as audit. The authors intend to use NFR as a platform for exploring auditing and logging, while simultaneously providing a freely available, high quality data source for researchers working on intrusion detection. Overview of the NFR Architecture The architecture of NFR was designed as a set of components, each tailored to a specific activity. Data is gathered by one or more packet suckers, forwarded to the decision engine for filtering and reassembly, and possibly recorded to a backend for storage or statistical processing. The query interface is kept completely separate from the input data flow to minimize the performance impact of a user’s querying the system while it is collecting data.

Medical network management article of manufacture

Abstract: In a medical network management system (NMS) (20), health plan beneficiaries access a team of health care professionals over the telephone to help them assess their health needs and select appropriate care. The NMS (20) is implemented with an article of manufacture for use with a data processing system (13). A storage medium (15) has stored therein a medical provider information stored program (22) and a medical provider database (24). The medical provider database describes clinical services or procedures available from each provider by clinical codes or procedure codes. The data processing system (13) is configured by the medical provider information stored program (22) when executed by the data processing system (13) to use the clinical codes or procedure codes to identify a medical provider from the medical provider database for providing a specific medical service to a patient.

In-vehicle network management using virtual networks

Abstract: A network management approach for use in a vehicle to control activation of electronic control units (ECUs) networked together throughout the vehicle. The ECUs are grouped together by function into virtual networks, with each virtual network including those ECUs used in carrying out a particular control task, such as controlling power windows or automatic headlights. The virtual networks are activated using a messaging protocol that specifies which virtual network is being activated. Periodic messages specifying the virtual network are also used to maintain it active. This permits the ECUs to be maintained in a low power quiescent state when the control functions are not needed, while allowing only those needed for a particular control task to be awakened and maintained in an activated state to carry out their associated control task. An ECU can activate one of the virtual networks by transmitting a wake-up signal followed by a message identifying the virtual network. Each of the ECUs receive this message and, if it is a member of the virtual network being initialized, maintains itself in an active state to carry out the control task associated with the virtual network. The other ECUs return to the quiescent state. Using this approach, an ECU is able to activate only the necessary ECUs for a particular control task without having to know which or how many ECUs are involved in performing the task.