rfc2430.txt

RFC 的详细文档！

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