Which of the following describes a network device capable of processing data?

(3) Network devices

A network device is a node in the wireless mesh network. It can transmit and receive wireless HART data and perform the basic functions necessary to support network formation and maintenance. Network devices include field devices, router devices, gateway devices, and mesh hand-held devices.

Field devices. The field device may be a process-connected instrument, a router, or hand-held device. The wireless HART network connects these devices together.

Router device. A router device is used to improve network coverage (to extend a network), so it is capable of forwarding messages from other network devices.

Process-connected instrument. It is typically a measuring or positioning device used for process monitoring and control; it is also capable of forwarding messages from other network devices.

Adapter. An adapter is a device that allows a HART instrument without wireless capability to be connected to a wireless HART network.

Hand-held support device. Hand-held devices are used in the commissioning, monitoring, and maintenance of network devices; they are portable and operated by plant personnel.

Wireless HART networks can be configured into a number of different topologies including the following:

Star network. Star networks have just one router that communicates with several end devices. This is one of the simplest network topologies, appropriate for small applications.

Mesh network. Mesh networks are formed by network devices that are all routers. They provide a robust network with redundant data paths, able to adapt to changing radio frequency environments.

Star mesh network. These are a combination of the above two.

7.3.1 Network Devices and Characteristics

A network device is an individual component of the network that participates at one or more of the protocol layers. This includes end devices, routers, switches, DSUs, hubs, and NICs. Network devices have characteristics that can be measured. They are grouped into end-to-end, per-link, per-network or per-element characteristics, as shown in Figure 7.3.

End-to-end characteristics are those that can be measured across multiple network devices in the path of one or more traffic flows, and may be extended across the entire network or between devices. Examples of end-to-end characteristics for network devices are availability, capacity, delay, delay variation (jitter), throughput, error rates, and network utilization. These characteristics may be modified or added to, depending on the types of traffic on the network.

Per-link/per-network and per-element characteristics are those that are specific to the type of element or connection between elements being monitored. These characteristics may be used individually, or may be combined to form an end-to-end characteristic. Examples of per-link characteristics are propagation delay and link utilization, while examples of per-element characteristics include (for an IP router) IP forwarding rates (e.g., in IP packets/second), buffer utilization for the router, and any logs of authentication failures.

Management of network devices and networks includes network planning (e.g., cell site planning for wireless), initial resource allocation (e.g., frequency or bandwidth allocations), and FCAPS from the telecommunication network management model: fault, configuration, accounting, performance, and security management.

Publisher Summary

Network devices will always be heterogeneous, both in the functionality they provide and in the way they represent and use management data. This adversely affects interoperability and makes management of networks and networked applications more difficult. This chapter describes the motivation and design of the FOCALE autonomic networking architecture. FOCALE is based on the following core principles: (1) use a combination of information and data models to establish a common “lingua franca” to map vendor- and technology-specific functionality to a common platform-, technology-, and language independent form, (2) augment this with ontologies to attach formally defined meaning and semantics to the facts defined in the models, (3) use the combination of models and ontologies to discover and program semantically similar functionality for heterogeneous devices independent of the data and language used by each device, (4) use context-aware policy management to govern the resources and services provided, (5) use multiple-control loops to provide adaptive control to changing context, and (6) use multiple machine learning algorithms to enable FOCALE to be aware of both itself and of its environment in order to reduce the amount of work required by human administrators. This chapter first motivates the need for autonomic systems and explains why a well-known but simple example of an autonomic control loop is not sufficient for network management purposes. It uses these deficiencies as motivation to explain the rationale behind the original FOCALE autonomic architecture. The chapter concludes with a discussion of how knowledge is represented in FOCALE.

2.6.6 SNMP Notifications

