Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_i/draft-ietf-issll-isslow-svcmap-00.txt

Text File | 1997-05-12 | 25KB | 599 lines

Internet Engineering Task Force                 Integrated Services WG
INTERNET-DRAFT                                  S. Jackowski
draft-ietf-issl-isslow-svcmap-00.txt               NetManage Inc.
                                                May 1997
                                                   Expires:  11/97


            Network Element Service Specification for Low Speed Networks


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 progress".

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   This draft is a product of the Integrated Services Working Group of
   the Internet Engineering Task Force.  Comments are solicited and
   should be addressed to the working group's mailing list at int-
   [e-mail] and/or the author(s).

Abstract

This document defines the service mappings for controlled load and
guaranteed services over low-bitrate networks.  These low bitrate
networks typically include components such as analog lines, ISDN
connections and sub-T1 rate links. The document specifies the per-
network element packet handling behavior, parameters required, traffic
specification, policing requirements, and traffic ordering
relationships which are required to provide both Guaranteed and
Controlled Load service capabilities.  It also includes evaluation
criteria for elements providing the service.

This document is a product of the IETF ISSL working group and is based
on [1] and [2] which describe modifications to the PPP protocol to
enable these services.

Jackowski              Expires 10/97               [Page 1]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt    May 1997


Table of Contents

1.  Introduction                                    3
2.  End to end Behavior                                4
3.  Motivation                                        5
4.  Network Element Data Handling                        5
4.1    Controlled Load Versus Guaranteed Service            7
4.2    Controlled Load and Guaranteed Service Data Handling    7
5.  Invocation Information                            7
6.  Exported Information                                8
7.  Policing                                        8
8.  Ordering and Merging                                8
9.  Guidelines for Implementors                        9
9.1    Admission Control                                9
10. Evaluation Criteria                                11
11. Security Considerations                            12
12. Author's Address                                12
13. References                                        12



Jackowski                  Expires 10/97               [Page 2]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt        May 1997


1. Introduction

With the proliferation of Internet usage in both businesses and homes,
there has been an explosion in demand for non-LAN access to the
Internet.  Most of these connections occur over dial up links.  There
has also been a recent surge in the requirements for ISDN and other sub-
T1 rate connections.  Unfortunately, the nature of these 'low-bitrate'
links is that it is difficult to provide Quality of Service (QoS) when
there are multiple flows of data over the link.  For example, it is
virtually impossible for a user to receive consistent performance when
running a browser, a file transfer and an IP telephony application
simultaneously over a low speed link.


The ISSLOW subgroup of the ISSL working group has focused on defining
mechanisms to permit flow differentiation and QoS capabilities for mixed
traffic over low speed links.  This has been accomplished through a
series of extensions to the PPP protocol which permit fragmentation
and/or suspension of large packets in favor of packets on flows which
require QoS.  The protocol extensions are presented in [1] and [2].

This document describes the service mapping required to implement the
controlled load and guaranteed services over these PPP protocol
extensions.  It is modeled on the Network Element Service Specification
Template described in [3].  It is assumed that the ISSLOW Network
Element is one portion of a  PPP service available to the system.


Jackowski                        Expires 11/97             [Page 3]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt      May 1997



2. End-to-end Behavior

Unlike many of the other specific link layers addressed in the ISSL
working group, ISSLOW operates only over low speed point to point links
or connections.  Examples of these links include dial up lines, ISDN
channels, and leased lines.  As such,  'end to end' simply means between
two points.  In today's inter/intranet environment, this will include:

-    host to directly connected host.
-    host to/from network access device (router or switch).
-     Edge device (subnet router or switch) to/from router or switch.
-     In rare circumstances, the link may run from backbone router to
    backbone router.

Thus, the endpoints are two network elements as described above.  The
Controlled Load and Guaranteed services for ISSLOW links are applied on
the link between these elements and often represent the first or last
wide area hop in a true end to end service.  It is important to note
that these links tend to be the most 'bandwidth constrained' along the
path.

