File: rfc2430.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 (899 lines) | stat: -rw-r--r-- 40,148 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
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899






Network Working Group                                              T. Li
Request for Comments: 2430                              Juniper Networks
Category: Informational                                       Y. Rekhter
                                                           Cisco Systems
                                                            October 1998


                      A Provider Architecture for
            Differentiated Services and Traffic Engineering
                                (PASTE)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

1.0 Abstract

   This document describes the Provider Architecture for Differentiated
   Services and Traffic Engineering (PASTE) for Internet Service
   Providers (ISPs).  Providing differentiated services in ISPs is a
   challenge because the scaling problems presented by the sheer number
   of flows present in large ISPs makes the cost of maintaining per-flow
   state unacceptable.  Coupled with this, large ISPs need the ability
   to perform traffic engineering by directing aggregated flows of
   traffic along specific paths.

   PASTE addresses these issues by using Multiprotocol Label Switching
   (MPLS) [1] and the Resource Reservation Protocol (RSVP) [2] to create
   a scalable traffic management architecture that supports
   differentiated services.  This document assumes that the reader has
   at least some familiarity with both of these technologies.

2.0 Terminology

   In common usage, a packet flow, or a flow, refers to a unidirectional
   stream of packets, distributed over time.  Typically a flow has very
   fine granularity and reflects a single interchange between hosts,
   such as a TCP connection.  An aggregated flow is a number of flows
   that share forwarding state and a single resource reservation along a
   sequence of routers.





Li & Rekhter                 Informational                      [Page 1]

RFC 2430                         PASTE                      October 1998


   One mechanism for supporting aggregated flows is Multiprotocol Label
   Switching (MPLS).  In MPLS, packets are tunneled by wrapping them in
   a minimal header [3].  Each such header contains a label, that
   carries both forwarding and resource reservation semantics.  MPLS
   defines mechanisms to install label-based forwarding information
   along a series of Label Switching Routers (LSRs) to construct a Label
   Switched Path (LSP).  LSPs can also be associated with resource
   reservation information.

   One protocol for constructing such LSPs is the Resource Reservation
   Protocol (RSVP) [4].  When used with the Explicit Route Object (ERO)
   [5], RSVP can be used to construct an LSP along an explicit route
   [6].

   To support differentiated services, packets are divided into separate
   traffic classes.  For conceptual purposes, we will discuss three
   different traffic classes: Best Effort, Priority, and Network
   Control.  The exact number of subdivisions within each class is to be
   defined.

   Network Control traffic primarily consists of routing protocols and
   network management traffic.  If Network Control traffic is dropped,
   routing protocols can fail or flap, resulting in network instability.
   Thus, Network Control must have very low drop preference.  However,
   Network Control traffic is generally insensitive to moderate delays
   and requires a relatively small amount of bandwidth.  A small
   bandwidth guarantee is sufficient to insure that Network Control
   traffic operates correctly.

   Priority traffic is likely to come in many flavors, depending on the
   application.  Particular flows may require bandwidth guarantees,
   jitter guarantees, or upper bounds on delay.  For the purposes of
   this memo, we will not distinguish the subdivisions of priority
   traffic.  All priority traffic is assumed to have an explicit
   resource reservation.

   Currently, the vast majority of traffic in ISPs is Best Effort
   traffic.  This traffic is, for the most part, delay insensitive and
   reasonably adaptive to congestion.

   When flows are aggregated according to their traffic class and then
   the aggregated flow is placed inside a LSP, we call the result a
   traffic trunk, or simply a trunk.  The traffic class of a packet is
   orthogonal to the LSP that it is on, so many different trunks, each
   with its own traffic class, may share an LSP if they have different
   traffic classes.





Li & Rekhter                 Informational                      [Page 2]

RFC 2430                         PASTE                      October 1998


