idnits 2.17.1 draft-li-paste-00.txt: ** The Abstract section seems to be numbered 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 6 months document validity. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 756 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 1998) is 9598 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) -- Looks like a reference, but probably isn't: 'RFC2205' on line 276 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-00 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-00 -- No information found for draft-davie-mpls-rsvp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Li 2 INTERNET DRAFT Juniper Networks 3 Yakov Rekhter 4 Cisco Systems 5 January 1998 7 Provider Architecture for Differentiated Services and Traffic Engineering 8 (PASTE) 10 12 Status 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet Drafts as reference material or to cite 22 them other than as a "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 1.0 Abstract 32 This document describes the Provider Architecture for Differentiated 33 Services and Traffic Engineering (PASTE) for Internet Service 34 Providers (ISPs). Providing differentiated services in ISPs is a 35 challenge because the scaling problems presented by the sheer number 36 of flows present in large ISPs makes the cost of maintaining per-flow 37 state unacceptable. Coupled with this, large ISPs need the ability 38 to perform traffic engineering by directing aggregated flows of 39 traffic along specific paths. 41 PASTE addresses these issues by using Multiprotocol Label Switching 42 (MPLS) [1] and the Resource Reservation Protocol (RSVP) [2] to create 43 a scalable traffic management architecture that supports 44 differentiated services. This document assumes that the reader has 45 at least some familiarity with both of these technologies. 47 2.0 Terminology 49 In common usage, a packet flow, or a flow, refers to a unidirectional 50 stream of packets, distributed over time. Typically a flow has very 51 fine granularity and reflects a single interchange between hosts, 52 such as a TCP connection. An aggregated flow is a number of flows 53 that share forwarding state and a single resource reservation along a 54 sequence of routers. 56 One mechanism for supporting aggregated flows is Multiprotocol Label 57 Switching (MPLS). In MPLS, packets are tunneled by wrapping them in 58 a minimal header [3]. Each such header contains a label, that 59 carries both forwarding and resource reservation semantics. MPLS 60 defines mechanisms to install label-based forwarding information 61 along a series of Label Switching Routers (LSRs) to construct a Label 62 Switched Path (LSP). LSPs can also be associated with resource 63 reservation information. 65 One protocol for constructing such LSPs is the Resource Reservation 66 Protocol (RSVP) [4]. When used with the Explicit Route Object (ERO) 67 [5], RSVP can be used to construct an LSP along an explicit route 68 [6]. 70 To support differentiated services, packets are divided into separate 71 traffic classes. For conceptual purposes, we will discuss three 72 different traffic classes: Best Effort, Priority, and Network 73 Control. The exact number of subdivisions within each class is to be 74 defined. 76 Network Control traffic primarily consists of routing protocols and 77 network management traffic. If Network Control traffic is dropped, 78 routing protocols can fail or flap, resulting in network instability. 79 Thus, Network Control must have very low drop preference. However, 80 Network Control traffic is generally insensitive to moderate delays 81 and requires a relatively small amount of bandwidth. A small 82 bandwidth guarantee is sufficient to insure that Network Control 83 traffic operates correctly. 85 Priority traffic is likely to come in many flavors, depending on the 86 application. Particular flows may require bandwidth guarantees, 87 jitter guarantees, or upper bounds on delay. For the purposes of 88 this memo, we will not distinguish the subdivisions of priority 89 traffic. All priority traffic is assumed to have an explicit 90 resource reservation. 92 Currently, the vast majority of traffic in ISPs is Best Effort 93 traffic. This traffic is, for the most part, delay insensitive and 94 reasonably adaptive to congestion. 96 When flows are aggregated according to their traffic class and then 97 the aggregated flow is placed inside a LSP, we call the result a 98 traffic trunk, or simply a trunk. The traffic class of a packet is 99 orthogonal to the LSP that it is on, so many different trunks, each 100 with its own traffic class, may share an LSP if they have different 101 traffic classes. 103 3.0 Introduction 105 The next generation of the Internet presents special challenges that 106 must be addressed by a single, coordinated architecture. While this 107 architecture allows for distinction between ISPs, it also defines a 108 framework within which ISPs may provide end-to-end differentiated 109 services in a coordinated and reliable fashion. With such an 110 architecture, ISP would be able to craft common agreements for the 111 handling of differentiated services in a consistent fashion, 112 facilitating end-to-end differentiated services via a composition of 113 these agreements. Thus, the goal of this document is to describe an 114 architecture for providing differentiated services within the ISPs of 115 the Internet, while including support for other forthcoming needs 116 such as traffic engineering. While this document addresses the needs 117 of the ISPs, its applicability is not limited to the ISPs. The same 118 architecture could be used in any large, multiprovider catenet 119 needing distributed services. 121 This document only discusses unicast services. Extensions to the 122 architecture to support multicast is a subject for future research. 124 One of the primary considerations in any ISP architecture is 125 scalability. Solutions that have state growth proportional to the 126 size of the Internet result in growth rates exceeding Moore's law, 127 making such solutions intractable in the long term. Thus, solutions 128 that use mechanisms with very limited growth rates are strongly 129 preferred. 131 Discussions of differentiated services to date have frequently 132 resulted in solutions that require per-flow state or per-flow 133 queuing. As the number of flows in an ISP within the "default-free 134 zone of the Internet" scales with the size of the Internet, the 135 growth rate is difficult to support and argues strongly for a 136 solution with lower state requirements. Simultaneously, supporting 137 differentiated services is a significant benefit to most ISPs. Such 138 support would allow providers to offer special services such as 139 guaranteed bandwidth for mission critical services for users willing 140 to pay a service premium. 142 Another important consideration in this architecture is the advent of 143 traffic engineering within ISPs. Traffic engineering is the ability 144 to move flows or trunks away from the path selected by the ISP's IGP 145 and onto a different path. This allows an ISP to route traffic 146 around known points of congestion in its network thereby making more 147 efficient use of the available bandwidth. In turn, this makes the 148 ISP more competitive within its market and also allows it to pass 149 lower costs and better service on to its customers. 151 Finally, the need to provide end-to-end differentiated services 152 implies that the architecture must support consistent inter-provider 153 differentiated services. Most flows in the Internet today traverse 154 multiple ISPs [?], making a consistent description and treatment of 155 priority flows across ISPs a necessity. 157 4.0 Components of the Architecture 159 The Differentiated Services Backbone architecture is the integration 160 of several different mechanisms that, when used in a coordinated way, 161 achieve the goals outlined above. This section describes each of the 162 mechanisms used in some detail. Subsequent sections will then go 163 into the interoperation of these mechanisms. 165 4.1 Traffic classes 167 As described above, packets may fall into a variety of different 168 traffic classes. For ISP operations, it is essential that packets be 169 accurately classified before entering the ISP and that it is very 170 easy for an ISP device to determine the traffic class for a 171 particular packet. 173 The traffic class of MPLS packets can be encoded in the three bits 174 reserved for CoS within the MPLS label header. In addition, traffic 175 classes for IPv4 packets can be classified via the IPv4 ToS byte, 176 possibly within the three precedence bits within that byte. Note 177 that the consistent interpretation of the traffic class, regardless 178 of the bits used to indicate this class, is an important feature of 179 PASTE. 181 In this architecture it is not overly important to control which 182 packets entering the ISP have a particular traffic class. From the 183 ISP's perspective, each Priority packet should involve some economic 184 premium for delivery. As a result the ISP need not pass judgment as 185 to the appropriateness of the traffic class for the application. 187 It is important that any Network Control traffic entering an ISP be 188 handled carefully. The contents of such traffic must also be 189 carefully authenticated. Currently, there is no need for traffic 190 generated external to a domain to transit a border router of the ISP 192 4.2 Trunks 194 One of the primary tools is the use of MPLS and RSVP to create LSPs 195 within and across an ISP's topology. As described above, traffic of 196 a single traffic class that is aggregated into a single LSP is called 197 a traffic trunk, or simply a trunk. Trunks are essential to the 198 architecture because they allow the overhead in the infrastructure to 199 be decoupled from the size of the network and the amount of traffic 200 in the network. Instead, as the traffic scales up, the amount of 201 traffic in the trunks increases; not the number of trunks. 203 The number of trunks within a given topology has a worst case of one 204 trunk per traffic class from each entry router to each exit router. 205 If there are N routers in the topology and C classes of service, this 206 would be (N * (N-1) * C) / 2 trunks. Fortunately, instantiating this 207 many trunks is not always necessary. 209 Trunks with a single exit point which share a common internal path 210 can be merged to form a single sink tree. The computation necessary 211 to determine if two trunks can be merged is straightforward. If, 212 when a trunk is being established, it intersects an existing trunk 213 with the same traffic class and the same remaining explicit route, 214 the new trunk can be spliced into the existing trunk at the point of 215 intersection. The splice itself is straightforward: both incoming 216 trunks will perform a standard label switching operation, but will 217 result in the same outbound label. Since each sink tree created this 218 way touches each router at most once and there is one sink tree per 219 exit router, the result is N * C sink trees. 221 The number of trunks or sink trees can also be reduced if multiple 222 trunks or sink trees for different classes follow the same path. 223 This works because the QoS of a trunk or sink tree is orthogonal to 224 the path defined by its LSP. Thus, two trunks with different traffic 225 classes can share a label for any part of the topology that is shared 226 and ends in the exit router. Thus, the entire topology can be 227 overlaid with N trunks. 229 Further, if Best Effort trunks and individual Best Effort flows are 230 treated identically, there is no need to instantiate any Best Effort 231 trunk that would follow the IGP computed path. This is because the 232 packets can be directly forwarded without an LSP. However, traffic 233 engineering may require Best Efforts trunks to be treated differently 234 from the individual Best Effort flows, thus requiring the 235 instantiatiation of LSPs for Best Effort trunks. Note that Priority 236 trunks must be instantiated because end-to-end RSVP packets to 237 support the aggregated Priority flows must be tunneled. 239 Trunks can also be aggregated with other trunks by adding a new label 240 to the stack of labels for each trunk, effectively bundling the 241 trunks into a single tunnel. For the purposes of this document, this 242 is also considered a trunk, or if we need to be specific, this will 243 be called an aggregated trunk. Two trunks can be aggregated if they 244 share a portion of their path. There is no requirement on the exact 245 length of the common portion of the path, and thus the exact 246 requirements for forming an aggregated trunk are beyond the scope of 247 this document. Note that traffic class (i.e., QoS indication) is 248 propagated when an additional label is added to a trunk, so trunks of 249 different classes may be aggregated. 251 Trunks can be terminated at any point, resulting in a deaggregation 252 of traffic. The obvious consequence is that there needs to be 253 sufficient switching capacity at the point of deaggregation to deal 254 with the resultant traffic. 256 High reliability for a trunk can be provided through the use of one 257 or more backup trunks. Backup trunks can be initiated either by the 258 same router that would initiate the primary trunk or by another 259 backup router. The status of the primary trunk can be ascertained by 260 the router that initiated the backup trunk (note that this may be 261 either the same or a different router as the router that initiated 262 the primary trunk) through out of band information, such as the IGP. 263 If a backup trunk is established and the primary router returns to 264 service, the backup trunk can be eliminated and the primary trunk 265 used instead. 267 4.3 RSVP 269 Originally RSVP was designed as a protocol to install state 270 associated with resource reservations for individual flows 271 originated/destined to hosts, where path was determined by 272 destination-based routing. Quoting directly from the RSVP 273 specifications, "The RSVP protocol is used by a host, or behalf of an 274 application data stream, to request a specific quality of service 275 (QoS) from the network for particular data streams or flows" 276 [RFC2205]. 278 The usage of RSVP in PASTE is quite different from the usage of RSVP 279 as it was originally envisioned by its designers. The first 280 difference is that RSVP is used in PASTE to install state that 281 applies to a collection of flows that all share a common path and 282 common pool of reserved resources. The second difference is that 283 RSVP is used in PASTE to install state related to forwarding, 284 including label switching information, in addition to resource 285 reservations. The third difference is that the path that this state 286 is installed along is no longer constrained by the destination-based 287 routing. 289 The key factor that makes RSVP suitable for the PASTE is the set of 290 mechanisms provided by RSVP. Quoting from the RSVP specifications, 291 "RSVP protocol mechanisms provide a general facility for creating and 292 maintaining distributed reservation state across a mesh of multicast 293 or unicast delivery paths." Moreover, RSVP provides a straightforward 294 extensibility mechanism by allowing for the creation of new RSVP 295 Objects. This flexibility allows us to also use the mechanisms 296 provided by RSVP to create and maintain distributed state for 297 information other than pure resource reservation, as well as allowing 298 the creation of forwarding state in conjunction with resource 299 reservation state. 301 The original RSVP design, where "RSVP itself transfers and 302 manipulates QoS control parameters as opaque data, passing them to 303 the appropriate traffic control modules for interpretation" can thus 304 be extended to include explicit route parameters and label binding 305 parameters. Just as with QoS parameters, RSVP can transfer and 306 manipulate explicit route parameters and label binding parameters as 307 opaque data, passing explicit route parameters to the appropriate 308 forwarding module, and label parameters to the appropriate MPLS 309 module. 311 Moreover, an RSVP session in PASTE is not constrained to be only 312 between a pair of hosts, but is also used between pairs of routers 313 that act as the originator and the terminator of a traffic trunk. 315 Using RSVP in PASTE helps consolidate procedures for several tasks: 316 (a) procedures for establishing forwarding along an explicit route, 317 (b) procedures for establishing a label switched path, and (c) RSVP's 318 existing procedures for resource reservation. In addition, these 319 functions can be cleanly combined in any manner. The main advantage 320 of this consolidation comes from an observation that the above three 321 tasks are not independent, but inter-related. Any alternative that 322 accomplished each of these functions via independent sets of 323 procedures, would require additional coordination between functions 324 that would in turn add more complexity to the system. 326 4.4 Traffic Engineering 328 The purpose of traffic engineering is to give the ISP precise control 329 over the flow of traffic within its network. Traffic engineering is 330 necessary because standard IGPs compute the shortest path across the 331 ISP's network based solely on the metric that has been 332 administratively assigned to each link. This computation does not 333 take into account the loading of each link. If the ISP's network is 334 not a full mesh of physical links, the result is that there may not 335 be an obvious way to assign metrics to the existing links such that 336 no congestion will occur given known traffic patterns. Traffic 337 engineering can be viewed as assistance to the routing infrastructure 338 that provides additional information in routing traffic along 339 specific paths, with the end goal of more efficient utilization of 340 networking resources. 342 Traffic engineering is performed by directing trunks along explicit 343 paths within the ISP's topology. This diverts the traffic away from 344 the shortest path computed by the IGP and presumably onto uncongested 345 links, eventually arriving at the same destination. Specification of 346 the explicit route is done by enumerating an explicit list of the 347 routers in the path. Given this list, traffic engineering trunks can 348 be constructed in a variety of ways. For example, a trunk could be 349 manually configured along the explicit path. This would involve 350 configuring each router along the path with state information for 351 forwarding the particular label. Such techniques are currently used 352 for traffic engineering in some ISPs today. 354 Alternately, a protocol such as RSVP can be used with an Explicit 355 Route Object (ERO) so that the first router in the path can establish 356 the trunk. The computation of the explicit route is beyond the scope 357 of this document but may include considerations of policy, static and 358 dynamic bandwidth allocation, congestion in the topology and manually 359 configured alternatives. 361 4.5 Resource reservation 363 Priority traffic has certain requirements on capacity and traffic 364 handling. To provide differentiated services, the ISP's 365 infrastructure must know of, and support these requirements. The 366 mechanism used to communicate these requirements dynamically is RSVP. 367 The flow specification within RSVP can describe many characteristics 368 of the flow or trunk. An LSR receiving RSVP information about a flow 369 or trunk has the ability to look at this information and either 370 accept or reject the reservation based on its local policy. This 371 policy is likely to include constraints about the traffic handling 372 functions that can be supported by the network and the aggregate 373 capacity that the network is willing to provide for Priority traffic. 375 4.6 Bilateral ISP agreements 377 Such reservations are likely to be based on legal agreements and some 378 other external consideration. As a result, one of the common 379 functions that we would expect to see in this type of architecture is 380 a bilateral agreement between ISPs to support differentiated 381 services. In addition to the obvious compensation, this agreement is 382 likely to spell out the acceptable traffic handling policies and 383 capacities to be used by both parties. 385 Documents similar to this exist today on behalf of Best Effort 386 traffic and are known as peering agreements. Extending this for 387 differentiated services presents a challenge in the definition of the 388 differentiated service but does not represent a business practice 389 unlike those in use today. 391 4.7 Traffic shaping and policing 393 To help support such agreements special facilities must be available 394 at the interconnect between ISPs. These mechanisms are necessary to 395 insure that the network transmitting a trunk of Priority traffic does 396 so within the agreed traffic characterization and capacity. A 397 simplistic example of such a mechanism might be a token bucket 398 system, implemented on a per-trunk basis. Similarly, there need to 399 be mechanisms to insure, on a per trunk basis, that an ISP receiving 400 a trunk receives only the traffic that is in compliance with the 401 agreement between ISPs. 403 4.8 Multilateral ISP agreements 405 Trunks may span multiple ISPs. As a result, establishing a 406 particular trunk may require more than two ISPs. The result would be 407 a multilateral agreement. This type of agreement is unusual with 408 respect to existing Internet business practices in that it requires 409 many parties to make it work. 411 Because this new type of agreement may be a difficulty, it may in 412 some cases be simpler for certain ISPs to establish aggregated trunks 413 through other ISPs and then contract with customers to aggregate 414 their trunks. In this way, trunks can span multiple ISPs without 415 requiring multilateral ISP agreements. 417 Either of these two alternatives is possible and acceptable within 418 this architecture, and the choice is left for the the participants to 419 make on a case-by-case basis. 421 5.0 The Provider Architecture for differentiated Services and Traffic 422 Engineering (PASTE) 424 The Provider Architecture for differentiated Services and Traffic 425 Engineering (PASTE) is based on the usage of MPLS and RSVP as 426 mechanisms to establish differentiated service connections across 427 ISPs. This is done in a scalable way by aggregating differentiated 428 flows into traffic class specific MPLS tunnels, also known as traffic 429 trunks. 431 Such trunks can be given an explicit route by an ISP to define the 432 placement of the trunk within the ISP's infrastructure, allowing the 433 ISP to traffic engineer its own network. Trunks can also be 434 aggregated and merged, which helps the scalability of the 435 architecture by minimizing the number of individual trunks that 436 intermediate systems must support. 438 Special traffic handling operations, such as specific queuing 439 algorithms or drop computations, can be supported by a network on a 440 per-trunk basis, allowing these services to scale with the number of 441 trunks in the network. 443 Agreements for handling of trunks between ISPs require both legal 444 documentation and conformance mechanisms on both sides of the 445 agreement. As a trunk is unidirectional, it is sufficient for the 446 transmitter to monitor and shape outbound traffic, while the receiver 447 polices the traffic profile. 449 Trunks can either be aggregated across other ISPs or can be the 450 subject of a multilateral agreement for the carriage of the trunk. 451 RSVP information about individual flows is tunneled in the trunk to 452 provide an end-to-end reservation. To insure that the return RSVP 453 traffic is handled properly, each trunk must also have another tunnel 454 running in the opposite direction. Note that the reverse tunnel may 455 be a different trunk or it may be an independent tunnel terminating 456 at the same routers as the trunk. Routing symmetry between a trunk 457 and its return is not assumed. 459 RSVP already contains the ability to do local path repair. In the 460 event of a trunk failure, this capability, along with the ability to 461 specify abstractions in the ERO, allows RSVP to re-establish the 462 trunk in many failure scenarios. 464 6.0 Traffic flow in the PASTE architecture 466 As an example of the operation of this architecture, we consider an 467 example of a single differentiated flow. Suppose that a user wishes 468 to make a telephone call using a Voice over IP service. While this 469 call is full duplex, we can consider the data flow in each direction 470 in a half duplex fashion because the architecture operates 471 symmetrically. 473 Suppose that the data packets for this voice call are created at a 474 node S and need to traverse to node D. Because this is a voice call, 475 the data packets are encoded as Priority packets. If there is more 476 granularity within the traffic classes, these packets might be 477 encoded as wanting low jitter and having low drop preference. 478 Initially this is encoded into the precedence bits of the IPv4 ToS 479 byte. 481 6.1 Propagation of RSVP messages 483 To establish the flow to node D, node S first generates an RSVP PATH 484 message which describes the flow in more detail. For example, the 485 flow might require 3kbps of bandwidth, be insensitive to jitter of 486 less than 50ms, and require a delay of less than 200ms. This message 487 is passed thru node S's local network and eventually appears in node 488 S's ISP. Suppose that this is ISP F. 490 ISP F has considerable latitude in its options at this point. The 491 requirement on F is to place the flow into a trunk before it exits 492 F's infrastructure. One thing that F might do is to perform the 493 admission control function at the first hop router. At this point, F 494 would determine if it had the capacity and capability of carrying the 495 flow across its own infrastructure to an exit router E. If the 496 admission control decision is negative, the first hop router can 497 inform node S using RSVP. Alternately, it can propagate the RSVP 498 PATH message along the path to exit router E. This is simply normal 499 operation of RSVP on a differentiated flow. 501 At exit router E, there is a trunk that ISP F maintains that transits 502 ISP X, Y, and Z and terminates in ISP L. Based on BGP path 503 information or on out of band information, Node D is known to be a 504 customer of ISP L. Exit router E matches the flow requirements in 505 the RSVP PATH message to the characteristics (e.g., remaining 506 capacity) of the trunk to ISP L. Assuming that the requirements are 507 compatible, it then notes that the flow should be aggregated into the 508 trunk. 510 To insure that the flow reservation happens end to end, the RSVP PATH 511 message is then encapsulated into the trunk itself, where it is 512 transmitted to ISP L. It eventually reaches the end of the trunk, 513 where it is decapsulated by router U. PATH messages are then 514 propagated all the way to the ultimate destination D. 516 Note that the end-to-end RSVP RESV messages must be carefully handled 517 by router U. The RESV messages from router U to E must return via a 518 tunnel back to router E. 520 RSVP is also used by exit router E to initialize and maintain the 521 trunk to ISP L. The RSVP messages for this trunk are not placed 522 within the trunk itself, however, the end-to-end RSVP messages are. 523 The existence of multiple overlapping RSVP sessions in PASTE is 524 straightforward, but requires explicit enumeration when discussing 525 particular RSVP sessions. 527 6.2 Propagation of user data 529 Data packets created by S flow through ISP F's network following the 530 flow reservation and eventually make it to router E. At that point, 531 they are given an MPLS label and placed in the trunk. Normal MPLS 532 switching will propagate this packet across ISP X's network. Note 533 that the same traffic class still applies because the class encoding 534 is propagated from the precedence bits of the IPv4 header to the CoS 535 bits in the MPLS label. As the packet exits ISP X's network, it can 536 be aggregated into another trunk for the express purpose of 537 tranisiting ISP Y. 539 Again, label switching is used to bring the packet across ISP Y's 540 network and then the aggregated trunk terminates at a router in ISP 541 Z's network. This router deaggregates the trunk, and forwards the 542 resulting trunk towards ISP L. This trunk transits ISP Z and 543 terminates in ISP L at router U. At this point, the data packets are 544 removed from the trunk and forwarded along the path computed by RSVP. 546 6.3 Trunk establishment and maintenance 548 In this example, there are two trunks in use. One trunk runs from 549 ISP F, thru ISP's X, Y and Z, and then terminates in ISP L. The 550 other aggregated trunk begins in ISP X, transits ISP Y and terminates 551 in ISP Z. 553 The first trunk may be established based on a multilateral agreement 554 between ISPs F, X, Z and L. Note that ISP Y is not part of this 555 multilateral agreement, and ISP X is contractually responsible for 556 providing carriage of the trunk into ISP Z. Also per this agreement, 557 the tunnel is maintained by ISP F and is initialized and maintained 558 thru the use of RSVP and an explicit route object that lists ISP's X, 559 Z, and L. Within this explicit route, ISP X and ISP L are given as 560 strict hops, thus constraining the path so that there may not be 561 other ISPs intervening between the pair of ISPs F and X and the pair 562 Z and L. However, no constraint is placed on the path between ISPs X 563 and Z. Further, there is no constraint placed on which router 564 terminates the trunk within L's infrastructure. 566 Normally this trunk is maintained by one of ISP F's routers adjacent 567 to ISP X. For robustness, ISP F has a second router adjacent to ISP 568 X, and that provides a backup trunk. 570 The second trunk may be established by a bilateral agreement between 571 ISP X and Y. ISP Z is not involved. The second trunk is constrained 572 so that it terminates on the last hop router within Y's 573 infrastructure. This tunnel is initialized and maintained thru the 574 use of RSVP and an explicit route that lists the last hop router 575 within ISP Y's infrastructure. In order to provide redundancy in the 576 case of the failure of the last hop router, there are multiple 577 explicit routes configured into ISP X's routers. These routers can 578 select one working explicit route from their configured list. 579 Further, in order to provide redundancy against the failure of X's 580 primary router, X provides a backup router with a backup trunk. 582 6.4 Robustness 584 Note that in this example, there are no single points of failure once 585 the traffic is within ISP F's network. Each trunk has a backup trunk 586 to protect against the failure of the primary trunk. To protect 587 against the failure of any particular router, each trunk can be 588 configured with multiple explicit route objects that terminate at one 589 of several acceptable routers. 591 7.0 Security considerations 593 Because Priority traffic intrinsically has more 'value' than Best 594 Effort traffic, the ability to inject Priority traffic into a network 595 must be carefully controlled. Further, signaling concerning Priority 596 traffic has to be authenticated because it is likely that the 597 signaling information will result in specific accounting and 598 eventually billing for the Priority services. ISPs are cautioned to 599 insure that the Priority traffic that they accept is in fact from a 600 know previous hop. Note that this is a simple requirement to fulfill 601 at private peerings, but is much more difficult at public 602 interconnects. For this reason, exchanging Priority traffic at 603 public interconnects should be done with great care. 605 RSVP traffic needs to be authenticated. This can possibly be done 606 thru the use of the Integrity Object. 608 8.0 Conclusion 610 The Provider Architecture for differentiated Services and Traffic 611 Engineering (PASTE) provides a robust, scalable means of deploying 612 differentiated services in the Internet. It provides scalability by 613 aggregating flows into class specific MPLS tunnels. These tunnels, 614 also called trunks, can in turn be aggregated, thus leading to a 615 hierarchical aggregation of traffic. 617 Trunk establishment and maintenance is done with RSVP, taking 618 advantage of existing work in differentiated services. Explicit 619 routes within the RSVP signaling structure allow providers to perform 620 traffic engineering by placing trunks on particular links in their 621 network. 623 The result is an architecture that is sufficient to scale to meet ISP 624 needs and can provide differentiated services in the large, support 625 traffic engineering, and continue to grow with the Internet. 627 8.1 Acknowledgments 629 Inspiration and comments about this document came from Noel Chiappa, 630 Der-Hwa Gan, Robert Elz, Lisa Bourgeault, and Paul Ferguson. 632 9.0 References 634 [1] "A Proposed Architecture for MPLS", E. Rosen, A. Viswanathan, R. 635 Callon, work in progress, draft-ietf-mpls-arch-00.txt, August 1997 637 [2] "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 638 Specification", R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. 639 Jamin, RFC 2205, September 1997 641 [3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, D. 642 Farinacci, G. Fedorkow, T. Li, A. Conta, work in progress, draft- 643 ietf-mpls-label-encaps-00.txt, November 1997 645 [4] "Use of Label Switching With RSVP", B. Davie, Y. Rekhter, E. 646 Rosen, A. Viswanathan, V. Srinivasan, work in progress, draft-davie- 647 mpls-rsvp-01.txt, November 1997 649 [5] "Setting up Reservations on Explicit Paths using RSVP, D.-H. Gan, 650 R. Guerin, S. Kamat, T. Li, E, Rosen, work in progress, draft- 651 guerin-expl-path-rsvp-01.txt, November 1997. 653 [6] "Explicit Route Support in MPLS", B. Davie, T. Li, E. Rosen, Y. 654 Rekhter, work in progress, draft-davie-mpls-explicit-routes-00.txt, 655 November 1997 657 10.0 Authors' Addresses 659 Tony Li 660 Juniper Networks, Inc. 661 385 Ravendale Dr. 662 Mountain View, CA 94043 663 Email: tli@juniper.net 664 Fax: +1 650 526 8001 665 Voice: +1 650 526 8006 667 Yakov Rekhter 668 cisco Systems, Inc. 669 170 W. Tasman Dr. 670 San Jose, CA 95134 671 Email: yakov@cisco.com