ISSLOW services are only provided if both endpoints on the link support
ISSLOW.  This is determined during the PPP negotiation.  Because of the
unique characteristics of a point to point link with both endpoints
supporting ISSLOW, traffic is automatically shaped.  That is, incoming
traffic will be TSpec conformant, and except for some special
considerations for Guaranteed Service (below), the  admission control
function can make decisions based on local state: it does not need to
coordinate with the network element on the other end of the link.  As
described in [5], Guaranteed Service should approximate the
functionality of a leased  line.  Since ISSLOW runs over point to point
links, when rate control and delay bounds are provided for individual
flows, the link acts like a leased circuit. So again, even for
Guaranteed Service, local state can suffice.

Jackowski                       Expires 11/97                 [Page 4]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt       May, 1997

3. Motivation

Previous sections described the motivation for the ISSLOW capabilities.
Dial up users are now treating their relatively low-bitrate connections
as they would a higher speed connection.  They are mixing multiple flows
of data and expect performance similar to what they see in a LAN
environment.  However, it is deployment of realtime applications which
is the primary motivation for hosts to implement Integrated Services.
In particular, IP Telephony, which has tight delay constraints for
commercial-level performance, produces small packets.  When these are
mixed with flows consisting of large packets (e.g. HTTP ,FTP), delay
variance increases and absolute delay suffers as these small packets
wait in the queue behind even a single large packet being transmitted on
the link.  Because of the jitter tolerance and adaptive nature of codecs
used for packet voice and video, just providing a controlled load
service would satisfy most of the need for IP Telephony and other
realtime applications which are expected to run over low bitrate
connections.


Another consideration in handling of packets over low speed links occurs
when looking at the end to end considerations.  The low speed link is
usually just one hop on a longer path between endpoints.  As such, it is
usually the limiting factor in performance.  While this needs to be
considered in the host to router configuration, it becomes more critical
between edge devices and backbone routers where there is a multiuser
subnet as source and destination for traffic and a low-bitrate link to
the router.  To ensure some performance bounds end to end, guaranteed
service should be considered over these links even if it cannot be
offered end to end in the network.

4. Network Element Data Handling Requirements

The ISSLOW Network Service element may be implemented in hardware or
software.  As described in [1] and [2], for systems which can perform
bit-oriented transmission control, the suspend/resume approach optimizes
the available bandwidth by minimizing header overhead associated with
MLPPP fragmentation. For systems which provide frame-oriented
transmission control, the fragmentation approach can be implemented with
no hardware changes.  Choice of suspend/resume versus fragmentation
should be made based on the hardware's capability to handle the new HDLC
framing described in [1] and the system overhead associated with byte by
byte scanning (required by suspend/resume).

To provide controlled load or guaranteed service with the suspend/resume
approach, when a packet for an IntServ admitted flow (QoS packet)
arrives during transmission of a best efforts packet and continued
transmission of the best efforts packet would violate delay constraints
of the QoS service flows, the best efforts packet is preempted, the QoS
packet/fragments are added to the transmission, and the best effort
packet transmission is then resumed: usually all in one transmission.
The receiving station separates the best effort packet from the embedded
QoS fragments.  It is also conceivable that one IntServe Flow's packet
might suspend another flow's packet if the delivery deadline of the new
packet is earlier than the current packet.

For systems which use fragmentation,  since suspend/resume is not
possible, all packets longer than the minimal tolerable delay for an
IntServ packet are fragmented prior to transmission so that a short
packet for another flow can be interleaved between fragments of a large
packet and still meet the transmission deadline for the IntServ flow.

Jackowski                      Expires 11/97                 [Page 5]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt       May 1997


Note that the fragmentation discussed in this document refers to
multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications
as described in [1], not IP fragmentation.  MTU size is preserved across
the link.

ISSLOW assumes that the nature of point to point links is such that
rate, transmission time and delay are fixed and consistent.  The rate of
the link is determined at connection time, and the devices on the link
(adapters, modems, DSU/CSUs, etc) exhibit fixed delay characteristics.
Although certain link types, like ISDN, permit dynamic allocation of
bandwidth, it is assumed that the Admission Control service will
consider the impact of multiple physical links over the point to point
logical connection.