3.0 Introduction

   The next generation of the Internet presents special challenges that
   must be addressed by a single, coordinated architecture.  While this
   architecture allows for distinction between ISPs, it also defines a
   framework within which ISPs may provide end-to-end differentiated
   services in a coordinated and reliable fashion.  With such an
   architecture, an ISP would be able to craft common agreements for the
   handling of differentiated services in a consistent fashion,
   facilitating end-to-end differentiated services via a composition of
   these agreements.  Thus, the goal of this document is to describe an
   architecture for providing differentiated services within the ISPs of
   the Internet, while including support for other forthcoming needs
   such as traffic engineering.  While this document addresses the needs
   of the ISPs, its applicability is not limited to the ISPs.  The same
   architecture could be used in any large, multiprovider catenet
   needing differentiated services.

   This document only discusses unicast services.  Extensions to the
   architecture to support multicast are a subject for future research.

   One of the primary considerations in any ISP architecture is
   scalability.  Solutions that have state growth proportional to the
   size of the Internet result in growth rates exceeding Moore's law,
   making such solutions intractable in the long term.  Thus, solutions
   that use mechanisms with very limited growth rates are strongly
   preferred.

   Discussions of differentiated services to date have frequently
   resulted in solutions that require per-flow state or per-flow
   queuing.  As the number of flows in an ISP within the "default-free
   zone of the Internet" scales with the size of the Internet, the
   growth rate is difficult to support and argues strongly for a
   solution with lower state requirements.  Simultaneously, supporting
   differentiated services is a significant benefit to most ISPs.  Such
   support would allow providers to offer special services such as
   priority for bandwidth for mission critical services for users
   willing to pay a service premium.  Customers would contract with ISPs
   for these services under Service Level Agreements (SLAs).  Such an
   agreement may specify the traffic volume, how the traffic is handled,
   either in an absolute or relative manner, and the compensation that
   the ISP receives.

   Differentiated services are likely to be deployed across a single ISP
   to support applications such as a single enterprise's Virtual Private
   Network (VPN).  However, this is only the first wave of service
   implementation.  Closely following this will be the need for
   differentiated services to support extranets, enterprise VPNs that



Li & Rekhter                 Informational                      [Page 3]

RFC 2430                         PASTE                      October 1998


   span ISPs, or industry interconnection networks such as the ANX [7].
   Because such applications span enterprises and thus span ISPs, there
   is a clear need for inter-domain SLAs.  This document discusses the
   technical architecture that would allow the creation of such inter-
   domain SLAs.

   Another important consideration in this architecture is the advent of
   traffic engineering within ISPs.  Traffic engineering is the ability
   to move trunks away from the path selected by the ISP's IGP and onto
   a different path.  This allows an ISP to route traffic around known
   points of congestion in its network, thereby making more efficient
   use of the available bandwidth.  In turn, this makes the ISP more
   competitive within its market by allowing the ISP to pass lower costs
   and better service on to its customers.

   Finally, the need to provide end-to-end differentiated services
   implies that the architecture must support consistent inter-provider
   differentiated services.  Most flows in the Internet today traverse
   multiple ISPs, making a consistent description and treatment of
   priority flows across ISPs a necessity.

4.0 Components of the Architecture

   The Differentiated Services Backbone architecture is the integration
   of several different mechanisms that, when used in a coordinated way,
   achieve the goals outlined above.  This section describes each of the
   mechanisms used in some detail.  Subsequent sections will then detail
   the interoperation of these mechanisms.

4.1 Traffic classes

   As described above, packets may fall into a variety of different
   traffic classes.  For ISP operations, it is essential that packets be
   accurately classified before entering the ISP and that it is very
   easy for an ISP device to determine the traffic class for a
   particular packet.

   The traffic class of MPLS packets can be encoded in the three bits
   reserved for CoS within the MPLS label header.  In addition, traffic
   classes for IPv4 packets can be classified via the IPv4 ToS byte,
   possibly within the three precedence bits within that byte.  Note
   that the consistent interpretation of the traffic class, regardless
   of the bits used to indicate this class, is an important feature of
   PASTE.







