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 canLi & 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 19986.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 19987.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 19989.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.comLi & Rekhter                 Informational                     [Page 15]RFC 2430                         PASTE                      October 199811.  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]