rfc2430.txt

RFC 的详细文档！

   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