Li & Rekhter                 Informational                      [Page 4]

RFC 2430                         PASTE                      October 1998


   In this architecture it is not overly important to control which
   packets entering the ISP have a particular traffic class.  From the
   ISP's perspective, each Priority packet should involve some economic
   premium for delivery.  As a result the ISP need not pass judgment as
   to the appropriateness of the traffic class for the application.

   It is important that any Network Control traffic entering an ISP be
   handled carefully.  The contents of such traffic must also be
   carefully authenticated.  Currently, there is no need for traffic
   generated external to a domain to transit a border router of the ISP.

4.2 Trunks

   As described above, traffic of a single traffic class that is
   aggregated into a single LSP is called a traffic trunk, or simply a
   trunk.  Trunks are essential to the architecture because they allow
   the overhead in the infrastructure to be decoupled from the size of
   the network and the amount of traffic in the network.  Instead, as
   the traffic scales up, the amount of traffic in the trunks increases;
   not the number of trunks.

   The number of trunks within a given topology has a worst case of one
   trunk per traffic class from each entry router to each exit router.
   If there are N routers in the topology and C classes of service, this
   would be (N * (N-1) * C) trunks.  Fortunately, instantiating this
   many trunks is not always necessary.

   Trunks with a single exit point which share a common internal path
   can be merged to form a single sink tree.  The computation necessary
   to determine if two trunks can be merged is straightforward.  If,
   when a trunk is being established, it intersects an existing trunk
   with the same traffic class and the same remaining explicit route,
   the new trunk can be spliced into the existing trunk at the point of
   intersection.  The splice itself is straightforward: both incoming
   trunks will perform a standard label switching operation, but will
   result in the same outbound label.  Since each sink tree created this
   way touches each router at most once and there is one sink tree per
   exit router, the result is N * C sink trees.

   The number of trunks or sink trees can also be reduced if multiple
   trunks or sink trees for different classes follow the same path.
   This works because the traffic class of a trunk or sink tree is
   orthogonal to the path defined by its LSP.  Thus, two trunks with
   different traffic classes can share a label for any part of the
   topology that is shared and ends in the exit router.  Thus, the
   entire topology can be overlaid with N trunks.





Li & Rekhter                 Informational                      [Page 5]

RFC 2430                         PASTE                      October 1998


   Further, if Best Effort trunks and individual Best Effort flows are
   treated identically, there is no need to instantiate any Best Effort
   trunk that would follow the IGP computed path.  This is because the
   packets can be directly forwarded without an LSP. However, traffic
   engineering may require Best Effort trunks to be treated differently
   from the individual Best Effort flows, thus requiring the
   instantiation of LSPs for Best Effort trunks.  Note that Priority
   trunks must be instantiated because end-to-end RSVP packets to
   support the aggregated Priority flows must be tunneled.

   Trunks can also be aggregated with other trunks by adding a new label
   to the stack of labels for each trunk, effectively bundling the
   trunks into a single tunnel.  For the purposes of this document, this
   is also considered a trunk, or if we need to be specific, this will
   be called an aggregated trunk.  Two trunks can be aggregated if they
   share a portion of their path.  There is no requirement on the exact
   length of the common portion of the path, and thus the exact
   requirements for forming an aggregated trunk are beyond the scope of
   this document.  Note that traffic class (i.e., QoS indication) is
   propagated when an additional label is added to a trunk, so trunks of
   different classes may be aggregated.

   Trunks can be terminated at any point, resulting in a deaggregation
   of traffic.  The obvious consequence is that there needs to be
   sufficient switching capacity at the point of deaggregation to deal
   with the resultant traffic.

   High reliability for a trunk can be provided through the use of one
   or more backup trunks.  Backup trunks can be initiated either by the
   same router that would initiate the primary trunk or by another
   backup router.  The status of the primary trunk can be ascertained by
   the router that initiated the backup trunk (note that this may be
   either the same or a different router as the router that initiated
   the primary trunk) through out of band information, such as the IGP.
   If a backup trunk is established and the primary trunk returns to
   service, the backup trunk can be deactivated and the primary trunk
   used instead.

