idnits 2.17.1 draft-rfced-info-rekhter-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 46 has weird spacing: '...ents of the t...' == Line 272 has weird spacing: '...and the route...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1996) is 10085 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'TDP' on line 259 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Expires March 1997 INTERNET-DRAFT 3 Network Working Group Yakov Rekhter 4 Internet Draft Cisco Systems, Inc. 5 Expiration Date: March 1997 6 Bruce Davie 7 Cisco Systems, Inc. 9 Dave Katz 10 Cisco Systems, Inc. 12 Eric Rosen 13 Cisco Systems, Inc. 15 George Swallow 16 Cisco Systems, Inc. 18 September 1996 20 Tag Switching Architecture Overview 22 24 Status of this Memo 26 This document is an Internet-Draft. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF), its areas, 28 and its working groups. Note that other groups may also distribute 29 working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 To learn the current status of any Internet-Draft, please check the 37 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 38 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 39 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 40 ftp.isi.edu (US West Coast). 42 Abstract 44 This document provides an overview of a novel approach to network 45 layer packet forwarding, called tag switching. The two main 46 components of the tag switching architecture - forwarding and 47 control - are described. Forwarding is accomplished using simple 48 label-swapping techniques, while the existing network layer routing 49 protocols plus mechanisms for binding and distributing tags are used 50 for control. Tag switching can retain the scaling properties of IP, 51 and can help improve the scalability of IP networks. While tag 52 switching does not rely on ATM, it can straightforwardly be applied 53 to ATM switches. A range of tag switching applications and deployment 54 scenarios are described. 56 Contents 58 1 Introduction ........................................... 2 59 2 Tag Switching components ............................... 3 60 3 Forwarding component ................................... 4 61 3.1 Tag encapsulation ...................................... 5 62 4 Control component ...................................... 5 63 4.1 Destination-based routing .............................. 6 64 4.2 Hierarchy of routing knowledge ......................... 8 65 4.3 Multicast .............................................. 9 66 4.4 Flexible routing (explicit routes) ..................... 10 67 5 Tag switching with ATM ................................. 10 68 6 Quality of service ..................................... 12 69 7 Tag switching migration strategies ..................... 12 70 8 Summary ................................................ 13 71 9 Security Considerations ................................ 13 72 10 Intellectual Property Considerations ................... 13 73 11 Acknowledgments ........................................ 13 74 12 Authors' Addresses ..................................... 14 76 1. Introduction 78 Continuous growth of the Internet demands higher bandwidth within the 79 Internet Service Providers (ISPs). However, growth of the Internet is 80 not the only driving factor for higher bandwidth - demand for higher 81 bandwidth also comes from emerging multimedia applications. Demand 82 for higher bandwidth, in turn, requires higher forwarding performance 83 (packets per second) by routers, for both multicast and unicast 84 traffic. 86 The growth of the Internet also demands improved scaling properties 87 of the Internet routing system. The ability to contain the volume of 88 routing information maintained by individual routers and the ability 89 to build a hierarchy of routing knowledge are essential to support a 90 high quality, scalable routing system. 92 We see the need to improve forwarding performance while at the same 93 time adding routing functionality to support multicast, allowing more 94 flexible control over how traffic is routed, and providing the 95 ability to build a hierarchy of routing knowledge. Moreover, it 96 becomes more and more crucial to have a routing system that can 97 support graceful evolution to accommodate new and emerging 98 requirements. 100 Tag switching is a technology that provides an efficient solution to 101 these challenges. Tag switching blends the flexibility and rich 102 functionality provided by Network Layer routing with the simplicity 103 provided by the label swapping forwarding paradigm. The simplicity 104 of the tag switching forwarding paradigm (label swapping) enables 105 improved forwarding performance, while maintaining competitive 106 price/performance. By associating a wide range of forwarding 107 granularities with a tag, the same forwarding paradigm can be used to 108 support a wide variety of routing functions, such as destination- 109 based routing, multicast, hierarchy of routing knowledge, and 110 flexible routing control. Finally, a combination of simple 111 forwarding, a wide range of forwarding granularities, and the ability 112 to evolve routing functionality while preserving the same forwarding 113 paradigm enables a routing system that can gracefully evolve to 114 accommodate new and emerging requirements. 116 The rest of the document is organized as follows. Section 2 117 introduces the main components of tag switching, forwarding and 118 control. Section 3 describes the forwarding component. Section 4 119 describes the control component. Section 5 describes how tag 120 switching could be used with ATM. Section 6 describes the use of tag 121 switching to help provide a range of qualities of service. Section 7 122 briefly describes possible deployment scenarios. Section 8 summarizes 123 the results. 125 2. Tag Switching components 127 Tag switching consists of two components: forwarding and control. 128 The forwarding component uses the tag information (tags) carried by 129 packets and the tag forwarding information maintained by a tag switch 130 to perform packet forwarding. The control component is responsible 131 for maintaining correct tag forwarding information among a group of 132 interconnected tag switches. 134 3. Forwarding component 136 The fundamental forwarding paradigm employed by tag switching is 137 based on the notion of label swapping. When a packet with a tag is 138 received by a tag switch, the switch uses the tag as an index in its 139 Tag Information Base (TIB). Each entry in the TIB consists of an 140 incoming tag, and one or more sub-entries of the form (outgoing tag, 141 outgoing interface, outgoing link level information). If the switch 142 finds an entry with the incoming tag equal to the tag carried in the 143 packet, then for each (outgoing tag, outgoing interface, outgoing 144 link level information) in the entry the switch replaces the tag in 145 the packet with the outgoing tag, replaces the link level information 146 (e.g MAC address) in the packet with the outgoing link level 147 information, and forwards the packet over the outgoing interface. 149 From the above description of the forwarding component we can make 150 several observations. First, the forwarding decision is based on the 151 exact match algorithm using a fixed length, fairly short tag as an 152 index. This enables a simplified forwarding procedure, relative to 153 longest match forwarding traditionally used at the network layer. 154 This in turn enables higher forwarding performance (higher packets 155 per second). The forwarding procedure is simple enough to allow a 156 straightforward hardware implementation. 158 A second observation is that the forwarding decision is independent 159 of the tag's forwarding granularity. For example, the same forwarding 160 algorithm applies to both unicast and multicast - a unicast entry 161 would just have a single (outgoing tag, outgoing interface, outgoing 162 link level information) sub-entry, while a multicast entry may have 163 one or more (outgoing tag, outgoing interface, outgoing link level 164 information) sub-entries. (For multi-access links, the outgoing link 165 level information in this case would include a multicast MAC 166 address.) This illustrates how with tag switching the same forwarding 167 paradigm can be used to support different routing functions (e.g., 168 unicast, multicast, etc...) 170 The simple forwarding procedure is thus essentially decoupled from 171 the control component of tag switching. New routing (control) 172 functions can readily be deployed without disturbing the forwarding 173 paradigm. This means that it is not necessary to re-optimize 174 forwarding performance (by modifying either hardware or software) as 175 new routing functionality is added. 177 3.1. Tag encapsulation 179 Tag information can be carried in a packet in a variety of ways: 181 - as a small "shim" tag header inserted between the layer 2 and 182 the Network Layer headers; 184 - as part of the layer 2 header, if the layer 2 header provides 185 adequate semantics (e.g., ATM, as discussed below); 187 - as part of the Network Layer header (e.g., using the Flow Label 188 field in IPv6 with appropriately modified semantics). 190 It is therefore possible to implement tag switching over virtually 191 any media type including point-to-point links, multi-access links, 192 and ATM. 194 Observe also that the tag forwarding component is Network Layer 195 independent. Use of control component(s) specific to a particular 196 Network Layer protocol enables the use of tag switching with 197 different Network Layer protocols. 199 4. Control component 201 Essential to tag switching is the notion of binding between a tag and 202 Network Layer routing (routes). To provide good scaling 203 characteristics, while also accommodating diverse routing 204 functionality, tag switching supports a wide range of forwarding 205 granularities. At one extreme a tag could be associated (bound) to a 206 group of routes (more specifically to the Network Layer Reachability 207 Information of the routes in the group). At the other extreme a tag 208 could be bound to an individual application flow (e.g., an RSVP 209 flow). A tag could also be bound to a multicast tree. 211 The control component is responsible for creating tag bindings, and 212 then distributing the tag binding information among tag switches. 213 The control component is organized as a collection of modules, each 214 designed to support a particular routing function. To support new 215 routing functions, new modules can be added. The following describes 216 some of the modules. 218 4.1. Destination-based routing 220 In this section we describe how tag switching can support 221 destination-based routing. Recall that with destination-based routing 222 a router makes a forwarding decision based on the destination address 223 carried in a packet and the information stored in the Forwarding 224 Information Base (FIB) maintained by the router. A router constructs 225 its FIB by using the information the router receives from routing 226 protocols (e.g., OSPF, BGP). 228 To support destination-based routing with tag switching, a tag 229 switch, just like a router, participates in routing protocols (e.g., 230 OSPF, BGP), and constructs its FIB using the information it receives 231 from these protocols. 233 There are three permitted methods for tag allocation and Tag 234 Information Base (TIB) management: (a) downstream tag allocation, (b) 235 downstream tag allocation on demand, and (c) upstream tag allocation. 236 In all cases, a switch allocates tags and binds them to address 237 prefixes in its FIB. In downstream allocation, the tag that is 238 carried in a packet is generated and bound to a prefix by the switch 239 at the downstream end of the link (with respect to the direction of 240 data flow). In upstream allocation, tags are allocated and bound at 241 the upstream end of the link. `On demand' allocation means that tags 242 will only be allocated and distributed by the downstream switch when 243 it is requested to do so by the upstream switch. Methods (b) and (c) 244 are most useful in ATM networks (see Section 5). Note that in 245 downstream allocation, a switch is responsible for creating tag 246 bindings that apply to incoming data packets, and receives tag 247 bindings for outgoing packets from its neighbors. In upstream 248 allocation, a switch is responsible for creating tag bindings for 249 outgoing tags, i.e. tags that are applied to data packets leaving the 250 switch, and receives bindings for incoming tags from its neighbors. 252 The downstream tag allocation scheme operates as follows: for each 253 route in its FIB the switch allocates a tag, creates an entry in its 254 Tag Information Base (TIB) with the incoming tag set to the allocated 255 tag, and then advertises the binding between the (incoming) tag and 256 the route to other adjacent tag switches. The advertisement could be 257 accomplished by either piggybacking the binding on top of the 258 existing routing protocols, or by using a separate Tag Distribution 259 Protocol [TDP]. When a tag switch receives tag binding information 260 for a route, and that information was originated by the next hop for 261 that route, the switch places the tag (carried as part of the binding 262 information) into the outgoing tag of the TIB entry associated with 263 the route. This creates the binding between the outgoing tag and the 264 route. 266 With the downstream tag allocation on demand scheme, operation is as 267 follows. For each route in its FIB, the switch identifies the next 268 hop for that route. It then issues a request (via TDP) to the next 269 hop for a tag binding for that route. When the next hop receives the 270 request, it allocates a tag, creates an entry in its TIB with the 271 incoming tag set to the allocated tag, and then returns the binding 272 between the (incoming) tag and the route to the switch that sent the 273 original request. When the switch receives the binding information, 274 the switch creates an entry in its TIB, and sets the outgoing tag in 275 the entry to the value received from the next hop. 277 The upstream tag allocation scheme is used as follows. If a tag 278 switch has one or more point-to-point interfaces, then for each 279 route in its FIB whose next hop is reachable via one of these 280 interfaces, the switch allocates a tag, creates an entry in its TIB 281 with the outgoing tag set to the allocated tag, and then advertises 282 to the next hop (via TDP) the binding between the (outgoing) tag and 283 the route. When a tag switch that is the next hop receives the tag 284 binding information, the switch places the tag (carried as part of 285 the binding information) into the incoming tag of the TIB entry 286 associated with the route. 288 Once a TIB entry is populated with both incoming and outgoing tags, 289 the tag switch can forward packets for routes bound to the tags by 290 using the tag switching forwarding algorithm (as described in Section 291 3). 293 When a tag switch creates a binding between an outgoing tag and a 294 route, the switch, in addition to populating its TIB, also updates 295 its FIB with the binding information. This enables the switch to add 296 tags to previously untagged packets. 298 To understand the scaling properties of tag switching in conjunction 299 with destination-based routing, observe that the total number of tags 300 that a tag switch has to maintain can not be greater than the number 301 of routes in the switch's FIB. Moreover, in some cases a single tag 302 could be associated with a group of routes, rather than with a single 303 route. Thus, much less state is required than would be the case if 304 tags were allocated to individual flows. 306 In general, a tag switch will try to populate its TIB with incoming 307 and outgoing tags for all routes to which it has reachability, so 308 that all packets can be forwarded by simple label swapping. Tag 309 allocation is thus driven by topology (routing), not traffic - it is 310 the existence of a FIB entry that causes tag allocations, not the 311 arrival of data packets. 313 Use of tags associated with routes, rather than flows, also means 314 that there is no need to perform flow classification procedures for 315 all the flows to determine whether to assign a tag to a flow. That, 316 in turn, simplifies the overall scheme, and makes it more robust and 317 stable in the presence of changing traffic patterns. 319 Note that when tag switching is used to support destination-based 320 routing, tag switching does not completely eliminate the need to 321 perform normal Network Layer forwarding. First of all, to add a tag 322 to a previously untagged packet requires normal Network Layer 323 forwarding. This function could be performed by the first hop router, 324 or by the first router on the path that is able to participate in tag 325 switching. In addition, whenever a tag switch aggregates a set of 326 routes (e.g., by using the technique of hierarchical routing), into a 327 single tag, and the routes do not share a common next hop, the switch 328 needs to perform Network Layer forwarding for packets carrying that 329 tag. However, one could observe that the number of places where 330 routes get aggregated is smaller than the total number of places 331 where forwarding decisions have to be made. Moreover, quite often 332 aggregation is applied to only a subset of the routes maintained by a 333 tag switch. As a result, on average a packet can be forwarded most of 334 the time using the tag switching algorithm. 336 4.2. Hierarchy of routing knowledge 338 The IP routing architecture models a network as a collection of 339 routing domains. Within a domain, routing is provided via interior 340 routing (e.g., OSPF), while routing across domains is provided via 341 exterior routing (e.g., BGP). However, all routers within domains 342 that carry transit traffic (e.g., domains formed by Internet Service 343 Providers) have to maintain information provided by not just interior 344 routing, but exterior routing as well. That creates certain problems. 345 First of all, the amount of this information is not insignificant. 346 Thus it places additional demand on the resources required by the 347 routers. Moreover, increase in the volume of routing information 348 quite often increases routing convergence time. This, in turn, 349 degrades the overall performance of the system. 351 Tag switching allows the decoupling of interior and exterior routing, 352 so that only tag switches at the border of a domain would be required 353 to maintain routing information provided by exterior routing, while 354 all other switches within the domain would just maintain routing 355 information provided by the domain's interior routing (which is 356 usually significantly smaller than the exterior routing information). 357 This, in turn, reduces the routing load on non-border switches, and 358 shortens routing convergence time. 360 To support this functionality, tag switching allows a packet to carry 361 not one but a set of tags, organized as a stack. A tag switch could 362 either swap the tag at the top of the stack, or pop the stack, or 363 swap the tag and push one or more tags into the stack. 365 When a packet is forwarded between two (border) tag switches in 366 different domains, the tag stack in the packet contains just one tag. 367 However, when a packet is forwarded within a domain, the tag stack in 368 the packet contains not one, but two tags (the second tag is pushed 369 by the domain's ingress border tag switch). The tag at the top of 370 the stack provides packet forwarding to an appropriate egress border 371 tag switch, while the next tag in the stack provides correct packet 372 forwarding at the egress switch. The stack is popped by either the 373 egress switch or by the penultimate (with respect to the egress 374 switch) switch. 376 The control component used in this scenario is fairly similar to the 377 one used with destination-based routing. In fact, the only essential 378 difference is that in this scenario the tag binding information is 379 distributed both among physically adjacent tag switches, and among 380 border tag switches within a single domain. One could also observe 381 that the latter (distribution among border switches) could be 382 trivially accommodated by very minor extensions to BGP (via a 383 separate Tag Binding BGP attribute). 385 4.3. Multicast 387 Essential to multicast routing is the notion of spanning trees. 388 Multicast routing procedures (e.g., PIM) are responsible for 389 constructing such trees (with receivers as leafs), while multicast 390 forwarding is responsible for forwarding multicast packets along such 391 trees. 393 To support a multicast forwarding function with tag switching, each 394 tag switch associates a tag with a multicast tree as follows. When a 395 tag switch creates a multicast forwarding entry (either for a shared 396 or for a source-specific tree), and the list of outgoing interfaces 397 for the entry, the switch also creates local tags (one per outgoing 398 interface). The switch creates an entry in its TIB and populates 399 (outgoing tag, outgoing interface, outgoing MAC header) with this 400 information for each outgoing interface, placing a locally generated 401 tag in the outgoing tag field. This creates a binding between a 402 multicast tree and the tags. The switch then advertises over each 403 outgoing interface associated with the entry the binding between the 404 tag (associated with this interface) and the tree. 406 When a tag switch receives a binding between a multicast tree and a 407 tag from another tag switch, if the other switch is the upstream 408 neighbor (with respect to the multicast tree), the local switch 409 places the tag carried in the binding into the incoming tag component 410 of the TIB entry associated with the tree. 412 When a set of tag switches are interconnected via a multiple-access 413 subnetwork, the tag allocation procedure for multicast has to be 414 coordinated among the switches. In all other cases tag allocation 415 procedure for multicast could be the same as for tags used with 416 destination-based routing. 418 4.4. Flexible routing (explicit routes) 420 One of the fundamental properties of destination-based routing is 421 that the only information from a packet that is used to forward the 422 packet is the destination address. While this property enables highly 423 scalable routing, it also limits the ability to influence the actual 424 paths taken by packets. This, in turn, limits the ability to evenly 425 distribute traffic among multiple links, taking the load off highly 426 utilized links, and shifting it towards less utilized links. For 427 Internet Service Providers (ISPs) who support different classes of 428 service, destination-based routing also limits their ability to 429 segregate different classes with respect to the links used by these 430 classes. Some of the ISPs today use Frame Relay or ATM to overcome 431 the limitations imposed by destination-based routing. Tag switching, 432 because of the flexible granularity of tags, is able to overcome 433 these limitations without using either Frame Relay or ATM. 435 To provide forwarding along the paths that are different from the 436 paths determined by the destination-based routing, the control 437 component of tag switching allows installation of tag bindings in tag 438 switches that do not correspond to the destination-based routing 439 paths. 441 5. Tag switching with ATM 443 Since the tag switching forwarding paradigm is based on label 444 swapping, and since ATM forwarding is also based on label swapping, 445 tag switching technology can readily be applied to ATM switches by 446 implementing the control component of tag switching. 448 The tag information needed for tag switching can be carried in the 449 VCI field. If two levels of tagging are needed, then the VPI field 450 could be used as well, although the size of the VPI field limits the 451 size of networks in which this would be practical. However, for most 452 applications of one level of tagging the VCI field is adequate. 454 To obtain the necessary control information, the switch should be 455 able (at a minimum) to participate as a peer in Network Layer routing 456 protocols (e.g., OSPF, BGP). Moreover, if the switch has to perform 457 routing information aggregation, then to support destination-based 458 unicast routing the switch should be able to perform Network Layer 459 forwarding for some fraction of the traffic as well. 461 Supporting the destination-based routing function with tag switching 462 on an ATM switch may require the switch to maintain not one, but 463 several tags associated with a route (or a group of routes with the 464 same next hop). This is necessary to avoid the interleaving of 465 packets which arrive from different upstream tag switches, but are 466 sent concurrently to the same next hop. Either the downstream tag 467 allocation on demand or the upstream tag allocation scheme could be 468 used for the tag allocation and TIB maintenance procedures with ATM 469 switches. 471 Therefore, an ATM switch can support tag switching, but at the 472 minimum it needs to implement Network Layer routing protocols, and 473 the tag switching control component on the switch. It may also need 474 to support some network layer forwarding. 476 Implementing tag switching on an ATM switch would simplify 477 integration of ATM switches and routers - an ATM switch capable of 478 tag switching would appear as a router to an adjacent router. That 479 could provide a viable, more scalable alternative to the overlay 480 model. It also removes the necessity for ATM addressing, routing and 481 signalling schemes. Because the destination-based forwarding approach 482 described in section 4.1 is topology driven rather than traffic 483 driven, application of this approach to ATM switches does not high 484 call setup rates, nor does it depend on the longevity of flows. 486 Implementing tag switching on an ATM switch does not preclude the 487 ability to support a traditional ATM control plane (e.g., PNNI) on 488 the same switch. The two components, tag switching and the ATM 489 control plane, would operate in a Ships In the Night mode (with 490 VPI/VCI space and other resources partitioned so that the components 491 do not interact). 493 6. Quality of service 495 Two mechanisms are needed for providing a range of qualities of 496 service to packets passing through a router or a tag switch. First, 497 we need to classify packets into different classes. Second, we need 498 to ensure that the handling of packets is such that the appropriate 499 QOS characteristics (bandwidth, loss, etc.) are provided to each 500 class. 502 Tag switching provides an easy way to mark packets as belonging to a 503 particular class after they have been classified the first time. 504 Initial classification would be done using information carried in the 505 network layer or higher layer headers. A tag corresponding to the 506 resultant class would then be applied to the packet. Tagged packets 507 can then be efficiently handled by the tag switching routers in their 508 path without needing to be reclassified. The actual packet scheduling 509 and queueing is largely orthogonal - the key point here is that tag 510 switching enables simple logic to be used to find the state that 511 identifies how the packet should be scheduled. 513 The exact use of tag switching for QOS purposes depends a great deal 514 on how QOS is deployed. If RSVP is used to request a certain QOS for 515 a class of packets, then it would be necessary to allocate a tag 516 corresponding to each RSVP session for which state is installed at a 517 tag switch. This might be done by TDP or by extension of RSVP. 519 7. Tag switching migration strategies 521 Since tag switching is performed between a pair of adjacent tag 522 switches, and since the tag binding information could be distributed 523 on a pairwise basis, tag switching could be introduced in a fairly 524 simple, incremental fashion. For example, once a pair of adjacent 525 routers are converted into tag switches, each of the switches would 526 tag packets destined to the other, thus enabling the other switch to 527 use tag switching. Since tag switches use the same routing protocols 528 as routers, the introduction of tag switches has no impact on 529 routers. In fact, a tag switch connected to a router acts just as a 530 router from the router's perspective. 532 As more and more routers are upgraded to enable tag switching, the 533 scope of functionality provided by tag switching widens. For example, 534 once all the routers within a domain are upgraded to support tag 535 switching, in becomes possible to start using the hierarchy of 536 routing knowledge function. 538 8. Summary 540 In this document we described the tag switching technology. Tag 541 switching is not constrained to a particular Network Layer protocol - 542 it is a multiprotocol solution. The forwarding component of tag 543 switching is simple enough to facilitate high performance forwarding, 544 and may be implemented on high performance forwarding hardware such 545 as ATM switches. The control component is flexible enough to support 546 a wide variety of routing functions, such as destination-based 547 routing, multicast routing, hierarchy of routing knowledge, and 548 explicitly defined routes. By allowing a wide range of forwarding 549 granularities that could be associated with a tag, we provide both 550 scalable and functionally rich routing. A combination of a wide range 551 of forwarding granularities and the ability to evolve the control 552 component fairly independently from the forwarding component results 553 in a solution that enables graceful introduction of new routing 554 functionality to meet the demands of a rapidly evolving computer 555 networking environment. 557 9. Security Considerations 559 Security considerations are not addressed in this document. 561 10. Intellectual Property Considerations 563 Cisco Systems may seek patent or other intellectual property 564 protection for some or all of the technologies disclosed in this 565 document. If any standards arising from this document are or become 566 protected by one or more patents assigned to Cisco Systems, Cisco 567 intends to disclose those patents and license them on reasonable and 568 non-discriminatory terms. 570 11. Acknowledgments 572 Significant contributions to this work have been made by Anthony 573 Alles, Fred Baker, Paul Doolan, Dino Farinacci, Guy Fedorkow, Jeremy 574 Lawrence, Arthur Lin, Morgan Littlewood, Keith McCloghrie, and Dan 575 Tappan. 577 12. Authors' Addresses 579 Yakov Rekhter 580 Cisco Systems, Inc. 581 170 Tasman Drive 582 San Jose, CA, 95134 584 E-mail: yakov@cisco.com 586 Bruce Davie 587 Cisco Systems, Inc. 588 250 Apollo Drive 589 Chelmsford, MA, 01824 591 E-mail: bsd@cisco.com 593 Dave Katz 594 Cisco Systems, Inc. 595 170 Tasman Drive 596 San Jose, CA, 95134 598 E-mail: dkatz@cisco.com 600 Eric Rosen 601 Cisco Systems, Inc. 602 250 Apollo Drive 603 Chelmsford, MA, 01824 605 E-mail: erosen@cisco.com 607 George Swallow 608 Cisco Systems, Inc. 609 250 Apollo Drive 610 Chelmsford, MA, 01824 612 E-mail: swallow@cisco.com