Currently, in AToM networks, the frame check sequence (FCS) of Ethernet, Frame Relay, High- Level Data Link Control (HDLC), and PPP Layer 2 frames is removed before AToM sends the frames across the pseudowire. At the remote end of the pseudowire, the egress PE inserts the FCS by calculating it over the received Layer 2 frame. This behavior might lead to problems if intermediate Label Switch Routers introduce a problem whereby they change the payload of the Multiprotocol Label Switching packet. This problem can go undetected until the packet reaches its destination host. That also makes troubleshooting the problem more difficult, because you first have to identify where the problem happens. A draft is currently within the IETF (draft-ietf-pwe3-fcs-retention) that describes FCS retention and how it can be signaled between PE routers so that the PE routers can decide whether to retain the original FCS. When the original FCS is retained, it guarantees the transparent behavior of the pseudowire for the Layer 2 frames.

AToM Fragmentation and Reassembly

Fragmentation is generally not good because it places a greater workload on the platform that is performing the fragmentation. Therefore, avoid it if possible. Path MTU Discovery and careful usage of the IP MTU and Multiprotocol Label Switching MTU commands generally get you far. Sometimes fragmentation is unavoidable, as in the case of Path MTU Discovery not working because of firewalls blocking the ICMP messages needed for Path MTU Discovery to work properly. If the payload is IP traffic, the ingress PE router can fragment the IP packet before it enters the pseudowire. In that case, the destination host reassembles the packet. If the frame payload is not IP, the ingress PE router can perform the fragmentation on the frame before it enters the pseudowire and the egress PE router reassembles the frame. The IETF draft “draft-ietf-pwe3-fragmentation” describes this procedure. Even if the Multiprotocol Label Switching MTU is sufficient in the Multiprotocol Label Switching cloud for the AToM traffic, you still might want to fragment frames to ensure a low latency transmission on the pseudowire. The receiving PE router should signal its capability to reassemble the fragments toward the ingress PE in the Virtual Circuit Forwarding Equivalence Class element. The fragmentation is handled through the control word, present below the label stack of the Multiprotocol Label Switching packet.

Circuit Emulation

There is still an enormous amount of time-division multiplexing (TDM) private lines and legacy equipment using these TDM services. Therefore, it makes sense to carry TDM over Multiprotocol Label Switching to support the legacy services using T1, E1, T3, E3, N × 64, and V.35. The advantage of carrying these types of services over Multiprotocol Label Switching is that one common network the Multiprotocol Label Switching network can carry the IP/AToM traffic and the TDM traffic. With TDM Circuit Emulation, the TDM bit stream is carried across the Multiprotocol Label Switching cloud over an Multiprotocol Label Switching pseudowire. The difficult part is the emulation of the TDM circuit. Examples include the clock recovery and procedures for alarm signaling. The egress PE router can recover the clock by using timestamps that the ingress PE router sets. Synchronous Digital Hierarchy/Synchronous Optical Network (SDH/SONET) circuit emulation over Multiprotocol Label Switching is another area of development. SONET and SDH are standards that describe a digital hierarchy to carry synchronous data on fiber networks. They are both popular—SONET in the United States and SDH in Europe.

GMultiprotocol Label Switching

Generalized Multiprotocol Label Switching (GMultiprotocol Label Switching) is based on Multiprotocol Label Switching TE, but it has added extensions that make it work on a newer set of platforms. These new platforms are dense wavelength-division multiplexing (DWDM) systems, Photonic Cross-Connects (PXC), and Optical Cross-Connects (OXC), among others. These platforms that run GMultiprotocol Label Switching are not just routers or Asynchronous Transfer Mode switches that have Multiprotocol Label Switching enabled. These nonrouter platforms run GMultiprotocol Label Switching in the control plane, while Multiprotocol Label Switching is absent from the data plane. That is because these new platforms do not switch packets that can be labeled, neither do they switch Asynchronous Transfer Mode cells.

They switch wavelengths (lambdas), time-division channels (Synchronous Optical Network and Synchronous Digital Hierarchy: SONET/SDH), and complete physical ports or fibers. The building blocks of GMultiprotocol Label Switching are the same as those of regular Multiprotocol Label Switching TE in the control plane: the IPv4 protocol, a link state routing protocol, and Resource Reservation Protocol (Resource Reservation Protocol) with the TE extensions. One new protocol required to run GMultiprotocol Label Switching is the Link Management Protocol (LMP), which was developed to manage the links easier. GMultiprotocol Label Switching needs LMP because these newer platforms can have a huge number of wavelengths between them, which makes the management of the links cumbersome. LMP takes care of the management and link connectivity verification on these links. GMultiprotocol Label Switching like Multiprotocol Label Switching TE distributes network constraints of the physical media to all the platforms that participate in GMultiprotocol Label Switching. You can then use these constraints to build Label Switch Routerss throughout the network that might—like regular Multiprotocol Label Switching TE deviate from the shortest path. The constraints are different from those used by Multiprotocol Label Switching TE, because the physical media is different. Different link capacity, protection, and restoration constraints are involved.

OAM Protocols

BFD is a new, lightweight, media independent protocol that detects faults in the data plane between two devices. It has been specifically developed to be routing protocol and media independent and to quickly detect data communication failures. The “quickly” stands for subsecond detection. SONET has alarms that can detect and notify problems quickly. Most media, however, have no such fast detection mechanisms. BFD quickly detects all failures between routers instead of relying on the hello mechanism of the routing protocols. The routing protocols can perform the same function, but they are slower and less scalable if the number of interfaces is large.