4.3 RSVP

   Originally RSVP was designed as a protocol to install state
   associated with resource reservations for individual flows
   originated/destined to hosts, where path was determined by
   destination-based routing. Quoting directly from the RSVP
   specifications, "The RSVP protocol is used by a host, on behalf of an
   application data stream, to request a specific quality of service
   (QoS) from the network for particular data streams or flows"
   [RFC2205].



Li & Rekhter                 Informational                      [Page 6]

RFC 2430                         PASTE                      October 1998


   The usage of RSVP in PASTE is quite different from the usage of RSVP
   as it was originally envisioned by its designers.  The first
   difference is that RSVP is used in PASTE to install state that
   applies to a collection of flows that all share a common path and
   common pool of reserved resources.  The second difference is that
   RSVP is used in PASTE to install state related to forwarding,
   including label switching information, in addition to resource
   reservations.  The third difference is that the path that this state
   is installed along is no longer constrained by the destination-based
   routing.

   The key factor that makes RSVP suitable for PASTE is the set of
   mechanisms provided by RSVP. Quoting from the RSVP specifications,
   "RSVP protocol mechanisms provide a general facility for creating and
   maintaining distributed reservation state across a mesh of multicast
   or unicast delivery paths." Moreover, RSVP provides a straightforward
   extensibility mechanism by allowing for the creation of new RSVP
   Objects. This flexibility allows us to also use the mechanisms
   provided by RSVP to create and maintain distributed state for
   information other than pure resource reservation, as well as allowing
   the creation of forwarding state in conjunction with resource
   reservation state.

   The original RSVP design, in which "RSVP itself transfers and
   manipulates QoS control parameters as opaque data, passing them to
   the appropriate traffic control modules for interpretation" can thus
   be extended to include explicit route parameters and label binding
   parameters. Just as with QoS parameters, RSVP can transfer and
   manipulate explicit route parameters and label binding parameters as
   opaque data, passing explicit route parameters to the appropriate
   forwarding module, and label parameters to the appropriate MPLS
   module.

   Moreover, an RSVP session in PASTE is not constrained to be only
   between a pair of hosts, but is also used between pairs of routers
   that act as the originator and the terminator of a traffic trunk.

   Using RSVP in PASTE helps consolidate procedures for several tasks:
   (a) procedures for establishing forwarding along an explicit route,
   (b) procedures for establishing a label switched path, and (c) RSVP's
   existing procedures for resource reservation.  In addition, these
   functions can be cleanly combined in any manner.  The main advantage
   of this consolidation comes from an observation that the above three
   tasks are not independent, but inter-related. Any alternative that
   accomplished each of these functions via independent sets of
   procedures, would require additional coordination between functions,
   adding more complexity to the system.




Li & Rekhter                 Informational                      [Page 7]

RFC 2430                         PASTE                      October 1998


4.4 Traffic Engineering

   The purpose of traffic engineering is to give the ISP precise control
   over the flow of traffic within its network.  Traffic engineering is
   necessary because standard IGPs compute the shortest path across the
   ISP's network based solely on the metric that has been
   administratively assigned to each link.  This computation does not
   take into account the loading of each link.  If the ISP's network is
   not a full mesh of physical links, the result is that there may not
   be an obvious way to assign metrics to the existing links such that
   no congestion will occur given known traffic patterns.  Traffic
   engineering can be viewed as assistance to the routing infrastructure
   that provides additional information in routing traffic along
   specific paths, with the end goal of more efficient utilization of
   networking resources.

   Traffic engineering is performed by directing trunks along explicit
   paths within the ISP's topology.  This diverts the traffic away from
   the shortest path computed by the IGP and presumably onto uncongested
   links, eventually arriving at the same destination.  Specification of
   the explicit route is done by enumerating an explicit list of the
   routers in the path.  Given this list, traffic engineering trunks can
   be constructed in a variety of ways.  For example, a trunk could be
   manually configured along the explicit path.  This would involve
   configuring each router along the path with state information for
   forwarding the particular label.  Such techniques are currently used
   for traffic engineering in some ISPs today.

   Alternately, a protocol such as RSVP can be used with an Explicit
   Route Object (ERO) so that the first router in the path can establish
   the trunk.  The computation of the explicit route is beyond the scope
   of this document but may include considerations of policy, static and
   dynamic bandwidth allocation, congestion in the topology and manually
   configured alternatives.

