rfc2105.txt

RFC 的详细文档！

   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: [e-mail]


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

   EMail: [e-mail]


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

   EMail: [e-mail]


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

   EMail: [e-mail]


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

   EMail: [e-mail]











Rekhter, et. al.             Informational                     [Page 13]