Note that because of the load balancing effect of Multilink PPP (MLPPP),
two 64 Kbps links should exhibit the delay and transmission
characteristics of a single 128 Kbps link.  However, MLPPP
implementations may approach load balancing and fragmentation
differently.  The mechanism used should be taken into consideration when
implementing the scheduler (especially token bucket) for packets,
fragments, and suspend/resume on top of existing MLPPP services to
ensure that adequate rate and delay characteristics are maintained.

4.1 Controlled Load versus Guaranteed Service

With most link layers, Guaranteed Service requires more tightly
controlled service by the Network Element, and in most cases, acceptance
of a Guaranteed Service request results in over-provisioning of link
level resources.  Controlled Load Service is usually less constrained
and permits more flexibility in scheduling of packets for the link.  For
ISSLOW, when the suspend/resume approach is used, Controlled Load
Service actually forces immediate preemption of any best efforts packet.
This is required to create the 'lightly loaded' link.  Ironically, with
Guaranteed Service, since delays are specified, suspend/resume only
needs to take place when continued transmission of the packet in
question would  violate the contracted delay bounds.  As such,
Guaranteed Service offers potentially better utilization of the link.

This anomaly does not exist with a fragmentation approach, since all
packets are fragmented to provide a maximum delay. Hence fragment
scheduling can ensure the appropriate characteristics of a lightly
loaded network.

One optional approach to avoid this would be to create a system level
definition of 'lightly loaded.'  The definition would specify the
acceptable delay in a lightly loaded network.  This would enable the
Controlled Load Service to only suspend packets if they violated the
delay constraints associated with the 'lightly loaded' definition.

Jackowski                     Expires 11/97                  [Page 6]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt       May 1997


4.2 Controlled Load and Guaranteed Service Data Handling

Upon arrival of a QoS flow's packet, The ISSLOW Network Element
determines if the packet is conformant.  If it is not, Policing is
applied (see Policing).  Conformant means:

1) The flow does not exceed the associated TSpec peak rate (RSpec rate
for Guaranteed Service: rT+b with T=time period).
2) The packet does not cause a token bucket overflow.

If the packet is conformant, it is compressed as required, fragmented
(if necessary), and scheduled.  If there is no conflicting best efforts
traffic, the packet is queued along with the rest of conformant QoS
traffic and scheduled with respect to any other IntServ flows such that
its transmission deadline is met.

For the suspend/resume implementation to achieve controlled load, any
best efforts packets which are being transmitted are suspended,
otherwise, the QoS packet/fragments are scheduled ahead of any queued
best efforts traffic.

For Fragmentation implementations, the packet/fragment is scheduled
ahead of any best efforts packets.  Note that all best efforts packets
are fragmented to the smallest MRU (or associated fragment size) of all
the QoS flows.  This incurs at most one fragment delay for the QoS
traffic: a lightly loaded network.

For Guaranteed Service or if the Lightly Loaded delay is defined, then
for both Fragmentation and suspend/resume, the scheduler determines if
continued transmission of the best effort packet being transmitted would
cause delay greater than the acceptable delay.  If so, the best efforts
packet is preempted or, in the case of fragmentation, the QoS packet is
scheduled ahead of the rest of the best effort packets' fragments.




5. Invocation Information

To invoke Controlled Load and Guaranteed Services, both traffic
characteristics and the flow itself must be identified to the Network
Element.  Several methods can be employed to identify the flows. For
RSVP, filtering can be used to identify the flows.  For non-RSVP
implementations, mechanisms such at the FlowID field in IP Version 6, or
the TOS field in IP version 4 can be used.  In fact, although
implementation dependent, there is some debate on the number of
different TSpecs that would have to be supported in the ISSLOW
environment.  It is possible that both the flows and the service level
could be specified by applications based on just the FlowID and TOS
fields. Otherwise:

As described in [4], Controlled Load Service is invoked by specifying
the flow's traffic characteristics through a TSpec (see [5]).

As described in [5], Guaranteed Service is invoked by specifying the
flow's TSpec and a requested reservation via an RSpec (see [6]).