4.5 Resource reservation

   Priority traffic has certain requirements on capacity and traffic
   handling.  To provide differentiated services, the ISP's
   infrastructure must know of, and support these requirements.  The
   mechanism used to communicate these requirements dynamically is RSVP.
   The flow specification within RSVP can describe many characteristics
   of the flow or trunk.  An LSR receiving RSVP information about a flow
   or trunk has the ability to look at this information and either
   accept or reject the reservation based on its local policy.  This
   policy is likely to include constraints about the traffic handling
   functions that can be supported by the network and the aggregate
   capacity that the network is willing to provide for Priority traffic.



Li & Rekhter                 Informational                      [Page 8]

RFC 2430                         PASTE                      October 1998


4.6 Inter-Provider SLAs (IPSs)

   Trunks that span multiple ISPs are likely to be based on legal
   agreements and some other external considerations.  As a result, one
   of the common functions that we would expect to see in this type of
   architecture is a bilateral agreement between ISPs to support
   differentiated services.  In addition to the obvious compensation,
   this agreement is likely to spell out the acceptable traffic handling
   policies and capacities to be used by both parties.

   Documents similar to this exist today on behalf of Best Effort
   traffic and are known as peering agreements.  Extending a peering
   agreement to support differentiated services would effectively create
   an Inter-Provider SLA (IPS).  Such agreements may include the types
   of differentiated services that one ISP provides to the other ISP, as
   well as the upper bound on the amount of traffic associated with each
   such service that the ISP would be willing to accept and carry from
   the other ISP.  Further, an IPS may limit the types of differentiated
   services and an upper bound on the amount of traffic that may
   originate from a third party ISP and be passed from one signer of the
   IPS to the other.

   If the expected costs associated with the IPS are not symmetric, the
   parties may agree that one ISP will provide the other ISP with
   appropriate compensation.  Such costs may be due to inequality of
   traffic exchange, costs in delivering the exchanged traffic, or the
   overhead involved in supporting the protocols exchanged between the
   two ISPs.

   Note that the PASTE architecture provides a technical basis to
   establish IPSs, while the procedures necessary to create such IPSs
   are outside the scope of PASTE.

4.7 Traffic shaping and policing

   To help support IPSs, special facilities must be available at the
   interconnect between ISPs.  These mechanisms are necessary to insure
   that the network transmitting a trunk of Priority traffic does so
   within the agreed traffic characterization and capacity.  A
   simplistic example of such a mechanism might be a token bucket
   system, implemented on a per-trunk basis.  Similarly, there need to
   be mechanisms to insure, on a per trunk basis, that an ISP receiving
   a trunk receives only the traffic that is in compliance with the
   agreement between ISPs.







Li & Rekhter                 Informational                      [Page 9]

RFC 2430                         PASTE                      October 1998