Network devices often maintain system software that is capable of operating in an asynchronous manner. Node software can sometimes be programmed to raise asynchronous alarms that are intended to alert the system's operator of some interesting condition or event. SNMP provides a means by which agents are able to issue asynchronous messages to managers (or midlevel managers). These messages are called SNMP notifications. SNMP notifications are defined in a MIB module with the NOTFICATION-TYPE macro. Notifications can be sent from a notification originator to a notification receiver using one of two mechanisms: either a TRAP sent (a TRAPv1 or a TRAPv2, depending on the version of the Protocol Operations being used), or an INFORM (only available with version 2 of the Protocol Operations).

The notification message contains one or more pairs of OIDs and values. Each pair consists of an OID and a corresponding value that is informative for the notification the object is contained in. The Trap version of a notification message is sent either in a reliable (INFORM) or unreliable (TRAPv2) manner. Therefore, reception of a notification is not always guaranteed. SNMPv2 added a reliable notification called an INFORM. An INFORM notification contains similar semantics to the notification except that the agent continues to attempt delivery of the INFORM message until it receives an acknowledgment from the manager that it has received it (or it times out). The trap or inform destinations are specified either directly on a device via its CLI, or using SNMP's RFC 2573 MIB module. Retry counts and timeouts for INFORMs are specified in those MIB modules.

Special care should be taken when using traps to ensure that a manager is generally capable of both catching them and then reacting in a reasonable amount of time to those messages if necessary. The transmission of notifications in large amounts can actually exacerbate a failure condition by either overloading the network between the device entity and the manager entity, or overloading the manager entity such that it cannot take appropriate corrective action because it is busy processing notifications.

UDP

For video and audio, another protocol is required. TCP can cause problems with audio and video files because its attempt to resend lost packets results in portions of the communication occurring out of place and therefore in the wrong sequence, making the video or audio communication intelligible. The human eye and ear are very good about rebuilding lost portions of communications. Imagine a restaurant in which you are overhearing a conversation at an adjacent table. You may not be able to hear the entire conversation—not every word because of the noise from others talking—but you can still follow what is being said.

Instead, what we need is a protocol that will send the data without error correction and without attempting to resend lost packets. That protocol is User Datagram Protocol (UDP). UDP is called a connectionless protocol because it does not attempt to fix bad packets. It simply sends them out and hopes they arrive. The transmitting device has no way of knowing whether they do.

UDP and its partner, Real-Time Protocol (RTP), work together to ensure that a constant stream of data (hence the term streaming data) is supplied for a receiving program to view or hear. RTP is used for audio and video. Typically, RTP runs on top of the UDP protocol.

As an industry default, all network data is called TCP/IP data, whether it is TCP/UDP or RTP. It is kind of like calling any tissue Kleenex™ or any copier a Xerox™ machine. It is not accurate; it is just that everyone does it.

Another important set of protocols that security designers will need to know about are unicast and multicast protocols. These are discussed in detail later in this chapter.

An Optimistic View

With today's network devices, even at line rate or close to line rate forwarding, packets will incur a very small processing delay at each device. Virtually every major network equipment vendor can show a third-party benchmarking result verifying that

Delay:<1 ms

Delay variation:<0.3 ms

Packet loss ratio: 0 percent (or well below 10−6)

while forwarding at line rate.

With such network devices, a national network of air route distance up to 4190 km (U.S. diagonal, between Boston in the northeast of the United States and Los Angeles in the southwest, longer than the distance between Lisbon and Moscow) and 14 hops will have:

Delay=14×1+1.25×4190×5/1000=40 ms

Delay variation≤14×0.3=4.2 ms

