Internet DRAFT - draft-worster-diffserv-gr


Internet Engineering Task Force                        Tom Worster
INTERNET-DRAFT                                          Avri Doria
Expires: November 1998                            General DataComm
                                                  Robert Wentworth
                                           Hyundai Network Systems

                                                      June 7, 1998

           Guaranteed Rate in Differentiated Services


Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on (Africa),
(Northern Europe), (Southern Europe),
(Pacific Rim), (US East Coast), or
(US West Coast).

We propose a diff-serv per hop behavior (PHB) for the transport
of non-real time traffic with a guaranteed rate (GR). This
proposal is based on principles developed for the specification
of the Guaranteed Frame Rate (GFR) service category currently
being specified for ATM [TM5]. It is shown that a diff-serv
network using the GR PHB together with a explicit routing
capability can support edge-to-edge guaranteed rate service.
Interconnection of diff-serv networks deploying GR to achieve
end-to-end service and interworking with ATM's GFR service are
also discussed.

1. Introduction, motivation, goals

What is now known at the ATM Forum as the Guaranteed Frame Rate
service category (and at ITU-T as the Guaranteed Frame Rate ATM

Worster et. al.                                               [Page 1]

Internet Draft       Guaranteed Rate in Diff Svcs         June 5, 1998

transfer capability) was introduced by Juha Heinanen in April
1996 [Hein]. It is currently in the process of specification at
both the ATM Forum Traffic Management Working Group and at ITU-T
Study Group 13. GFR is part of the draft ATM Forum TM 5.0
specification which is planned to go to letter ballot in December

The "frame" in GFR comes from that fact that in ATM the
definition involves a minimum cell rate where only cells
delivered in complete frames count towards fulfilling the
service; a complication that is avoided in a diff-serv PHB
defined at the IP level.

GFR is intended to provide a non-real time service with a
guaranteed minimum rate.  Traffic offered to the network in
excess of the minimum rate is handled with best effort service.
The GFR service definition was intended to be simple for the user
to understand, simple to tariff, and useful for a wide range of
network applications including aggregated router-to-router data.

In this ID we propose a Guaranteed Rate (GR) PBH for diff-serv
adhering to the operational model proposed in [NiBl]. This
proposal is based directly on ideas and definitions developed in
the specification of the GFR service. Together with a suitable
routeing mechanism, deployment of the GR PHB allows a diff-serv
network to provide an edge-to-edge ("edge-to-edge" implies
reference points on the exterior interfaces of edge nodes
belonging to a diff-serv compliant area) minimum bit rate service
guarantee for non-real time traffic. The same service guarantee
can also be supported over multiple ISPs' networks. Direct
interworking between GR and GFR ATM connections (in either the
conventional layering or MPLS architectures) is another goal.
The goals of this ID include the stimulation of interest in the
proposal, discussion of the technical issues and experimentation.
Ultimately it is intended that this effort would end in
standardization of a PHB codepoint.

2. Guaranteed Rate in the diff-serv model

In this section we provide a high-level description of the GR PHB
proposal and explain how it can be used together with other
mechanisms to provide guaranteed rate edge-to-edge service.
While the goal of the current proposal is the definition of the
GR PHB we also use the name Guaranteed Rate service (GR service)
when speaking of the resulting edge-to-edge or end-to-end

Worster et. al.                                               [Page 2]

Internet Draft       Guaranteed Rate in Diff Svcs         June 5, 1998

Several elements of this section have been adapted directly from
the text of [TM5].

2.1 High level description of GR PHB and service

The GR PHB and service are intended to support non-real time
applications. The GR service provides transport of IP data with a
minimum bit rate guarantee under the assumption of a given burst
This service guarantee implies that if the user sends bursts of
packets that in total do not exceed the maximum burst limit then
the user should expect to see all of these packets delivered
across the network with minimal loss. The GR service also allows
the user to send in excess of the committed rate and the
associated burst limit but the excess traffic will only be
delivered within the limits of available resources. Furthermore
the GR PHB specifies that the excess traffic from each user
should have access to a fair share of available resources. The
definition of fair share is implementation or network specific
and is not specified by either the GR PHB or service.

2.2 Environmental considerations

The current proposal is an attempt to work strictly within the
diff-serv framework and operational model [NiBl]. While the GR
proposal is clearly intended as a basis for providing a
network transport service with guaranteed minimum bit rate we
are proposing to do so using a bottom-up approach based on a
GR PHB and the goal of this proposal is to define and
standardize that PHB.