4.8 Multilateral IPSs

   Trunks may span multiple ISPs.  As a result, establishing a
   particular trunk may require more than two ISPs.  The result would be
   a multilateral IPS.  This type of agreement is unusual with respect
   to existing Internet business practices in that it requires multiple
   participating parties for a useful result.  This is also challenging
   because without a commonly accepted service level definition, there
   will need to be a multilateral definition, and this definition may
   not be compatible used in IPSs between the same parties.

   Because this new type of agreement may be a difficulty, it may in
   some cases be simpler for certain ISPs to establish aggregated trunks
   through other ISPs and then contract with customers to aggregate
   their trunks.  In this way, trunks can span multiple ISPs without
   requiring multilateral IPSs.

   Either or both of these two alternatives are possible and acceptable
   within this architecture, and the choice is left for the the
   participants to make on a case-by-case basis.

5.0 The Provider Architecture for differentiated Services and Traffic
    Engineering (PASTE)

   The Provider Architecture for differentiated Services and Traffic
   Engineering (PASTE) is based on the usage of MPLS and RSVP as
   mechanisms to establish differentiated service connections across
   ISPs.  This is done in a scalable way by aggregating differentiated
   flows into traffic class specific MPLS tunnels, also known as traffic
   trunks.

   Such trunks can be given an explicit route by an ISP to define the
   placement of the trunk within the ISP's infrastructure, allowing the
   ISP to traffic engineer its own network.  Trunks can also be
   aggregated and merged, which helps the scalability of the
   architecture by minimizing the number of individual trunks that
   intermediate systems must support.

   Special traffic handling operations, such as specific queuing
   algorithms or drop computations, can be supported by a network on a
   per-trunk basis, allowing these services to scale with the number of
   trunks in the network.

   Agreements for handling of trunks between ISPs require both legal
   documentation and conformance mechanisms on both sides of the
   agreement.  As a trunk is unidirectional, it is sufficient for the
   transmitter to monitor and shape outbound traffic, while the receiver
   polices the traffic profile.



Li & Rekhter                 Informational                     [Page 10]

RFC 2430                         PASTE                      October 1998


   Trunks can either be aggregated across other ISPs or can be the
   subject of a multilateral agreement for the carriage of the trunk.
   RSVP information about individual flows is tunneled in the trunk to
   provide an end-to-end reservation.  To insure that the return RSVP
   traffic is handled properly, each trunk must also have another tunnel
   running in the opposite direction.  Note that the reverse tunnel may
   be a different trunk or it may be an independent tunnel terminating
   at the same routers as the trunk.  Routing symmetry between a trunk
   and its return is not assumed.

   RSVP already contains the ability to do local path repair.  In the
   event of a trunk failure, this capability, along with the ability to
   specify abstractions in the ERO, allows RSVP to re-establish the
   trunk in many failure scenarios.

6.0 Traffic flow in the PASTE architecture

   As an example of the operation of this architecture, we consider an
   example of a single differentiated flow.  Suppose that a user wishes
   to make a telephone call using a Voice over IP service.  While this
   call is full duplex, we can consider the data flow in each direction
   in a half duplex fashion because the architecture operates
   symmetrically.

   Suppose that the data packets for this voice call are created at a
   node S and need to traverse to node D.  Because this is a voice call,
   the data packets are encoded as Priority packets.  If there is more
   granularity within the traffic classes, these packets might be
   encoded as wanting low jitter and having low drop preference.
   Initially this is encoded into the precedence bits of the IPv4 ToS
   byte.

6.1 Propagation of RSVP messages

   To establish the flow to node D, node S first generates an RSVP PATH
   message which describes the flow in more detail.  For example, the
   flow might require 3kbps of bandwidth, be insensitive to jitter of
   less than 50ms, and require a delay of less than 200ms.  This message
   is passed through node S's local network and eventually appears in
   node S's ISP.  Suppose that this is ISP F.

   ISP F has considerable latitude in its options at this point.  The
   requirement on F is to place the flow into a trunk before it exits
   F's infrastructure.  One thing that F might do is to perform the
   admission control function at the first hop router.  At this point, F
   would determine if it had the capacity and capability of carrying the
   flow across its own infrastructure to an exit router E.  If the
   admission control decision is negative, the first hop router can



Li & Rekhter                 Informational                     [Page 11]