BFD also detects data plane failures for Multiprotocol Label Switching Label Switch Routerss. Although Label Switch Routers Ping can do this, it also checks information from the control plane against the data plane. BFD for Multiprotocol Label Switching Label Switch Routerss does not do this; therefore, it is lighter in design and can be implemented easier in hardware. A BFD session is established between the ingress and egress Label Switch Router, and BFD control packets are sent across. As such, BFD tracks the liveliness of the Multiprotocol Label Switching Label Switch Routers and detects failures in the data plane for the Label Switch Routers. Because BFD for Multiprotocol Label Switching Label Switch Routerss is lighter than Label Switch Routers Ping, it is more scalable. You can use BFD on more Label Switch Routerss, and it detects failures more quickly. One problem with Multiprotocol Label Switching is often that the control plane looks fine but the data plane does not. Label Distribution Protocol (Label Distribution Protocol), Resource Reservation Protocol, or Border Gateway Protocol (Border Gateway Protocol) might indicate the correct incoming and outgoing labels, but the forwarding plane—the LFIB or the ASIC that is programmed with the LFIB—might be doing the wrong forwarding, resulting in the packet being misrouted or dropped.

A solution for this problem is an Label Switch Router testing its own data plane information. This functionality is called the Label Switching Router Self-Test. The Label Switch Router doing the testing sends a special packet called an Multiprotocol Label Switching Data Plane Verification Request to its upstream neighbor. This packet holds the incoming label stack that the Label Switch Router doing the testing expects on packets coming from its upstream neighbor. This upstream Label Switch Router then forwards the labeled packet to the downstream neighbor of the Label Switch Router under test. The Label Switch Router doing the testing performs normal label forwarding on the packet and hence is testing the correctness of one Label Switch Routers in its data plane. In other words, the Label Switch Router doing the testing performs the normal label operation (pop, push, or swap) on the labeled packet and forwards it to its downstream neighbor. The downstream neighbor intercepts the packet and sends an Multiprotocol Label Switching Data Plane Verification Reply to the Label Switch Router doing the testing. The Multiprotocol Label Switching Data Plane Verification Reply packet indicates the interface on the downstream neighbor on which the packet was received and the label stack. The Label Switch Router doing the testing can then verify this information. This Label Switch Router Self-Test functionality is based on the Label Switch Routers Ping functionality, but extensions were added to it.

Multiprotocol Label Switching Labeled Multicast

Recent developments have been made on Multiprotocol Label Switching labeled multicast. IP multicast is a known architecture that is proven in the industry. Many want multicast traffic to be Multiprotocol Label Switching labeled. The label switched paths (Label Switch Routers) encountered in this article are point-to-point. You could make them point-to-multipoint or even multipoint-to-multipoint. Multiprotocol Label Switching TE and Resource Reservation Protocol for TE have been extended to be able to create point-to-multipoint Label Switch Routerss. Label Distribution Protocol can also create these point-tomultipoint Label Switch Routerss for the people who do not need TE or who already have a deployed Multiprotocol Label Switching network with Label Distribution Protocol. Label Distribution Protocol has been extended to provide these point-to-multipoint and multipointto- multipoint Label Switch Routerss. Even though you can use downstream label distribution with Multiprotocol Label Switching labeled multicast, it introduces upstream label distribution. Multiprotocol Label Switching networks so far have not used upstream label distribution. When transporting multicast as Multiprotocol Label Switching labeled packets, one Label Switch Router can forward a single copy of one labeled packet on a multiaccess link to multiple downstream Label Switch Routers.

The Label Switch Router can only do this if it supports Upstream Label Distribution mode, because then it distributes one label to its downstream Label Switch Routers for one point-to-multipoint Label Switch Routers. In Downstream Label Distribution mode, each downstream Label Switch Router assigns independently a different label for the same point-to-multipoint Label Switch Routers. This prohibits the upstream Label Switch Router from sending a single copy of one labeled packet on the pointto- multipoint Label Switch Routers on the multiaccess link. One of the most interesting applications of labeling multicast traffic is carrying Multiprotocol Label Switching Virtual Private Network multicast traffic across the Multiprotocol Label Switching backbone on point-to-multipoint Label Switch Routerss.

The Proliferation of Multiprotocol Label Switching

Multiprotocol Label Switching is no longer solely used by service providers, but more and more by enterprise networks that have a larger network diameter or that have specific needs. Furthermore, Multiprotocol Label Switching has already moved from the core of the network closer to the edge. An example of this is the extensions of the Label Switch Routerss onto the CE router for the easier deployment of QoS in Multiprotocol Label Switching Virtual Private Network networks. Although Multiprotocol Label Switching Virtual Private Network autonomous systems are still interconnected via IP most of the time, in the future, more and more Multiprotocol Label Switching Virtual Private Network networks will be interconnected via Multiprotocol Label Switching, and the packets will be sent labeled toward the other autonomous system. The interconnection between Multiprotocol Label Switching networks will not be limited to interconnecting Multiprotocol Label Switching Virtual Private Network networks but will also be used to switch AToM or IPv6 traffic from one provider to another. This trend of more labeled packets in places where they are not today will most likely continue. Multiprotocol Label Switching has spread from being solely used on IP routers and Asynchronous Transfer Mode switches to being used in the control plane of OXCs, DWDM systems, and TDM switches. Multiprotocol Label Switching most definitely still has to mature in this area.