Internet DRAFT - draft-brunner-nsis-req
draft-brunner-nsis-req
Andreas Schrader
Internet Draft Hannes Hartenstein
Document: draft-brunner-nsis-req-00.txt Ralf Schmitz
Expires: May 2002 Juergen Quittek
Morihisa Momona
Marcus Brunner
NEC
Robert Hancock
Eleanor Hepworth
Roke Manor Research
Mathias Rautenberg
Hannes Tschofenig
Cornelia Kappler
Hans-Peter Schwefel
Christoph Niedermeier
Siemens AG
Holger Karl
Xiaoming Fu
TU Berlin
Andreas Kassler
University Ulm
November 2001
Requirements for QoS Signaling Protocols
<draft-brunner-nsis-req-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.
Informational - Expires May 2002 1
Requirements for QoS Signaling Protocols November 2001
Abstract
This draft proposes a set of requirements for signaling QoS across
different network environments. To achieve wide applicability of the
requirements, the starting point is a diverse set of user scenarios
concerning both access and core networks, application interactions,
and use within cellular networks. We also provide an outline
structure for the problem, including QoS related terminology. Taken
with the user scenarios, this allows us to focus more precisely on
which parts of the overall QoS problem needs to be solved. We
present the assumptions and the aspects not considered within scope
before listing the requirements grouped according to areas such as
architecture and design goals, signaling flows, layering,
performance, flexibility, security, and mobility. The motivation for
each requirement is included as well as a distinction between
requirements that should be met by the core part of the solution and
those that could be implemented as extensions.
1. Introduction
In order to derive requirements for QoS signaling it is necessary to
first have a clear idea of the scope within which they are
applicable. After defining terminology in Section 2, we therefore
start in Section 3 with a set of QoS signaling scenarios. These
scenarios derive from a variety of backgrounds, and help obtain a
clearer picture of what is in or out of scope of the NSIS work. They
illustrate the problem of QoS signaling from various perspectives
(end-system, access network, core network) and for various areas
(fixed line, mobile, wireless environments). As the NSIS work
becomes more clearly defined, scenarios will be added or dropped, or
defined in more detail.
Based on these scenarios, we are able to define the QoS signaling
problem on a more abstract level. In Section 4, we thus present a
simple conceptual model of the QoS signaling problem, describe the
entities involved in QoS signaling, and typical signaling paths.
Additionally we list our assumptions and exclusions.
The model of Section 4 allows deriving requirements from the
scenarios presented in Section 2 in a coherent and consistent
manner. Requirements are grouped according to areas such as
Architecture and design goals, Signaling Flows, Layering,
Performance, Flexibility, Security and Mobility.
QoS is a pretty large field with a lot of interaction with other
protocols, mechanisms, applications etc. In the following, some
thoughts from an end-system point of view and from an network point
of view.
End-system perspective: In future mobile terminals, the support of
adaptive applications is more and more important. Adaptively can be
seen as an important technique to react to QoS violations that may
occur frequently, e.g., in wireless environments due to changed
environmental and network conditions. This may result in degraded
Brunner et al. Informational - Expires May 2002 2
Requirements for QoS Signaling Protocols November 2001
end-to-end performance. It is then up to adaptive applications to
react to the new resource availability. Therefore, it is essential
to define interoperability between media-, mobility- and QoS
management. While most likely mobile terminals cannot assume, that
explicit QoS reservation schemes are available, some access networks
nevertheless may offer such capabilities. Applications subscribed to
an end-system QoS management system should be supported with a
dedicated QoS API to set-up, control and adapt media sessions.
Network perspective: QoS enabled IP networks are expected to handle
two different kinds of QoS granularities: per-flow QoS and per-
trunk/per-class QoS. Per-flow QoS might be needed in access networks
and may there be subject of QoS signaling. However, in the core
network only per-trunk or per-class QoS can be considered for
scalability reasons. Therefore there might be different requirements
on QoS signaling applying to different parts of the network. In the
access network QoS signaling is an interaction between end systems
and access routers or access network QoS managers (in the following
we call them QoS initiator and QoS controller). In the core network
QoS signaling refers to trunks or classes of traffic between core
and edge systems or between peering core systems. Please note that
this does not exclude the transport of per-flow signaling through
core networks.
It is clear from these descriptions that the subject of QoS is
uniquely complex and any investigation could potentially have a very
broad scope - so broad that it is a challenge to focus work on an
area which could lead to a concrete and useful result. This is our
motivation for considering a set of use cases which map out the
domain of application that we want to address; these use cases are
given in section 3. It is also the motivation for defining a problem
structure, which allows us to state the boundaries of what types of
functionality to consider, and to list background assumptions. This
structure is given in section 4. The requirements themselves follow
in section 5. There are several areas of the requirements related to
networking aspects which are incomplete, for example, interaction
with host and site multi-homing, use of anycast services, and so on.
These issues should be considered in any future requirement analysis
work.
2. Terminology
Aggregate: a group of flows, usually with similar QoS requirements,
which can be treated together as a whole with a single overall QoS
requirement for signaling and provisioning. Aggregates and flows can
be further aggregated together.
[QoS] Domain: a collection of networks under the same administrative
control and grouped together for administrative purposes.
Egress point: the router via which a path exits a domain/subdomain.
End Host: the end system or host, for whose flows QoS is being
requested and provisioned.
Brunner et al. Informational - Expires May 2002 3
Requirements for QoS Signaling Protocols November 2001
End-to-End QoS: the QoS delivered by the network between two
communicating end hosts. End-to-end QoS co-ordinates and enforces
predefined traffic management policies across multiple network
entities and administrative domains.
Edge-to-edge QoS: QoS within an administrative domain that connects
to other networks rather than hosts or end systems.
Flow: a traffic stream (sequence of IP packets between two end
systems) for which a specific level of QoS is to be provided. The
flow can be unicast (uni- or bi-directional) or multicast.
Flow Administration: represents the policy associated with how flows
should be treated in the network, for example whether and how the
flows should be aggregated. It may consist of both user and local
network management information.
Higher Layers: the higher layer (transport protocol and application)
functions that request QoS from the network layer. The request might
be a trigger generated within the end system, or the trigger might
be provided by some entity within the network (e.g. application
proxy or policy server).
Indication: feedback from QoS provisioning to indicate the current
QoS being provided to a flow or aggregate, and whether any
violations have been detected by the QoS technology being used
within the local domain/subdomain.
Ingress point: the router via which a path enters a
domain/subdomain.
Mapping: the act of transforming parameters from QSCs to values that
are meaningful to the actual QoS technology in use in the
domain/subdomain.
Path: the route across the networks taken by a flow or aggregate,
i.e. which domains/subdomains it passes through and the
egress/ingress points for each.
Path segment: the segment of a path within a single
domain/subdomain.
QoS Administration Function: a generic term for all functions
associated with admission control, policy control, traffic
engineering etc.
QoS Control Information: the information the governs the QoS
treatment to be applied to a flow or aggregate, including the QSC,
flow administration, and any associated security or accounting
information.
QoS Controller: this is responsible for interpreting the signaling
carrying the user QoS parameters, optionally inserting/modifying the
Brunner et al. Informational - Expires May 2002 4
Requirements for QoS Signaling Protocols November 2001
parameters according to local network QoS management policy, and
invoking local QoS provisioning mechanisms.
QoS Initiator: this is responsible for generating the QSCs for
traffic flow(s) based on user or application requirements and
signaling them to the network as well as invoking local QoS
provisioning mechanisms. This can be located in the end system, but
may reside elsewhere in network.
QoS Provisioning: the act of actually allocating resources to a flow
or aggregate of flows, may include mechanisms such as LSP initiation
for MPLS, packet scheduler configuration within a router, and so on.
The mechanisms depend on the overall QoS technology being used
within the [sub]domain.
QoS Service Classes (QSC): specify the QoS requirements of a traffic
flow or aggregate. Can be further sub-divided into user specific
and network related parameters
QoS Signalling: a way to communicate QSCs and QoS management
information between hosts, end systems and network devices etc. May
include request and response messages to facilitate negotiation/re-
negotiation, asynchronous feedback messages (not delivered upon
request) to inform End Hosts, QoS initiators and QoS controllers
about current QoS levels, and QoS querying facilities.
[QoS] Subdomain: a network within an administrative domain using a
uniform technology/QoS provisioning function to provision resources.
QoS Technology: a generic term for a set of protocols, standards and
mechanisms that can be used within a QoS domain/subdomain to manage
the QoS provided to flows or aggregates that traverse the domain.
Examples might include MPLS, DiffServ, and so on. A QoS technology
is associated with certain QoS provisioning techniques.
QoS Violation: occurs when the QoS applied to a flow or aggregate
does not meet the requested and negotiated QoS agreed for it.
Resource: something of value in a network infrastructure to which
rules or policy criteria are first applied before access is granted.
Examples of resources include the buffers in a router and bandwidth
on an interface.
Resource Allocation: part of a resource that has been dedicated for
the use of a particular traffic type for a period of time through
the application of policies
For terminology in IP paging etc. see RFC 3132 [1] and in mobility
see [3].
3. Scenarios
Brunner et al. Informational - Expires May 2002 5
Requirements for QoS Signaling Protocols November 2001
In the following we describe some scenarios, which are important to
cover, and which allow us to discuss various requirements. Note that
the NSIS working group might choose to explicitly not cover some of
them.
3.1. Scenario 1: Terminal Mobility
The scenario we are looking at is the case where a mobile terminal
(MT) changes from one access point to another access point. The
access points are located in separate QoS domains. We assume Mobile
IP to handle mobility on the network layer in this scenario and
consider the various extensions (i.e., IETF proposals) to Mobile IP,
in order to provide 'fast handover' for roaming Mobile Terminals.
The goal to be achieved lies in providing, keeping, and adapting the
requested QoS for the ongoing IP sessions in case of handover.
Furthermore, the negotiation of QoS parameters with the new domain
via the old connection might be needed, in order to support the
different 'fast handover' proposals within the IETF.
The entities involved in this scenario include a mobile terminal,
access points, a access network manager, communication partners of
the MT (the other end(s) of the communication association).
From a technical point of view, terminal mobility means changing the
access point of a mobile terminal (MT). However, technologies might
change in various directions (access technology, QoS technology,
administrative domain). If the access points are within one specific
QoS technology (independent of access technology) we call this
intra-QoS technology handoff. In the case of an inter-QoS technology
handoff, one changes from e.g. a DiffServ to an IntServ domain,
however still using the same access technology. Finally, if the
access points are using different access technologies we call it
inter-technology hand-off.
The following issues are of special importance in this scenario:
1) Handoff decision
- The QoS management requests handoff. The QoS management can decide
to change the access point, since the traffic conditions of the new
access point are better supporting the QoS requirements. The metric
may be different (optimized towards a single or a group/class of
users). Note that the MT or the network (see below) might trigger
the handoff.
- The mobility management forces handoff. This can have several
reasons. The operator optimizes his network, admission is no longer
granted (e.g. emptied prepaid condition). Or another example is when
the MT is reaching the focus of another base station. However, this
might be detected via measurements of QoS on the physical layer and
is therefore out of scope of QoS signaling in IP. Note again that
the MT or the network (see below) might trigger the handoff.
- This scenario shows that local decisions might not be enough. The
rest of the path to the other end of the communication needs to be
Brunner et al. Informational - Expires May 2002 6
Requirements for QoS Signaling Protocols November 2001
considered as well. Hand-off decisions in a QoS domain, does not
only depend on the local resource availability, e.g., the wireless
part, but involves the rest of the path as well. Additionally,
decomposition of an end-to-end reservation might be needed, in order
to change only parts of it.
2) Trigger sources
- Mobile terminal: If the end-system QoS management identifies
another (better suited) access point, it will request the handoff
from the terminal itself. This will be especially likely in the case
that two different provider networks are involved. Another important
example is when the current access point bearer disappears (e.g.
removing the Ethernet cable). In this case, the QoS initiator is
basically located on the mobile terminal.
- Network (access network manager): Sometimes, the handoff trigger
will be issued from the network management to optimize the overall
load situation. Most likely this will result in changing the base-
station of a single providers network. Most likely the QoS initator
is located on a system within the network.
3) Integration with other protocols
- Interworking with other protocol must be considered in one or the
other form. E.g., it might be worth combining QoS signaling between
different QoS domains with mobility signaling at hand-over.
3.2. Scenario 2: Cellular Networks
In this scenario, the user is using the packet service of a 3rd
generation cellular system, e.g. using UMTS. The region between the
End Host and the edge node connecting the cellular network to
another QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is
considered to be a single QoS domain [4][5].
Cellular systems provide their own QoS technology with specialized
parameters to co-ordinate the QoS provided by both the radio access
and access network. For example, in a UMTS network, one aspect of
GPRS is that it can be considered as a QoS technology; provisioning
of QoS within GPRS is described mainly in terms of things called
UMTS bearer classes. This QoS technology needs to be invoked with
suitable parameters when a request for QoS is triggered by higher
layers, and this therefore involves mapping the requested IP QoS
onto these UMTS bearer classes. This request for resources triggers
IP signaling messages that pass across the cellular system, and
possibly other QoS domains, to negotiate for network resources.
Typically, cellular system specific messages invoke the underlying
cellular system QoS technology in parallel with the IP QoS
negotiation, to allocate the resources within the cellular system.
The QoS initiator could be located at the End Host (triggered by
applications), the GGSN/PDSN, or at a node not directly on the data
path, such as a bandwidth broker. In the second case, the GGSN/PDSN
Brunner et al. Informational - Expires May 2002 7
Requirements for QoS Signaling Protocols November 2001
could either be acting as a proxy on behalf of an End Host with
little capabilities, and/or managing aggregate resources within its
QoS domain (the UMTS core network). The IP signaling messages are
interpreted by the QoS controllers, which may be located at the
GGSN/PDSN, and in any QoS sub-domains within the cellular system.
IP-level QoS re-negotiation may be initiated by either the End Host,
or by the network, based on current network loads.
Note that in comparison to the former scenario, the emphasis is much
less on the mobility aspects, because mobility is mainly handled on
the lower layer.
3.3. Scenario 3: Session mobility
In this scenario, a session is moved from one end-system to another.
Ongoing sessions are kept and QoS parameters need to be adapted,
since it is very likely that the new device provides different
capabilities. Note that it is open which entity initiates the move,
which implies that the QoS initiator might be triggered by different
entities.
User mobility (i.e., a user changing the device and therefore moving
the sessions to the new device) is considered to be a special case
within the session mobility scenario.
Note that this scenario is different from terminal mobility. Not the
terminal (end-system) has moved to a different access point. Both
terminals are still connected to an IP network at their original
points. Keeping the QoS guarantees negotiated implies that the end-
point(s) of communication are changed without changing the
reservations.
3.4. Scenario 4: QoS reservations/negotiation from access to core
network
The scenario includes the signaling between access networks and core
networks in order to setup and change reservations together with
potential negotiation.
The issues to be solved in this scenario are different from previous
ones. The entity of reservation is most likely an aggregate, and the
time scales of reservations might be different (long living
reservations of aggregates, rarer re-negotiation). However, the
specification of the traffic, a particular QoS is guaranteed for,
needs to be changed. E.g., in case additional flows are added to the
aggregate, the traffic specification of the flow needs to be added
if it is not already included in the aggregates specification.
3.5. Scenarios 5: QoS reservation/negotiation over administrative
boundaries
Signaling between two or more core networks to provide QoS is
handled in this scenario. The might also include access to core
signaling over administrative boundaries. Compare to the previous
Brunner et al. Informational - Expires May 2002 8
Requirements for QoS Signaling Protocols November 2001
one it adds the case, the two networks are not in the same
administrative domain. Basically, it is the inter-domain/inter
provider signaling which is handled in here.
The domain boundary is the critical issue to be resolved. Normally,
only basic information should be exchanged, if the signaling is
between competing administrations. Specifically information about
core network internals (e.g., topology, technology, etc.) should not
be exchanged. Some information exchange about the "access points" of
the core networks (which is topology information as well) may need
to be exchanged.
Additionally, as in scenario 4, signaling most likely is based on
aggregates.
4. Problem Statement and Scope
We provide in the following a preliminary architectural picture as a
basis for discussion. We will refer to it in the following
requirement section.
The overall problems to be solved have been given at a top level by
the use cases/scenarios of section 3. However, the problem of QoS
has an extremely wide scope and there is a great deal of work
already done to provide different components of the solution, such
as QoS technologies for example. A basic goal should be to re-use
these wherever possible, and to focus requirements work at an early
stage on those areas where a new solution is needed (e.g. an
especially simple one). We also try to avoid defining requirements
related to internal implementation aspects.
In this section, we present a simple conceptual model of the overall
QoS problem in order to identify the applicability to NSIS of
requirements derived from the use cases, and to clarify the scope of
the work, including any open issues. This model also identifies
further sources of requirements from external interactions with
other parts of an overall QoS solution, clarifies the terminology
used, and allows the statement of design goals about the nature of
the solution (see section 5).
Note that this model is intended not to constrain the technical
approach taken subsequently, simply to allow concrete phrasing of
requirements (e.g. requirements about placement of the QoS
initiator, or ability to 'drive' particular QoS technologies.)
4.1. Problem Discussion Model
A simple layer model covering a single path segment is shown in
figure 1, using the terminology from Section 2.
Roughly, the scope of NSIS within the context of this diagram is
assumed to be the interaction between the initiator and
controller(s), including selection of signaling protocols to carry
Brunner et al. Informational - Expires May 2002 9
Requirements for QoS Signaling Protocols November 2001
the QoS information, and the syntax/semantics of the information
that is exchanged. Further statements on assumptions/exclusions are
given below. The main elements shown are:
1. Something that starts the request for QoS, the QoS Initiator.
This might be in the end system or within some part of the network.
The distinguishing feature of the QoS initiator is that it acts on
triggers coming (directly or indirectly) from the higher layers in
the end systems, mapping the QoS requested by them, and also
provides feedback information to the higher layers which might be
used by transport layer rate management or adaptive applications.
2. Something that assists in managing QoS further along the path,
the QoS controller. The QoS controller does not interact with higher
layers, but interacts with the QoS initiator and possibly more QoS
controllers on the path, edge to edge or possibly end to end.
3. The QoS initiator and controller(s) interact with each other,
path segment by path segment. This interaction involves the exchange
of data (QoS control information) over some signaling protocol.
4. The path segment traverses an underlying network (QoS domain or
subdomain) covering one or more IP hops. The underlying network uses
some local QoS technology. This QoS technology has to be provisioned
appropriately for the flow, and this is done by the QoS initiator
and controller(s), mapping their QoS control information to
technology-related QoS parameters and receiving indications about
success or failure in response.
Brunner et al. Informational - Expires May
2002 10
Requirements for QoS Signaling Protocols November 2001
.............. ................
. request/ . . response/ .
.trigger from. . feedback to .
.higher layer. .higher layers .
.............. ................
| ^
| |
| | ...............
| | . QoS Control .
V | . Information .
+----------------+ ............... +----------------+
--->| |------------------------->| |->
| | QoS signalling | |
| QoS Initiator | (request/query, | QoS Controller |
| | response/error etc.) | |
<---| |<-------------------------| |<-
+----------------+ +----------------+
^ | ^ |
| | | |
| ............ | | ............ |
| QoS | | QoS |
| provisioning | | provisioning |
| commands & | | commands & |
| responses | | responses |
| ............ | | ............ |
| | | |
| | | |
| V | V
+--------------------------------------------------------------+
| QoS (sub)domain using any |
| Qos technology |
| |
| +------+ +------+ +------+ |
| |Router| |Router| |Router| |
=========| |=======| |=====================| |=======
| | | | | flow path | | |
| +------+ +------+ +------+ |
+--------------------------------------------------------------+
Figure 1: Generic scope of signaling
A second diagram, figure 2, concentrates more on the overall end to
end (multiple QoS domains) aspects, in particular:
1. The QoS initiator need not be located at the end system, and the
QoS controllers are not assumed to be located on the flow path.
However, they must be able to identify the ingress and egress points
for the flow path as it traverses the domain/subdomain. Any
signalling protocol must be able to find the appropriate QoS
controller and carry this ingress/egress point information.
2. We see the network at the level of domains/subdomains rather than
individual routers (except in the special case that the domain
Brunner et al. Informational - Expires May 2002 11
Requirements for QoS Signaling Protocols November 2001
contains one link). Domains are assumed to be administrative
entities, so security requirements apply to the signaling between
them. Subdomains are introduced to allow the fact a given QoS
provisioning mechanism may only be used within a part of a domain,
typically for a particular subnetwork technology boundary.
Aggregation can also take place at subdomain boundaries.
3. Only a unicast flow is shown, with the QoS initiator at or near
one end. However, we do not exclude bi-directional flows with the
QoS requested by either end. Further QoS initiators may exist on the
path. Multicast or anycast flows or flows with variable paths within
a subdomain (e.g. to a mobile end system) are also logically
possible.
4. Any domain may contain QoS administration functions (e.g. to do
with traffic engineering, admission control, policy and so on).
These are assumed to interact with the QoS initiator and controllers
(and end systems) using standard mechanisms.
Brunner et al. Informational -
Expires May 2002 12
Requirements for QoS Signaling Protocols November 2001
+--------------------------+
| QoS Domain |
+----+ flow path +-+ +-+
|Host|==================|R|========================|R|==========++
+----+ +-+ +-+ ||
| \ / | ||
| \+----+ +----+/ | ||
| |QoS | |QoS | | ||
| |cont| |init| | ||
| +----+ +----+ | ||
| ^ ^ | ||
| | | | ||
| V V | ||
| +------------------+ | ||
| |QoS administration| | ||
| | functions | | ||
| +------------------+ | ||
+--------------------------+ ||
||
+-----------------------------------------+ ||
| +--------------------+ | ||
| +-----| QoS controller |--+ | ||
| / +--------------------+ \ | ||
| / \ | ||
| / +--------------------------+ \ | ||
| / | QoS Subdomain | \ | ||
+----+ +-+ +-+ +-+ +-+ ||
|Host|========|R|======|R|************************|R|===|R|====++
+----+ +-+ +-+ aggregate path +-+ +-+
| | \ / | |
| | \+----+ +----+/ | |
| | |QoS | |QoS | | |
| | |init| |cont| | |
|QoS | +----+ +----+ | |
|Domain +--------------------------+ |
+-----------------------------------------+
Figure 2: Signaling in a multiple (QoS)domains
4.2. Assumptions and Non-Assumptions
1. The NSIS signaling could run end to end, end to edge, or edge to
edge, or network-to-network ((between providers), depending on what
point in the network acts as the initiator, and how far towards the
other end of the network the signaling propagates. One extreme would
be to have the initiator at the end system and the scope of
signaling only as far as the first hop router; another would be to
have signaling edge to edge across an interior QoS domain, triggered
e.g. by a application layer proxy.
2. It does not make much sense to consider 'pure' end-to-end QoS
signaling that is not interpreted anywhere within the network.
Brunner et al. Informational - Expires May 2002 13
Requirements for QoS Signaling Protocols November 2001
Mainly in the area of mobility it is essential to decompose the path
into path segments (see scenario 1,2,3). This is part of the
transport or application layers.
3. Where the signaling does cover several QoS domains or subdomains,
we do not exclude that different signaling protocols are used in
each path segment. We only place requirements on the universality of
the QoS control information that is being transported. (The goal
here would be to allow the use of signaling protocols which are
matched to the characteristics of the portion of the network being
traversed.) Note that the outcome of NSIS work might result in
various protocols or various flavors of the same protocol. This
implies the need for the translation of information into QoS domain
specific format as well.
4.3. Exclusions
1. Development of specific mechanisms and algorithms for application
and transport layer adaptation are not considered, nor are the
protocols that would support it.
2. Specific mechanisms (APIs and so on) for interaction between
transport/applications and the network layer are not considered,
except to clarify the requirements on the negotiation capabilities
and information semantics that would be needed of the signaling
protocol. The same applies to application adaptation mechanisms.
3. Specific mechanisms for QoS provisioning within a
domain/subdomain are not considered. It should be possible to
exploit these mechanisms optimally within the end to end context.
Consideration of how to do this might generate new requirements for
NSIS however. For example, the information needed by an QoS
controller to manage a radio subnetwork needs to be provided by the
NSIS solution.
4. Specific mechanisms (APIs and so on) for interaction between the
network layer and underlying QoS provisioning mechanisms are not
considered.
5. Interaction with QoS administration capabilities is not
considered. Standard protocols should be used for this (e.g. COPS).
This may imply requirements for the sort of information that should
be exchanged between the NSIS network QoS entities.
6. Security issues related to multicasting are outside the scope of
the QoS signaling protocol.
Since multicasting is currently not an issue for the QoS protocol,
security issues related to multicast are outside the scope.
Multicast security may additionally be an application issue which is
also outside the scope of the QoS protocol.
7. Protection of non-QoS signaling messages are outside the scope of
the QoS protocol
Brunner et al. Informational - Expires May 2002 14
Requirements for QoS Signaling Protocols November 2001
Security protection of data messages transmitted along the establish
QoS path are outside the scope of the QoS protocol. These security
properties are likely to be application specific and may be provided
by the corresponding application layer protocol.
5. Requirements
This section defines more detailed requirements for a QoS signaling
solution, derived from consideration of the use cases/scenarios, and
respecting the framework, scoping assumptions, and terminology
considered earlier. The requirements are in subsections, grouped
roughly according to general technical aspects: architecture and
design goals, topology issues, QoS parameters, performance,
security, information, and flexibility.
Two general (and potentially contradictory) goals for the solution
are that it should be applicable in a very wide range of scenarios,
and at the same time lightweight in implementation complexity and
resource requirements in nodes. One approach to this is that the
solution could deal with certain requirements via modular components
or capabilities, which are optional to implement in individual
nodes. Requirements which could be handled this way are labeled
[Extension] in what follows.
There may be a better label than [Extension], but we think it has
the right implications: it doesn't imply 'optional to solve in the
work of the group' (like 'option' would) but it does not need to be
part of a 'core' solution.
Some of the requirements are technically contradictory. Depending on
the scenarios a solution apply to one or the other requirement is
applicable. We believe that the working group needs to decide first
on the scenarios to be covered, and which one to exclude.
5.1. Architecture and Design Goals
This section contains requirements related to desirable overall
characteristics of a solution, e.g. enabling flexibility, or
independence of parts of the framework.
1) Signaling must be applicable for different QoS technologies.
This includes sufficient QoS information. The information exchanged
over the signaling protocol must be in such detail and quantity that
it is useful for various QoS technologies.
2) Resource availability information on request [Extension]
In some scenarios, e.g., the mobile terminal scenario, it is
required to query, whether resources are available, without
performing a reservation on the resource. Feedback
3) Modularity
Brunner et al. Informational - Expires May 2002 15
Requirements for QoS Signaling Protocols November 2001
A modular design should allow for more lightweight implementations,
if fewer features are needed. Mutually exclusive solutions are
supported. Examples for modularity:
- Work over any kind of network (narrowband / broadband, error-prone
/ reliable...) - This implies low bandwidth signaling and redundant
information must be supported if necessary.
- In case QoS requirements are soft (e.g. banking transactions,
gaming), fast and lightweight signaling (e.g., not more than one
round-trip time)
- Uni- and bi-directional reservations are possible
4) Decoupling of protocol and information it is carrying
The signaling protocol(s) used should be clearly separated from the
QoS control information being transported. This provides for the
independent development of these two aspects of the solution, and
allows for this control information to be carried within other
protocols, including application layer ones, to be developed in the
future. The gained flexibility in the information transported allows
for the applicability of the same protocol in various scenarios.
However, note that the information carried needs to be the same.
Otherwise interoperability is difficult to achieve.
5) Reuse of existing QoS provisioning
Reuse existing QoS functions and protocols for QoS provisioning
within a domain/subdomain unchanged. (Motivation: 'Don't re-invent
the wheel'.)
6) Avoid duplication of [sub]domain signaling functions
The specification of the NSIS signaling protocol should be optimised
to avoid duplication of existing [sub]domain QoS signaling and to
minimise the overall complexity. (Motivation: we don't want to
introduce duplicate feedback or negotiation mechanisms, or
complicate the work by including all possible existing QoS signaling
in some form. The function will be placed in the new part if it has
to be end-to-end, universal to all network types
('simple/lightweight'), or if it has to be protected by upper layer
security mechanisms.)
The point here is that the QoS technology (lower layer stuff) gets
re-used unchanged, and we have new signaling above it. But, in many
cases the local QoS technology will contain equivalent functions to
the NSIS-required ones, just in a technology specific form. Examples
of these functions would be error/QoS violation notifications,
ability to query for resources and so on. So, there is a danger that
our 'lightweight' signaling ends up trying to carry all this
information all over again, and (even worse) that the
initiator/controller functions have to weigh up nearly equivalent
information coming from two directions. However, the basic problem
here is that the boundary between new and re-used stuff is pretty
shaky. The requirement is trying to scope our problem (a) to
eliminate the potential overlap, and (b) to keep the new NSIS stuff
simple.
Brunner et al. Informational - Expires May 2002 16
Requirements for QoS Signaling Protocols November 2001
7) Avoid modularity with large overhead (in various dimensions)
The protocols used for transporting signaling information over
various path segments do not need to be the same. Only the QoS
control information needs to be interworked between each segment.
(Motivation: the protocol can be chosen optimally for the
characteristics of the QoS domain being traversed. Also, we allow a
choice of protocols in end systems and networks without forcing
everyone to implement all choices; the network implementer's choice
of protocol can be local.)
8) Possibility to use the signaling protocol for existing local
technologies
It needs to be possible to use the new signaling as another local
QoS technology in its own right. For example, the treatment of
aggregates but possibly for other reasons also. Note that figure 2
shows precisely this case, it is being used there to support
signaling QoS for the aggregates.
5.2. Signaling Flows
This section contains requirements related to the possible signaling
flows that should be supported, e.g. over what parts of the flow
path, between what entities (end-systems, routers, middleboxes,
management systems), in which direction.
1) The protocol(s) must work in various scenarios end-to-end, edge-
to-edge, (e.g., just within one providers domain), user-to-network
(from end system into the network, ending, e.g., at the entry to the
network and vice versa), network-to-network (e.g., between
providers). In the figures of section 4, this means the location of
QoS Initiator and QoS Controllers can be chosen freely.
2) QoS signaling and QoS Controllers must not be constrained to be
in the data path.
3) Concealment of topology
In various scenarios, topology information should be hidden for
various reasons. From a business point of view, some administrations
don't want to reveal the topology and technology used.
4) Optional transparency of QoS signaling to network
It should be possible for the QoS signaling for some flows to
traverse path segments transparently, i.e. without interpretation at
QoS controllers within the network. An example would be a subdomain
within a core network, which only interpreted signaling for
aggregates established at the domain edge, with the flow-related
signaling passing transparently through it.
5.3. Additional information beyond signaling of QoS information
This section contains the desired signaling (messages) for other
purpose other than that for conveying QoS parameters.
Brunner et al. Informational - Expires May 2002 17
Requirements for QoS Signaling Protocols November 2001
1) Explicit release of resources
When a QoS reservation is no longer necessary, e.g. because the
application terminates, or because a mobile host experienced a hand-
off, it must be possible to explicitly release resources.
2) Ability to signal life-time of a reservation
Information about the life-time of a reservation allows to reduce
the reservation update frequency in case of soft state based
signaling. Note however, that we do not require in advance
reservation, only the expected duration of the reservation should be
included.
3) Possibility for automatic release of resources after failure
When the QoS Initiator goes down, the resources it requested should
be released, since they will no longer be necessary.
4) Possibility for automatic re-setup of resources after recovery
[Extension]
In case of a failure, the reservation can get setup again
automatically. It enables sort of a persistent reservation, if the
QoS Initiator requests it. In scenarios where the reservations are
on a longer time scale, this could make sense to reduce the
signaling load in case of failure and recovery.
5) Prompt notification of QoS violation in case of error / failure
to QoS Initiator and QoS Controllers
6) Feedback about the actually received level of QoS guarantees
The feedback must be independent of streaming technology used.
In some scenarios it might be requested to receive statistics about
the QoS received. E.g., feedback information might be used as input
to adaptation mechanisms.
7) Automatic notification on available resources not been granted
before [Extension]
In many cases, a QoS initiator does want to get a notification if
the resource he requested for some time ago, gets free. In order to
keep it simple, information on how long a request is kept and
notified. It implies keeping state about requests, which have been
rejected.
5.4. Layering
This section contains requirements related to the way the signaling
being considered interacts with upper layer functions (users,
applications, and QoS administration), and lower layer QoS
technologies.
1) The signaling protocol and QoS control information should be
application independent. However, opaque application information
should get transported in the signaling message, without being
handled in the network. Development and deployment of new
applications should be possible without impacting the network
Brunner et al. Informational - Expires May 2002 18
Requirements for QoS Signaling Protocols November 2001
infrastructure. Additionally, QoS protocols are expected to conform
to the Internet principles.
5.5. QoS Control Information
This section contains requirements related to the QoS control
information that needs to be exchanged.
1) Mutability information on parameters
It should be possible for the initiator to control the mutability of
the QSC information. This prevents from being changed in a non-
recoverable way. The initiator should be able to control what is
requested end to end, without the request being gradually mutated as
it passes through a sequence of domains. This implies that in case
of changes made on the parameters, the original requested ones must
still be available.
2) Possibility to add and remove local domain information
It should be possible for the QoS control functions to add and
remove local scope elements. E.g., at the entrance to a QoS domain
domain-specific information is added, which is used in this domain
only, and the information is removed again when a signaling message
leaves the domain. The motivation is in the economy of re-use the
protocol for domain internal signaling of various information. Where
additional information is needed for QoS control within a particular
domain, it should be possible to carry this at the same time as the
'end to end' information.)
3) The QoS service classes should be defined taking into account how
they will be mapped to QoS provisioning or upper layer parameters.
(Motivation: the simpler and more direct this mapping, the more
faithful the overall QoS provided to the application.)
4) Aggregation method specification
The initiator should be able to specify the aggregation method that
will be applied to the flow. Since the aggregation method implicitly
affects the QoS that applies to the flows, the initiator must be
able to influence this.
The point in this requirement is that a reservation for a flow may
make sense in isolation, but for scalability we need to aggregate
flows together (as we all know). The treatment of the flow within
the aggregate won't match the original reservation exactly - there
has to most likely be an information loss - but the user (QoS
initiator) should be able to at least indicate how the aggregation
takes place.
As an example, we use a controlled load service request for NRT
traffic as an example. the initiator is happy to have just some sort
of fair sharing with other flows within the aggregate rather than
precise matching of the leaky bucket parameters at every hop along
the aggregate path. a second more direct aspect is that a user might
want to make a set of reservations but indicate the way they get
Brunner et al. Informational - Expires May 2002 19
Requirements for QoS Signaling Protocols November 2001
aggregated together (e.g. set of reservations which are all intended
to share a common resource).
As another example, say a user has multiple web sessions running and
wants anything sent to him on port 80 to be aggregated onto a single
reservation where possible (so that he doesn't have to pay for
individual reservations for each session). The requirement is to
allow the user to specify a minimum aggregation that he would like
for his flows, but without preventing each individual domain from
further aggregating flows according to their own QoS technology.
5) Multiple levels of detail
The QSC should allow for multiple levels of detail in description.
(Motivation: someone interpreting the request can tune its own level
of complexity by going down to more or less levels of detail. A
lightweight implementation within the core could consider only the
coarsest level.)
6) Ranges in specification
The QSC should allow for specification of minimum required QoS
and/or desirable QoS. (Motivation: The QoS Service Classes should
allow optionally for ranges to be indicated, to minimize negotiation
latency and suppress error notifications during handover events.)
7) Independence of reservation identifier
A reservation identifier must be used, which is independent of the
flow identifier, the IP address of the QoS Initiator, and the flow
end-points. Various scenarios in the mobility area require this
independence because flows resulting from handoff might have changed
end-points etc. but still have the same QoS requirement.
8) Seamless modification of already reserved QoS
In many case, the reservation needs to be updated (up or downgrade).
This must happen seamlessly without service interruption. At least
the signaling protocol must allow for it, even if some data path
elements might not be capable of doing so.
9) Signaling must support quantitative, qualitative, and relative
QoS specifications
10) QoS conformance specification
The initiator should be able to indicate how faithfully the QoS
provided by the network should conform to that requested.
(Motivation: this allows for some flexibility in the level of QoS
fulfilled by the network compared to that requested by the initiator
deep inside the network.)
5.6. Performance
This section discusses performance requirements and evaluation
criteria and the way in which these could and should be traded off
against each other in various parts of the solution.
1) Scalability
Brunner et al. Informational - Expires May 2002 20
Requirements for QoS Signaling Protocols November 2001
Scalability is a must anyway. However, depending on the scenario the
question to which extend the protocol must be scalable. The protocol
must be scalable:
- in the number of messages received by a signaling communication
partner (QoS initiator and controller)
- in number of hand-offs
- in the number of interactions for setting up a reservation
- in the number of state per entity (QoS initiators and QoS
controllers)
2) Low latency
Low latency is only needed in scenarios, where reservations are in a
short time scale (e.g. mobile environments), or where human
interaction is immediately concerned (e.g., voice communication
setup delay)
3) Low bandwidth consumption
Again only small sets of scenarios call for low bandwidth, mainly
those where wireless links are involved.
Note that many of the performance issues are heavily dependent on
the scenario assumed and are normally a trade-off between speed,
reliability, complexity, and scalability. The trade-off varies in
different parts of the network. For example, in radio access
networks low bandwidth consumption will overweight the low latency
requirement, while in core networks it may be reverse.
5.7. Flexibility
This section lists the various ways the protocol can flexibly be
employed.
1) Aggregation capability, including the capability to select and
change the level of aggregation.
2) Flexibility in the placement of the QoS initiator
It might be the sender or the receiver of content. But also network
initiated reservations are required in various scenarios.
3) Flexibility in the initiation of re-negotiation (QoS change
requests)
Again the sender or the receiver of content might initiate a re-
negotiation due to various reasons, such as local resource shortage
(CPU, memory on end-system) or a user changed application
preference/profiles. But also network-initiated re-negotiation is
required in cases, where the network is not able to further
guarantee resources etc.
4) Uni / bi-directional reservation
Both uni-directonal as well as bi-direction reservations must be
possible.
Brunner et al. Informational - Expires May 2002 21
Requirements for QoS Signaling Protocols November 2001
5.8. Security
This section includes security-related requirements.
1) The QoS protocol must provide strong authentication
A QoS protocol must make provision for enabling various entities to
be authenticated against each other using data origin and/or entity
authentication. The QoS protocol must enable mutual authentication
between the two communicating entities. The term strong
authentication points to the fact that weak plaintext password
mechanisms must not be used for authentication.
2) The QoS protocol must provide means to authorize resource
requests
This requirement demands a hook to interact with a policy entity to
request authorization data. This allows an authenticated entity to
be associated with authorization data and to verify the resource
request. Authorization prevents reservations by unauthorized
entities, reservations violating policies, theft of service and
additionally limit denial of service attacks against parts of the
network or the entire network.
3) The QoS signaling messages must provide integrity protection.
The integrity protection of the transmitted signaling messages
prevent an adversary from mounting denial of service attacks against
network elements participating in the QoS protocol, from hijacking a
connection and from forging reservation requests and the
corresponding replies.
4) The QoS signaling messages must provide protection against replay
attack.
To prevent replay of previous signaling messages the QoS protocol
must provide means to detect old messages. A solution must cover
issues of synchronization problems in the case of a restart or a
crash of a participating network element.
5) The QoS signaling protocol must allow for hop-by-hop security.
Hop-by-Hop security is a well-known and proven concept in QoS
protocols that allows intermediate nodes that actively participate
in the QoS protocol to modify the messages as required by the QoS
processing. Note that this requirement does not exclude end-to-end
security of a QoS reservation request. End-to-End security between
the initiator and the responder may be used to provide protection of
non-mutable data fields. Since the QoS protocol makes no provision
to establish an end-to-end security association such an end-to-end
protection cannot be a must-requirement.
6) The QoS protocol should allow identity confidentiality and
location privacy.
Brunner et al. Informational - Expires May 2002 22
Requirements for QoS Signaling Protocols November 2001
Identity confidentiality enables privacy and avoids profiling of
entities by an adversary eavesdropping the signaling traffic along
the path. The identity used in the process of authentication may
also be hidden to a limited extent from a network to which the
initiator is attached. It is however required that the identity
provides enough information for the access network to collect
accounting data. Location privacy is an issue for the initiator who
triggers the QoS protocol. In some scenarios the initiator may not
be willing to reveal location information to the responder.
7) The QoS protocol should provide hooks for AAA protocols
The security mechanism should be developed with respect to be able
to collect usage records from one or more network elements.
8) The QoS protocol should prevent denial-of-service attacks against
signaling entities.
To effectively prevent denial-of-service attacks the QoS protocol
and the used security mechanisms should not force to do heavy
computation to verify a resource request. The QoS protocol and the
used security mechanisms should not require large resource
consumption for example main memory to take place.
9) The QoS protocol should not disclose the network topology
The QoS protocol should allow hiding the internal structure of a QoS
domain from end-nodes and from other networks. Hence an adversary
should not be able to learn the internal structure of a network with
the help of the QoS protocol.
10) The QoS protocol may support confidentiality of signaling
messages.
Based on the signaling information exchanged between nodes
participating in the QoS protocol an adversary may learn both the
identities and the content of the QoS messages. To prevent this from
happening, confidentiality of the QoS requests in a hop-by-hop
manner may be provided. Note that hop-by-hop is always required
whenever entities actively participating in the protocol must be
able to read and eventually modify the content of the QoS messages.
This does not exclude the case where one or more network elements
are not required to read the information of the transmitted QoS
messages.
11) The QoS protocol should provide hooks to interact with
authentication and key management negotiation protocols
The negotiation of an authentication and key management protocols
within the QoS protocol is outside the scope of the QoS protocol.
The goal of such a negotiation step is to determine which
authentication and key management protocol to use is executed prior
to the execution of the chosen key management protocol. A QoS
Brunner et al. Informational - Expires May 2002 23
Requirements for QoS Signaling Protocols November 2001
protocol should however provide a way to interact with these
negotiation protocols.
12) The QoS protocol should provide means to interact with key
management protocols
Key management protocols typically require a larger number of
messages to be transmitted to allow a session key and the
corresponding security association to be derived. To avoid the
complex issue of mapping individual authentication and key
management protocols to a QoS protocol such a protocol is outside
the scope of the QoS protocol. Although the key management protocol
may be independent there must be a way for the QoS protocol to
exploit existing security associations to avoid executing a separate
key management protocol (or instance of the same protocol) for
protocols that closely operate together. If no such security
association exists then there should be means for the QoS protocol
to trigger a key management protocol to dynamically create the
required security associations.
5.9. Mobility
Mobility related requirements are already covered in [2], and are
not repeated here.
5.10.
Interworking with other protocols and techniques
Hooks must be provided to enable efficient interworking between
various protocols and techniques including:
1) Policies, traffic engineering, network management, accounting,
Session signaling (particularly SIP proxy), Context transfer
2) The solution should not constrain either to IPv4 or IPv6
3) Combination with Mobility management
Combining mobility and QoS signaling should be supported for
economic signaling behavior (e.g., negotiation with the new access
network: Mobile IP message to acquire new care-of address and query
for QoS information could be combined, in order to preserve
bandwidth and reduce latency).
4) Independence from charging model
Signaling must not be constrained by charging models or the charging
infrastructure used. However, the end-system should be able to query
current pay statistics and to specify user cost functions.
6. References
[1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem
Statement", RFC 3132, June 2001.
Brunner et al. Informational - Expires May 2002 24
Requirements for QoS Signaling Protocols November 2001
[2] Chaskar, H., "Requirements of a QoS Solution for Mobile IP",
draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress,
August 2001
[3] Manner. J., et al, "Mobility Related Terminology", draft-manner-
seamoby-terms-02.txt, Work In Progress, July 2001.
[4] 3GPP, "General Packet Radio Service (GPRS); Service Description
Stage 2 v 7.7.0", TS 03.60, June 2001
[5] 3GPP2, "Network Reference Model for cdma2000 Spread Spectrum
System, revision B", S.R0005-B, May 2001
[6] Bradner, S., Mankin, A., "Report of the Next Steps in Signaling
BOF", draft-bradner-nsis-bof-00.txt, Work in Progress, July 2001
[7] Partain, D., et al, "Resource Reservation Issues in Cellular
Radio Access Networks", draft-westberg-rmd-cellular-issues-00.txt,
Work in Progress, June 2001
7. Acknowledgments
Quite a number of people have been involved in the discussion of the
draft, adding some ideas, requirements, etc. We list them without a
guarantee on completeness: Changpeng Fan, Krishna Paul, Maurizio
Molina, Mirko Schramm.
8. Author's Addresses
Andreas Schrader, Hannes Hartenstein, Ralf Schmitz, Juergen Quittek,
Marcus Brunner
NEC Europe Ltd.
Network Laboratories
Adenauerplatz 6
D-69115 Heidelberg
Germany
E-Mail: brunner@ccrle.nec.de (contact)
Morihisa Momona
NEC Corporation
Japan
E-Mail: momona@ccm.cl.nec.co.jp
Robert Hancock, Eleanor Hepworth
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk
Cornelia Kappler
Siemens AG
Berlin 13623
Brunner et al. Informational - Expires May 2002 25
Requirements for QoS Signaling Protocols November 2001
Germany
Phone: +49-30-386-32894
E-Mail: cornelia.kappler@icn.siemens.de
Holger Karl, Xiaoming Fu
Technical University Berlin
Sekr. 5-2, Einsteinufer 25
Berlin 10587
Germany
Phone: +49-30-314-23826
E-Mail: [karl|fu]@ee.tu-berlin.de
Hans-Peter Schwefel
Siemens AG
Munich
Germany
Phone +49-89-722-59890
E-Mail: hans.schwefel@icn.siemens.de
Mathias Rautenberg
Siemens AG
Hofmannstr. 51
81359 Munchen
Germany
E-Mail: Mathias.Rautenberg@icn.siemens.de
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munchen
Germany
Email: Hannes.Tschofenig@mchp.siemens.de
Dr. Christoph Niedermeier
CT SE 2
Siemens AG
D-81730 Muenchen,
Germany
phone: ++49-89/636-45783
fax: ++49-89/636-40898
email: Christoph.Niedermeier@mchp.siemens.de
Andreas Kassler
Dept. Distributed Systems
University of Ulm
Oberer Eselsberg
89069 Ulm
Germany
Tel.: ++49 731 502 4139
Fax.: ++49 731 502 4142
eMail: kassler@informatik.uni-ulm.de
Brunner et al. Informational - Expires May 2002 26
Requirements for QoS Signaling Protocols November 2001
Brunner et al.
Informational - Expires May 2002 27