Packet loss ratio: 0 percent (if a single device's packet loss ratio is 10−6, then the path of 14 devices will have a packet loss ratio of about 14×10−6, or 0.0014 percent. See [Y.1541] for a precise calculation method. Because it is sufficiently low, we treat it as 0 percent.

The factor of 1.25 in the above formula is used to convert the air route distance to fiber route distance, as recommended by Y.1541. The reason the device count is set at 14 will be explained in the next section. 5/1000 comes from the propagation delay of 5 ms per 1000 km. Note that all the values are one-way values, not round-trip ones. Note also that delay variation is not additive. That is, if each device has a delay variation of 0.3 ms, the whole path of 14 devices can have a delay variation between 0 ms and 4.2 ms. Here we simply use the worst-case value.

This means that a national IP network covering an area as big as the United States can easily meet the Y.1541 Class 0 requirements.

Similarly, an intercontinental network of air route distance 22,240 km (between Sydney, Australia, and Frankfurt, Germany, via Los Angeles4) and 24 hops will have:

Delay=24×1+1.25×22,240×5/1000=163 ms

Delay variation≤24×0.3=7.2 ms

Packet loss ratio: 0 percent

This means that an intercontinental IP network can easily meet the Y.1541 Class 1 requirements.

Most backbone NSPs would agree with the network performance statistics above. In fact, Global Crossing, a major global NSP, has a web site where people can find out network delay between any two major cities in the world:

//www.globalcrossing.com/network/network_looking_glass.aspx

According to this web site, the reported round-trip network delay between Boston and Los Angeles is 72 ms, or 36 ms one way. The reported round-trip network delay between Sydney and Frankfurt is 315 ms, or 157 ms one way. Packet loss ratio is 0 percent. These statistics are fairly close to our simple calculation results above.

However, the following points must be noted for the network performance discussion above:

The per device delay, delay variation, and packet loss ratio values are for high-performance network devices. While this is applicable to pure backbone providers like Global Crossing, it is not applicable to NSPs with broadband access infrastructure because access devices are usually slower.

The transmission delay for access links is not included. Therefore, this discussion is not applicable for networks with low-access speed, for example, broadband access networks.

The possible congestion at the peering or transit is not considered. Such congestion may cause long delay, delay variation, and packet loss.

The delay and delay variation of the end-point applications are not considered.

Therefore, the performance statistics presented in this section represent an optimistic view of network performance.

In the next section, we present a conservative view of end-to-end performance. Because the real end-to-end performance will be somewhere in between, this approach will give us a good idea of what the real performance may be like.

2.2.4 Other Authentication Schemes

To distinguish legitimate WBAN devices on/near body from imposters, [43,44] propose a channel-based and proximity-based authentication scheme – BANA – based on the observation that an off-body attacker has obviously distinct RSS variation behavior with an on-body sensor. The advantage of BANA lies in the fact that it is simple, lightweight, and does not require any additional hardware, but still promises effectiveness, efficiency, and applicability in real-life scenarios. It is important to note that body movements are required in BANA to obtain unique channel characteristics for authentication.

4.3 The IEEE 802.15 Technologies: Wireless Personal Area Networks

WSN is often deployed under the auspice of the wireless personal area network (WPAN), which was initially designed to have characteristics of low complexity, low data rate, and low energy consumption. WSN facilitates large-scale and fast deployment, as well as low implementation cost. It supports short-range wireless communications and is typically adopted in industry and smart homes. WSNs have been widely used in diverse applications, such as surveillance for crimes, traffic congestion avoidance, telemedicine and e-healthcare, and environmental monitoring. Nevertheless, sensor networks used in power systems are mostly wired-based and are not interconnected [4]. Moreover, WSNs deployed in the smart grid system have more stringent requirements than those in other applications in terms of communications link quality, radio frequency (RF) interference, quality of service (QoS) provisioning, latency, and security [3, 4,12,13]. Several challenges have been identified in the studies, among which severe interference in shared ISM bands with the existing communications networks is a main concern.

In order to alleviate the problem, techniques such as multichannel access [14], WiFi features adoption [15], and cognitive radio [16] integrated in WSNs were proposed to enhance the performance of the smart grid communications. Utilizing the channel resource over time (e.g., parallel transmission using dual transceivers) helps address the coexistence issue, as well as reduce traffic loads (including retransmission) and energy consumption to some degree. It may also mitigate the packet loss caused by collision, congestion, and wireless impairments. In other words, spectrum sensing management, data traffic management, and power control management are important elements that predominantly determine how optimized the network performance can be achieved, subject to the constraints of complexity, cost, overhead, and power consumption.

By the second quarter of 2011, the IEEE 802.15 Working Group (WG) for WPAN consisted of nine Task Groups (TGs) [17], as described in Table 4.2

Table 4.2. IEEE 802.15 Task Groups

Wireless MAC and PHY specifications have been defined for different WPAN purposes among TGs [18]. IEEE 802.15.1 was originally developed by the Bluetooth Special Interest Group. It defines PHY and MAC for the conventional WPAN. The coverage of wireless connectivity with fixed or portable/handheld digital wireless devices operated by a person or object is up to 10 m (in radius) of a personal operating space (POS). Unlike ZigBee, Bluetooth supports much shorter range and coordinates no more than seven devices in its network. Besides, it is power-hungry (i.e., the supported lifetime is only a few days) due to the FHSS (frequency-hopping spread spectrum) technology employed in the PHY. Similarly, Z-Wave Alliance [19], a proprietary standard designed for home automation operating in around 900 MHz, is not as popular as ZigBee.

IEEE 802.15.2 addresses the limitation of coexistence of IEEE 802.15.1-2002 WPANs and IEEE 802.11b-1999 WLANs operated in unlicensed ISM frequency bands. It provides a number of modifications to other standards in IEEE 802.15 for enhancing coexistence with other wireless devices, as well as recommended practices for IEEE 802.11-1999 devices to facilitate coexistence with IEEE 802.15 devices.

IEEE 802.15.3 was meant for wireless multimedia to support high data rates in WPAN required for time dependent and different consumer applications, such as large file transfer in video and digital still imaging. IEEE 802.15.3b adds enhancements to improve the efficiency of IEEE 802.15.3 including the newly defined MLME-SAP (MAC layer management entity-service access point), ACK (acknowledgment) policy and implied-ACK, LLC/SNAP (logical link control/subnetwork access protocol) data frame, and a method for CTA (channel time allocation). IEEE 802.15.3c, namely mmWave, enables data rates greater than 5 Gbps operating in the 60 GHz band and defines a beam-forming negotiation protocol to improve the communications range for transmitters. It also supports aggregation of incoming data and ACKs, respectively, into single packets to improve MAC efficiency by reducing retransmission overhead as well as facilitating coexistence with microwave systems in WPAN. Applications such as real-time video streaming, HDTV, video on demand, and content downloading are supported.

IEEE 802.15.4b, i.e., 802.15.4-2006, the basis for the ZigBee specification, adds enhancements and corrections to IEEE 802.15.4-2003. Major modifications are reducing unnecessary complexities, increasing flexibility in security key usage, and supporting additional frequency bands in various countries. IEEE 802.15.4a [20] provides enhanced resistance to multipath fading with very low transmit power. In order to alleviate the problem, two alternative PHYs were developed. One is to use an ultra wideband (UWB) impulse radio operating in the unlicensed UWB spectrum (i.e., sub-GHz or below 1 GHz, 3–5 GHz, and 6–10 GHz) to increase the precision ranging capability to an accuracy of one meter or better. Another one is to employ chirp spread spectrum (CSS) in the unlicensed 2.4 GHz ISM band to support long-range links or links for mobile devices moving at high speed by adopting the unique windowed chirp technique in order to enhance robustness and mobility. The CSS method outperforms 802.15.4b (250 Kbps), 802.15.3 (22 Mbps), 802.15.1 (1 Mbps), and 802.11b (1, 2, 5.5, 11 Mbps) operating in the 2.4 GHz ISM band. Moreover, IEEE 802.15.4c defines an alternate PHY in addition to those in IEEE 802.15.4b and IEEE 802.15.4a to support one or more of the Chinese 314–316 MHz, 430–434 MHz, and 779–787 MHz bands. It also provides modifications to MAC needed to support the associated PHY. IEEE 802.15.4d specifies alternate PHYs for the Japanese 950 MHz band, and modifies MAC to support the new frequency allocation. By the time of this publication, IEEE 802.15.4-2011 which is a revision of the 2006 version will be published as a single document to consolidate the previous three amendments (i.e., 2 PHYs and 1 MAC) in order to avoid inadequacies or ambiguities discovered in the earlier standards. Table 4.3 provides detailed information on specifications for IEEE 802.15.4b/a/c/d.

Table 4.3. PHY Specifications in IEEE 802.15.4a, b, c, and d

IEEE 802.15.5 provides an architectural framework enabling WPAN devices to promote interoperable, stable, and scalable wireless mesh topologies. The features include the extension of network coverage without either increasing the transmit power or receiver sensitivity, enhanced reliability via route redundancy, easier network configuration, and longer battery life on devices. Lee et al. [21] discussed issues of addressing and unicast/multicast routing. They further investigated the mesh routing in HR-WPAN supporting QoS by using hierarchically logical tree and address blocks. Solutions of energy saving from asynchronous and synchronous aspects as well as the support of portability for mobile devices in LR-WPAN were further presented. Other WGs in progress [17] include the following:

TG4e enhances and adds functionality to the IEEE 802.15.4-2011 MAC. The improvement will support the industrial markets and permit compatibility with modifications being proposed within the Chinese WPAN. It will further enable various application spaces including factory/process/building automations, asset tracking, home medical health/monitor, and telecommunications applications.

TG4f works on the specifications of an active RFID (RF IDentification) tag device. Such a device is typically attached to an asset or a person with a unique identification. It acquires the ability to produce its own radio signal by employing ambient energy harvested from the surrounding environment.

TG4g is creating a PHY amendment to IEEE 802.15.4-2011 to provide a globally fundamental standard for the smart utility neighborhood (SUN) network operating in the 700 MHz–1 GHz and 2.4 GHz ISM bands with data rates supported in between 40 kbps and 1 Mbps. The associated IEEE 802.11ah developing standard, which will define the use of frequencies below 1 GHz for WiFi networks, has been considered as a direction for the IEEE 802.15.4g participants.

TG6 is developing a standard optimized for very-low-power devices worn on/around or implanted in human/animal bodies to serve a variety of applications for medical purposes and others.

TG7 introduces a new communications technology that is different from the traditional RF technology and uses visible light having wavelength between ~400 nm (750 THz) and ~700 nm (428 THz). This technology has mainly been tested in restricted areas such as aircraft, spaceships, and hospitals. Moreover, the group is also looking into the future of LED (light-emitting diode) evolution for applications of illumination, display, ITS, and others, in the interest of its attractive potential for environmental protection, energy saving, and efficiency.

IGthz intends to explore the feasibility of the terahertz frequency band roughly from 300 GHz to 3 THz for wireless communications.

WNG is charged by the IEEE 802.15 Wireless Next-Generation standing committee to facilitate and stimulate presentations and discussions on new wireless related technologies within the defined scope.

Notably, some of these standards will be completed by early 2012; meanwhile, it can be foreseen that more Working Group activities will be formed to address related issues with respect to the IEEE 802.15 standard. Readers are referred to Reference [17] for the corresponding updates. Nonetheless, among the aforementioned standards, IEEE 802.15.3 HR-WPAN and IEEE 802.15.4 LR-WPAN are the most promising technologies to support smart grid applications with various bandwidth requirements. SUN, specified by the IEEE 802.15.4g Task Group (TG4g), has been developed to tackle a number of technical challenges in communications systems for the utility operators: (1) how to manage high volumes of metering data and control messages among a large number of meters/sensors (or nodes) in SUN networks throughout the AMI, and (2) how to establish self-configuring and self-healing utility networks in an efficient and cost-effective manner. The legacy IEEE 802.15.4 has been amended to provision the PHY (by TG4g) and MAC (by the IEEE 802.15.4e Task Group or TG4e) layer requirements in the SUN design. Three modulation formats in the PHY layer proposal are the multirate frequency shift keying (MR-FSK), multirate orthogonal frequency division multiplexing (MR-OFDM), and multirate offset quadrature phase shift keying (MR-OQPSK) [59]. Depending on different regions and network requirements (e.g., dense urban areas versus distant rural locations), various modulation modes, data rates, bandwidths, and channel spacing must be adaptively configured and allocated. The primary issue in SUN is coexistence with homogeneous and heterogeneous systems, especially in sharing the same network resources. Utilizing sub-GHz frequency bands (i.e., license-exempt bands below 1 GHz)1[59] as well as facilitating multi-PHY management (MPM) with the common signaling mode (CSM)2[60] is a foreseeable solution to signal interference in SUN networks.

In addition to the proposals of the state-of-the-art PHY schemes for SUN, most of the MAC protocols specified in IEEE 802.15.4 are adopted for SUN only with minor changes. Therefore, we will review a number of issues and challenges in the following section that have been addressed based on recent LR-WPAN studies predominantly in MAC designs. The survey on network measurements in the legacy IEEE 802.15.4 protocol will provide useful collation for investigation of SUN networks research.

10.5.1 Logical Diagrams

Logical diagrams show the connectivity and relationships among network devices. Relationships show how devices may interact with one another, how they may work together to provide service and support in the network, and what you might expect from them. For example, you could have a logical diagram showing the routers in your network, or showing just the border routers, or just the interfaces to all external networks. Such diagrams may also include security devices and how they will be connected to the routers, providing insight regarding how the routers and security devices would work together at an external interface.

Diagrams that focus on logical relationships do so at the expense of accuracy in physical descriptions (i.e., location accuracy). Such diagrams can provide approximate correlations between devices and their physical locations; however, they do not provide an accurate representation of physical space. I refer to such descriptions as logical diagrams and not blueprints, as they do not provide the traditional spatial accuracy and level of detail expected in blueprints. Diagrams showing logical relationships among devices are quite useful as companions to network blueprints, or as early drafts of blueprints. Figure 10.12 is an example of a network diagram.

This figure is an example of a communications closet. It shows the types of network devices planned for that closet, and how they are logically connected. For example, from the diagram you can tell that there are multiple firewalls and switches in the communications closet. You can also see the connectivity between devices, to the local networks, and to the Internet. At this stage, however, it does not describe the actual equipment or vendor selections, cable paths or types, or the physical arrangement of the devices in racks or shelves. Diagrams such as these are useful for planning purposes; however, they are not detailed enough to be considered blueprints.

Another example of a logical diagram is shown in Figure 10.13. Instead of describing a particular location, this diagram shows the logical interconnection of devices from across a network. This diagram is useful in that it describes the hierarchy of connections, which can be easily mapped to traffic flows in the network.

15.2.1 Without SDN/NFV technologies

Without SDN/NFV technologies, the behavior of network devices requires a definition with a static set of protocols and rules. In the scenario of this chapter, network devices can utilize the traditional server discovery mechanism to choose the destination server. The approach implemented in this example is to utilizing ARP to monitor the transmission latency characteristics for each server as follows. When the gateway switch receives the first packet of a flow from the mobile client, it broadcasts an ARP request based on the destination IP address encapsulated in the packet. To simplify the IP Address Management (IPAM) in this example, the broadcast IPv4 address [278] is used as the destination address for all packets sent from the client. Following this approach, all application servers respond to the ARP request. As the ARP protocol is a simple link layer protocol implemented in the OS kernel, generating the ARP response does not require significant computational resources. Subsequently, the server should send an ARP response in a relatively short time, even if it is under heavy computational workload. The delay between this ARP request and a server response can be employed as a reasonable estimation of the transmission delay. The gateway switch is configured to follow a straightforward static rule: It forwards all traffic of a flow to the server that has the minimal ARP response delay.