Deployment of a GR service requires protocols and mechanisms
besides those discussed here. Specifically, a GR network
should be aware of specific network streams, (_stream_  is
used in the same sense as in [Call]). These streams may be
defined in many different ways and several mechanisms are
available to support discrimination of these streams in the
network nodes. For example, a stream could be the aggregate of
packets from one edge node to another. Or a stream could be
the aggregate of packets making up a logical connection in
either a layer 2 or layer 3 VPN. The mechanisms that support
these discriminations could be based, for example, on hardware
accelerated classification of the IP header, on MPLS labels,
on ATM VPI/VCIs, on the VPN Identifier [HeRo], or a
combination of these. We consider that one of the first areas
of application may be in conjunction with MPLS.

Worster et. al.                                               [Page 3]

Internet Draft       Guaranteed Rate in Diff Svcs         June 5, 1998

The GR PHB specifies the requirement on a network node that
its behavior with respect to the specified stream should be to
provide a minimum service rate according to the committed rate
and burst limit parameters. Clearly the network node needs to
be told the stream specification and the values of the
parameters. Protocols that could be used (or be extended so
that they could be used) to carry these data include SNMP,
CMIP, LDP, RSVP, BGP4, and the various ATM signalling
protocols. The issues involved in distributing the data are
not discussed in this draft. The related issues, including
resource allocation, route selection, and resource congestion,
are also side-stepped by limiting this draft's scope to the
diff-serv charter.

So far we have only considered applying GR to non-multicast
streams. To accommodate multicast applications the proposed GR
PHB (section 2.3.2) would need to be extended to allow for
multiple-input and/or multiple-output "generalized streams."

