Operations, Administration and Maintenance (OAM) features for RAW

Reliable and Available Wireless (RAW) is an effort that extends DetNet to approach end-to-end deterministic performances over a network that includes scheduled wireless segments. The wireless and wired media are fundamentally different at the physical level. Enabling thus reliable and available wireless communications is even more challenging than it is in wired IP networks, due to the numerous causes of loss in transmission that add up to the congestion losses and the delays caused by overbooked shared resources. To provide quality of service along a multihop path that is composed of wired and wireless hops, additional methods needs to be considered to leverage the potential lossy wireless communication. Traceability belongs to Operations, Administration, and Maintenance (OAM) which is the toolset for fault detection and isolation, and for performance measurement. More can be found on OAM Tools in . The main purpose of this document is to detail the requirements of the OAM features recommended to construct a predictable communication infrastructure on top of a collection of wireless segments. This document describes the benefits, problems, and trade-offs for using OAM in wireless networks to provide availability and predictability. In this document, the term OAM will be used according to its definition specified in . We expect to implement an OAM framework in RAW networks to maintain a real-time view of the network infrastructure, and its ability to respect the Service Level Agreements (SLA), such as delay and reliability, assigned to each data flow.

OAM entity: a data flow to be controlled; OAM end-devices: the source or destination of a data flow; defect: a temporary change in the network characteristics (e.g. link quality degradation because of temporary external interference, a mobile obstacle) fault: a definite change which may affect the network performance, e.g. a node runs out of energy,

RAW networks expect to make the communications reliable and predictable on top of a wireless network infrastructure. Most critical applications will define a SLA to respect for the data flows it generates. RAW considers network plane protocol elements such as OAM to improve the RAW operation at the service and at the forwarding sub-layers. To respect strict guarantees, RAW relies on a Path Computation Element (PCE) which will be responsible to schedule the transmissions in the deployed network. Thus, resources have to be provisioned a priori to handle any defect. OAM represents the core of the over provisioning process, and maintains the network operational by updating the schedule dynamically. Fault-tolerance also assumes that multiple path have to be provisioned so that an end-to-end circuit keeps on existing whatever the conditions. OAM is in charge of controlling the replication/elimination processes. To be energy-efficient, reserving some dedicated out-of-band resources for OAM seems idealistic, and only in-band solutions are considered here. RAW supports both proactive and on-demand troubleshooting.

OAM features will enable RAW with robust operation both for forwarding and routing purposes.

We need to verify that two endpoints are connected with each other. Since we reserve resources along the path independently for each flow, we must be able to verify that the path exists for a given flow label. The control and data packets may not follow the same path, and the connectivity verification has to be triggered in-band without impacting the data traffic. In particular, the control plane may work while the data plane may be broken. The ping packets must be labeled in the same way as the data packets of the flow to monitor.

Ping and traceroute are two very common tools for diagnostic. They help to identify the list of routers in the route. However, to be predictable, resources are reserved per flow in RAW. Thus, we need to define route tracing tools able to track the route for a specific flow. Because the network has to be fault-tolerant, multipath can be considered, with multiple Maintenance Intermediate Endpoints for each hop in the path. Thus, all the possible paths between two maintenance endpoints should be retrieved.

RAW expects to operate fault-tolerant networks. Thus, we need mechanisms able to detect faults, before they impact the network performance. The network has to detect when a fault occurred, i.e. the network has deviated from its expected behavior. While the network must report an alarm, the cause may not be identified precisely. For instance, the end-to-end reliability has decreased significantly, or a buffer overflow occurs. We have to minimize the amount of statistics / measurements to exchange: energy efficiency: low-power devices have to limit the volume of monitoring information since every bit consumes energy. bandwidth: wireless networks exhibit a bandwidth significantly lower than wired, best-effort networks. per-packet cost: is is often more expensive to send several packets instead of combining them in a single link-layer frame. Thus, localized and centralized mechanisms have to be combined together, and additional control packets have to be triggered only after a fault detection.

The network has isolated and identified the cause of the fault. For instance, the quality of a specific link has decreased, requiring more retransmissions, or the level of external interference has locally increased.

To take proper decisions, the network has to expose a collection of metrics, including: Packet losses: the time-window average and maximum values of the number of packet losses has to be measured. Many critical applications stop to work if a few consecutive packets are dropped; Received Signal Strength Indicator (RSSI) is a very common metric in wireless to denote the link quality. The radio chipset is in charge of translating a received signal strength into a normalized quality indicator; Delay: the time elapsed between a packet generation / enqueuing and its reception by the next hop; Buffer occupancy: the number of packets present in the buffer, for each of the existing flows. These metrics should be collected: per virtual circuit to measure the end-to-end performance for a given flow. Each of the paths has to be isolated in multipath strategies; per radio channel to measure e.g. the level of external interference, and to be able to apply counter-measures (e.g. blacklisting) per device to detect misbehaving node, when it relays the packets of several flows.

RAW aims to enable real-time communications on top of an heterogeneous architecture. Since wireless networks are known to be lossy, RAW has to implement strategies to improve the reliability on top of unreliable links. Hybrid Automatic Repeat reQuest (ARQ) has typically to enable retransmissions based on the end-to-end reliability and latency requirements. To take correct decisions, the controller needs to know the distribution of packet losses for each flow, and for each hop of the paths. In other words, average end-to-end statistics are not enough. They must allow the controller to predict the worst-case.

RAW targets also low-power wireless networks, where energy represents a key constraint. Thus, we have to cake care of the energy and bandwidth consumption. The following techniques aim to reduce the cost of such maintenance: piggybacking: some control information are inserted in the data packets if they do not fragment the packet (i.e. the MTU is not exceeded). Information Elements represent a standardized way to handle such information; flags/fields: we have to set-up flags in the packets to monitor to be able to monitor the forwarding process accurately. A sequence number field may help to detect packet losses. Similarly, path inference tools such as insert additional information in the headers to identify the path followed by a packet a posteriori.

RAW needs to implement a self-healing and self-optimization approach. The network must continuously retrieve the state of the network, to judge about the relevance of a reconfiguration, quantifying: the cost of the sub-optimality: resources may not be used optimally (e.g. a better path exists); the reconfiguration cost: the controller needs to trigger some reconfigurations. For this transient period, resources may be twice reserved, and control packets have to be transmitted. Thus, reconfiguration may only be triggered if the gain is significant.

To be fault-tolerant, several paths can be reserved between two maintenance endpoints. They must be node-disjoint, so that a path can be available at any time.

When multiple paths are reserved between two maintenance endpoints, they may decide to replicate the packets to introduce redundancy, and thus to alleviate transmission errors and collisions. For instance, in , the source node S is transmitting the packet to both parents, nodes A and B. Each maintenance endpoint will decide to trigger the replication / elimination process when a set of metrics passes through a threshold value.

(A) => (C) => (E) === // \\// \\// \\ source (S) //\\ //\\ (R) (root) \\ // \\ // \\ // ===> (B) => (D) => (F) === ]]>

Because the QoS criteria associated to a path may degrade, the network has to provision additional resources along the path. We need to provide mechanisms to patch a schedule (changing the channel offset, allocating more timeslots, changing the path, etc.).

Since RAW expects to support real-time flows, we have to support soft-reconfiguration, where the novel ressources are reserved before the ancient ones are released. Some mechanisms have to be proposed so that packets are forwarded through the novel track only when the resources are ready to be used, while maintaining the global state consistent (no packet re-ordering, duplication, etc.)