You can use Multiprotocol Label Switching Operation and Maintenance (OAM) to detect operational failures, but also for accounting and performance measurement in the Multiprotocol Label Switching network. Problems on the control plane can be reported by traps or seen by polling the Management Information Base (MIB). This might suffice for IP networks, but it is more difficult to detect the problems that are purely in the data plane when the network is running Multiprotocol Label Switching. Multiprotocol Label Switching OAM is a set of protocols that detects problems in the Multiprotocol Label Switching network more easily and more quickly and keeps track of measurements that are important in networks that have service level agreements (SLAs) with customers or other companies. The goal of Multiprotocol Label Switching OAM is to detect, report, and fix a problem before a user calls it in.

Requirements of Multiprotocol Label Switching OAM

The requirements of Multiprotocol Label Switching OAM are the following:

■ Detection and diagnosis of control and data plane defects
■ Detection of a defect in a label switched path (Label Switch Routers)
■ OAM packets flowing on the same path as Multiprotocol Label Switching data traffic
■ Path characterization
■ Measurement of SLAs
■ OAM Interworking
■ MIBs
■ Accounting

Detection and Diagnosis of Control and Data Plane Defects

Common problems for Multiprotocol Label Switching networks are packets arriving at a label switching router (Label Switch Router) with a specific top label for which the Label Switch Router has no forwarding information or incorrect forwarding information. This problem can be detected by the control information that Label Distribution Protocol (Label Distribution Protocol), Resource Reservation Protocol (Resource Reservation Protocol), IP routing protocols, routing table, label information base (LIB), and label forwarding information base (LFIB) provide. However, the problem only becomes apparent if actual traffic is flowing and fails at some Label Switch Router. A more subtle and more difficult-to-detect problem is the one in which the control plane information is correct but the data plane fails. It is possible for the control plane software to behave correctly, with the problem undetected by show commands on the router, while the data plane drops or mistreats the packet, which might result in a forwarding failure. For instance, an ASIC that performs the forwarding of labeled packets in hardware on the Label Switch Router might treat the TTL value wrongly. In that case, the packets might fail at this Label Switch Router or at an Label Switch Router that is further downstream. You will see later in this article that Label Switch Routers ping and Label Switch Routers traceroute are tools that can detect problems in the Multiprotocol Label Switching control and data planes.

Detection of a Defect in a Label Switched Path (Label Switch Routers)

Another common problem is the failure of a label advertisement between two Label Switch Routers. For instance, the Label Distribution Protocol peer neighborship might be down between two Label Switch Routers, which causes the packets to be dropped or forwarded without a label stack. For instance, if Multiprotocol Label Switching transports Layer 2 traffic that becomes unlabeled on a provider (P) router, it is dropped. Similarly, if IPv4 traffic becomes unlabeled, it might be forwarded according to the global routing table. If no route for the destination IP address exists, the packet is dropped. If a routing entry exists, the packet is forwarded. In that case, two things can happen: The packet might actually make it and be forwarded to the destination, or it might be forwarded to the wrong destination. The packet might be dropped later on, or the return packet might be dropped. Another commonly seen problem in Multiprotocol Label Switching networks is MTU problems. Because of the added label stack, the size of the packet increases by n times 4 bytes—where n is the number of labels in the label stack. If the control word is present between the label stack and the Multiprotocol Label Switching payload, another 4 bytes is added. This can cause MTU problems on certain routers, either because they cannot support greater MTU sizes or because of a configuration error. In either case, as long as smaller packets are forwarded, the problem goes undetected. The problem is detected the first time larger packets are transmitted. In networks that have equal cost multi paths (ECMP), some problems can go unnoticed as long as one path of the ECMP paths is not used. However, as soon as traffic flows across that one failing path, the problem becomes apparent. It is best to detect these problems before a customer calls them in. Multiprotocol Label Switching OAM was developed with this is mind.

OAM Packets Flowing on the Same Path as Multiprotocol Label Switching Data Traffic

It is important that the OAM packets follow the same path as the real user data to detect the errors in the data plane of the Label Switch Router. Therefore, the Multiprotocol Label Switching OAM traffic is simple User Datagram Protocol (UDP) traffic and not a special data type that the routers might treat differently. For instance, Internet Control Message Protocol (ICMP) traffic might be forwarded differently on routers than common TCP or UDP traffic. The forwarding in the data plane plays an important role here. Some hardware forwarding is different depending on the type of traffic, or sometimes it is bypassed, with the software forwarding the traffic.

Path Characterization

OAM traffic can determine the path characteristics of the Multiprotocol Label Switching traffic. These characteristics can include the following:

■ Quality of service (QoS) treatment
■ Time To Live (TTL) treatment
■ Latency
■ Jitter
■ ECMP behavior
■ Maximum transmission unit (MTU) along the path
■ Packet loss

It is important when looking at the treatment of traffic along an Label Switch Routers or traffic belonging to a specific Forwarding Equivalence Class (Forwarding Equivalence Class) that you measure the correct characteristics. It is, for instance, important that voice traffic has a small latency and jitter value along the path, whereas this is not so important for Internet data traffic. An excellent tool to characterize the data path is IP SLA, which is discussed later in this article.

Measurement of SLAs

If SLAs apply to the Multiprotocol Label Switching network, the characteristics of the Label Switch Routerss should correspond to the predefined SLAs. As such, Multiprotocol Label Switching OAM should provide a mechanism to measure the characteristics of the Label Switch Routerss. For SLAs, the latency, jitter, round-trip-time (RTT), and packet loss are important characteristics to measure for each Label Switch Routers. You can look at MIB information to achieve this, or you can actively measure it by sending probes onto the Label Switch Routerss. IP SLA can send probes to measure the performance of the network ad hoc or at regular intervals.

OAM Interworking

 When you transport Layer 2 frames across the Multiprotocol Label Switching cloud (AToM), each provider edge (PE) router has attachment circuits (AC). These ACs can have Layer 2 protocols with their own OAM messages and error packets. Multiprotocol Label Switching OAM must support the translation or mapping of these native Layer 2 protocol OAM messages (or at least a subset of them) into newly defined Multiprotocol Label Switching OAM messages. In the opposite way, specific Multiprotocol Label Switching error conditions that affect the pseudowires must be mapped to the native OAM messages of the AC protocols on the PE routers.

MIBs

Management always plays an important role in networking. This is no different for Multiprotocol Label Switching networks. Management and MIBs play an important role in tracking the status of a network and provide an early warning when things go wrong. Specific MIBs for Multiprotocol Label Switching have been developed, and new ones are still being worked on. In the light of OAM for Multiprotocol Label Switching networks, management needs much attention, and its importance is often forgotten or understated.

Accounting

Accounting is important for network measurements and billing purposes. Netflow can provide accounting in Cisco IOS. Netflow has been made Multiprotocol Label Switching aware to account labeled traffic per Label Switch Routers and even finer than that, because any label in the label stack can be tracked. Netflow is explained later in this article.