doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc2105.txt b/doc/rfc/rfc2105.txt
new file mode 100644
index 0000000..bedc069
--- /dev/null
+++ b/doc/rfc/rfc2105.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                         Y. Rekhter
+Request for Comments: 2105                                      B. Davie
+Category: Informational                                          D. Katz
+                                                                E. Rosen
+                                                              G. Swallow
+                                                     Cisco Systems, Inc.
+                                                           February 1997
+
+
+           Cisco Systems' Tag Switching Architecture Overview
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+IESG Note:
+
+   This protocol is NOT the product of an IETF working group nor is it a
+   standards track document.  It has not necessarily benefited from the
+   widespread and in depth community review that standards track
+   documents receive.
+
+Abstract
+
+   This document provides an overview of a novel approach to network
+   layer packet forwarding, called tag switching. The two main
+   components of  the tag switching architecture - forwarding and
+   control - are described.  Forwarding is accomplished using simple
+   label-swapping techniques, while the existing network layer routing
+   protocols plus mechanisms for binding and distributing tags are used
+   for control. Tag switching can retain the scaling properties of IP,
+   and can help improve the scalability of IP networks. While tag
+   switching does not rely on ATM, it can straightforwardly be applied
+   to ATM switches. A range of tag switching applications and deployment
+   scenarios are described.
+
+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
+
+
+
+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. Introduction
+
+   Continuous growth of the Internet demands higher bandwidth within the
+   Internet Service Providers (ISPs). However, growth of the Internet is
+   not the only driving factor for higher bandwidth - demand for higher
+   bandwidth also comes from emerging multimedia applications.  Demand
+   for higher bandwidth, in turn, requires higher forwarding performance
+   (packets per second) by routers, for both multicast and unicast
+   traffic.
+
+   The growth of the Internet also demands improved scaling properties
+   of the Internet routing system. The ability to contain the volume of
+   routing information maintained by individual routers and the ability
+   to build a hierarchy of routing knowledge are essential to support a
+   high quality, scalable routing system.
+
+   We see the need to improve forwarding performance while at the same
+   time adding routing functionality to support multicast, allowing more
+   flexible control over how traffic is routed, and providing the
+   ability to build a hierarchy of routing knowledge. Moreover, it
+   becomes more and more crucial to have a routing system that can
+   support graceful evolution to accommodate new and emerging
+   requirements.
+
+   Tag switching is a technology that provides an efficient solution to
+   these challenges. Tag switching blends the flexibility and rich
+   functionality provided by Network Layer routing with the simplicity
+   provided by the label swapping forwarding paradigm.  The simplicity
+   of the tag switching forwarding paradigm (label swapping) enables
+   improved forwarding performance, while maintaining competitive
+   price/performance.  By associating a wide range of forwarding
+   granularities with a tag, the same forwarding paradigm can be used to
+   support a wide variety of routing functions, such as destination-
+   based routing, multicast, hierarchy of routing knowledge, and
+   flexible routing control. Finally, a combination of simple
+   forwarding, a wide range of forwarding granularities, and the ability
+   to evolve routing functionality while preserving the same forwarding
+   paradigm enables a routing system that can gracefully evolve to
+
+
+
+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 and
+   control. Section 3 describes the forwarding component.  Section 4
+   describes the control component. Section 5 describes how tag
+   switching could be used with ATM. Section 6 describes the use of tag
+   switching to help provide a range of qualities of service.  Section 7
+   briefly describes possible deployment scenarios. Section 8 summarizes
+   the results.
+
+2. Tag Switching components
+
+   Tag switching consists of two components: forwarding and control.
+   The forwarding component uses the tag information (tags) carried by
+   packets and the tag forwarding information maintained by a tag switch
+   to perform packet forwarding. The control component is responsible
+   for maintaining correct tag forwarding information among a group of
+   interconnected tag switches.
+
+3. Forwarding component
+
+   The fundamental forwarding paradigm employed by tag switching is
+   based on the notion of label swapping. When a packet with a tag is
+   received by a tag switch, the switch uses the tag as an index in its
+   Tag Information Base (TIB). Each entry in the TIB consists of 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 with the incoming tag equal to the tag carried in the
+   packet, then for each (outgoing tag, outgoing interface, outgoing
+   link level information) in the entry the switch replaces the tag in
+   the packet with the outgoing tag, replaces the link level information
+   (e.g MAC address) in the packet with the outgoing link level
+   information, and forwards the packet over the outgoing interface.
+
+   From the above description of the forwarding component we can make
+   several observations. First, the forwarding decision is based on the
+   exact match algorithm using a fixed length, fairly short tag as an
+   index. This enables a simplified forwarding procedure, relative to
+   longest match forwarding traditionally used at the network layer.
+   This in turn enables higher forwarding performance (higher packets
+   per second). The forwarding procedure is simple enough to allow a
+   straightforward hardware implementation.
+
+   A second observation is that the forwarding decision is independent
+   of the tag's forwarding granularity. For example, the same forwarding
+   algorithm applies to both unicast and multicast - a unicast entry
+   would just have a single (outgoing tag, outgoing interface, outgoing
+
+
+
+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 have
+   one or more (outgoing tag, outgoing interface, outgoing link level
+   information) sub-entries. (For multi-access links, the outgoing link
+   level information in this case would include a multicast MAC
+   address.) This illustrates how with tag switching the same forwarding
+   paradigm can be used to support different routing functions (e.g.,
+   unicast, multicast, etc...)
+
+   The simple forwarding procedure is thus essentially decoupled from
+   the control component of tag switching. New routing (control)
+   functions can readily be deployed without disturbing the forwarding
+   paradigm.  This means that it is not necessary to re-optimize
+   forwarding performance (by modifying either hardware or software) as
+   new routing functionality is added.
+
+3.1. Tag encapsulation
+
+   Tag information can be carried in a packet in a variety of 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).
+
+   It is therefore possible to implement tag switching over virtually
+   any media type including point-to-point links, multi-access links,
+   and ATM.
+
+   Observe also that the tag forwarding component is Network Layer
+   independent. Use of control component(s) specific to a particular
+   Network Layer protocol enables the use of tag switching with
+   different Network Layer protocols.
+
+4. Control component
+
+   Essential to tag switching is the notion of binding between a tag and
+   Network Layer routing (routes). To provide good scaling
+   characteristics, while also accommodating 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.
+
+
+
+Rekhter, et. al.             Informational                      [Page 4]
+
+RFC 2105           Cisco's Tag Switching Architecture      February 1997
+
+
+   The control component is responsible for creating tag bindings, and
+   then distributing the tag binding information among tag switches.
+   The control component is organized as a collection of modules, each
+   designed to support a particular routing function. To support new
+   routing functions, new modules can be added. The following describes
+   some of the modules.
+
+4.1. Destination-based routing
+
+   In this section we describe how tag switching can support
+   destination-based routing. Recall that with destination-based routing
+   a router makes a forwarding decision based on the destination address
+   carried in a packet and the information stored in the Forwarding
+   Information Base (FIB) maintained by the router. A router constructs
+   its FIB by using the information the router receives from routing
+   protocols (e.g., OSPF, BGP).
+
+   To support destination-based routing with tag switching, a tag
+   switch, just like a router, participates in routing protocols (e.g.,
+   OSPF, BGP), and constructs its FIB using the information it receives
+   from these protocols.
+
+   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 all cases, a switch allocates tags and binds them to address
+   prefixes in its FIB. In downstream allocation, the tag that is
+   carried in a packet is generated and bound to a prefix by the switch
+   at the downstream end of the link (with respect to the direction of
+   data flow). In upstream allocation, tags are allocated and bound at
+   the upstream end of the link. `On demand' allocation means that tags
+   will only be allocated and distributed by the downstream switch when
+   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 in
+   downstream allocation, a switch is responsible for creating tag
+   bindings that apply to incoming data packets, and receives tag
+   bindings for outgoing packets from its neighbors. In upstream
+   allocation, a switch is responsible for creating tag bindings for
+   outgoing tags, i.e. tags that are applied to data packets leaving the
+   switch, and receives bindings for incoming tags from its neighbors.
+
+   The downstream tag allocation scheme operates as follows: for each
+   route in its FIB the switch allocates a tag, creates an entry in its
+   Tag Information Base (TIB) with the incoming tag set to the allocated
+   tag, and then advertises the binding between the (incoming) tag and
+   the route to other adjacent tag switches. The advertisement could be
+   accomplished by either piggybacking the binding on top of the
+   existing routing protocols, or by using a separate Tag Distribution
+
+
+
+Rekhter, et. al.             Informational                      [Page 5]
+
+RFC 2105           Cisco's Tag Switching Architecture      February 1997
+
+
+   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 as part of the binding
+   information) into the outgoing tag of the TIB entry associated with
+   the route. This creates the binding between the outgoing tag and the
+   route.
+
+   With the downstream tag allocation on demand scheme, operation is as
+   follows. For each route in its FIB, the switch identifies the next
+   hop for that route. It then issues a request (via TDP) to the next
+   hop for a tag binding for that 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 then returns the binding
+   between the (incoming) tag and the  route to the switch that sent the
+   original request. When the switch receives the binding information,
+   the switch creates an entry in its TIB, and sets the outgoing tag in
+   the entry to the value received from the next hop.
+
+   The upstream tag allocation scheme is used as follows. 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 these
+   interfaces, the switch allocates a tag, creates an entry in its TIB
+   with the outgoing tag set to the allocated tag, and then advertises
+   to the next hop (via TDP) the binding between the (outgoing) tag and
+   the route. When a tag switch that is the next hop receives the tag
+   binding information, the switch places the tag (carried as part of
+   the binding information) into the incoming tag of the TIB entry
+   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 by
+   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, the switch, in addition to populating its TIB, also updates
+   its FIB with the binding information. This enables the switch to add
+   tags to previously untagged packets.
+
+   To understand the scaling properties of tag switching in conjunction
+   with destination-based routing, observe that the total number of tags
+   that a tag switch has to maintain can not be greater than the number
+   of routes in the switch's FIB. Moreover, in some cases a single tag
+   could be associated with a group of routes, rather than with a single
+   route. Thus, much less state is required than would be the case if
+   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 incoming
+   and outgoing tags for all routes to which it has reachability, so
+   that all packets can be forwarded by simple label swapping. Tag
+   allocation is thus driven by topology (routing), not traffic - it is
+   the existence of a FIB entry that causes tag allocations, not the
+   arrival of data packets.
+
+   Use of tags associated with routes, rather than flows, also means
+   that there is no need to perform flow classification procedures for
+   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 and
+   stable in the presence of changing traffic patterns.
+
+   Note that when tag switching is used to support destination-based
+   routing, tag switching does not completely eliminate the need to
+   perform normal Network Layer forwarding. First of all, to add a tag
+   to a previously untagged packet requires normal Network Layer
+   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 tag
+   switching. In addition, whenever a tag switch aggregates a set of
+   routes (e.g., by using the technique of hierarchical routing), into a
+   single tag, and the routes do not share a common next hop, the switch
+   needs to perform Network Layer forwarding for packets carrying that
+   tag. However, one could observe that the number of places where
+   routes get aggregated is smaller than the total number of places
+   where forwarding decisions have to be made.  Moreover, quite often
+   aggregation is applied to only a subset of the routes maintained by a
+   tag switch. As a result, 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 via interior
+   routing (e.g., OSPF), while routing across domains is provided via
+   exterior routing (e.g., BGP). However, all routers within domains
+   that carry transit traffic (e.g., domains formed by Internet Service
+   Providers) have to maintain information provided by not just interior
+   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 the
+   routers. Moreover, increase in the volume of routing information
+   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 required
+   to maintain routing information provided by exterior routing, while
+
+
+
+Rekhter, et. al.             Informational                      [Page 7]
+
+RFC 2105           Cisco's Tag Switching Architecture      February 1997
+
+
+   all other switches within the domain would just maintain routing
+   information provided by the domain's interior routing (which is
+   usually significantly smaller than the exterior routing information).
+   This, in turn, reduces the routing load on non-border switches, and
+   shortens routing convergence time.
+
+   To support this functionality, tag switching allows a packet to carry
+   not one but a set of tags, organized as a stack. A tag switch could
+   either swap the tag at the top of the stack, or pop the stack, or
+   swap the tag and push one or more tags into 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.
+   However, when a packet is forwarded within a domain, the tag stack in
+   the packet contains not one, but two tags (the second tag is pushed
+   by the domain's ingress border tag switch).  The tag at the top of
+   the stack provides packet forwarding to an appropriate egress border
+   tag switch, while the next tag in the stack provides correct packet
+   forwarding at the egress switch.  The stack is popped by either the
+   egress switch or by the penultimate (with respect to the egress
+   switch) switch.
+
+   The control component used in this scenario is fairly similar to the
+   one used with destination-based routing. In fact, the only essential
+   difference is that in this scenario the tag binding information is
+   distributed both among physically adjacent tag switches, and among
+   border tag switches within a single domain. One could also observe
+   that the latter (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 such trees (with receivers as leafs), while multicast
+   forwarding is responsible for forwarding multicast packets along such
+   trees.
+
+   To support a multicast forwarding function with tag switching, each
+   tag switch associates a tag with a multicast tree as follows.  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 the entry, the switch also creates local tags (one per outgoing
+   interface).  The switch 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.  This creates a binding between a
+
+
+
+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 each
+   outgoing interface associated with the entry the binding between the
+   tag (associated with this interface) and the tree.
+
+   When a tag switch receives a binding between a multicast tree and a
+   tag from another tag switch, if the 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 tag allocation
+   procedure for multicast could be the same as for tags used with
+   destination-based routing.
+
+4.4. Flexible routing (explicit routes)
+
+   One of the fundamental properties of destination-based routing is
+   that the only information from a packet that is used to forward the
+   packet is the destination address. While this property enables highly
+   scalable routing, it also limits the ability to influence the actual
+   paths taken by packets. This, in turn, limits the ability to evenly
+   distribute traffic among multiple links, taking the load off highly
+   utilized links, and shifting it towards less utilized links. For
+   Internet Service Providers (ISPs) who support different classes of
+   service, destination-based routing also limits their ability to
+   segregate different classes with respect to the links used by these
+   classes.  Some of the ISPs today use Frame Relay or ATM to overcome
+   the limitations imposed by destination-based routing. Tag switching,
+   because of the flexible granularity of tags, is able to overcome
+   these limitations without using either Frame Relay or ATM.
+
+   To provide forwarding along the paths that are different from the
+   paths determined by the destination-based routing, the control
+   component of tag switching allows installation of tag bindings in tag
+   switches that do not correspond to the destination-based routing
+   paths.
+
+5. Tag switching with ATM
+
+   Since the tag switching forwarding paradigm is based on label
+   swapping, and since ATM forwarding is also based on label swapping,
+   tag switching technology can readily be applied to ATM switches by
+   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 the
+   VCI field. If two levels of tagging are needed, then the VPI field
+   could be used as well, although the size of the VPI field limits the
+   size of networks in which this would be practical. However, for most
+   applications of one level of tagging the VCI field is adequate.
+
+   To obtain the necessary control information, the switch should be
+   able (at a minimum) to participate as a peer in Network Layer routing
+   protocols (e.g., OSPF, BGP). Moreover, if the switch has to perform
+   routing information aggregation, then to support destination-based
+   unicast routing the switch should be able to perform Network Layer
+   forwarding for some fraction of the traffic as well.
+
+   Supporting the destination-based routing function with tag switching
+   on an ATM switch may require the switch to maintain not one, but
+   several tags associated with a route (or a group of routes with the
+   same next hop).  This is necessary to avoid the interleaving of
+   packets which arrive from different upstream tag switches, but are
+   sent concurrently to the same next hop. Either the downstream tag
+   allocation on demand or the upstream tag allocation scheme could be
+   used for the tag allocation and TIB maintenance procedures with ATM
+   switches.
+
+   Therefore, an ATM switch can support tag switching, but at the
+   minimum it needs to implement Network Layer routing protocols, and
+   the tag switching control component on the switch. It may also need
+   to support some network layer forwarding.
+
+   Implementing tag switching on an ATM switch would simplify
+   integration of ATM switches and routers - an ATM switch capable of
+   tag switching would appear as a router to an adjacent router. That
+   could provide a viable, more scalable alternative to the overlay
+   model. It also removes the necessity for ATM addressing, routing and
+   signalling schemes. Because the destination-based forwarding approach
+   described in section 4.1 is topology driven rather than traffic
+   driven, application of this approach to ATM switches does not high
+   call setup rates, nor does it depend on the longevity of flows.
+
+   Implementing tag switching on an ATM switch does not preclude the
+   ability to support a traditional ATM control plane (e.g., PNNI) on
+   the same switch. The two components, tag switching and the ATM
+   control plane, would operate in a Ships In the Night mode (with
+   VPI/VCI space and other resources partitioned so that the components
+   do not interact).
+
+
+
+
+
+
+
+Rekhter, et. al.             Informational                     [Page 10]
+
+RFC 2105           Cisco's Tag Switching Architecture      February 1997
+
+
+6. Quality of service
+
+   Two mechanisms are needed for providing a range of qualities of
+   service to packets passing through a router or a tag switch. First,
+   we need to classify packets into different classes. Second, we need
+   to ensure that the handling of packets is such that the appropriate
+   QOS characteristics (bandwidth, loss, etc.) are provided to each
+   class.
+
+   Tag switching provides an easy way to mark packets as belonging to a
+   particular class after they have been classified the first time.
+   Initial classification would be done using information carried in the
+   network layer or higher layer headers. A tag corresponding to the
+   resultant class would then be applied to the packet. Tagged packets
+   can then be efficiently handled by the tag switching routers in their
+   path without needing to be reclassified. The actual packet scheduling
+   and queueing is largely orthogonal - the key point here is that tag
+   switching enables simple logic to be used to find the state that
+   identifies how the packet should be scheduled.
+
+   The exact use of tag switching for QOS purposes depends a great deal
+   on how QOS is deployed. If RSVP is used to request a certain QOS for
+   a class of packets, then it would be necessary to allocate a tag
+   corresponding to each RSVP session for which state is installed at a
+   tag switch. This might be done by TDP or by extension of RSVP.
+
+7. Tag switching migration strategies
+
+   Since tag switching is performed between a pair of adjacent tag
+   switches, and since the tag binding information could be distributed
+   on a pairwise basis, tag switching could be introduced in a fairly
+   simple, incremental fashion. For example, once a pair of adjacent
+   routers are converted into tag switches, each of the switches would
+   tag packets destined to the other, thus enabling the other switch to
+   use tag switching. Since tag switches use the same routing protocols
+   as routers, the introduction of tag switches has no impact on
+   routers. In fact, a tag switch connected to a router acts just as a
+   router from the router's perspective.
+
+   As more and more routers are upgraded to enable tag switching, the
+   scope of functionality provided by tag switching widens. For example,
+   once all the routers within a domain are upgraded to support tag
+   switching, in becomes possible to start using the hierarchy of
+   routing knowledge function.
+
+
+
+
+
+
+
+Rekhter, et. al.             Informational                     [Page 11]
+
+RFC 2105           Cisco's Tag Switching Architecture      February 1997
+
+
+8. Summary
+
+   In this document we described the tag switching technology. Tag
+   switching is not constrained to a particular Network Layer protocol -
+   it is a multiprotocol solution.  The forwarding component of tag
+   switching is simple enough to facilitate high performance forwarding,
+   and may be implemented on high performance forwarding hardware such
+   as ATM switches. The control component is flexible enough to support
+   a wide variety 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 could be associated with a tag, we provide both
+   scalable and functionally rich routing. A combination of a wide range
+   of forwarding granularities and the ability to evolve the control
+   component fairly independently from the forwarding component results
+   in a solution that enables graceful introduction of new routing
+   functionality to meet the demands of a rapidly evolving computer
+   networking environment.
+
+9. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+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 arising from 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
+
+   Significant contributions to this work have been made by Anthony
+   Alles, Fred Baker, Paul Doolan, Dino Farinacci, Guy Fedorkow, Jeremy
+   Lawrence, Arthur Lin, Morgan Littlewood, Keith McCloghrie, and Dan
+   Tappan.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, et. al.             Informational                     [Page 12]
+
+RFC 2105           Cisco's Tag Switching Architecture      February 1997
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, et. al.             Informational                     [Page 13]
+