The GR proposal has been developed around the notion that the
GR PBH (with it's rate and burst limit parameters) applies to
a specific network stream. However, components of the proposal
may have broader applicability. Something akin to GR service,
but without the stream orientation, has already been discussed
within in the diff-serv framework. In such schemes a traffic
conditioner at the network's ingress edge would monitor the
rate of user traffic sent to the network (or perhaps the rate
of a portion of that traffic as defined by a packet
discriminator) and mark the traffic as either "in" or "out" of
profile accordingly. Engineering of network resources
according to a projected network traffic load matrix is used
and the per hop resource reservation associated with the GR
PBH is avoided. It may be that the same service representation
(we propose a formal service representation for GR in section
2.3.1) may be used for both the stream oriented approach to
resource allocation and the network traffic engineering

2.3 Components of GR

The components of the GR service discussed here are the GR PHB,
the representation of the GR service and the edge traffic
conditioner. Compared to ATM these are related in some way to
GFR's conformance definition and service guarantee. Several
options are discussed below with an indication of our preference.

Worster et. al.                                               [Page 4]

Internet Draft       Guaranteed Rate in Diff Svcs         June 5, 1998

2.3.1 Service representation
The term "service representation" (SR) refers to a description of
the service that the network commits to provide to the user. The
SR includes a description of guaranteed minimum rate and the
packet characteristics that identify the stream of packets to
which the service commitment applies.
In the context of diff-serv the SR is not the central part of the
GR proposal. The motivation for including a formal specification
for the SR is to allow us to demonstrate how a formally defined
level of network service can be built on the basis of the PHB of
the following section.
The guaranteed minimum rate is defined using a leaky bucket and
rate and credit parameter. Appendix A defines an algorithm we
call the GPRA(x, y) (generic packet rate algorithm) where x is
the abstract rate parameter in bytes/s and y is the abstract
credit limit parameter in bytes.
The SR is characterized by the triplet (S, CR, BL). S is the set
of characteristics of the packet stream to which service is being
committed. The guaranteed minimum rate specification in is
defined as GPRA(CR, BL) where CR is the committed rate in bit/s
and BL is the burst limit in bytes.
The interpretation of this SR is: The network commits to
transporting with minimal loss at least those packets belonging
to the stream specified by S that pass a hypothetical
implementation of the GPRA(CR, BL) located at the network's
ingress interface. Additional parameters
The (CR, BL) portion of the SR is essentially a restricted
version of the Tspec (traffic specification) defined in [RFC2212]
for use in specifying traffic to be serviced with delay
guarantees.  In addition to the rate and burst limit (referred to
as the "bucket depth" in [RFC2212]), a Tspec contains a peak
rate, a minimum policed unit,and a maximum datagram size.
Some applications naturally generate packet streams with a
bounded short term data rate while other applications may
comfortably adapt to such a bounded "peak" rate. If a peak rate
limited stream is forwarded across network trunks with a large
bandwidth capacity relative to the stream's peak rate then
network nodes may be able to make significant savings in resource
allocation using knowledge of the peak rate. If these savings
were of sufficient value to ISPs it might be worth considering
introducing a peak rate specification into both the SR and the
PHB. Similarly, introducing a minimum policed unit or a maximum
datagram size could be considered.
For the time being we consider the additional complexity
associated with these extra parameters to be unjustified.

Worster et. al.                                               [Page 5]

Internet Draft       Guaranteed Rate in Diff Svcs         June 5, 1998

2.3.2 The GR PHB
The GR PHB is characterized by the triplet (S, R, L) where S is
the set of characteristics that exclusively identify a stream of
packets. R defines a minimum service rate for the stream in
bytes/s and L defines the tolerance to bursts that the node MUST
With respect to a stream specified by S the network node MUST
forward to the stream's output port, with high probability, at
least those packets that would pass a hypothetical GPRA(R, L)
algorithm located at the streams input port.
Resources available for the service of excess GR traffic MUST be
divided fairly among the active GR streams. The definition of
fairness is implementation and/or network specific.

2.3.3 Traffic conditioning
Several possibilities present themselves for traffic
The most obvious possibility is that the conditioner monitors the
rate of the incoming stream relative to the committed rate and
burst limit and sets the "IN" bit of the DS octet of incoming
packets accordingly.
If the peak rate parameter is defined then the conditioner has
the possibility of discarding traffic in excess of the specified
peak rate. Alternatively if In/Out marking according to the
committed rate is not required then In/Out marking could be
performed with respect to the peak rate. In the latter case the
GR PHB could be modified so that the service commitment in
network nodes applies only to "In" packets.
For the time being we consider the utility of the above
conditioning primitives to be unsubstantiated and therefore not

3. Concatenation of PHBs

We have made the suggestion that the GR PHB is a useful building
block from which and edge-to-edge guaranteed rate service may,
together with some additional mechanisms outside the scope of
diff-serv, be constructed. In this chapter we attempt to show how
this might be done and to include some discussion of the
reasoning behind the proposal.

Assume that a mechanism is in place to identify a particular
stream of packets, and that a network node queues these packets
and schedules their transmission in a way that attempts to ensure
a service rate which is always at least R as defined in the GR
PHB.  This "guaranteed rate" behavior could take a number of
forms. One example of a form this could take is described in the

Worster et. al.                                               [Page 6]

Internet Draft       Guaranteed Rate in Diff Svcs         June 5, 1998

following theorem, which also describes an implication of this
particular behavior.

       THEOREM: Let a_j be the arrival time of the start of
       packet j, let t_j be the time when the start of packet j
       is transmitted, and let TL_j be the total length of
       packet j. Suppose the transmission times satisfy s_j <
       t_j < s_j + T_2, where s_(j+1) - s_j <= (TL_j/R), and
       also suppose that if a packet arrives when no other
       packets in the stream are awaiting transmission, then a_j
       + T_0 <= s_j < a_j + T_0 + T_1. T_0, T_1, and T_2 are,
       respectively, the fixed empty-queue packet latency, the
       maximum variation in the empty-queue packet latency, and
       the scheduling tolerance. Then, if the arriving packets
       all pass GPRA(R, B), the transmitted packets will all
       pass GPRA(R, (B + (T_0 + T_1)*R))

       The proof of this theorem is given in Appendix B.

Though perhaps not all "guaranteed rate" nodes will schedule
packets in a way that fits this form, the preceding theorem
suggests that it is reasonable to expect that a significant class
of such devices would have  the ability to guarantee that if the
input packet stream satisfies GPRA(R, B) then the output packet
stream will satisfy GPRA(R, B + BTI) where BTI is the devices
burst tolerance increment for the stream in question.
This result allows us to consider several possible schemes by
which an edge-to-edge guaranteed rate service commitment may be
made. For example, if we know that each node has a BTI that does
not exceed BTI_max then we can establish GR service with
parameters {S, CR, and BL} by provisioning a GR PHB with
parameters {S, R = CR, and B = BL + BTI_max} along the stream's
path though the network.
We do not attempt to specify the rules by which a network
operator should distribute appropriate GR PHB parameters. To some
extent the appropriate scheme will depend on characteristics of
the implementation of the GR PBH in network nodes. It may also
depend on limitations of the protocol used to distribute the
GR service can also be supported across concatenated GR diff-serv

4. Interworking with ATM

One of the aims of the GR diff-serv proposal is that it should
facilitate interworking with ATM to some extent. So far, the ATM
service categories (CBR, VBR-rt, VBR-nrt, ABR and UBR) have not

Worster et. al.                                               [Page 7]

Internet Draft       Guaranteed Rate in Diff Svcs         June 5, 1998

proven to be very well adapted to the needs of data networking or
the Internet. On the other hand the GFR proposal is intended to
provide a service category designed to work well for applications
in IP networks and the Internet. We assume that in the future a
mixture of network technologies including ATM will co-exist and
interoperate within our networks hence the desire for GR-ATM
There are many ways in which ATM can be incorporated into IP
networks and without discussing these we identify two approaches
to GR-ATM interworking:
  - the GR PHB is mapped onto an ATM switch, or
  - the GR service is mapped onto an ATM connection.

5. Implementation example

A description of how GR could be deployed in an MPLS context.

6. Security considerations

Not thought about yet.


   [Hein]  J. Heinanen, "MCR for UBR," ATM Forum
           Contribution 96-0362, April 1996.

   [TM5]   ATM Forum Traffic Management Baseline Text
           Document, <btd-tm-01.02>, May 1998.

   [NiBl]  K. Nichols and S. Blake (editors),
           "Differentiated Services Operational Model and
           Definitions," Internet Draft <draft-nichols-
           dsopdef-00.txt>, Feb 1998.

   [Call]  R. Callon et al, "A Framework for Multiprotocol
           Label Switching," Internet Draft <draft-ietf-
           mpls-framework-02.txt>, Nov 1997.

   [HeRo]  J. Heinanen and E. Rosen, "VPN support with
           MPLS," Internet Draft <draft-heinanen-mpls-vpn-
           01.txt>, Mar 1998.

   [RFC2212] S. Shenker, C. Partridge, R.
           Guerin,"Specification of Guaranteed Quality of
           Service," RFC 2212, Sep 1997.

Worster et. al.                                               [Page 8]

Internet Draft       Guaranteed Rate in Diff Svcs         June 5, 1998

Worster et. al.                                               [Page 9]

Internet Draft       Guaranteed Rate in Diff Svcs         June 5, 1998

Appendix A.

The Generic Packet Rate Algorithm GPRA(x, y)

Define a Generic Packet Rate Algorithm, GPRA(x, y), where x is a
rate specified in bits per second and y is a burst tolerance
expressed in bytes. The algorithm has two state variables, the
traffic excess over x, W, and the last pass time, LPT.
Initially, W = 0, and LPT = 0, assuming t >= 0.
Let TL be the total length in bytes of an arriving packet, and
let t_a be the arrival time of the start of the packet.  When a
packet arrives, the algorithm executes as follows.

       W' = W - (t_a - LPT)*x
       if ( (W' > y) or (external factor indicates no-pass) )
           pass = false
           pass = true
       end if

       if (pass) then
           W = max(W', 0) + TL
           LPT = t_a
       end if
The output of the algorithm is the variable pass which classifies
a stream's packets as being either in (i.e. pass == true) or out
of the traffic profile established by the parameters x and y..

Appendix B.

Proof of the concatenation theorem
To be written. Based on a closely related proof by R. Wentworth
given in ATM_Forum contribution 97-0980, Dec 1997.

Worster et. al.                                              [Page 10]

Internet Draft       Guaranteed Rate in Diff Svcs         June 5, 1998

Authors' Addresses

   Tom Worster                   Avri Doria
   General DataComm, Inc.        General DataComm, Inc.
   5 Mount Royal Avenue          5 Mount Royal Avenue
   Marlboro  MA 01752            Marlboro  MA 01752
   Tel: +1 508 624 6723 x224     Tel: +1 508 624 6723 x236
   Fax: +1 508 481 3668          Fax: +1 508 481 3668 

   Robert Wentworth
   Hyundai Network Systems
   520 Herndon Parkway
   Herndon, VA 20170-5225
   Tel: 703-478-2400
   Fax: 703-478-2405

Worster et. al.                                              [Page 11]