| < Day Day Up > |
|
MPLS switches, like the switchboard operators of old, must be trained; they must learn all the rules and all the circumstances under which to apply those rules. Two methods are used to make switches that are “trained” for these purposes.
One method uses hard programming and is similar to how a router is programmed for static routing. Static programming eliminates the ability to dynamically reroute or manage traffic.
Modern networks change on a dynamic basis. To accommodate the adjusted needs of these networks, many network engineers have chosen to use the second method of programming MPLS switches: dynamic signaling and label distribution. Dynamic label distribution and signaling can use one of several protocols.
Each protocol has its advantages and disadvantages. Because this is an emerging technology, we have not seen the dust fully settle on the most dominant labeling and signaling protocols. Yet, despite the selection of protocols and their tradeoffs, the basic concepts of label distribution and signaling remain consistent across the protocols.
At a minimum, MPLS switches must learn how to process packets with incoming labels. This process is accomplished through the use of a cross-connect table.
Here is an example of a cross-connect function: Label 101 entering at Port A will exit via Port B with a label swapped for 175. The major advantage of using cross-connect tables instead of routing is that cross-connect tables can be processed at the “data link” layer, where processing is considerably faster than routing.
We start our discussion using a simple network (see Figure 2.2) with four routers. Each router has designated ports. For the sake of illustration, each port has been given a simple letter (a, b, s, h, a, and e). These port identifications are router specific. The data flows from the input a of R1 to the input of R4.
Figure 2.2: Basic MPLS Network with Four Routers
The basic network diagram shown in Figure 2.2 will be enhanced as we progress through MPLS signaling.
Two modes are used to load cross-connect tables: independent control and ordered control.
Each router could listen to routing tables, make its own cross-connect tables, and inform others of its information. These routers would be operating independently.
Independent control is a term given to a situation in which there is no designated label manager and when every router has the ability to listen to routing protocols, generate cross-connect tables, and distribute them freely (see Figure 2.3).
Figure 2.3: Independent Control
The other model of loading tables is ordered control, as shown in Figure 2.4. In the ordered control mode, one router—typically the egress LER—is responsible for distributing labels.
Figure 2.4: Ordered Control (Pushed)
Each of the two models has its tradeoffs. Independent control provides for faster network convergence. Any router that hears of a routing change can relay that information to all other routers. The disadvantage is that there is no single point of control that is generating traffic, which makes engineering more difficult.
Ordered control has the advantages of better traffic engineering and tighter network control; however, its disadvantages are that convergence time is slower and the label controller is the single point of failure.
Within ordered control, two major methods are used to trigger the distribution of labels. These are called downstream unsolicited (DOU) and downstream on demand (DOD).
In Figure 2.4, we saw the labels “pushed” to the downstream routers. This push is based on the decisions of the router that has been designated as label manager. When labels are sent out unsolicited by the label manager, it is known as downstream unsolicited, or DOU.
Consider these examples: The label manager may use trigger points (such as time intervals) to send out labels or label-refresh messages every 45 seconds. Or a label manager may use the change of standard routing tables as a trigger; when a router changes, the label manager may send out label updates to all affected routers.
When labels are requested, they are “pulled” down, or demanded, so this method has been called pulled or downstream on demand, or DOD. Note in Figure 2.5 that labels are requested in the first step, and they are sent in the second step.
Figure 2.5: Downstream on Demand (DOD)
Whether the labels arrive via independent control or ordered control, via DOD or DOU, the LSR creates a cross-connect table like the one shown in Figure 2.6.
Figure 2.6: LSR with Cross-Connect Tables Populated
The connect tables are sent from R3 to R1. The table headings read label-in, port-in, label-out, port-out, and instruction (I). In this case, the instruction is to swap (S). It is important to note that the labels and cross-connect tables are router specific.
After the cross-connect tables are loaded, the data can flow from Router 1 to Router 4, with each router following specific instructions to swap the labels.
After the cross-connect tables are loaded, the data can follow a designated LSP and flow from Router 1 to Router 4, as shown in Figure 2.7.
Figure 2.7: Data Flow on LSP
Checkpoint | Answer the following questions:
Answers: 1. pulled; 2. one; 3. independent control; 4. true. |
To begin a review, we know that routers need cross-connect tables in order to make switching decisions. Routers can receive these tables either from their neighbors (via independent control) or from a label manager (via ordered control).
A label manager can send labels on demand downstream on demand, or DOD), or it can send labels when it decides to do so, even though the downstream routers have made no label requests, by using downstream unsolicited, or DOU.
With these basic concepts understood, there are some more advanced concepts to consider, such as these: Just how are labels sent to routers? What vehicle is used to carry these labels? How is the QoS information relayed or sent to the routers?
To review a bit, it is understood that MPLS packets carry labels; however, they do not contain any areas that tell routers how to process the packets for QoS.
Recalling that traffic can be separated into groups called forward equivalence classes (FECs) and that FECs can be assigned to label switch paths (LSPs), we can perform traffic engineering that will force high-priority FECs on to high-quality LSPs and lower-priority FECs on to lower-quality LSPs. The mapping of traffic with use of different QoS standards will lead the distribution of labels and maps to become a more complex process.
Figure 2.8 shows a drawing of what goes on inside an LSR. There are two planes: the data plane and the control plane. Labeled packets enter at input a with a label of 1450, and they exit port b with a label of 1006. This function takes place in the cross-connect table. This table can also be called the next-hop label forwarding entry (NHLFE) table.
Figure 2.8: A Closer Look at the Router
This table is not a standalone database. It connects to two additional databases in the control plane: the FEC database and the FEC-to-NHLFE database. The FEC database contains, at a minimum, the destination IP address, but it can also contain traffic characteristics and packet-processing requirements. Data in this database must be related to a label; the process of relating an FEC to a label is called binding.
Tables 2.1–2.4 constitute an example of how labels and FECs are designed to work together. We see that packets with labels can be quickly processed when entering the data plane, provided that the labels are bound to an FEC. However, a lot of background processing must take place offline with data traffic before a cross-connect table can be established.
FEC 192.168.10.1 | Protocol 06 | Port 443 | Guaranteed no packet loss |
FEC 192.168.10.2 | Protocol 11 | Port 69 | Best effort |
FEC 192.168.10.3 | Protocol 06 | Port 80 | Controlled load |
100–10,000 are not in use at this time. |
FEC | Label In | Label Out |
---|---|---|
192.168.10.1 | 1400 | 100 |
192.168.10.2 | 500 | 101 |
192.168.10.3 | 107 | 103 |
Label In | Label Out |
---|---|
1400 | 100 |
500 | 101 |
107 | 103 |
| < Day Day Up > |
|