RFC 2430                         PASTE                      October 1998


   inform node S using RSVP.  Alternately, it can propagate the RSVP
   PATH message along the path to exit router E.  This is simply normal
   operation of RSVP on a differentiated flow.

   At exit router E, there is a trunk that ISP F maintains that transits
   ISP X, Y, and Z and terminates in ISP L.  Based on BGP path
   information or on out of band information, Node D is known to be a
   customer of ISP L.  Exit router E matches the flow requirements in
   the RSVP PATH message to the characteristics (e.g., remaining
   capacity) of the trunk to ISP L.  Assuming that the requirements are
   compatible, it then notes that the flow should be aggregated into the
   trunk.

   To insure that the flow reservation happens end to end, the RSVP PATH
   message is then encapsulated into the trunk itself, where it is
   transmitted to ISP L.  It eventually reaches the end of the trunk,
   where it is decapsulated by router U.  PATH messages are then
   propagated all the way to the ultimate destination D.

   Note that the end-to-end RSVP RESV messages must be carefully handled
   by router U.  The RESV messages from router U to E must return via a
   tunnel back to router E.

   RSVP is also used by exit router E to initialize and maintain the
   trunk to ISP L.  The RSVP messages for this trunk are not placed
   within the trunk itself but the end-to-end RSVP messages are.  The
   existence of multiple overlapping RSVP sessions in PASTE is
   straightforward, but requires explicit enumeration when discussing
   particular RSVP sessions.

6.2 Propagation of user data

   Data packets created by S flow through ISP F's network following the
   flow reservation and eventually make it to router E.  At that point,
   they are given an MPLS label and placed in the trunk.  Normal MPLS
   switching will propagate this packet across ISP X's network.  Note
   that the same traffic class still applies because the class encoding
   is propagated from the precedence bits of the IPv4 header to the CoS
   bits in the MPLS label.  As the packet exits ISP X's network, it can
   be aggregated into another trunk for the express purpose of
   tranisiting ISP Y.

   Again, label switching is used to bring the packet across ISP Y's
   network and then the aggregated trunk terminates at a router in ISP
   Z's network.  This router deaggregates the trunk, and forwards the
   resulting trunk towards ISP L.  This trunk transits ISP Z and
   terminates in ISP L at router U.  At this point, the data packets are
   removed from the trunk and forwarded along the path computed by RSVP.



Li & Rekhter                 Informational                     [Page 12]

RFC 2430                         PASTE                      October 1998


6.3 Trunk establishment and maintenance

   In this example, there are two trunks in use.  One trunk runs from
   ISP F, through ISPs X, Y and Z, and then terminates in ISP L.  The
   other aggregated trunk begins in ISP X, transits ISP Y and terminates
   in ISP Z.

   The first trunk may be established based on a multilateral agreement
   between ISPs F, X, Z and L.  Note that ISP Y is not part of this
   multilateral agreement, and ISP X is contractually responsible for
   providing carriage of the trunk into ISP Z.  Also per this agreement,
   the tunnel is maintained by ISP F and is initialized and maintained
   through the use of RSVP and an explicit route object that lists ISP's
   X, Z, and L.  Within this explicit route, ISP X and ISP L are given
   as strict hops, thus constraining the path so that there may not be
   other ISPs intervening between the pair of ISPs F and X and the pair
   Z and L.  However, no constraint is placed on the path between ISPs X
   and Z.  Further, there is no constraint placed on which router
   terminates the trunk within L's infrastructure.

   Normally this trunk is maintained by one of ISP F's routers adjacent
   to ISP X.  For robustness, ISP F has a second router adjacent to ISP
   X, and that provides a backup trunk.

   The second trunk may be established by a bilateral agreement between
   ISP X and Y.  ISP Z is not involved.  The second trunk is constrained
   so that it terminates on the last hop router within Y's
   infrastructure.  This tunnel is initialized and maintained through
   the use of RSVP and an explicit route that lists the last hop router
   within ISP Y's infrastructure.  In order to provide redundancy in the
   case of the failure of the last hop router, there are multiple
   explicit routes configured into ISP X's routers.  These routers can
   select one working explicit route from their configured list.
   Further, in order to provide redundancy against the failure of X's
   primary router, X provides a backup router with a backup trunk.