Jackowski                     Expires 11/97                  [Page 7]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt       May 1997

6. Exported Information.

For Controlled Load Service, there is no requirement to export
information.

For Guaranteed service, both C and D terms for delay computations must
be made available for export through the Adspec or other means.  See
Sections 9.1 (Admission Control) for guidelines on computing the C and D
terms.

See [4] and [5] for additional information on Exported Information.

7. Policing

Policing is applied to non-conformant QoS traffic and to best efforts
traffic whose transmission would violate the Controlled Load or
Guaranteed Service constraints.  This document does not require a
specific a packet scheduling implementation.  As such, implementors
should do their best to maintain best efforts service levels as well as
to provide QoS services.  Ideally, best efforts traffic can be serviced
through separate queues and a weighted queuing mechanism, or when a
conflict with QoS traffic arises, it can simply be discarded.

Both Controlled Load and Guaranteed Services permit scheduling of non-
conformant traffic as well as the option to discard non-conformant
packets.  See [4] and [5] for additional information on policing options
for Controlled Load and Guaranteed Services.

8. Ordering and Merging

Refer to [4] and [5] for TSpec and RSpec ordering and merging
guidelines.

Jackowski                     Expires 11/97                     [Page 8]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt       May 1997


9. Guidelines for Implementors

9.1 Admission Control Considerations

The ISSLOW specification supports several PPP options.  When deciding
whether to admit a flow, Admission Control must compute the impact of
the following on MTU size, rate, and fragment size:

Header compression: Van Jacobson or Casner-Jacobsen.
Prefix Elision.
CCP.
Fragment header option used.
Fragmentation versus suspend/resume approach.

If any of the compression options is implemented for the connection, the
actual transmission rate, and thus the bandwidth required of the link,
will be reduced by the compression method(s) used.  The fragment header
option and use of fragmentation versus suspend/resume will determine the
additional overhead associated with the MLPPP transmissions.

Admission Control must decide whether to admit a flow based on rate and
delay.  Assume the following:

LinkRate is the rate of the link.
MTU is the maximum transmission unit from a protocol.
MRU is the maximum receive unit for a particular link.
CMTU is the maximum size of the MTU after compression is applied.
eMTU is the maximum effective size of the MTU after fragmentation.
FRAG is the fragment size including MLPPP header/trailers.
Header is the size of the header/trailers/framing for MLPPP/Fragments.
pHeader is the additional header/framing overhead associated with
    suspend/resume.
pDelay is the delay associated with suspend/resume packets.
b is the bucket depth in bytes
R is the requested Rate.
D is the fixed overhead delay for the link (Modem, DSU, etc).
C is the delay associated with transmission and fragmentation.
eRate is the effective rate after compression and fragmentation.

The D term may be configured by an administrative tool once the network
is installed; it may be computed using the Adspec or other realtime
measurement means; or it may be available from hardware during link
setup and/or PPP negotiation.

Admission Control must compute CMTU, eMTU, and eRate for Controlled Load
Service, and it must compute CMTU, eMTU, eRate, and C for Guaranteed
Service:

Jackowski                     Expires 11/97                  [Page 9]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt       May 1997


To determine whether the requested rate is available, Admission Control
must compute the effective rate of the request (eRate) - worse case - as
follows:

#_of_Fragments = (CMTU + FRAG)/(FRAG-Header)

