|
 Like traffic in a large city, traffic on a WAN is sometimes unpredictable, and your best bet is knowing an alternate route. To ensure that your packets get to their destinations in the most efficient manner, you've got to route them on a particular VC (virtual circuit) based upon the destination point. Traffic is relegated to a specific path through a network and doesn't deviate from that path. While this has been the basis of both frame relay with DLCIs (data link control identifiers) and ATM with VPIs/VCIs (virtual path identifiers/virtual channel identifiers), not all traffic can be routed in this manner. Pure IP networks are entirely different: IP routing over large networks is a step-by-step process. Based upon its routing table, each router along the way analyzes the header and determines the best path for the next leg of a packet's journey.
This can be extremely inefficient, as each router spends precious time examining each packet and determining to which router the packet is sent next. The amount of information held in most headers isn't enough to let a router send the packet all the way to its final destination; the routers rarely if ever have a complete view of the path each packet takes.
The other way of getting IP traffic to its destination is by broadcasting it. Basically, broadcasting a packet means sending it everywhere in the hope that it will end up where it was supposed to go eventually. This method has an obvious drawback in that traffic on the broadcast network is unbearably slow because every router has to deal with every packet no matter if it is meant for Timbuktu or Antarctica. Security is also nonexistent in a broadcast network because every router on the network has access to every data conversation taking place.
MPLS (Multiprotocol Label Switching) bridges the gap between broadcasting and dedicated VCs by creating paths through a network, as an ATM or frame relay VC does. The difference is that MPLS gives the routers a choice of paths and lets the packets be rerouted as needed. 
On ATM networks, MPLS should not be considered a replacement for LANE (LAN Emulation) or MPOA (Multiprotocol Over ATM) as it does not include any provisions for virtual networks. It could be better defined as an IP-centric alternative to PNNI (Private Network-to-Network Interface). MPLS-enabled routers are meant to provide better routes for IP packets to travel through WAN networks as well as to ease the routers' overhead by simplifying routing tables.
In an MPLS cloud, an IP packet header is analyzed by the first router at the edge of the cloud. That router then determines the best path through the network and places a label on the front of the packet identifying the stream (network path) the packet is to take. Each router in the MPLS network looks only at this label and places the packet onto the path identified by the label. Exiting the network, the packet is routed via normal IP methods to its destination. MPLS offers network managers the ability to apply many WAN features to their data at the IP level instead of at the frame relay or ATM level. IP customers are not used to having this improved QoS (Quality of Service), traffic engineering and private data streams on their WANs--and they still have the flexibility of nondedicated paths. Although smaller customers won't be able to deploy MPLS directly in their networks, carriers will begin offering private IP networks that use MPLS to direct and shape traffic, thereby bringing the benefits to businesses of all sizes. Label Everything In the beginning, an MPLS router places a four-octet "label" on packets entering the network. This label identifies the path, or "flow," that the packet will follow to its destination. Packets taking the same path are assigned to a FEC (forwarding-equivalence class), a logical (nonphysical) grouping of traffic with a like destination. This cuts down on overhead since only the first packet needs to be analyzed. The actual identifying label occupies the first 20 bits; the next three bits are for experimental use, and then there's one bit to indicate the label at the bottom of the stack. The last octet is used for TTL (time to live). This label is placed after the data-link layer headers and before the network layer headers of an Ethernet packet. The label is placed in the VPI/VCI field of the header in ATM networks and in the DLCI field of a frame relay header. A number of these labels can be placed one after the other. Each router examines only the label at the top of the stack until that label reaches its destination. At the destination, the top label is peeled off. If other labels exist on a packet, each one is examined in turn, causing the packet to be routed until all labels have been removed. If necessary, labels can be swapped or replaced. Labels are bound to a FEC by the downstream LSR (label-switching router); each label is then communicated to the upstream LSR. An LSR also can be set to look only at labels within a particular numeric range and will therefore assign values only within that range. LSRs use a set of procedures known as LDP (Label Distribution Protocol) to inform each other of the labels being created among them. The LDP also is used between two LSRs to learn about each other's MPLS capabilities. The advantage is that there isn't only one LDP; existing protocols like BGP (Border Gateway Protocol) and RSVP (Resource Reservation Protocol) are being extended so LDP data can be included with them. In the absence of these, protocols like MPLS-LDP have been created specifically to pass labels between the LSRs. Two distribution methods are defined within MPLS: downstream on demand and unsolicited downstream. Downstream on demand lets an LSR specifically request that a label be created for a connection. Unsolicited downstream is exactly as it sounds: It lets LSRs distribute labels without being requested. LSRs can support both of these methods, but the methods must be agreed upon by the upstream and downstream LSR. Label retention, or the ability to maintain labels in a lookup table, is handled in one of two methods. LSRs that observe conservative retention maintain only labels that are from valid next-hop LSRs. All other labels are discarded as soon as they are received. This method lets a small label table be maintained internally, requiring less RAM and quicker lookups. On the other hand, liberal retention uses more RAM within the LSR because it maintains a larger table. Liberal retention lets an LSR respond more quickly and reroute traffic should a connection to a valid next hop go down. Longer Hops Are Better Single labels can be placed onto a packet, but doing so doesn't really improve efficiency. Each router along the path would go through the same process of deciding for itself which label to attach for the next step in the process. LSPs (label-switched paths) are created when an LSR places onto a packet several labels that direct its flow through the network. Called explicit routing, this eliminates hop-by-hop routing in MPLS and improves router efficiency. The labels usually are popped onto the stack by the ingress LSR but can be placed on by any LSR in the cloud. Explicit routing is useful in traffic engineering by controlling the flow that a packet takes to a particular destination. Explicit routing is also useful in creating VPNs over MPLS networks. In this manner, explicit routing lets IP traffic be sent over LSPs within an IP network without having to encrypt the traffic. Security is maintained because traffic is kept within an LSP. By using MPLS as a carrier for VPN traffic, router overhead is cut down even further because encryption and decryption no longer need to take place as the data is traveling over a path similar to a frame relay or ATM VC. LSPs enhance the capabilities and benefits of RSVP. By extending RSVP to also carry LDP information, you can define LSPs and explicit routes between two end points from within RSVP. RSVP would therefore provide not only a guaranteed amount of bandwidth through a network, but also a guaranteed path. Using MPLS can also cut down on the setups between RSVP routers. Each time a data stream is sent over RSVP, the connection has to be set up and appropriate guarantees need to be agreed upon by both sides. This can go on forever. With MPLS-extended RSVP, this setup needs to occur only once, to create the label and FEC binding. Once a label is created and agreed upon by the two routers, any traffic given that label will be able to travel between the routers with the accepted QoS. The procedure for using RSVP to create LSP in MPLS is discussed further in the document draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, which is available from the IETF (www.ietf.org). Encapsulation MPLS is designed to work over ATM and other WAN topologies. In an MPLS-enabled ATM switch, traditional ATM traffic and MPLS traffic are each handled separately--never the twain shall meet. In this way, MPLS traffic is transmitted over VPIs/VCIs separately from ATM traffic, and an MPLS router can continue carrying traditional ATM traffic. This needs to be taken into account when provisioning ATM circuits in a switch. MPLS and ATM traffic can share the entire port, or they can be divided by protocol or service. Creating a protocol partition involves assigning percentages of port capacity to both MPLS and ATM. By creating multiple partitions of shared capacity, service partitions group MPLS and ATM traffic into a percentage of port capacity based upon the service being carried over them. Frame relay won't be left out of the picture, though the painters are still hard at work. A draft specification (draft-ietf-mpls-fr-04.txt), published at the beginning of May by the IETF, describes how MPLS should be handled by frame relay routers. The application of this draft is some time off, and additional problems, such as frame relay-to-ATM-service interworking, for example, still need to be addressed. Differing Views MPLS is being implemented by several vendors, and there are varying proposals on just how MPLS should work. The most recognizable is the tag-switching architecture developed by Cisco Systems. For all intents and purposes, tag switching is MPLS--the names have just been changed to protect the innocent. In Cisco's implementation, labels are tags; therefore, LSRs become TSRs and so on, but the overall operation stays the same. Although IBM Corp. worked on tag switching and creating the IETF MPLS Working Group with Cisco, its own format, ARIS (Aggregate Route-Based IP Switching), is unique. ARIS is designed to work more closely with ATM than other proposals do and requires ISRs (integrated switch routers) to have a larger buffer capacity to permit assembly of AAL-5 PDUs (ATM Adaption Layer-5 Protocol Data Units). This facilitates merging traffic onto a particular VC as the entire datagram is collected and sent sequentially. ARIS differs greatly from tag switching because ARIS uses a route-based paradigm instead of one based upon flows. ARIS' routes can be thought of as a tree structure rooted at the egress point. As traffic gets closer to the egress point, branches converge and traffic is merged into one flow toward the egress router. IP Switch, though a generic term, is the name of a group of products from Ipsilon Networks, now a part of Nokia. IP Switch is entrenched in ATM even more than ARIS is. Ipsilon used an IP switch controller as a routing and forwarding engine connected to an ATM switch. This method creates a "router on a stick" topology and uses the controller only as a switch fabric, placing traffic back into normal ATM VPIs/VCIs to be carried to its destination. Toshiba Corp. is using an architecture called CSRs (Cell Switching Routers), developed at the Tokyo Institute of Technology. Although it is similar to IP Switch, its purpose is to connect ATM local IP subnets running LANE or classical IP over ATM. Unlike IP Switch, CSR has the advantage of being able to route non-IP protocols. Send your comments on this article to Darrin S. Woods at
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
link: http://www.nwc.com/1113/1113ws2.html |
