File: rfc2105.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (731 lines) | stat: -rw-r--r-- 33,013 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
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]