Internet DRAFT - draft-fiaschi-qoscapability-ppp
draft-fiaschi-qoscapability-ppp
INTERNET DRAFT Giovanni Fiaschi
Category: Informational Fabio Poggi
Title: draft-fiaschi-qoscapability-ppp-00.txt GianLuca Rolandelli
Date: July, 2000 Marconi
Expires: January, 2001
A proposal to provide QoS capability for PPP
draft-fiaschi-qoscapability-ppp-00.txt
Status of this Memo
This document is an internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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''.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Quality of Service in the IP protocol has been proposed in some
service definitions (Int-Serv and Diff-Serv) and in a variety of
schemes and supporting protocols (RSVP). These schemes assume,
of course, that all the protocols supporting IP links in turn
provide a well-defined degree of QoS the IP schemes can rely upon.
One of the most common link protocols is PPP.
The PPP protocol provides a standard method for transporting
multi-protocol datagrams over point-to-point links. It was
designed to be used in serial point-to-point links. These ones
can be for example PSTN circuits, characterized by a fixed
bandwidth and fixed delay. Hence, there was no need to specify QoS
mechanisms for PPP: the IP layer (or more generally the network
layer) did not take into account the data-link layer to
calculate the available resources.
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 1]
INTERNET DRAFT July 2000
The same is valid for ATM connections carrying PPP sessions: the
PPP inherits the ATM QoS characteristics. On the other hand,
if the PPP protocol is used over shared media (such as Ethernet)
or it is multiplexed over a L2TP tunnel, the bordering conditions
change and new solutions have to be developed to guarantee QoS
in such a model.
This draft presents a proposal to provide "native" QoS capability
on the PPP protocol.
Two scenarios, in which QoS over PPP may be effective, are considered
in this draft: L2TP Access Concentrator (LAC) and PPP over Ethernet
(PPPoE).
Table of Contents
1.0 Introduction
1.1 Conventions
2.0 LAC
2.1 Network Model
2.2 QoS issues for LAC
2.3 Information Flow
2.4 QoS in underlying protocols
2.5 Other non-ATM Access Network
3.0 PPPoE
3.1 Network Model
3.2 QoS issues for PPPoE Server
3.3 Information Flow
3.4 QoS in underlying protocols
3.4.1 QoS-enabled Ethernet
4.0 References
5.0 Acknowledgements
6.0 Authors' Addresses
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 2]
INTERNET DRAFT July 2000
1.0 Introduction
Quality of Service in the IP protocol has been proposed in some
service definitions (Int-Serv and Diff-Serv) and in a variety of
schemes and supporting protocols (RSVP).
In particular, according to RFC 2475 [4], with Diff-Serv, packets are
classified and marked in order to be managed with a particular
forwarding methodology based on a "per-hop behavior" on the nodes along
their path. Classification, marking, policing, and shaping operations
are implemented in the network boundaries or hosts.
On the other hand, with Int-Serv [5], IETF has defined a framework that
provides individualized quality of service guarantees to
individual application sessions. This architecture is based on
Reserved Resources and on Call Setup.
Moreover, according with RFC 2205 [6], RSVP was developed in order to
provide a receiver-initiated setup of resource reservations for
multicast or unicast data flows, with good scaling and robustness
properties. The RSVP protocol is setup by a host with the aim to
request specific qualities of service from the network for
particular application data streams or flows. It is also used by
routers to deliver Quality of Service (QoS) requests to all nodes
along the path(s) of the flows and to establish and maintain state to
provide the requested service.
These schemes above assume, of course, that all the protocols
supporting IP links in turn provide a well-defined degree of QoS the IP
schemes can rely upon. One of the most common link protocols is PPP [1].
PPP provides a standard method for transporting
multi-protocol datagrams over point-to-point links. These links,
carrying packets between two peers, are characterized by
full-duplex simultaneous bi-directional communications, and are assumed
to deliver packets in order. These links can be for example PSTN
circuits, characterized by a fixed bandwidth and fixed delay.
Hence, there was no need to specify QoS mechanisms for PPP: the
IP layer (or more generally the network layer) did not take into
account the data-link layer to calculate the available resources.
The same is valid for ATM connections carrying PPP sessions: the
PPP inherits the ATM QoS capabilities.
If the PPP protocol is used over shared media (such as Ethernet) or
it is multiplexed over a L2TP tunnel, the bordering conditions change
and new solutions have to be developed to guarantee QoS in such a model.
Two scenarios, in which QoS over PPP may be effective, are considered in
this draft, L2TP Access Concentrator (LAC) and PPP over Ethernet (PPPoE).
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 3]
INTERNET DRAFT July 2000
1.1 Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL, or MANDATORY -- This item is an absolute
requirement of the specification.
o SHOULD or RECOMMEND -- This item should generally be followed
for all but exceptional circumstances.
o MAY or OPTIONAL -- This item is truly optional and may be
followed or ignored according to the needs of the implementor.
2.0 L2TP Access Concentrator (LAC)
This section will analyze the QoS problem for PPP from an
L2TP Access Aggregation (LAA) network architecture perspective.
In the LAA architecture an ATM Access Network is supposed.
It is also supposed (in this Draft) a PVC environment.
The PPP sessions starting from the Hosts rely directly over ATM PVCs
by means of RFC 2364 (PPP over ATM, or PPPoA).
The Network Model is described in session 2.1.
2.1 Network Model
The reference circuit is the following:
+------------+ +-----------+
| | +--------+ | | +--------+
+----+ | ATM | | Access | | Transport | | Access |
|Host|----| Access |----| Server |----| Network |----| Router |
+----+ | Network | | (LAC) | | | | (LNS) |
| | +--------+ | | +--------+
+------------+ +-----------+
From the PPP point of view, the Access Network is made by Hosts,
an Access Server (LAC), and Access Routers (LNS). Hosts have to
set up a PPP session with the selected Access Router.
The Access Server can be seen as a PPP Switch.
In the following of this document the terms LAC and Access Server
and the terms LNS and Access Router have to be considered as synonyms.
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 4]
INTERNET DRAFT July 2000
In the ATM Access Network, we suppose to have one ATM PVC per PPP
connection (a dedicated circuit exists between the Host and
the Access Server).
In the Transport Network, all the PPP sessions for the same ISP are
multiplexed and tunneled by means of L2TP (a shared link exists
between the LAC and the Access Router).
2.2 QoS issues for LAC
Between the Host and the Access Server there is one PVC per PPP
connection. So it is reasonable to assume that the PPP inherits the
quality of the underlying ATM PVC.
As there is a shared link (tunnel) between the Access Server and
the Access Router, QoS mechanisms for PPP MUST be provided in
the LAC in order to allocate bandwidth for the incoming PPP sessions.
To provide the PPP with QoS capability, the PPP network elements
(that are the LAC and the LNS) MUST be equipped with the following
functions:
- admission control, a way to check resource availability and
possibly refuse the request;
- classification, a way to recognize the flow a frame belongs to;
- policy enforcement, a way to ensure that the access network
users are not using more resources than agreed;
- scheduling, a way to treat frames according to contracts by
means of prioritization.
The Access Server knows the QoS parameters of the PVC that carry an
incoming PPP session. In the upstream direction, the Access Server
is able to determine the possibility of allocating (on the shared link)
the resources required by the incoming PPP session.
2.3 Information Flow
The Access Server MUST notify the Access Router with the QoS
parameters of the PVC. In this way the Access Router will be able to
allocate the necessary resources on the shared link for downstream
traffic.
In order to notify this information, there is the need to introduce
new AVPs in the L2TP protocol for ICRQ messages. These new AVPs
will contain the ATM PVC parameters (UBR, CBR, UBR-rt, UBR-nrt, etc.)
that carry the PPP session.
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 5]
INTERNET DRAFT July 2000
2.4 QoS in underlying protocols
The PPP protocol is in turn supported by:
- the ATM protocol on the customer side;
- the L2TP protocol on the ISP side.
For a correct admission control procedure, the PPP Switch MUST be
aware of the QoS characteristics of these underlying protocols.
If either of the two is not QoS capable or provides insufficient
QoS, the request cannot be admitted.
We will assume that the L2TP is implemented over a QoS-capable network
and that the tunnel has a static and known QoS. If this is the
case, it is enough to insert in the PPP Switch information about
tunnels QoS at configuration time.
For the ATM part we have assumed a one-to-one correspondence
between the PPP session and the ATM PVC. The PPP Switch will be aware
of the QoS parameters of each PVC.
2.5 Other non-ATM Access Networks
If the Access Network is a non-ATM network and QoS parameters
cannot be inferred, the host MUST explicitly signal QoS parameters
to the LAC.
A way to signal those parameters SHOULD be the use of Fully Qualified
Domain Names (FQDN) in the form of "username@qosparams.domain".
3.0 PPPoE
This section will analyze the QoS problem for PPP in case the host
is equipped with a PPPoE Client and the LAC is equipped with a
PPPoE Server.
3.1 Network Model
The reference circuit is the following:
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 6]
INTERNET DRAFT July 2000
+------------+ +-----------+
| | +--------+ | | +--------+
+----+ | Ethernet | | Access | | Transport | | Access |
|Host|----| Access |----| Server |----| Network |----| Router |
+----+ | Network | | (LAC) | | | | (LNS) |
| | +--------+ | | +--------+
+------------+ +-----------+
This network model is quite similar to the LAC one shown above
(see Section 2.1). The main difference resides on the Access Network
that in this model is Ethernet-based.
Also in this model, hosts have to set up a PPP session with
the selected Access Router, and the Access Server can be seen
as a PPP Switch.
As long as the Access Network is Ethernet-based (a shared architecture
by definition), a proper method to adapt the PPP to this shared
environment is needed and this is the PPPoE.
With this protocol is possible to emulate a point to point
connection over the Ethernet connectionless architecture.
As in the LAC network model, the Transport Network multiplexes
and tunnels all the PPP sessions for the same ISP over an L2TP tunnel.
3.2 QoS issues for PPPoE Server
As between the Host and the LAC there is an Ethernet-based Access
Network, a mechanism is needed to make the Ethernet network QoS enabled.
This issue is discussed later in section 3.4.
Between the LAC and the LNS the situation is identical to that
described in section 2.2.
3.3 Information Flow
Unlike the LAC model, for this case there is no way to deduce the
desired QoS info from the underlying layers, hence this info
MUST be explicitly signaled.
There is a tag specified in RFC 2516 named Service_Name. It is used
to specify the Services the Access Server can provide to the user.
It can also include the QoS services offered to the user, e.g., in
the form of Olympic Services (Gold, Silver and Bronze Services)
or byte rates.
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 7]
INTERNET DRAFT July 2000
In the Discovery phase, the Access Server notifies to the user the
available QoS classes and the user selects one of them. From now on,
the Access Server will manage the traffic coming from that user
with a queuing discipline defined for the class chosen. The PPP frames
are policed and served as IP packets are managed in QoS-enabled
routers: PPP sessions are multiplexed over tunnels towards ISPs in
the same way as IP packets are multiplexed over data-link connections.
From this point of view the PPPoE protocol serves as a signaling
protocol such as the RSVP protocol serves as a signaling protocol at
network layer.
As in the LAC case, the Access Server MUST notify the Access Router
with the QoS parameters signaled by the Host with the PPPoE protocol.
In this way the Access Router will be able to allocate the
necessary resources on the shared link for downstream traffic.
In order to notify this information, there is the need to introduce
new AVPs in the L2TP protocol for ICRQ messages. These new AVPs
will contain the QoS parameters signaled by the Host.
Both for the LAC case and for the PPPoE case, the semantic of
these new AVPs will be consistent with RFC 2215 ("General
characterization parameters for Integrated Services network
elements") [5].
3.4 QoS in underlying protocols
The PPP protocol is in turn supported by:
- the Ethernet protocol on the customer side;
- the L2TP protocol on the ISP side.
For a correct admission control procedure, the PPP Switch must be
aware of the QoS characteristics of these underlying protocols.
If either of the two is not QoS capable or provides insufficient
QoS, the request cannot be admitted.
We will assume that the L2TP is implemented over a QoS-capable network
and that the tunnel has a static and known QoS. If this is the
case, it is enough to insert in the PPP Switch information about
tunnels QoS at configuration time.
For the Ethernet part we must think more complex.
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 8]
INTERNET DRAFT July 2000
3.4.1 QoS-enabled Ethernet
The IEEE 802.1p standard defines a set of priority levels
that helps introduction of QoS in an Ethernet LAN. A priority
scheme is unavoidable if traffic has to be scheduled over limited
capacity interfaces. But a complete QoS system requires also
admission and policy enforcement.
If we consider that the critical part of the Ethernet LAN
(extended up to the PPP switch) is the Customer Premises Network,
one could avoid to deploy public admission and enforcement
mechanisms to guarantee QoS parameters at the Ethernet layer.
In fact we can assume the Ethernet portion that is shared among
several customers to be located entirely inside the PPP Switch site
and to support available band larger than the sum of the capacity
needed by all the customers. This given, only the private portions
of the Ethernet must be checked against unfair bandwidth allocation,
but this is reasonably up to the owner of the resource.
A more general scheme should include complete Ethernet QoS
mechanisms to be developed. Inside IETF it is being standardized
how an Ethernet switch must interpret the RSVP signaling in order
to manage the bandwidth and provide QoS. This work led to the
development of "A framework for providing Integrated Services over
shared and switched IEEE 802 LAN technologies" [SBMFRAME]
and to the definition of the "SBM (Subnet Bandwidth Manager):
a protocol for RSVP-based admission control over IEEE 802-style
networks" [SBMPROT] (Internet-Drafts of the Integrated Services
over Specific Link Layers Working Group). In the reference model
presented in the draft, the signaling information carried by
RSVP is extracted and interpreted by every Ethernet switch it
passes across.
A new framework with similar characteristics is then needed
if we want to preserve the QoS parameters contracted by means of
PPPoE. The situation here could be simplified compared to native
SBM, as we have a centralized control point (the PPPoE server). If we
provide the PPPoE server with the knowledge of the entire Ethernet
access network, it will have the possibility to exercise
the Admission Control function during a PPPoE discovery phase.
According to the required service, an appropriate IEEE 802.1p
priority will be assigned to the service.
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 9]
INTERNET DRAFT July 2000
4.0 References
[1] W. Simpson. "The Point-to-Point Protocol (PPP)", RFC 1661.
July 1994.
[2] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
B. Palter. "Layer Two Tunneling Protocol (L2TP)". August 1999.
[3] Y. T'Joens, P. Crivellari, B. Sales. "Layer Two
Tunneling Protocol: ATM Access Network extensions",
draft-ietf-l2tpext-atmext-02.txt. May 2000.
[4] S. Blake, T. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss.
"An Architecture for Differentiated Services". December 1998.
[5] S. Shenker, J. Wroclawski. "General characterization
parameters for Integrated Services network elements".
September 1997.
[6] R. Braden, L. Zang, S. Berson, S. Herzog, S. Jamin.
"Resource ReSerVation Protocol (RSVP)". September 1997.
5.0 Acknowledgements
This Draft has been largely inspired from an unpublished paper
written by Mauro Filippi (Marconi Services), Sergio Torassa
(Infostrada) and Giovanni Fiaschi (Marconi Communications).
The Authors would also like to acknowledge Diego Caviglia
(Marconi Communications) and Luca Patrone (Marconi Communications)
for their contributions to this Draft.
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 10]
INTERNET DRAFT July 2000
6.0 Authors' Addresses
Questions about this memo can be directed to:
Giovanni Fiaschi
Marconi
Marconi Communications S.p.A.
Via A. Negrone, 1/A
16153 GENOVA, ITALY
Phone: +39.10.6003583
Fax: +39.10.6003849
E-mail: giovanni.fiaschi@marconi.com
GianLuca Rolandelli
Marconi
Marconi Communications S.p.A.
Via A. Negrone, 1/A
16153 GENOVA, ITALY
Phone: +39.10.6003540
Fax: +39.10.6003849
E-mail: gianluca.rolandelli@marconi.com
Fabio Poggi
Marconi
Marconi Communications S.p.A.
Via A. Negrone, 1/A
16153 GENOVA, ITALY
Phone: +39.10.6003586
Fax: +39.10.6003849
E-mail: fabio.poggi@marconi.com
Fiaschi, Poggi, Rolandelli expires January 2001 [Page 11]