eMTU = (#_of_Fragments) * FRAG

eRate = eMTU/CMTU * R

Admission Control should compare the eRate of the request against the
remaining bandwidth available to determine if the requested rate can be
delivered.

For Controlled Load Service,  a flow can be admitted as long as there is
sufficient bandwidth available (after the above computation) to meet the
rate requirement, and if there is sufficient buffer space (sum of the
token bucket sizes does not exceed the buffer capacity).  While some
statistical multiplexing could be done in computing admissability, the
nature of the low-bitrate links could make this approach risky as any
delay incurred to address a temporary overcommitment could be difficult
to amortize.

Guaranteed Service and a 'lightly loaded' delay bound require delay
computations.  These computation are based on the standard formula for
delay:

Delay = b/R + C/R + D

Note that for suspend/resume, an additional term is required:

pDelay = b/R + C/R + D + pHeader/R.

This term exists because of the additional overhead associated with the
suspend/resume headers created when suspending a packet.  In the worse
case, every transmission of a QoS packet could require suspension of a
best efforts packet and thus incur the overhead.  In most networks, this
term will be nominal at most.  However, on some low-bitrate links, the
overhead may be worth computing.

Since MLPPP includes fragmentation, the C term is not fixed and must be
represented by the worse case fragmentation as computed in the effective
MTU size:

C = eMTU.

Note that because ISSLOW runs on point to point links, Guaranteed
Service can be offered over a link without any negotiated agreement from
the next hop.  However, if these services are used in conjunction with
RSVP, the C and D values above should be used in the Adspec.

Jackowski                     Expires 11/97                  [Page 10]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt       May 1997


10. Evaluation Criteria

For Controlled Load Service, the ISSLOW network element must ensure that
the service requested via the TSpec is delivered to the requesting QoS
flow such that the PPP link appears to be a 'lightly loaded link.

As a baseline, it is suggested that performance measurements on
throughput, delay, and packet error measurements be performed on an
unloaded link with just the QoS flow using various packet sizes.  The
baseline should measure performance for both conformant and non-
conformant traffic where for a single flow, this means overloading the
link.  Once these measurements are complete, measurements of the
Controlled Load Service should be performed as follows:

1) Request QoS flows in the presence of best efforts traffic and ensure
that the QoS flows' performance approximate the unloaded baseline
measurements.

2) Request QoS flows whose aggregate throughput would exceed the link
capacity.  Admission Control should deny these service requests or admit
them as best efforts only.

3) Generate traffic on a QoS flow which exceeds it's TSpec commitment.
Ensure recovery of the flow once the traffic becomes conformant.

For Guaranteed Service:

1) Ensure that Admission Control will deny service requests or convert
them to Best Efforts when link capacity or delay bounds would be
exceeded.

2) On a best-efforts loaded link, ensure that the number of lost packets
do not exceed those established in the baseline measurements.

3) On a best-efforts loaded link, ensure that delay an rate commitments
can be met for QoS flows.

4) With multiple QoS flows, ensure that an admission of additional QoS
flows does not cause a violation in rate, error rate, or delay
constraints of any QoS flow.

Jackowski                     Expires 11/97                  [Page 11]



INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-00.txt       May 1997



11. Security Considerations

Security considerations for PPP links are the subject of other working
groups and are not discussed in this document.


12. References


   [1] C. Bormann "The Multi-Class Extension to Multilink PPP"
   Internet Draft, March 1997, <draft-ietf-issl-isslow-mcml-01.txt>

   [2] C. Bormann "PPP in a real-time oriented HDLC-like framing"
   Internet Draft, March 1997, <draft-ietf-issl-isslow-rtf-00.txt>

   [3] S. Shenker and J. Wroclawski. "Network Element Service
   Specification Template", Internet Draft, November 1996,
   <draft-ietf-intserv-svc-template-03.txt>

   [4] J. Wroclawski. "Specification of the Controlled Load Quality
   of Service", Internet Draft, November 1996, <draft-ietf-intserv-ctrl-
   load-svc-04.txt>

   [5] S. Shenker, C. Partridge, and R Guerin. "Specification of
   Guaranteed Quality of Service", Internet Draft, February 1997,
   <draft-ietf-intserv-guaranteed-svc-07.txt>

   [6] S. Shenker and J. Wroclawski. "General Characterization
   Parameters for Integrated Service Network Elements", Internet Draft,
   October 1996, <draft-ietf-intserv-charac-02.txt>


13 Author's Address:


   Steve Jackowski
   NetManage, Inc
   269 Mt Hermon Rd, Ste 201
   Scotts Valley, CA  95060
   [e-mail]
   408-439-6834
   408-438-5115 (fax)

Jackowski                         Expires 11/97            [Page 12]