6.4 Robustness

   Note that in this example, there are no single points of failure once
   the traffic is within ISP F's network.  Each trunk has a backup trunk
   to protect against the failure of the primary trunk.  To protect
   against the failure of any particular router, each trunk can be
   configured with multiple explicit route objects that terminate at one
   of several acceptable routers.







Li & Rekhter                 Informational                     [Page 13]

RFC 2430                         PASTE                      October 1998


7.0 Security Considerations

   Because Priority traffic intrinsically has more 'value' than Best
   Effort traffic, the ability to inject Priority traffic into a network
   must be carefully controlled.  Further, signaling concerning Priority
   traffic has to be authenticated because it is likely that the
   signaling information will result in specific accounting and
   eventually billing for the Priority services.  ISPs are cautioned to
   insure that the Priority traffic that they accept is in fact from a
   known previous hop.  Note that this is a simple requirement to
   fulfill at private peerings, but it is much more difficult at public
   interconnects.  For this reason, exchanging Priority traffic at
   public interconnects should be done with great care.

   RSVP traffic needs to be authenticated.  This can possibly be done
   through the use of the Integrity Object.

8.0 Conclusion

   The Provider Architecture for differentiated Services and Traffic
   Engineering (PASTE) provides a robust, scalable means of deploying
   differentiated services in the Internet.  It provides scalability by
   aggregating flows into class specific MPLS tunnels.  These tunnels,
   also called trunks, can in turn be aggregated, thus leading to a
   hierarchical aggregation of traffic.

   Trunk establishment and maintenance is done with RSVP, taking
   advantage of existing work in differentiated services.  Explicit
   routes within the RSVP signaling structure allow providers to perform
   traffic engineering by placing trunks on particular links in their
   network.

   The result is an architecture that is sufficient to scale to meet ISP
   needs and can provide differentiated services in the large, support
   traffic engineering, and continue to grow with the Internet.

8.1 Acknowledgments

   Inspiration and comments about this document came from Noel Chiappa,
   Der-Hwa Gan, Robert Elz, Lisa Bourgeault, and Paul Ferguson.











Li & Rekhter                 Informational                     [Page 14]

RFC 2430                         PASTE                      October 1998


9.0 References

   [1] Rosen, E., Viswanathan, A., and R. Callon, "A Proposed
       Architecture for MPLS", Work in Progress.

   [2] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
       "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
       Specification", RFC 2205, September 1997.


   [3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow,, G.,
       Li, T., and A. Conta, "MPLS Label Stack Encoding", Work in
       Progress.

   [4] Davie, B., Rekhter, Y., Rosen, E., Viswanathan, A., and V.
       Srinivasan, "Use of Label Switching With RSVP", Work in Progress.

   [5] Gan, D.-H., Guerin, R., Kamat, S., Li, T., and E. Rosen, "Setting
       up Reservations on Explicit Paths using RSVP", Work in Progress.

   [6] Davie, B., Li, T., Rosen, E., and Y. Rekhter, "Explicit Route
       Support in MPLS", Work in Progress.

   [7] http://www.anxo.com/

10.0 Authors' Addresses

   Tony Li
   Juniper Networks, Inc.
   385 Ravendale Dr.
   Mountain View, CA 94043

   Phone: +1 650 526 8006
   Fax:   +1 650 526 8001
   EMail: tli@juniper.net


   Yakov Rekhter
   cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134

   EMail:  yakov@cisco.com








Li & Rekhter                 Informational                     [Page 15]

RFC 2430                         PASTE                      October 1998


11.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Li & Rekhter                 Informational                     [Page 16]