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

Document Type RFC - Informational (October 1998; No errata)
Was draft-li-paste (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2430 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
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

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

   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

   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
Show full document text