rfc2430.txt

IPv6协议中flow_label的相关RFC

   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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


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

   EMail:  [e-mail]








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]