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: 2019-Feb-11
Document File: 16 page(s) / 24K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

T. Li: AUTHOR [+1]

Related Documents

10.17487/RFC2430: DOI

Abstract

This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 9% 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.

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

Processing...
Loading...