home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- 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]
-
-