When we left off, we were examining the feasibility of using a Layer-2 topology within a WAN provider’s cloud, as shown in Figure 1:
Having built the physical topology using Layer-2 switches and interconnecting links, let’s see how we might establish customer connectivity, using Frame Relay as an example. With Frame Relay, the Layer-2 address contained within the frame header is a ten-bit value called a DLCI (Data-Link Connection Identifier). The WAN provider builds a table within each switch that forwards frames based on a combination of the inbound interface and DLCI. Here’s an example of a Frame Relay switching table:| Inbound DLCI | Inbound Interface | Outbound DLCI | Outbound Interface |
| 101 | 1 | 456 | 2 |
| 246 | 1 | 801 | 3 |
| 982 | 2 | 101 | 1 |
| 300 | 3 | 254 | 2 |
For example, when a frame enters the switch with DLCI = 246 on Interface 1, the DLCI is changed (swapped) to 801, and the frame is then forwarded out Interface 3. Note that with Frame Relay, unlike Ethernet, the Layer-2 addresses (DLCIs) can (and usually do) change at each switch hop as a data frame traverses the provider’s cloud. Once the provider has programmed the switches along the path with the correct DLCIs, the customer can then use the circuit. As an example, let’s look at Figure 2:
Note the heavy red line representing the physical path of data flow between site A1 and site A3, and see how the DLCI values change (101−456−153−46−207) as a data frame proceeds from A1 towards A3. With Frame Relay, the physical path between A1 and A3 must be the same in both directions, but it’s not required that the intermediate DLCIs used in the two directions be the same. What about data flowing from A3 towards A1? Refer to figure 3:
As you can see, the progression of DLCIs in the core when traveling from A3 to A1 (207−841−552−982−101) is not the same as when traveling from A1 to A3.
Let’s discuss one more thing. Instead of a cloud of switches, let’s imagine that we have an actual physical cable running point-to-point between two sites. With this topology, we know that the following things would be true:
- As frames cross the media, their order will be preserved.
- At most one copy of each frame will reach the far side.
It’s possible that one or more frames could be lost (the cable could break), but we’ll never get more than one of each frame making it to the far side, and whichever frames do make it across will arrive in the right order.
If we build a cloud of switches, establish a path through it, and enforce the two rules listed above, we would have a “VC” (Virtual Circuit), where “virtual” means “it acts like”. In other words, VC’s emulate physical circuits with regard to the sequencing and numbers of frames.
VC’s come in two varieties, “PVC” (Permanent VC) and “SVC” (Switched VC). In a PVC, the path is determined in advance, and programmed into the switches, reserving bandwidth on that path for that customer. With SVCs, the paths are determined “on the fly”, with the possibility that bandwidth between two sites might not be available (similar to “all circuits are busy” with a voice call over a telco). Frame Relay uses PVCs, while X25 and ATM can use PVCs or SVCs.
Next time, we’ll discuss the advantages of the system we’ve designed.
