As per Relevance of the word switching, we have this rfc below:
Network Working Group Y.
Request for Comments: 2105 B.
Category: Informational D.
E.
G.
Cisco Systems, Inc
February 1997
Cisco Systems' Tag Switching Architecture
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
IESG Note
This protocol is NOT the product of an IETF working group nor is it
standards track document. It has not necessarily benefited from
widespread and in depth community review that standards
documents receive
This document provides an overview of a novel approach to
layer packet forwarding, called tag switching. The two
components of the tag switching architecture - forwarding
control - are described. Forwarding is accomplished using
label-swapping techniques, while the existing network layer
protocols plus mechanisms for binding and distributing tags are
for control. Tag switching can retain the scaling properties of IP
and can help improve the scalability of IP networks. While
switching does not rely on ATM, it can straightforwardly be
to ATM switches. A range of tag switching applications and
scenarios are described
Table of
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
Rekhter, et. al. Informational [Page 1]
RFC 2105 Cisco's Tag Switching Architecture February 1997
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.
Continuous growth of the Internet demands higher bandwidth within
Internet Service Providers (ISPs). However, growth of the Internet
not the only driving factor for higher bandwidth - demand for
bandwidth also comes from emerging multimedia applications.
for higher bandwidth, in turn, requires higher forwarding
(packets per second) by routers, for both multicast and
traffic
The growth of the Internet also demands improved scaling
of the Internet routing system. The ability to contain the volume
routing information maintained by individual routers and the
to build a hierarchy of routing knowledge are essential to support
high quality, scalable routing system
We see the need to improve forwarding performance while at the
time adding routing functionality to support multicast, allowing
flexible control over how traffic is routed, and providing
ability to build a hierarchy of routing knowledge. Moreover,
becomes more and more crucial to have a routing system that
support graceful evolution to accommodate new and
requirements
Tag switching is a technology that provides an efficient solution
these challenges. Tag switching blends the flexibility and
functionality provided by Network Layer routing with the
provided by the label swapping forwarding paradigm. The
of the tag switching forwarding paradigm (label swapping)
improved forwarding performance, while maintaining
price/performance. By associating a wide range of
granularities with a tag, the same forwarding paradigm can be used
support a wide variety of routing functions, such as destination
based routing, multicast, hierarchy of routing knowledge,
flexible routing control. Finally, a combination of
forwarding, a wide range of forwarding granularities, and the
to evolve routing functionality while preserving the same
paradigm enables a routing system that can gracefully evolve
Rekhter, et. al. Informational [Page 2]
RFC 2105 Cisco's Tag Switching Architecture February 1997
accommodate new and emerging requirements
The rest of the document is organized as follows. Section 2
introduces the main components of tag switching, forwarding
control. Section 3 describes the forwarding component. Section 4
describes the control component. Section 5 describes how
switching could be used with ATM. Section 6 describes the use of
switching to help provide a range of qualities of service. Section 7
briefly describes possible deployment scenarios. Section 8
the results
2. Tag Switching
Tag switching consists of two components: forwarding and control
The forwarding component uses the tag information (tags) carried
packets and the tag forwarding information maintained by a tag
to perform packet forwarding. The control component is
for maintaining correct tag forwarding information among a group
interconnected tag switches
3. Forwarding
The fundamental forwarding paradigm employed by tag switching
based on the notion of label swapping. When a packet with a tag
received by a tag switch, the switch uses the tag as an index in
Tag Information Base (TIB). Each entry in the TIB consists of
incoming tag, and one or more sub-entries of the form (outgoing tag
outgoing interface, outgoing link level information). If the
finds an entry with the incoming tag equal to the tag carried in
packet, then for each (outgoing tag, outgoing interface,
link level information) in the entry the switch replaces the tag
the packet with the outgoing tag, replaces the link level
(e.g MAC address) in the packet with the outgoing link
information, and forwards the packet over the outgoing interface
From the above description of the forwarding component we can
several observations. First, the forwarding decision is based on
exact match algorithm using a fixed length, fairly short tag as
index. This enables a simplified forwarding procedure, relative
longest match forwarding traditionally used at the network layer
This in turn enables higher forwarding performance (higher
per second). The forwarding procedure is simple enough to allow
straightforward hardware implementation
A second observation is that the forwarding decision is
of the tag's forwarding granularity. For example, the same
algorithm applies to both unicast and multicast - a unicast
would just have a single (outgoing tag, outgoing interface,
Rekhter, et. al. Informational [Page 3]
RFC 2105 Cisco's Tag Switching Architecture February 1997
link level information) sub-entry, while a multicast entry may
one or more (outgoing tag, outgoing interface, outgoing link
information) sub-entries. (For multi-access links, the outgoing
level information in this case would include a multicast
address.) This illustrates how with tag switching the same
paradigm can be used to support different routing functions (e.g.,
unicast, multicast, etc...)
The simple forwarding procedure is thus essentially decoupled
the control component of tag switching. New routing (control
functions can readily be deployed without disturbing the
paradigm. This means that it is not necessary to re-
forwarding performance (by modifying either hardware or software)
new routing functionality is added
3.1. Tag
Tag information can be carried in a packet in a variety of ways
- as a small "shim" tag header inserted between the layer 2
the Network Layer headers
- as part of the layer 2 header, if the layer 2 header
adequate semantics (e.g., ATM, as discussed below);
- as part of the Network Layer header (e.g., using the Flow
field in IPv6 with appropriately modified semantics).
It is therefore possible to implement tag switching over
any media type including point-to-point links, multi-access links
and ATM
Observe also that the tag forwarding component is Network
independent. Use of control component(s) specific to a
Network Layer protocol enables the use of tag switching
different Network Layer protocols
4. Control
Essential to tag switching is the notion of binding between a tag
Network Layer routing (routes). To provide good
characteristics, while also accommodating diverse
functionality, tag switching supports a wide range of
granularities. At one extreme a tag could be associated (bound) to
group of routes (more specifically to the Network Layer
Information of the routes in the group). At the other extreme a
could be bound to an individual application flow (e.g., an
flow). A tag could also be bound to a multicast tree
Rekhter, et. al. Informational [Page 4]
RFC 2105 Cisco's Tag Switching Architecture February 1997
The control component is responsible for creating tag bindings,
then distributing the tag binding information among tag switches
The control component is organized as a collection of modules,
designed to support a particular routing function. To support
routing functions, new modules can be added. The following
some of the modules
4.1. Destination-based
In this section we describe how tag switching can
destination-based routing. Recall that with destination-based
a router makes a forwarding decision based on the destination
carried in a packet and the information stored in the
Information Base (FIB) maintained by the router. A router
its FIB by using the information the router receives from
protocols (e.g., OSPF, BGP).
To support destination-based routing with tag switching, a
switch, just like a router, participates in routing protocols (e.g.,
OSPF, BGP), and constructs its FIB using the information it
from these protocols
There are three permitted methods for tag allocation and
Information Base (TIB) management: (a) downstream tag allocation, (b
downstream tag allocation on demand, and (c) upstream tag allocation
In all cases, a switch allocates tags and binds them to
prefixes in its FIB. In downstream allocation, the tag that
carried in a packet is generated and bound to a prefix by the
at the downstream end of the link (with respect to the direction
data flow). In upstream allocation, tags are allocated and bound
the upstream end of the link. `On demand' allocation means that
will only be allocated and distributed by the downstream switch
it is requested to do so by the upstream switch. Methods (b) and (c
are most useful in ATM networks (see Section 5). Note that
downstream allocation, a switch is responsible for creating
bindings that apply to incoming data packets, and receives
bindings for outgoing packets from its neighbors. In
allocation, a switch is responsible for creating tag bindings
outgoing tags, i.e. tags that are applied to data packets leaving
switch, and receives bindings for incoming tags from its neighbors
The downstream tag allocation scheme operates as follows: for
route in its FIB the switch allocates a tag, creates an entry in
Tag Information Base (TIB) with the incoming tag set to the
tag, and then advertises the binding between the (incoming) tag
the route to other adjacent tag switches. The advertisement could
accomplished by either piggybacking the binding on top of
existing routing protocols, or by using a separate Tag
Rekhter, et. al. Informational [Page 5]
RFC 2105 Cisco's Tag Switching Architecture February 1997
Protocol [TDP]. When a tag switch receives tag binding
for a route, and that information was originated by the next hop
that route, the switch places the tag (carried as part of the
information) into the outgoing tag of the TIB entry associated
the route. This creates the binding between the outgoing tag and
route
With the downstream tag allocation on demand scheme, operation is
follows. For each route in its FIB, the switch identifies the
hop for that route. It then issues a request (via TDP) to the
hop for a tag binding for that route. When the next hop receives
request, it allocates a tag, creates an entry in its TIB with
incoming tag set to the allocated tag, and then returns the
between the (incoming) tag and the route to the switch that sent
original request. When the switch receives the binding information
the switch creates an entry in its TIB, and sets the outgoing tag
the entry to the value received from the next hop
The upstream tag allocation scheme is used as follows. If a
switch has one or more point-to-point interfaces, then for
route in its FIB whose next hop is reachable via one of
interfaces, the switch allocates a tag, creates an entry in its
with the outgoing tag set to the allocated tag, and then
to the next hop (via TDP) the binding between the (outgoing) tag
the route. When a tag switch that is the next hop receives the
binding information, the switch places the tag (carried as part
the binding information) into the incoming tag of the TIB
associated with the route
Once a TIB entry is populated with both incoming and outgoing tags
the tag switch can forward packets for routes bound to the tags
using the tag switching forwarding algorithm (as described in
3).
When a tag switch creates a binding between an outgoing tag and
route, the switch, in addition to populating its TIB, also
its FIB with the binding information. This enables the switch to
tags to previously untagged packets
To understand the scaling properties of tag switching in
with destination-based routing, observe that the total number of
that a tag switch has to maintain can not be greater than the
of routes in the switch's FIB. Moreover, in some cases a single
could be associated with a group of routes, rather than with a
route. Thus, much less state is required than would be the case
tags were allocated to individual flows
Rekhter, et. al. Informational [Page 6]
RFC 2105 Cisco's Tag Switching Architecture February 1997
In general, a tag switch will try to populate its TIB with
and outgoing tags for all routes to which it has reachability,
that all packets can be forwarded by simple label swapping.
allocation is thus driven by topology (routing), not traffic - it
the existence of a FIB entry that causes tag allocations, not
arrival of data packets
Use of tags associated with routes, rather than flows, also
that there is no need to perform flow classification procedures
all the flows to determine whether to assign a tag to a flow. That
in turn, simplifies the overall scheme, and makes it more robust
stable in the presence of changing traffic patterns
Note that when tag switching is used to support destination-
routing, tag switching does not completely eliminate the need
perform normal Network Layer forwarding. First of all, to add a
to a previously untagged packet requires normal Network
forwarding. This function could be performed by the first hop router
or by the first router on the path that is able to participate in
switching. In addition, whenever a tag switch aggregates a set
routes (e.g., by using the technique of hierarchical routing), into
single tag, and the routes do not share a common next hop, the
needs to perform Network Layer forwarding for packets carrying
tag. However, one could observe that the number of places
routes get aggregated is smaller than the total number of
where forwarding decisions have to be made. Moreover, quite
aggregation is applied to only a subset of the routes maintained by
tag switch. As a result, on average a packet can be forwarded most
the time using the tag switching algorithm
4.2. Hierarchy of routing
The IP routing architecture models a network as a collection
routing domains. Within a domain, routing is provided via
routing (e.g., OSPF), while routing across domains is provided
exterior routing (e.g., BGP). However, all routers within
that carry transit traffic (e.g., domains formed by Internet
Providers) have to maintain information provided by not just
routing, but exterior routing as well. That creates certain problems
First of all, the amount of this information is not insignificant
Thus it places additional demand on the resources required by
routers. Moreover, increase in the volume of routing
quite often increases routing convergence time. This, in turn
degrades the overall performance of the system
Tag switching allows the decoupling of interior and exterior routing
so that only tag switches at the border of a domain would be
to maintain routing information provided by exterior routing,
Rekhter, et. al. Informational [Page 7]
RFC 2105 Cisco's Tag Switching Architecture February 1997
all other switches within the domain would just maintain
information provided by the domain's interior routing (which
usually significantly smaller than the exterior routing information).
This, in turn, reduces the routing load on non-border switches,
shortens routing convergence time
To support this functionality, tag switching allows a packet to
not one but a set of tags, organized as a stack. A tag switch
either swap the tag at the top of the stack, or pop the stack,
swap the tag and push one or more tags into the stack
When a packet is forwarded between two (border) tag switches
different domains, the tag stack in the packet contains just one tag
However, when a packet is forwarded within a domain, the tag stack
the packet contains not one, but two tags (the second tag is
by the domain's ingress border tag switch). The tag at the top
the stack provides packet forwarding to an appropriate egress
tag switch, while the next tag in the stack provides correct
forwarding at the egress switch. The stack is popped by either
egress switch or by the penultimate (with respect to the
switch) switch
The control component used in this scenario is fairly similar to
one used with destination-based routing. In fact, the only
difference is that in this scenario the tag binding information
distributed both among physically adjacent tag switches, and
border tag switches within a single domain. One could also
that the latter (distribution among border switches) could
trivially accommodated by very minor extensions to BGP (via
separate Tag Binding BGP attribute).
4.3.
Essential to multicast routing is the notion of spanning trees
Multicast routing procedures (e.g., PIM) are responsible
constructing such trees (with receivers as leafs), while
forwarding is responsible for forwarding multicast packets along
trees
To support a multicast forwarding function with tag switching,
tag switch associates a tag with a multicast tree as follows. When
tag switch creates a multicast forwarding entry (either for a
or for a source-specific tree), and the list of outgoing
for the entry, the switch also creates local tags (one per
interface). The switch creates an entry in its TIB and
(outgoing tag, outgoing interface, outgoing MAC header) with
information for each outgoing interface, placing a locally
tag in the outgoing tag field. This creates a binding between
Rekhter, et. al. Informational [Page 8]
RFC 2105 Cisco's Tag Switching Architecture February 1997
multicast tree and the tags. The switch then advertises over
outgoing interface associated with the entry the binding between
tag (associated with this interface) and the tree
When a tag switch receives a binding between a multicast tree and
tag from another tag switch, if the other switch is the
neighbor (with respect to the multicast tree), the local
places the tag carried in the binding into the incoming tag
of the TIB entry associated with the tree
When a set of tag switches are interconnected via a multiple-
subnetwork, the tag allocation procedure for multicast has to
coordinated among the switches. In all other cases tag
procedure for multicast could be the same as for tags used
destination-based routing
4.4. Flexible routing (explicit routes
One of the fundamental properties of destination-based routing
that the only information from a packet that is used to forward
packet is the destination address. While this property enables
scalable routing, it also limits the ability to influence the
paths taken by packets. This, in turn, limits the ability to
distribute traffic among multiple links, taking the load off
utilized links, and shifting it towards less utilized links.
Internet Service Providers (ISPs) who support different classes
service, destination-based routing also limits their ability
segregate different classes with respect to the links used by
classes. Some of the ISPs today use Frame Relay or ATM to
the limitations imposed by destination-based routing. Tag switching
because of the flexible granularity of tags, is able to
these limitations without using either Frame Relay or ATM
To provide forwarding along the paths that are different from
paths determined by the destination-based routing, the
component of tag switching allows installation of tag bindings in
switches that do not correspond to the destination-based
paths
5. Tag switching with
Since the tag switching forwarding paradigm is based on
swapping, and since ATM forwarding is also based on label swapping
tag switching technology can readily be applied to ATM switches
implementing the control component of tag switching
Rekhter, et. al. Informational [Page 9]
RFC 2105 Cisco's Tag Switching Architecture February 1997
The tag information needed for tag switching can be carried in
VCI field. If two levels of tagging are needed, then the VPI
could be used as well, although the size of the VPI field limits
size of networks in which this would be practical. However, for
applications of one level of tagging the VCI field is adequate
To obtain the necessary control information, the switch should
able (at a minimum) to participate as a peer in Network Layer
protocols (e.g., OSPF, BGP). Moreover, if the switch has to
routing information aggregation, then to support destination-
unicast routing the switch should be able to perform Network
forwarding for some fraction of the traffic as well
Supporting the destination-based routing function with tag
on an ATM switch may require the switch to maintain not one,
several tags associated with a route (or a group of routes with
same next hop). This is necessary to avoid the interleaving
packets which arrive from different upstream tag switches, but
sent concurrently to the same next hop. Either the downstream
allocation on demand or the upstream tag allocation scheme could
used for the tag allocation and TIB maintenance procedures with
switches
Therefore, an ATM switch can support tag switching, but at
minimum it needs to implement Network Layer routing protocols,
the tag switching control component on the switch. It may also
to support some network layer forwarding
Implementing tag switching on an ATM switch would
integration of ATM switches and routers - an ATM switch capable
tag switching would appear as a router to an adjacent router.
could provide a viable, more scalable alternative to the
model. It also removes the necessity for ATM addressing, routing
signalling schemes. Because the destination-based forwarding
described in section 4.1 is topology driven rather than
driven, application of this approach to ATM switches does not
call setup rates, nor does it depend on the longevity of flows
Implementing tag switching on an ATM switch does not preclude
ability to support a traditional ATM control plane (e.g., PNNI)
the same switch. The two components, tag switching and the
control plane, would operate in a Ships In the Night mode (
VPI/VCI space and other resources partitioned so that the
do not interact).
Rekhter, et. al. Informational [Page 10]
RFC 2105 Cisco's Tag Switching Architecture February 1997
6. Quality of
Two mechanisms are needed for providing a range of qualities
service to packets passing through a router or a tag switch. First
we need to classify packets into different classes. Second, we
to ensure that the handling of packets is such that the
QOS characteristics (bandwidth, loss, etc.) are provided to
class
Tag switching provides an easy way to mark packets as belonging to
particular class after they have been classified the first time
Initial classification would be done using information carried in
network layer or higher layer headers. A tag corresponding to
resultant class would then be applied to the packet. Tagged
can then be efficiently handled by the tag switching routers in
path without needing to be reclassified. The actual packet
and queueing is largely orthogonal - the key point here is that
switching enables simple logic to be used to find the state
identifies how the packet should be scheduled
The exact use of tag switching for QOS purposes depends a great
on how QOS is deployed. If RSVP is used to request a certain QOS
a class of packets, then it would be necessary to allocate a
corresponding to each RSVP session for which state is installed at
tag switch. This might be done by TDP or by extension of RSVP
7. Tag switching migration
Since tag switching is performed between a pair of adjacent
switches, and since the tag binding information could be
on a pairwise basis, tag switching could be introduced in a
simple, incremental fashion. For example, once a pair of
routers are converted into tag switches, each of the switches
tag packets destined to the other, thus enabling the other switch
use tag switching. Since tag switches use the same routing
as routers, the introduction of tag switches has no impact
routers. In fact, a tag switch connected to a router acts just as
router from the router's perspective
As more and more routers are upgraded to enable tag switching,
scope of functionality provided by tag switching widens. For example
once all the routers within a domain are upgraded to support
switching, in becomes possible to start using the hierarchy
routing knowledge function
Rekhter, et. al. Informational [Page 11]
RFC 2105 Cisco's Tag Switching Architecture February 1997
8.
In this document we described the tag switching technology.
switching is not constrained to a particular Network Layer protocol -
it is a multiprotocol solution. The forwarding component of
switching is simple enough to facilitate high performance forwarding
and may be implemented on high performance forwarding hardware
as ATM switches. The control component is flexible enough to
a wide variety of routing functions, such as destination-
routing, multicast routing, hierarchy of routing knowledge,
explicitly defined routes. By allowing a wide range of
granularities that could be associated with a tag, we provide
scalable and functionally rich routing. A combination of a wide
of forwarding granularities and the ability to evolve the
component fairly independently from the forwarding component
in a solution that enables graceful introduction of new
functionality to meet the demands of a rapidly evolving
networking environment
9. Security
Security issues are not discussed in this memo
10. Intellectual Property
Cisco Systems may seek patent or other intellectual
protection for some or all of the technologies disclosed in
document. If any standards arising from this document are or
protected by one or more patents assigned to Cisco Systems,
intends to disclose those patents and license them on reasonable
non-discriminatory terms
11.
Significant contributions to this work have been made by
Alles, Fred Baker, Paul Doolan, Dino Farinacci, Guy Fedorkow,
Lawrence, Arthur Lin, Morgan Littlewood, Keith McCloghrie, and
Tappan
Rekhter, et. al. Informational [Page 12]
RFC 2105 Cisco's Tag Switching Architecture February 1997
12. Authors'
Yakov
Cisco Systems, Inc
170 Tasman
San Jose, CA, 95134
EMail: yakov@cisco.
Bruce
Cisco Systems, Inc
250 Apollo
Chelmsford, MA, 01824
EMail: bsd@cisco.
Dave
Cisco Systems, Inc
170 Tasman
San Jose, CA, 95134
EMail: dkatz@cisco.
Eric
Cisco Systems, Inc
250 Apollo
Chelmsford, MA, 01824
EMail: erosen@cisco.
George
Cisco Systems, Inc
250 Apollo
Chelmsford, MA, 01824
EMail: swallow@cisco.
Rekhter, et. al. Informational [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
