RFC 2105

Cisco Systems' Tag Switching Architecture Overview 🎀✨

Network Working Group: Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow 🦋 Request for Comments: 2105 Category: Informational (so it's not a standards-track thing 💅) Date: February 1997 Authors' org: Cisco Systems, Inc. 🌸 Obsoletes / Updates: the header doesn't list either one, so it doesn't replace or change any other RFC 🫶

Status of This Memo 📜

okay bestie, this part is the legal-ish bit. This memo is info for the Internet community 💜. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈.

IESG Note 🙈

this is important so read it 👀. This protocol is not the product of an IETF working group, and it's not a standards track document either. It hasn't necessarily gotten the big, deep community review that standards track docs get 💀. So treat it as an idea worth knowing about, not a finished spec 🧚.

Abstract ✨

okay so this doc gives you an overview of a totally novel way to forward packets at the network layer, called tag switching 🔥. It has two main parts, forwarding and control 🍓. Forwarding is basically simple label-swapping 🦋. Control is where the existing network layer routing protocols come in, plus the mechanisms for binding and distributing tags 🧠. Tag switching can keep the scaling properties of IP and help make IP networks more scalable 📈. It doesn't rely on ATM, BUT it can be applied to ATM switches straightforwardly 💅. There's also a range of applications and deployment scenarios described (we'll get there 😌).

---

Table of Contents 🗂️

1      Introduction  ...........................................   2
2      Tag Switching components  ...............................   3
3      Forwarding component  ...................................   3
3.1    Tag encapsulation  ......................................   4
4      Control component  ......................................   4
4.1    Destination-based routing  ..............................   5
4.2    Hierarchy of routing knowledge  .........................   7
4.3    Multicast  ..............................................   8
4.4    Flexible routing (explicit routes)  .....................   9
5      Tag switching with ATM  .................................   9
6      Quality of service  .....................................  11
7      Tag switching migration strategies  .....................  11
8      Summary  ................................................  12
9      Security Considerations  ................................  12
10     Intellectual Property Considerations  ...................  12
11     Acknowledgments  ........................................  12
12     Authors' Addresses  .....................................  13

1. Introduction 🌷

okay so the internet keeps growing and that means ISPs need more bandwidth 📶. But it's not just growth. Emerging multimedia apps want more bandwidth too 🎬. And more bandwidth means routers need higher forwarding performance (packets per second) 🔥, for both multicast AND unicast traffic 💜.

Growth also means the routing system needs better scaling 📈. Routers need to be able to contain how much routing info they're holding, and we need to build a hierarchy of routing knowledge. That's essential for a high quality, scalable routing system 💅.

So the vibe is: we need better forwarding performance, AND we want to add routing functionality for multicast 🦋, more flexible control over how traffic gets routed 🎀, and a way to build that hierarchy 🌸. Plus, it's getting crucial to have a routing system that can gracefully evolve for new requirements 🌈.

Tag switching is the solve 👑. It blends the flexibility and rich functionality of network layer routing with the simplicity of the label swapping forwarding paradigm ✨. That simplicity lets forwarding get faster while keeping competitive price/performance 💖. By attaching a wide range of forwarding granularities to a tag, the same forwarding paradigm can support lots of routing functions, like destination-based routing, multicast, hierarchy of routing knowledge, and flexible routing control 🧚. Put it all together (simple forwarding, a wide range of granularities, and the ability to evolve routing without changing the forwarding paradigm) and you get a routing system that can gracefully evolve for whatever comes next 🫶💜.

The rest of the doc is laid out like this 🗺️. Section 2 introduces the main components, forwarding and control 🍓. Section 3 covers the forwarding component 🦋. Section 4 covers the control component 🧠. Section 5 talks about how tag switching could work with ATM ⚡. Section 6 is about using tag switching to provide a range of qualities of service 🎀. Section 7 briefly describes possible deployment scenarios 🚀. Section 8 summarizes the results 💅.

2. Tag Switching components 🧩

okay bestie, tag switching has two components: forwarding and control 🫶. The forwarding component uses the tag info (tags) carried by packets, plus the tag forwarding info that a tag switch maintains, to do the actual packet forwarding 🚀. The control component is in charge of keeping the correct tag forwarding info across a group of interconnected tag switches 👑.

3. Forwarding component 🚀

so the fundamental forwarding paradigm in tag switching is based on label swapping 🔄. When a tag switch gets a packet with a tag, it uses that tag as an index into its Tag Information Base (TIB) 📚. Each TIB entry has an incoming tag and one or more sub-entries of the form (outgoing tag, outgoing interface, outgoing link level information) 🍓. If the switch finds an entry whose incoming tag matches the tag in the packet, then for each (outgoing tag, outgoing interface, outgoing link level information) in that entry, the switch does three things 💅: it replaces the tag in the packet with the outgoing tag, it replaces the link level information (e.g MAC address) in the packet with the outgoing link level information, and it forwards the packet over the outgoing interface 🦋.

a few observations, because they're so good 😭. First, the forwarding decision is based on an exact match algorithm, using a fixed length, fairly short tag as the index 🎯. This is simpler than the longest match forwarding traditionally used at the network layer ✨, and that simplicity means higher forwarding performance (higher packets per second) 🔥. It's simple enough for a straightforward hardware implementation 🛠️.

Second, the forwarding decision doesn't depend on the tag's forwarding granularity 🌈. Same forwarding algorithm for unicast AND multicast. A unicast entry just has a single (outgoing tag, outgoing interface, outgoing link level information) sub-entry, while a multicast entry may have one or more of them 💜. (For multi-access links, the outgoing link level info in this case would include a multicast MAC address 🙈.) This shows how tag switching lets the same forwarding paradigm support different routing functions (e.g., unicast, multicast, etc...) 🧚.

The simple forwarding procedure is basically decoupled from the control component 🫧. That means new routing (control) functions can get deployed without disturbing the forwarding paradigm 💖. So you don't have to re-optimize forwarding performance (by changing either hardware or software) every time new routing functionality gets added 🎀. Iconic, honestly 👑.

3.1. Tag encapsulation 🎁

tag info can be carried in a packet in a few different ways 🛍️:

• as a small "shim" tag header inserted between the layer 2 and the Network Layer headers 🍬;
• as part of the layer 2 header, if the layer 2 header provides adequate semantics (e.g., ATM, as discussed below) ⚡;
• as part of the Network Layer header (e.g., using the Flow Label field in IPv6 with appropriately modified semantics) 🌸.

so it's possible to implement tag switching over basically any media type, including point-to-point links, multi-access links, and ATM 🌍. Also, the tag forwarding component is Network Layer independent 🙌. Using control component(s) specific to a particular Network Layer protocol is what lets tag switching work with different Network Layer protocols 🦋.

4. Control component 🧠

the key idea in tag switching is the binding between a tag and Network Layer routing (routes) 🔗. To get good scaling characteristics while still handling diverse routing functionality, tag switching supports a wide range of forwarding granularities 📈. At one extreme, a tag could be associated (bound) to a group of routes (more specifically to the Network Layer Reachability Information of the routes in the group) 🍓. At the other extreme, a tag could be bound to an individual application flow (e.g., an RSVP flow) 🎀. A tag could also be bound to a multicast tree 🌳.

The control component creates tag bindings and then distributes that binding info among tag switches 📡. It's organized as a collection of modules, each designed to support a particular routing function 🧩. To support new routing functions, you just add new modules 💅. The following describes some of the modules 💜.

4.1. Destination-based routing 🗺️

Okay bestie, this part is about destination-based routing. Quick refresher: with destination-based routing, a router makes its forwarding decision from the destination address in the packet plus whatever is stored in its Forwarding Information Base (FIB) 🦋. The router builds that FIB from what it learns through routing protocols (e.g., OSPF, BGP).

So to do destination-based routing with tag switching, a tag switch acts like a router. It joins routing protocols (e.g., OSPF, BGP) and builds its FIB from what they tell it ✨.

There are three permitted methods for tag allocation and Tag Information Base (TIB) management: (a) downstream tag allocation, (b) downstream tag allocation on demand, and (c) upstream tag allocation. In every case, the switch allocates tags and binds them to address prefixes in its FIB. The difference is who does the allocating. With downstream allocation, the tag carried in a packet is generated and bound to a prefix by the switch at the downstream end of the link (relative to the direction of data flow) 💖. With upstream allocation, tags are allocated and bound at the upstream end of the link instead. "On demand" means the downstream switch only allocates and distributes tags when the upstream switch asks for them 🙈. Methods (b) and (c) are most useful in ATM networks (see Section 5) 💜.

Also, in downstream allocation, a switch creates tag bindings for incoming data packets and receives tag bindings for outgoing packets from its neighbors. In upstream allocation it's flipped: the switch creates bindings for outgoing tags (the ones on packets leaving the switch) and receives bindings for incoming tags from its neighbors 🫶.

Here's how downstream tag allocation goes 🌸. For each route in its FIB, the switch allocates a tag, makes an entry in its TIB with the incoming tag set to that allocated tag, and then advertises the (incoming) tag–route binding to its adjacent tag switches. The advertisement can be piggybacked on existing routing protocols, or it can use a separate Tag Distribution Protocol [TDP]. When a tag switch receives tag binding information for a route, and that information was originated by the next hop for that route, the switch places the tag (carried in the binding information) into the outgoing tag of the TIB entry for that route. That creates the binding between the outgoing tag and the route 🎀.

On-demand downstream allocation goes like this 🧚. For each route in its FIB, the switch identifies the next hop for that route. It then sends a request (via TDP) to that next hop asking for a tag binding for the route. When the next hop receives the request, it allocates a tag, creates an entry in its TIB with the incoming tag set to the allocated tag, and returns the (incoming) tag–route binding to the switch that sent the original request. When the switch receives that binding information, it creates an entry in its TIB and sets the outgoing tag to the value received from the next hop 👑.

Upstream tag allocation works like this 🦋. If a tag switch has one or more point-to-point interfaces, then for each route in its FIB whose next hop is reachable via one of those interfaces, the switch allocates a tag, creates an entry in its TIB with the outgoing tag set to the allocated tag, and advertises the (outgoing) tag–route binding to the next hop (via TDP). When the tag switch that is the next hop receives the tag binding information, it places the tag (carried in the binding information) into the incoming tag of the TIB entry for that route 💅.

Once a TIB entry has both incoming and outgoing tags, the tag switch can forward packets for the routes bound to those tags using the tag switching forwarding algorithm (as described in Section 3) ✨.

When a tag switch creates a binding between an outgoing tag and a route, it updates its TIB and also updates its FIB with the binding information. This lets the switch add tags to previously untagged packets 🏷️.

Now for the scaling tea ☕. The total number of tags a tag switch has to maintain can not be greater than the number of routes in the switch's FIB 💀. Sometimes a single tag can be associated with a group of routes instead of just one route, so much less state is needed than if tags were allocated to individual flows 🌈.

In general, a tag switch will try to fill its TIB with incoming and outgoing tags for all the routes it can reach, so that all packets can be forwarded by simple label swapping 💜. Tag allocation is driven by topology (routing), not traffic. The existence of a FIB entry is what causes tag allocations, not the arrival of data packets 🙈.

Using tags for routes instead of flows also means there's no need to run flow classification to decide whether each flow gets a tag. That simplifies the overall scheme and makes it more robust and stable when traffic patterns change 🫶.

BUT (sorry, not sorry) tag switching doesn't completely get rid of normal Network Layer forwarding 😭. First, adding a tag to a previously untagged packet still requires normal Network Layer forwarding. That job could be done by the first hop router, or by the first router on the path that is able to take part in tag switching. In addition, whenever a tag switch aggregates a set of routes into a single tag (for example, by using hierarchical routing) and those routes don't share a common next hop, the switch needs to perform Network Layer forwarding for packets carrying that tag. Still, you could notice that the places where routes get aggregated are fewer than the total number of places where forwarding decisions have to be made. Plus, aggregation is pretty often applied to only a subset of the routes a tag switch maintains. So on average, a packet can be forwarded most of the time using the tag switching algorithm 🎉.

4.2. Hierarchy of routing knowledge 🌳

The IP routing architecture models a network as a collection of routing domains 🏘️. Within a domain, routing is provided by interior routing (e.g., OSPF), and routing across domains is provided by exterior routing (e.g., BGP). But all routers within domains that carry transit traffic (like domains formed by Internet Service Providers) have to maintain information from not just interior routing, but exterior routing as well 😤. That creates some problems. First, the amount of this information is not insignificant, so it puts extra demand on router resources. Also, an increase in the volume of routing information often increases routing convergence time, and that in turn degrades the overall performance of the system 😩.

Tag switching allows interior and exterior routing to be decoupled 💖. That means only tag switches at the border of a domain need to maintain routing information provided by exterior routing, while all other switches within the domain just maintain routing information provided by the domain's interior routing (which is usually significantly smaller than the exterior routing information). This reduces the routing load on non-border switches and shortens routing convergence time ⚡.

To support this, tag switching lets a packet carry not one but a set of tags, organized as a stack 🥞. A tag switch can swap the tag at the top of the stack, pop the stack, or swap the tag and push one or more tags onto the stack.

When a packet is forwarded between two (border) tag switches in different domains, the tag stack in the packet contains just one tag. But when a packet is forwarded within a domain, the stack contains two tags 👯. The second tag is pushed by the domain's ingress border tag switch. The tag at the top of the stack gets the packet to an appropriate egress border tag switch, while the next tag in the stack provides correct forwarding at the egress switch 🎯. The stack is popped either by the egress switch or by the penultimate switch (with respect to the egress switch) 🫧.

The control component used in this scenario is pretty similar to the one used with destination-based routing. The one essential difference is that here, tag binding information is distributed both among physically adjacent tag switches and among border tag switches within a single domain 🤝. You could also notice that distribution among border switches could be trivially accommodated by very minor extensions to BGP (via a separate Tag Binding BGP attribute) 🧠.

4.3. Multicast 📡

Essential to multicast routing is the notion of spanning trees 🌲. Multicast routing procedures (e.g., PIM) are responsible for constructing those trees (with receivers as leafs), while multicast forwarding is responsible for forwarding multicast packets along them.

To support a multicast forwarding function with tag switching, each tag switch associates a tag with a multicast tree like this 🎀. When a tag switch creates a multicast forwarding entry (either for a shared or for a source-specific tree) and the list of outgoing interfaces for that entry, the switch also creates local tags, one per outgoing interface. It creates an entry in its TIB and populates (outgoing tag, outgoing interface, outgoing MAC header) with this information for each outgoing interface, placing a locally generated tag in the outgoing tag field. That creates a binding between a multicast tree and the tags. The switch then advertises, over each outgoing interface associated with the entry, the binding between the tag (associated with that interface) and the tree 📣.

When a tag switch receives a binding between a multicast tree and a tag from another tag switch, and that other switch is the upstream neighbor (with respect to the multicast tree), the local switch places the tag carried in the binding into the incoming tag component of the TIB entry associated with the tree 💜.

When a set of tag switches are interconnected via a multiple-access subnetwork, the tag allocation procedure for multicast has to be coordinated among the switches 🤝. In all other cases, the tag allocation procedure for multicast can be the same as for tags used with destination-based routing ✨.

4.4. Flexible routing (explicit routes) 🦋

okay so here's the thing bestie 🫶 destination-based routing is lowkey iconic because the ONLY thing a router looks at to forward a packet is the destination address. That's what makes it so scalable ✨ but it also means you can't really steer packets along different paths. So you can't easily spread traffic across multiple links, take load off the busy ones, and shift it onto the quiet ones 😭 ISPs that offer different classes of service have the same problem, because they can't easily keep each class on its own set of links.

Some ISPs today work around this with Frame Relay or ATM 💅 Tag switching is giving a cleaner way out, because tags can be as fine-grained or as coarse as you need. You get past these limits without Frame Relay or ATM. Slay 👑

Here's the trick: the control component of tag switching can install tag bindings in tag switches that don't match the destination-based routing paths 🌈 So packets can take the route you actually picked, not just the one the routing table would normally give them. Main character energy 💖

5. Tag switching with ATM 🎀

okay so tag switching forwarding is based on label swapping, and guess what, ATM forwarding is also based on label swapping 🙈 That means tag switching can be applied to ATM switches pretty directly, as long as you implement the control component of tag switching on them ✨

The tag information can ride in the VCI field 🦋 If you need two levels of tagging, the VPI field could be used too. Just know the size of the VPI field limits how big the networks can be where that makes sense 🌸 For most single-level tagging, though, the VCI field is plenty.

To get the control information it needs, the switch should be able (at a minimum) to take part as a peer in Network Layer routing protocols, like OSPF and BGP 💜 And if the switch has to do routing information aggregation, then to support destination-based unicast routing, it should also be able to do Network Layer forwarding for some fraction of the traffic 🧚

Supporting destination-based routing with tag switching on an ATM switch may mean the switch has to keep not just one tag, but several tags for a route (or a group of routes that share the same next hop) 💅 This is needed to stop packets that arrive from different upstream tag switches, but get sent at the same time to the same next hop, from getting interleaved 😭 Either downstream tag allocation on demand or upstream tag allocation could be used for tag allocation and TIB maintenance with ATM switches 🍓

So, to sum up: an ATM switch can support tag switching, but at the very least it needs to run the Network Layer routing protocols and have the tag switching control component on board 🔥 It may also need to support some network layer forwarding.

Doing tag switching on an ATM switch would make integrating ATM switches and routers way easier 💖 An ATM switch that can do tag switching would look like a router to an adjacent router. That could be a viable, more scalable alternative to the overlay model 🦋 It also gets rid of the need for ATM addressing, routing and signalling schemes ✨ And because the destination-based forwarding approach from section 4.1 is topology driven rather than traffic driven, using it on ATM switches doesn't bring high call setup rates, and it doesn't depend on how long flows last 🙈

Doing tag switching on an ATM switch doesn't rule out a traditional ATM control plane (like PNNI) on that same switch 🌈 The two components, tag switching and the ATM control plane, would run in Ships In the Night mode, with VPI/VCI space and other resources partitioned so the two don't interact 💜

6. Quality of service 👑

To give packets passing through a router or a tag switch a range of qualities of service, you need two mechanisms 💅 First, you classify packets into different classes. Second, you make sure packets get handled so each class gets the right QOS characteristics (bandwidth, loss, and so on) 🫶

Tag switching gives you an easy way to mark packets as belonging to a particular class after they've been classified the first time ✨ The first classification is done using information in the network layer or higher layer headers. A tag for the resulting class is then applied to the packet 🦋 Tagged packets can be handled efficiently by the tag switching routers along their path without being reclassified again 🌸 Scheduling and queueing are mostly orthogonal to this, and the key point is that tag switching lets simple logic find the state that says how the packet should be scheduled 💖

How QOS gets used with tag switching depends a lot on how QOS is deployed 😭 If RSVP is used to request a certain QOS for a class of packets, then a tag would need to be allocated for each RSVP session that has state installed at a tag switch 🧚 That could be done by TDP or by extending RSVP 🔥

7. Tag switching migration strategies 🌈

Tag switching happens between a pair of adjacent tag switches, and the tag binding information can be distributed pairwise 💜 So tag switching can be rolled out in a pretty simple, incremental way 🎀 For example, once a pair of adjacent routers is converted into tag switches, each switch can tag packets headed for the other, so the other switch can start using tag switching too ✨ Since tag switches use the same routing protocols as routers, adding tag switches has no impact on routers 💅 In fact, a tag switch connected to a router looks just like a router from that router's point of view 🫶

As more and more routers get upgraded to do tag switching, the scope of what tag switching can do keeps growing 🦋 For example, once all the routers in a domain are upgraded to support tag switching, it becomes possible to start using the hierarchy of routing knowledge function 👑

8. Summary 💖

In this document we went through tag switching technology 🌸 Tag switching isn't tied to one Network Layer protocol. It's a multiprotocol solution 🧚 The forwarding component is simple enough for high performance forwarding, and it can be implemented on high performance forwarding hardware like ATM switches 🔥 The control component is flexible enough to support a wide range of routing functions, such as destination-based routing, multicast routing, hierarchy of routing knowledge, and explicitly defined routes 🌈 By allowing a wide range of forwarding granularities that can be associated with a tag, you get routing that's both scalable and functionally rich 💜 Put that together with the ability to evolve the control component fairly independently of the forwarding component, and you get a solution that can be introduced gracefully as new routing functionality is needed for a rapidly evolving computer networking environment 👑✨

9. Security Considerations 💀

🚨 Security issues are not discussed in this memo. 🚨 Bestie, this is the one section where the answer is just "not covered here" 😭 Please don't assume this document has security sorted out. Go find the security analysis somewhere else before you deploy anything 💀

10. Intellectual Property Considerations 🎀

Cisco Systems may seek patent or other intellectual property protection for some or all of the technologies disclosed in this document 🌸 If any standards that come out of this document are, or become, protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non-discriminatory terms 🫶

11. Acknowledgments 🫶

Huge thanks to the people who made significant contributions to this work: Anthony Alles, Fred Baker, Paul Doolan, Dino Farinacci, Guy Fedorkow, Jeremy Lawrence, Arthur Lin, Morgan Littlewood, Keith McCloghrie, and Dan Tappan 💖🌈

12. Authors' Addresses 🦋

Yakov Rekhter
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134

EMail: yakov@cisco.com

Bruce Davie
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824

EMail: bsd@cisco.com

Dave Katz
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134

EMail: dkatz@cisco.com

Eric Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824

EMail: erosen@cisco.com

George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824

EMail: swallow@cisco.com

---

That's a wrap on RFC 2105, bestie! 🌈👑💖