Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

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

IP.com Disclosure Number: IPCOM000003008D
Original Publication Date: 1998-Oct-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 13 page(s) / 38K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

T. Li: AUTHOR [+2]

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 8% of the total text.

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.

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 eac...