As I write this at the end of July, I'm just back from Halifax, Nova Scotia, where Cisco just put a technical conference for CCIE's. It consisted of some rather technical talks to keep CCIE's current. Those who wished took an early morning written test. There was also an awards dinner, which we were lead to by a bagpiper!
Attending such events occasionally will be part of the the CCIE recertification process. Rumor says that in the future there will be a CCIE track at Networkers conferences.
Anyway, the talks were very, very good. I hope to pass along some of the stuff I learned in future articles (and classes).
For the statistically inclined: there are now about 1800 CCIE's now, out of 6200 attempts. Of those, about 1/2 are in the U.S. and 2/3 work for Cisco. If that's correct, a rough calculation says that about 300 U.S. CCIE's don't work for Cisco. Mentor Technologies now has seven (7) of those 300, teaching courses and consulting. We're also proud that Mentor Technologies'owner, Terry Slattery was given an award for support of the CCIE program. Terry is CCIE #1026, the 2nd CCIE awarded. Hopefully, all this shows up in quality teaching and consulting.
This month's article is about a hot topic, Tag Switching.
The basic idea behind Tag Switching stems from the Label Swapping that occurs in Frame Relay and ATM, and also in IBM APPN networking (on LAN's). Under Label Swapping, a cell or frame is forwarded to a switch (or APPN network node). This device looks up the current tag in a table associated with the port or interface the frame (or cell) was received on. From the tag table, the outgoing port and tag are determined. The old tag is replaced with the new one, and the frame is forwarded out the designated port. The point to this is that the switching logic is very simple, and so it can be done at very high speeds.
Here's what has to happen:
The next question is "How do the tag tables get set up to effectively pass frames (cells) from one edge of the label swapping network to the other?"
Frame Relay switches seem to mostly do this statically, using proprietary management schemes from the switch vendor. Some may have re-routing mechanisms in case of outage. ATM has had permanent virtual circuits (PVC's) for a while, but they are typically rather static. ATM has also had to define protocols for switch-to-switch signalling, user-to-network signalling, tracking what addresses and resources are where (PNNI), etc., to allow switched virtual circuits (SVC's). There's a lot of cumbersome protocol and programming machinery required to make circuit establishment more dynamic.
Tag Switching is "just" another mechanism for establishing label swapping tables. Once there's a mechanism for dynamic creation of VC's, then different control modules can drive it, for various purposes.
Cisco training courses have been presenting the idea that routing and switching frames are two separate activities. Switching involves a high speed forwarding decision. Routing is the background activity that updates tables used for the fast-paced switching decisions. Different routing protocols lead to different switching tables.
Tag Switching does this on a distributed basis. The control logic is analogous to routing: Tag Switches need to somehow negotiate VC establishment and tear-down. This creates Label Swapping tables in the Tag Switches, which can then forward frame (cells) at high speed, as above.
The company Ipsilon made Tag Switching hot, starting about a year ago. Their scheme routes IP packets through a cloud of their low-end ATM switches. These specialized ATM switches dynamically set up virtual circuits (VC's) for long-lived data flows. The programming code required to move data in this setting is much, much smaller than with the full ATM Forum approach. (Is anyone still holding their breath for MPOA or variants? They're coming.) Potentially, this scheme very effectively moves a lot of data through an Ipsilon ATM cloud. And a number of vendors saw this as a chance to combine ATM activities with effective high-speed routing, perhaps as a chance to compete with Cisco.
Ipsilon published their label management protocol in a pair of RFC's. They have not published the control logic that determines when and how to set up a VC.
Now Cisco, IBM, 3Com, Toshiba, and of course Ipsilon, have jumped right into the standards game, each with their own version of How It Should Be Done. The IETF committee forming a standard is the MPLS, Multi-Protocol Label Switching group.
This is a very simple way to integrate ATM switches and IP routers. It also is a conceptual breakthrough, since it amounts to realizing "if we make the ATM switches a little bit smarter about data networking, then look how easy everything gets." Instead of solving the hard problem of matching routers and data networking with an "alien" telephony-style ATM routing scheme, this takes the much easier path of adding data awareness to ATM switches. This is "breaking the rules", "thinking outside the box", usually recognized as "why didn't I think of that".
Embedding routing code in switches helps with data network scaling issues, as in today's large Frame Relay (FR) and WAN ATM networks which interconnect routers. One problem is flatness of the switch network: every edge router is a peer of every other router (potentially). This large number of routing adjacencies is hard on router CPU's, bandwidth, etc. And that's true no matter what routing protocol you use. Making such a network more hierarchical adds intermediate routers, and adds latency.
Looked at a bit differently, every router is connected to a very small number of peer FR or ATM switches, and if it can "see" the switches, and if its interactions are restricted to only neighboring switches, then many of the scaling issues go away.
This doesn't necessarily disrupt ATM Forum behavior of switches (classical, or legacy ATM?), it just adds separate functionality to it.
It also adds other features to the ATM network. If Class of Service or Security considerations are involved, separate VC's can be set up to carry different types of traffic. Note that CoS (Class of Service) is not QoS (Quality of Service): you get different classes of service, but the relation to quality is perhaps not explicit as in ATM QoS.
So control logic consists of:
But Tag Switching can do all of these! The edge devices control how tags and VC's are used. If one wants a VC per data flow, fine. If one wants a VC per destination IP subnet, or per IPX network, that's fine too.
Let's look at a proposed Tag Distribution Protocol (TDP), one that uses a "downstream" tag maintenance scheme. In this scheme, a tag router advertises to its neighbor a binding, combining a tag and an IP prefix (routing destination). For example, {5, 192.1.2.0 /24}. This in effects says "if you have traffic for 192.1.2.0 /24, I'd appreciate it being sent to me with tag 5 on it. The recipient puts this into a label swapping table, and on each port it picks an unused tag, stores it, and passes the information along.
This mechanism might use incremental updates over reliable transport, very similar to BGP.
It's easy to imagine this instead being done on-demand: "I'd like to send traffic to 192.1.2.0/24, what tag do you want me to send it to you with?" That's another possible mechanism. Upstream is yet another: "traffic for 192.1.2.0/24 will be coming at you with this tag in front of it".
The downstream approach can be driven off routing tables (when the routing table changes, it triggers TDP information). This creates routes in advance of need. The on-demand approach reduces the number of tags to just what's needed for existing traffic, but the cost is that there may be delays in forwarding the first packets of a data flow.
Performing better is why we want routers interconnected by ATM switches: the speed of Label Swapping means that we can forward cells (or frames) through the switch cloud without the store-and-forward (and other) latency a router introduces.
For migration, new routing and TDP software can be loaded into ATM switches, making them capable of Tag Switching. When enough are upgraded (software only), then traffic can switch to using Tag Switching instead the current methods. In the meantime, Tag Switching routers just look like regular routers to non-Tag Switching routers. This means ISP's can mix and match existing routers and ATM switches, instead of having to cut themselves and their customers over to using ATM. New routing protocols or control mechanisms can then be incrementally added on top of this. Tag Switching in effect puts the Cisco IOS into ATM switches, allowing a blurring of the router-switch distinction.
We looked at scaling, above, and how it helps with routers connected to an ATM cloud. There's another way that Tag Switching scales better. The LAN emulation (LANE) and Multi-Protocol Over ATM (MPOA) protocols are complex. Behind the scenes, they set up a relatively large number of SVC's. As the network grows, this number can easily reach the tens of thousands range. If there are N devices, the number of SVC's is O(N-squared), since there is an SVC between every pair of LAN Emulation Clients (LEC's). If there is an outage, time to re-establish that large number of SVC's can be a significant factor, since current call setup times are in the range of 10 to 20 per second. Call setup is also rough on the CPU in the ATM switch.With Tag Switching, the TDP causes entries to be put into the local switch's Label Swapping table. There is no call establishment, and the Tag VC is much like a PVC.
Tag Switching can be done using the Cisco Packet Over SONET (POS) interfaces. This gives a lower overhead data-only alternative to ATM. Cisco currently provides OC-3 POS interfaces, and is working on OC-12 and OC-48.
Tag Switching opens the door to traffic engineering. This is not ATM traffic management, with flow control, quality of service, etc. Instead, it's like Traffic Shifting in the voice telephone networks. Phone companies, and apparently also UUnet, have discovered that profitability is related to the efficiency of using the fiber links. With data, the idea is to view the Layer 3 data network as an overlay on the Layer 2 network. You then set up tunnels to carry moderately-sized flows, and shift the paths used by the tunnels to make most effective use of existing transmission media. Initially this will be done manually, with some tool assistance. Netsys has been chosen as the tool for doing this. It does have to be made tag and tunnel aware, but it already does a good bit of the rest of what's needed. (If you're looking for more about Netsys, see my prior articles).
The tunnel mechanism is rendered efficient by using tag switching. In terms of our prior discussion, this is a different control module. The Cisco engineers anticipate using RSVP to reserve bandwidth along the tunnel path, and are suggesting modifications to RSVP to allow tunnel establishment as well. The process looks like VC call setup. At the tunnel entrance, we configure the path (a sequence of devices) and the tunnel ID. The protocol then sends a message to the other end of the tunnel, and tags for a VC are established along the reverse path.
Tunnels come with an admission control: which packets are allowed through the tunnel. The initial plan is to focus on BGP next hop, with IP Class of Service perhaps the next feature to be looked at. Packets not admitted to the tunnel get processed normally.
The tunnel itself uses a stack of tags. The "visible" or outermost tag is the tunnel tag. At the tunnel endpoint, this tag is stripped and normal tag switching resumes. This allows ISP's to decouple eBGP routing from their IGP internal routing. The IGP is typically used to reach the ISP exit point (BGP next hop).
There are also mechanisms to make this robust, fallback tunnels, loop detection, and lots of other details we don't have space for here. Neat stuff! (See the Networkers '97 slides).
Demo Tag Switching code has been produced for the LS1010.
Stratacom BPX code is expected by the end of the year. Multicast support might be available in late 1997.
A quick search of Cisco CCO on "tag switching" is of course another way to locate documents not found at this URL.
Networkers '97 had two good talks on the topic, presented in LA by Bruce Davie.
SunWorld Online article (very lucid, some good links, too): http://www.sun.com/sunworldonline/swol-02-1997/swol-02-tagswitching.html
Network World articles (the Search area has access to a Tag Switching topic area with relevant articles listed): http://www.nwfusion.com
Internet drafts:
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .