NSIS Working Group Maarten Buchli
Internet Draft Danny Goderis
draft-buchli-nsis-req-00.txt Sven Van den Bosch
Expires: August 2002 Juan-Carlos Rojas
Stefan Custers
Alcatel
February 2002
QoS signaling requirements, interfaces and architecture
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
This draft gives evidence for the existence of different QoS
signaling interfaces based on a reference architecture that is
derived from two use cases. The main purpose is to refine the
requirements for the signaling interface that is being considered in
scope of NSIS.
The two use cases are the interconnection of PSTN trunking gateways
over an IP core network and the connection of an UMTS access network
to an IP core network. From these use cases a QoS reference
architecture is derived containing QoS Initiator (QI) and QoS
Controller (QC) entities, as defined in draft-brunner-nsis-req-
00.txt. The architecture encompasses the inter-connection of any
type of access networks over an IP DiffServ core network and does
not require any upgrade of the existing (and deployed) DiffServ
routers.
The proposed architecture identifies four relevant signaling
interfaces between functional entities. We believe the interface
between QI and QC to be of particular interest in the context of
Buchli et al. Informational - Expires August 2002 1
QoS signaling architecture, interfaces February 2002
and requirements
NSIS. Based on our architecture, the signaling protocol over this
interface can be kept simple.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Conventions used in this document..................................2
1. Introduction....................................................3
2. Terminology.....................................................4
3. Overview of signaling requirements..............................5
4. Use cases.......................................................6
4.1 PSTN trunking gateway scenario.................................7
4.2 UMTS access scenario...........................................8
5. General architecture............................................9
5.1 Signaling architecture........................................10
5.2 Protocol interfaces...........................................13
5.2.1 Host to QoS Initiator.......................................13
5.2.2 QoS Initiator to Access Gate................................13
5.2.3 QoS Initiator to QoS Controller (NSIS)......................14
5.2.4 QoS Controller to Network Management System (NMS)...........14
5.3 Evolution scenario............................................15
6. Requirements on the QoS Initiatorûto-QoS Controller interface..15
6.1 Signaling requirements........................................15
6.2 Requirements on protocol content..............................17
6.3 Open issues...................................................18
7. Security Considerations........................................18
8. Conclusions....................................................19
9. Acknowledgment.................................................20
References........................................................20
Author's Addresses................................................21
Buchli et al. Informational - Expires August 2002 2
QoS signaling architecture, interfaces February 2002
and requirements
1. Introduction
The task of the NSIS working group is to specify general QoS
signaling requirements and possibly propose a new protocol or
modifications to existing ones.
Two use cases are presented in this draft to explore such QoS
signaling requirements. The first case is a PSTN trunking gateway
interconnection scenario. The second case is the interconnection
between a UMTS access network and an IP core network.
In addition to the NSIS requirements draft [8], and based on the two
use cases, we introduce a QoS signaling reference architecture and
identify the different protocol interfaces that are in place. An
important observation is that several QoS signaling interfaces may
exist and that their requirements are of a different nature. We
identify four relevant signaling interfaces, which may be involved
in QoS provisioning. The most important being the interface between
the QoS Initiator (QI) and the QoS Controller (QC) as also described
in [8].
The basic requirements of the QI-to-QC interface are described and
compared with the requirements as expressed in [8]. In particular it
must be possible to gradually deploy the NSIS QoS solution on top of
existing networks. This high-level requirement yields concrete
consequences for the QoS signaling in as well access as core
networks.
First it is noted that access networks (UMTS, Packet cable, ADSL
access, etc) may use their own specific QoS signaling protocols for
quite some time. Moreover, in current networks, QoS signaling in
access may be very technology dependent, while for IP core networks
we need definitely a technology independent protocol. This may
involve mapping requirements and the draft discusses particular
features of this mapping and the actual place in the network where
this mapping can take place.
Thus, in a first phase, access networks may still use their own QoS
signaling, which is mapped onto a generic NSIS protocol by an entity
at the edge of the network. However, in a second phase the NSIS
protocol may also be supported by the end-host and used in the
access networks to setup QoS reservations. Hence, this provides an
evolution scenario for gradual deployment of the NSIS protocol in
access networks.
Second the QoS technology used by most operators in IP core networks
is Differentiated Services (DiffServ). It should be possible to
deploy the QoS solution onto these networks without upgrading the
routers. This may require the compatibility of in-band and out-of-
band signaling because, for pure DiffServ networks, the QoS
signaling can not be done on the data-path. This draft presents one
way of doing this for scenarios involving one IP core and several
access networks. It presents a two-step approach in order to support
Buchli et al. Informational - Expires August 2002 3
QoS signaling architecture, interfaces February 2002
and requirements
end-user Quality of Service (QoS). First step is to pre-provision
bandwidth pipes in the transport network defined by means of e.g.
DiffServ Service Level Specifications (SLS). These are e.g. IP VLLs
with statistical QoS guarantees, such as edge-to-edge delay and
packet loss bounds, for traffic aggregates. The second step is then
to admit (micro)-flows in the bandwidth pipes based on the user QoS
request. As a consequence of this two-step approach, the dynamic
per-flow QoS signaling can be simplified and kept out of the
(DiffServ) routers.
The outline of the draft is as follows.
The terminology is defined in section 2. Section 3 summarizes the
main signaling requirements for the QI-to-QC interface and makes the
comparison with [8]. Section 4 presents the two use cases while
section 5 draws conclusions and proposes a more general signaling
architecture. The requirements on the signaling protocol and the
parameter groups are discussed in section 6. The conclusions are
presented in the final section.
2. Terminology
The terminology used in this draft is in line with the DiffServ
terminology [10] and the NSIS requirements draft from Brunner et al.
[8]. The relevant terminology is repeated here and some new terms
are introduced. See e.g. figure 3 for a position of the relevant
functional entities in the network.
Host: end-user entity where the application is running that requires
QoS to another host or server. The end-user service, which should be
supported end-to-end by the network, is supposed to be a dynamic QoS
demanding service such as voice, video, etc.
Access Gate (AG): functional entity that enforces QoS policy by
policing and traffic conditioning per microflow.
In this context, a microflow is understood as the IP packet flow
carrying the payload of the actual service to be supported in the
network (e.g. voice) and may be formally defined as e.g. the IntServ
5-tuple. A microflow is always understood to be end-to-end, i.e.
host-to-host.
Edge router (ER): router at the edge of a Differentiated Services
(DiffServ) capable network. It is a common DiffServ edge router
enforcing QoS policy by policing and traffic conditioning traffic
aggregates and DiffServ Service Level Specifications SLS, see e.g.
[8][9].
According to DiffServ an SLS is "a set of technical parameters and
their values, which together define the service, offered to a
traffic stream by a (DiffServ) transport network". In this context,
an SLS is the technical specification of a long-lived QoS service
such as an IP VLL or an assured rate bandwidth pipe. The
geographical scope of an SLS is single domain, i.e. edge-to-edge.
The edge-to-edge statistical QoS guarantees, such as maximum delay,
Buchli et al. Informational - Expires August 2002 4
QoS signaling architecture, interfaces February 2002
and requirements
are provided to the in-profile packets of the traffic aggregate
stream defined by the SLS. For a detailed description of SLSs, see
[9]. For its support and implementation in a DiffServ network by
means of Per Hop Behaviors (PHB) and Per Domain Behaviors (PDB), see
[8].
Network Management System (NMS): common network and element
management platform, configuring the edge and core routers of a
single IP network by e.g. the SNMP or COPS protocol. In this context
the NMS is the functional entity responsible for the configuration
and provisioning of long-lived QoS services, which are technically
described by SLSs.
QoS Controller (QC): the functional entity that is ôresponsible for
interpreting the signaling carrying the end-user service QoS
parameters, optionally inserting/modifying the parameters according
to local network QoS management policy, and invoking local QoS
provisioning mechanismsö [8]. More specifically in this context the
QC performs per-microflow admission control for a single IP domain.
The QC manages or "owns" (part of) the pre-provisioned network
resources, which are described by a set of Service Level
Specifications. These SLSs provide statistical edge-to-edge QoS
guarantees.
QoS Initiator (QI): the functional entity ôgenerating the QoS
request 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ö [8]. This draft takes
the same viewpoint and discusses use cases for different locations
of the QI. The QI is in any case an ôNSIS-speakerö, i.e. it
implements the (to-be-defined) NSIS protocol and signals a QoS
request to the QC. In case the QI is situated at the network edge
(access-core), the QI should perform a mapping from the (access
technology dependent) user QoS request to the QoS request towards
the QC.
3. Overview of signaling requirements
The main purpose of this document is to derive requirements for NSIS
protocol interfaces that are identified from use cases. In this
section, we give an overview of the requirement list. The
requirements are primarily derived for the QI-QC interface but it
seems advantageous that they be reused (partly) for the QC-QC
interface. Each requirement will be put into context and clarified
in subsequent sections.
Apart from the generic requirements that the protocol should be fast
and lightweight, it
- must support both in-band and out-of-band signaling
- must support priority
- must allow notification of (QoS) failure
Buchli et al. Informational - Expires August 2002 5
QoS signaling architecture, interfaces February 2002
and requirements
- must decouple the messaging mechanism from the information being
signaled
- should be independent of core transport technology
- should avoid extra complexity due to (optional) multicast support
- should be optimized for interactive multimedia services
- should support different service levels for a service class
- the mobility aspects should have no impact on the NSIS protocol
Two considerations are left as open issues:
- the protocol may be stateful or stateless
- it should consider allowing grouping of microflows
Related work in the NSIS group [8] states that:
"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."
The two-step approach for which requirements are documented in this
draft achieves this goal of exploiting the QoS intra-domain
provisioning solution. In this way, it inherently addresses some of
the requirements in [8]:
- it avoids duplication of sub-domain signaling
- it provides independence of the underlying technology
- it reuses existing QoS technologies and does not impact existing
infrastructure during deployment
- it decomposes the path which is essential to provide mobility
It also emphasizes some other requirements in [8]:
- QoS signaling and QoS Controllers must not be constrained to be in
the data path
- the network is expected to handle 2 QoS granularities: per-flow
and per-trunk or per-class
Note, however, that an important difference is that per-flow
signaling can be considered in the core because the required amount
of signaling information is strongly reduced by the two-step
approach.
Finally, it allows to relax some of the signaling requirements in
[8]:
- the info that is passed as signaling content does not have to be
universal. It suffices that it can be translated by each domain in
the appropriate local QoS.
- communication between QoS administration functionality (e.g.
traffic engineering) and QI is not needed.
- it is not necessary to map opaque application-dependent
information in the message. The QI provides a mapping function and
the end-host to end-host alignment can be obtained at the
application layer.
4. Use cases
Buchli et al. Informational - Expires August 2002 6
QoS signaling architecture, interfaces February 2002
and requirements
In [8] the concepts of QoS Initiator (QI) and QoS Controller (QC)
were introduced. Here we analyze these functions for two concrete
use cases. In 3.1 a scenario of interconnecting PSTN trunking
gateways is discussed. In this case the QI and QC are integrated in
one entity. In 3.2 a possible scenario is shown for providing end-
to-end QoS with UMTS access networks. In this case the QI and QC are
two separate entities. In both cases the QI function is not part of
the end-host.
4.1 PSTN trunking gateway scenario
This section discusses an example scenario where a number of PSTN
trunking gateways are interconnected by a QoS enabled IP transport
network. The PSTN consists of a network carrying 64 kb/s circuits.
It is connected to the Edge Router (ER) of the IP network by a Media
GateWay (MG). The PSTN call signaling is transported over a separate
SS7 signaling network. This signaling network is connected to a
Media GateWay Controller (MGC). In the IP network the SS7 signaling
is carried with the ISUP/SIGTRAN protocol [11]. The MGC controls the
MG with the Megaco protocol [5].
In figure 1 the example scenario is shown for two media gateways,
i.e. trunking gateways. The Network Management System (NMS) is the
entity that is able to provision bandwidth pipes in the transport
network.
+-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+
: / : \
: / : \
: / +--------:----------+ \
: MEGACO / / : \ \
: / / +-----+ \ \
: / / | NMS | \ \
: / | +-----+ | \
: : | | :
+--------------+ +-----+ | bandwidth pipe (SLS) | +-----+
| PSTN network |--| MG |--|ER|=====================|ER|-| MG |--
+--------------+ +-----+ \ / +-----+
\ QoS network /
+-------------------+
Figure 1: PSTN trunking gateway scenario
Resources should be pre-provisioned between the media gateways. This
is done by establishing a mesh of bandwidth pipes, with strict delay
guarantees, between the trunking gateways. The capacity of the pipes
should be determined by means of traffic prediction and use of e.g.
Erlang calculations in order to provision for a small call blocking
probability.
Buchli et al. Informational - Expires August 2002 7
QoS signaling architecture, interfaces February 2002
and requirements
The MGC receives the call setup signaling and should perform per-
microflow admission control onto the pre-provisioned resources. The
MGC determines the rate of the microflow from the type of codec that
is used in the MG. The resource request is a number of 64kb channels
and hence, a simple counter to keep track of the used capacity of
the bandwidth pipe could be sufficient to perform admission control.
The MGC should have the information about the capacity of all
bandwidth pipes and should block call setups when the capacity is
completely used. The capacity of the bandwidth pipe may be
negotiated by an off-line process via paper contracts or by an
automated process with an SLS negotiation protocol.
In this scenario the MG has the role of Access Gate and the MGC acts
as the QoS Controller, performing admission control in the pre-
provisioned bandwidth pipes. The QoS Initiator functionality may
reside in as well the MG as in the MGC, exchanging information by
the MEGACO protocol. This depends on the concrete implementation of
MG and MGC. In any case the codec type must be mapped onto a traffic
descriptor, which is then used for the admission control of the
micro-flow into the bandwidth pipe.
In this scenario there may be a separate network provider (owning
the transport network and NMS) and voice service provider (owning
the MGs and the MGC). Both legal entities have a service level
agreement (SLA) and the technical part, i.e. the SLS, describes the
mesh of bandwidth pipes between the MGs. The existence of such a SLA
is shown as a line between MGC and NMS in figure 1. For more
details, see section 5.2 ôQC-to-NMS interfaceö. Remark also that
multiple service providers may be active on the same physical
network through SLAs with the network provider.
4.2 UMTS access scenario
The UMTS access scenario is shown in figure 2. The Proxy-Call State
Control Function/Policy Control Function (P-CSCF/PCF) is the
outbound SIP proxy of the visited domain, i.e. the domain where the
mobile user wants to set-up a call. The Gateway GPRS Support Node
(GGSN) is the egress router of the UMTS domain and connects the UMTS
access network to the Edge Router (ER) of the core IP network. The
P-CSCF/PCF communicates with the GGSN via the COPS protocol [4]. The
User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal
Equipment (TE), e.g. a laptop.
+--------+
+----------| P-CSCF |-------> SIP signaling
/ +--------+
/ SIP :
: +--------+ NSIS +----------------+
: | PCF |---------| QoS Controller |
: +--------+ +----------------+
Buchli et al. Informational - Expires August 2002 8
QoS signaling architecture, interfaces February 2002
and requirements
: :
: : COPS
: :
+----+ +--------+ +----+
| UE |----------| GGSN |------| ER |
+----+ +--------+ +----+
Figure 2: UMTS access scenario
In this scenario the GGSN has the role of Access Gate. According to
3GPP standardization, the PCF is responsible for the policy-based
control of the end-user service in the UMTS access network (i.e.
from UE to GGSN). In the current UMTS release R.5, the PCF is part
of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF
may evolve to an open standardized interface. In any case the PCF
has all required QoS information for per-flow admission control in
the UMTS access network (which it gets from the P-CSCF and/or GGSN).
Thus the PCF would be the appropriate entity to host the
functionality of QI, initiating the "NSIS" QoS signaling towards the
core IP network. The PCF/P-CSCF has to do the mapping from codec
type (derived from SIP/SDP signaling) to IP traffic descriptor. SDP
extensions to explicitly signal QoS information [7] are useful to
avoid the need to store codec information in the PCF and to allow
for more flexibility and accurate description of the QoS traffic
parameters. The PCF also controls the GGSN to open and close the
gates and to configure per-flow policers, i.e. to authorize or
forbid user traffic.
The QC is (of course) not part of the standard UMTS architecture.
However, to achieve end-to-end QoS a QC is needed such that the PCF
can request a QoS connection to the IP network. As in the previous
example, the QC could manage a set of pre-provisioned resources in
the IP network, i.e. bandwidth pipes, and the QC performs per-flow
admission control into these pipes. In this way, a connection can be
made between two UMTS access networks, and hence, end-to-end QoS can
be achieved. In this case the QI and QC are clearly two separate
entities.
This use case clearly illustrates the need for an "NSIS" QoS
signaling protocol between QI and QC. An important application of
such a protocol may be its use in the inter-connection of UMTS
networks over an IP backbone.
5. General architecture
This section proposes a QoS reference architecture generalizing the
examples discussed above. The architecture encompasses the inter-
connection of any type of (layer two) access networks with an IP
backbone and provides QoS to any type of (uni-cast) end-user
services (i.e. not only telephony services). The extension of the
architecture to multiple IP backbones, with multiple QCs on the end-
to-end signaling path, is for further study.
Buchli et al. Informational - Expires August 2002 9
QoS signaling architecture, interfaces February 2002
and requirements
In 4.1 the architecture is presented. The different signaling
interfaces are identified and discussed in 4.2. In 4.3 an NSIS
evolution scenario is discussed with regard to access networks.
5.1 Signaling architecture
The reference architecture is shown in figure 3. In this
architecture the host requests QoS to the QoS Initiator, which in
turn contacts the QoS Controller. The functional entities are shown
separately but they may be located in the same physical box. For the
sake of simplicity the access networks are presented as single lines
between host and Access Gates.
+----+ 3 NSIS +----+ NSIS +----+
+-| QI |-------------| QC |-------------| QI |-+
/ +----+ +----+ +----+ \
/ : : : \
1 / : 4 : SLS IF : \
/ : +-----:-----+ : \
/ : 2 / +-----+ \ : \
/ : / | NMS | \ : \
: : / +-----+ \ : :
: : | | : :
+------+ +----+ | | +----+ +------+
| Host |----| AG |===|ER|===================|ER|==| AG |---| Host |
+------+ +----+ | SLS | +----+ +------+
\ /
+---------------+
IP network
Figure 3: QoS signaling interfaces and functional entities
The architecture identifies at least three roles, i.e. the end-user,
the service provider (SP) and the network provider (NP). The NP is
the owner of the IP transport equipment. The SP naturally provides
end-user services and may or may not be the same entity as the NP.
For example the SP could be an UMTS mobile operator, leasing
transport capacity from an IP Network Provider. The leased capacity
inter-connects the Access Gates of the SP and is formalized by a
SLSs, which are part of a Service Level Agreement between NP and SP
(see section 5.2 ôQC-to-NMS interfaceö for more details).
The IP network is DiffServ enabled and therefore capable of
providing e.g. IP virtual leased line services. These IP VLLs are
specified by DiffServ Service Level Specifications (SLSs), which are
the technical part of the SLA.
QoS provisioning for individual flows is done by a two-step
approach. First step is to provision the capacity in the network by
provisioning bandwidth pipes between the ingress and egress points
of the IP network by means of SLSs. The second step is to perform
Buchli et al. Informational - Expires August 2002 10
QoS signaling architecture, interfaces February 2002
and requirements
admission control for microflows, i.e. checking whether they still
fit in the bandwidth pipe. This admission control function is done
by the QoS Controller.
The end-user QoS provisioning is described in detail below. Steps 1)
and 2) are the pre-provisioning steps for aggregate bandwidth pipes
(SLS). Steps 3) and 4) are the per-microflow signaling and admission
control steps.
1) The QoS Controller requests one or more bandwidth pipes (i.e.
virtual leased lines) to the NMS. These bandwidth pipe IP services
are specified as SLSs and are requested over an SLS interface or
they are negotiated off-line, resulting in a paper contract SLA (in
case NP and SP are distinct legal entities). The capacity of the
bandwidth pipes is based on some kind of traffic prediction process.
The SLSs are stored in databases in the QoS Controller and the NMS.
2) The NMS triggers a traffic management process in order to
provision the required resources (SLSs) in the network. This may
involve reconfiguring one or more network elements. The traffic
conditioning block in the edge routers are configured to police the
bandwidth pipes. Thus, the traffic is policed on an aggregate base.
3) The application (e.g. VoIP) at the end-host, requiring a
connection with QoS guarantees to another host or server, signals
the QoS request to the QoS Initiator. This signaling may be access
technology dependent. The QoS initiator performs the mapping to a
technology independent format and signals the QoS request to the QoS
Controller by the NSIS protocol.
4) The QoS Controller performs admission control for the QoS
request. It determines whether sufficient capacity is available in
the bandwidth pipes that are defined by the SLSs. The QC will return
an admit or reject message. Note, that this step does not involve
any configuration of network elements. If the flow has been admitted
the QoS Initiator will configure the Access Gate in order to police
the microflow.
This end-user QoS provisioning approach provides a clear distinction
between the provisioning of resources in the transport network and
the admission of per-microflow QoS requests. The per-flow QoS
signaling can therefore be kept simple since the complexity resides
mainly in the resource provisioning in the network and specification
of the bandwidth pipes (i.e. SLSs). The provisioning may be static
or semi-dynamic. The provisioning is anyhow already in place when
the per-flow QoS request arrive.
This two-step approach is also visible in the way the traffic is
policed. The edge router polices per SLS (bandwidth pipe), and
hence, on aggregated traffic. The Access Gate polices per-microflow.
The main point here is that the DiffServ network is not (required to
be) per micro-flow aware. The DiffServ network operator only
Buchli et al. Informational - Expires August 2002 11
QoS signaling architecture, interfaces February 2002
and requirements
provides QoS guarantees to the (SLA/SLS contracted) long-term
aggregate IP services such as IP virtual leased lines.
Above we made abstraction of the QoS class and QoS parameters to be
signaled. This is discussed in more detail below, but it is
instructive to make the following key observation at this point.
The main objective is to keep the NSIS signaling protocol between QI
and QC as simple as possible, certainly if it should be extended to
QC-to-QC inter-domain scenarios. Basically, the information to be
signaled is an indication of the QoS class plus a required
throughput R (peak rate, token rate, etc) for this particular QoS
class.
Indeed, provided the QoS class is determined by other means, the
required throughput is the main parameter needed by the QC to be
able to perform per-flow admission control (i.e. answering the
question whether there is still enough capacity in the QoS pipe SLS
for admitting e.g. R bandwidth units). We argue that there is no
need to signal delay values in the NSIS protocol (interface 3),
because the statistical delay bounds are already known and provided
by the SLSs. If the QC admits the request for R bandwidth units,
then the service will enjoy the delay bounds guaranteed by the SLS.
The remaining question is whether this approach can deal with
several service (QoS) classes. Suppose for example that there are
two QoS classes ôGoldö and ôSilverö. This could e.g. be used for the
offering of voice services with different quality. Another example
is to use the Gold QoS class for real-time, delay-sensitive services
and the Silver QoS class for elastic, non-delay sensitive services.
The latter only require a throughput guarantee. How is this handled
in the two-step approach described above?
First step: the pre-provisioning. The SLSs describing the bandwidth
pipes between the AGs may or may not contain edge-to-edge delay-
bound guarantees, corresponding respectively with gold and silver
type of services. The Gold and Silver SLSs are realized by
respectively the DiffServ Virtual Wire PDB and Assured Rate PDB.
Second step: per-flow signaling. Clearly the signaling between host
and QI (interface 1) must indicate whether the requested service is
gold or silver. The QoS class could also be implicitly derived from
the type of service (e.g. voice). Besides the QoS class the user
must at minimum also signal the required throughput.
In any case, the QI knows the appropriate QoS class and the required
throughput.
What remains to be decided is what information is signaled between
QI and QC. If the same QC is allowed to manage as well Gold as
Silver SLSs, then the QI needs to signal the required QoS Class. If
a QC only manages one type of SLSs, corresponding with one QoS
class, then the QI decides (based on QoS class information) which QC
Buchli et al. Informational - Expires August 2002 12
QoS signaling architecture, interfaces February 2002
and requirements
he has to request resources and signals (only) the required
throughput. It is for further study to decide whether both
approaches should be possible and able to inter work.
5.2 Protocol interfaces
5.2.1 Host to QoS Initiator
The host to QoS Initiator protocol interface will in most cases
depend on the access technology that is used. Due to the variety of
access QoS technologies it is to be expected that there will not be
one single protocol used over this protocol interface.
The QoS Initiator is the entity that triggers the actual QoS setup
in the core network. There are several possibilities how the host
can trigger the QoS Initiator.
1) The QoS Initiator may be integrated in a web-host or an outbound
SIP proxy. In the first case the end-user may e.g. use a webpage in
order to specify the service he/she would like to use. The web host
may then initiate a QoS connection. In the latter case, the host may
piggyback the QoS information on the session setup signaling. More
precisely, QoS information may be carried in SDP [7] and may be
interpreted by the SIP proxy, which will trigger the QoS setup in
the network.
2) The host uses an access specific layer 2 or 3 protocol. This is
e.g. an RSVP-derived protocol for PacketCable networks and the
Packet Data Protocol (PDP) for UMTS networks. For xDSL broadband
access a mechanism based on ATM Virtual Connections (VC) maybe used.
The AG intercepts this QoS signaling and forwards it to the QoS
Initiator. In this way the access specific QoS signaling is coupled
to the generic QoS setup in the core.
This protocol interface is within the scope of NSIS in the sense
that existing access signaling protocols should be assessed whether
they contain the minimum set of parameters that are required at the
QoS Initiator in order to map them to the generic signaling protocol
between the QoS Initiator and the QoS Controller. Of course, the
first step should be to specify this minimum set of parameters
required for the generic signaling protocol.
5.2.2 QoS Initiator to Access Gate
The protocol interface between the QI and the AG is used to
configure the AG such that it correctly installs per-flow policers.
In order to configure the policer a flow identifier is required
(e.g. five-tuple) and a traffic descriptor (e.g. token bucket
parameters). Optionally an indication for DiffServ packet marking
may be signaled (i.e. the DiffServ Code Point value).
Buchli et al. Informational - Expires August 2002 13
QoS signaling architecture, interfaces February 2002
and requirements
This protocol interface may be e.g. COPS [4] or a future MIDCOM [13]
protocol. Hence, this protocol interface is outside the scope of
NSIS.
5.2.3 QoS Initiator to QoS Controller (NSIS)
The protocol interface between the QoS Initiator and the QoS
Controller is discussed in section 6. This protocol is generic in
the sense that is technology independent. The QI is responsible for
mapping the access technology dependent user QoS request on this
protocol.
This protocol interface is certainly within the scope of NSIS.
5.2.4 QoS Controller to Network Management System (NMS)
A Service Level Agreement (SLA) is a legal agreement between a
customer and a provider. The technical part of the SLA is called a
Service Level Specification (SLS). The SLS specifies capacity and
QoS guarantees between one or more ingress and egress points of a
network. The SLS also specifies the availability and reliability of
the bandwidth service. The services specified in an SLS usually stay
in place for a long duration (e.g. days or months) and their setup
(time between the request of the service from the customer and the
availability) will not be real-time. The resources needed to fulfill
the SLS may be provisioned by means of traffic engineering. In case
the IP network is a DiffServ domain, the SLS may be implemented with
a PDB [6], e.g. a virtual wire or assured rate PDB.
Remark that it is not required for the architecture to automate this
interface. Indeed the SLA may be negotiated off-line yielding full
static SLS pipes between the Access Gates. It may however evolve to
an automated, (to-be-standardized) interface.
It is argued that automation and standardization of this SLS
interface may yield two key advantages for QoS provisioning. First,
it may be used to semi-dynamically negotiate SLSs. For example, if
the QoS Controller has to block too many calls between two AGs, the
QC may trigger the NMS for more resources on a dynamic basis.
Second, the interface may be used to exchange monitoring
information. In other words, the NMS may send information about e.g.
the current traffic load in the bandwidth pipe that is specified by
the SLS. The monitoring information applies to the traffic aggregate
SLSs. The QC may use this monitoring information to cross check
whether the currently admitted flows (and their throughput)
corresponds with the actual traffic load in the bandwidth pipe SLSs.
An SLS template has been specified by the European IST-project
Tequila [9] in order to facilitate for both functions.
Finally note that in figure 3 the SLS interface is shown as a line
between the QC and NMS. This is a somewhat simplified view because
Buchli et al. Informational - Expires August 2002 14
QoS signaling architecture, interfaces February 2002
and requirements
in practice, the service provider owning the QC will also dispose of
an NMS for managing his equipment (e.g. Access Gates). Thus an SLS
interface will rather be implemented between two NMSÆs of providers.
These NMSÆs each have their SLS-database and the QC has access to
the NMS of the service provider for executing the policy-based
admission control decision.
This protocol interface may be in scope of NSIS.
5.3 Evolution scenario
In the previous section it was assumed that the end-host and QI were
two separate entities. This is because each type of access network
has its own QoS signaling protocol. The QI couples the access
dependent QoS signaling with the generic NSIS signaling in the core
(i.e. between QI and QC). Hence, in the short/medium-term the NSIS
protocol will be used between the QI and QC and an access technology
dependent protocol will be used between the host and the QI.
However, once an NSIS protocol has been specified and deployed
between QI and QC the access networks may gradually start to adopt
NSIS signaling. This implies that the QoS Initiator becomes
integrated in the end-host and that the NSIS protocol is also used
to setup QoS in the access. Of course, this is an evolution scenario
since there is a large installed base of cable, UMTS, xDSL access
networks only supporting their own QoS signaling methods.
Hence, in the long-term the NSIS signaling protocol may be supported
by the end-host (acting as QoS Initiator) and may also be used for
QoS signaling in the access network, realizing effectively end-to-
end (NSIS) QoS signaling.
6. Requirements on the QoS Initiatorûto-QoS Controller interface
Per-flow QoS requests are mapped onto an SLS. Hence, most of the
complexity resides in the specification and provisioning of SLSs.
This results in a small set of requirements for the end-user QoS
signaling.
The QoS Initiator must map the parameters from the host-to-QI
interface on the QoS Initiator-to-QoS Controller (NSIS) protocol.
This section discusses the signaling requirements and parameter
groups that need to be signaled.
6.1 Signaling requirements
1) The protocol should be lightweight.
The required processing power and memory consumption per QoS request
should be very small at the QoS Controller such that large amounts
of reservation requests can be processed per time unit. The protocol
Buchli et al. Informational - Expires August 2002 15
QoS signaling architecture, interfaces February 2002
and requirements
can be lightweight since the complexity resides in the pre-
provisioning of resources by means of SLSs.
2) The time to setup a QoS connection should be constrained to one
or a few round trip times.
This may be necessary for a telephony application because this
requires a small call setup delay. Short set up times can be
achieved by the two-step approach discussed earlier in this draft,
i.e. pre-provision bandwidth pipes by means of SLSs and map flow in
these bandwidth pipes.
3) Support of priority
A minimal support of priority and preemption in case of congestion
may be needed in the signaling or in the class description.
4) Immediate notification of QoS failure
The signaling must allow the users to be notified in case of QoS
failure or violation. This notification must be immediate if no
local recovery action is taken. The notification should occur when
local recovery actions are taken. This requirement is due to the
high reliability of the service that needs at least to make the user
know in case the QoS is no more guaranteed.
5) Both in-band and out-of-band signaling should be supported. This
implies that the QoS Initiator and QoS Controller may not be located
on the data path of the media flow. See e.g. the UMTS use case. The
main advantage of out-of-band signaling is that it avoids the need
to upgrade (edge) routers with e.g. the NSIS protocol. Indeed the
QCs can be deployed on existing (DiffServ) IP networks. In other
words, the network needs only to provision bandwidth pipes (e.g. by
means of DiffServ PDBs) while the QoS Controller performs per-flow
admission control into these pipes and processes the per-flow (NSIS)
signaling. Therefore, the NSIS protocol MUST allow for interworking
between both in-band and out-of-band signaling approaches for
(gradual) deployment reasons.
6) The protocol should be independent of core transport technology
as opposed to the access part where the transport and QoS are
technology specific. Because of this there is a need for
interworking between the QoS in the access network with the QoS in
the core network in order to offer end-to-end QoS (i.e. from host to
host).
7) The signaling information should be independent from the protocol
that carries it.
Different protocols may be used but the semantics should be the
same. The information semantics of the host-to-QI protocol must be
mapped on a QI-to-QC protocol. This mapping should take place in the
QoS Initiator. This couples the technology dependent signaling
protocols in the access with a generic protocol in the core. In
order to do this a minimal set of protocol parameters that need to
be mapped should be specified.
Buchli et al. Informational - Expires August 2002 16
QoS signaling architecture, interfaces February 2002
and requirements
8) Multicast consideration should not impact the protocol complexity
for unicast flows.
Multicast support is not considered as a priority, because the
targeted interactive multimedia services are mainly unicast. For
this reason, if considered in the solution, multicast should not
bring complexity in the unicast scenario.
9) Effective support of unidirectional reservations
Bidirectional reservations are considered as almost impossible in a
multidomain configuration due to the unidirectional nature of IP. So
bidirectionnal reservations are considered as exceptional if not out
of the scope of the protocol.
10) the mobility aspects should have no impact on the NSIS protocol
A QoS controller should not be affected by mobility issues. In UMTS
networks, the users has an anchor point in the GGSN, and thus does
not require mobility support.
11) Optimization for interactive multimedia services
The SIP/H.323 applications are foreseen as the main drivers for end
to end QoS solutions. NSIS protocols should be designed in order to
be optimised for such traffics.
12) Support for different service levels
The protocol should be able to support different service levels for
a service class. This may, for instance, be used in relation to
olympic service classes ("gold", "silver" and "bronze")
6.2 Requirements on protocol content
The per-flow QoS requests are mapped onto the bandwidth pipe, which
is specified by an SLS. These pipes may provide statistical
guarantees such as delay and packet loss bounds (depending on the
QoS class). In order to invoke per-flow QoS services the only
parameter needed is a required rate, a means to identify the data
path (mapping on SLS) and eventually a reservation identifier.
1) Microflow/reservation description
The signaling should allow the request to describe the microflow
whose QoS would be guaranteed by giving at least the source and
destination IP addresses of the media flow. In case the QC is
stateful (per microflow) there may be a need to include a unique
reservation identifier (e.g. QI identifier+counter) such that in
case of e.g. a tear down message the reservation can be easily
identified in the QC.
2) Traffic descriptor
The required peak rate must be signaled. Optionally the traffic
parameters may be expressed in terms of token bucket parameters
(similar to the TSpec in RSVP).
Buchli et al. Informational - Expires August 2002 17
QoS signaling architecture, interfaces February 2002
and requirements
6.3 Open issues
Two points are left as open issues:
1) The protocol may be stateful or stateless.
Because of the two-level approach, statefulness needs to be
considered both for the pre-provisioned pipes and for the
microflows.
Clearly, per QoS-class state will need to be maintained by the NMS
and the QC; so the (long-term) bandwidth pipe reservations always
should be stateful.
It is not clear yet whether per microflow state should be maintained
by the QC.
A stateful approach allows simple implementation of per-flow
notification of QoS violation and priority/preemption. This may be
feasible in some parts of the network because the two-step approach
strongly reduces the state information that needs to be kept. Still,
in core networks the number of reservations may be too large to use
a stateful approach. A stateful approach can keep hard-state or
soft-state. Regardless of the fact whether hard-state or soft-state
is used, we see a possible need for explicit refresh/feedback
messages that may be used for teardown and/or performance
notification (performance level and/or violation). Note that these
messages may be per-flow or per-class.
A stateless approach may simply decrement/increment capacity on pre-
provisioned bandwidth pipes without keeping per-flow state. In this
case, the information required for priority support and/or QoS
failure notification may be implemented on a per-class basis. Note
that in this case, only one setup message should be sent in order to
avoid duplicate reservation. Notification messages should be clearly
distinguishable as such in order to avoid unnecessary or unwanted
allocation or deallocation of resources.
2) Grouping of microflows
As a consequence of the optimization for the interactive multimedia
services, the signaling should allow one unique request for several
micro flows having the same origination and destination IP
addresses. This is usually the case for multimedia SIP calls where
the voice and video micro flows follow the same path. This grouping
of requests allows optimization of the QoS processing. Note that
this may be detrimental for the call setup time. The use of grouping
for microflows may be restricted to teardown and/or notification
messages when call setup time is a concern.
7. Security Considerations
This draft does not identify other security aspects than those
described in [8].
Buchli et al. Informational - Expires August 2002 18
QoS signaling architecture, interfaces February 2002
and requirements
8. Conclusions
Based on the use cases of an interconnection scenario of PSTN
trunking gateways and an interconnection scenario between a UMTS
access network and an IP core network, a general architecture is
proposed and the different protocol interfaces where identified.
These are between the:
1) host and the QoS Initiator,
2) QoS Initiator and the Access Gate,
3) QoS Initiator and the QoS Controller,
4) QoS Controller and the Network Management System.
The QoS signaling in the access is usually technology dependent.
However, the QoS signaling in the core should be technology
independent. The signaling protocol requirements and the parameter
groups to be signaled between the QoS Initiator and the QoS
Controller where discussed in this draft.
The proposed architecture involves two steps in QoS provisioning:
1) Provisioning of bandwidth pipes between the ingress and egress
points of the IP core network by means of SLSs. This involves
configuration of network elements by a Network Management System.
2) Admission control of per-flow QoS request in the pre-provisioned
bandwidth pipes. In other words, a functional entity in the network
checks if the usage of the bandwidth pipe between the ingress and
egress points of the network does not exceed the capacity specified
in the SLS. Hence, this step does not involve any configuration of
network elements.
The following recommendations are made towards the NSIS working
group:
1) A first priority for NSIS should be the signaling interface
between the QoS Initiator and the QoS Controller. This is completely
in line with the recommendation in [8].
2) The protocol between the host and the QoS Initiator is access
technology dependent. Therefore, NSIS should study the different
access signaling protocol and assess whether they contain the
minimal set of protocol parameter groups (that have to be defined in
step 1). If not, changes may be proposed for these access signaling
protocols.
3) The SLS interface between the QoS Controller and the NMS is used
for SLS negotiation and for the exchange of SLS monitoring
information. The SLS negotiation may be off-line by means of a paper
contract or may be semi-dynamically signaled. The monitoring aspect
of SLSs is very important and requires that the protocol between the
NMS and the QC is able to exchange such information. Therefore, NSIS
may consider adding this signaling interface to their scope.
Buchli et al. Informational - Expires August 2002 19
QoS signaling architecture, interfaces February 2002
and requirements
9. Acknowledgment
The authors would like to acknowledge Alban Couturier for his
contributions to the QoS signaling requirement section.
The authors would also like to acknowledge Christian Jacquenet,
George Pavlou, Richard Egan, David Griffin, Panos Georgatsos, Pim
Van Heuven, Eleni Mykoniati and other participants in the TEQUILA
project for their input and reflection on this work.
References
1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
2 RFC 2205 Braden, R. et al., "Resource ReSerVation Protocol (RSVP)
- Version 1 Functional Specification", RFC 2205, September 1997.
3 RFC 2223 Postel, J. and Reynolds, J., "Instructions to RFC
Authors", RFC 2223, October 1997.
4 RFC 2748 Boyle, J. et al., "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
5 RFC 3015 Cuervo, F. et al., "Megaco Protocol Version 1.0", RFC
3015, November 2000.
6 RFC 3086 Nichols, K. and Carpenter, B., "Definition of
Differentiated Services Per Domain Behaviors and Rules for their
specification", RFC 3086, April 2001.
7 Bos, L. et al., "A Framework for End-to-End User Perceived
Quality of Service Negotiation", draft-bos-mmusic-sdpqos-
framework-00.txt, Work in Progress, November 2001.
8 Brunner, M. et al., "Requirements for QoS Signaling Protocols",
draft-brunner-nsis-req-00.txt, Work in Progress, November 2001.
9 Goderis, D. et al., "Service Level Specification Semantics,
Parameters and negotiation requirements", draft-tequila-sls-
02.txt, Work in Progress, February 2002.
10 Grossman, D., "New terminology for diffserv", , draft-ietf-
diffserv-new-terms-08.txt, work in progress, January 2002.
11 Sidebottom, G. et al., "SS7 MTP3-User Adaptation Layer (M3UA)",
draft-ietf-sigtran-m3ua-12.txt, Work in Progress, Febuary 2002.
Buchli et al. Informational - Expires August 2002 20
QoS signaling architecture, interfaces February 2002
and requirements
12 Westberg, L. et al., "Resource Management in Diffserv (RMD)
Framework", draft-westberg-rmd-framework-01.txt, Work in
Progress, February 2002.
13 IETF Middlebox Communication (MIDCOM) working group,
http://www.ietf.org/html.charters/midcom-charter.html/
14 IST-Tequila project http://www.ist-tequila.org/
Author's Addresses
Maarten Buchli
Alcatel
Network Strategy Group
Francis Wellesplein 1
B-2018 Antwerpen Phone: +32 3 2407081
BELGIUM Email: maarten.buchli@alcatel.be
Danny Goderis
Alcatel
Network Strategy Group
Francis Wellesplein 1
B-2018 Antwerpen Phone: +32 3 2407853
BELGIUM Email: danny.goderis@alcatel.be
Sven Van den Bosch
Alcatel
Network Strategy Group
Francis Wellesplein 1
B-2018 Antwerpen Phone: +32 3 2408103
BELGIUM Email: sven.van_den_bosch@alcatel.be
Juan-Carlos Rojas
Alcatel
Next Generation Networks Division
Le Mail
F-44708 Orvault Cedex Phone: +33 2 51781282
FRANCE Email: juan-carlos.rojas@alcatel.fr
Stefan Custers
Alcatel
Next Generation Networks Division
Francis Wellesplein 1
B-2018 Antwerpen Phone: +32 3 2409071
BELGIUM Email: stefan.custers@alcatel.be
Buchli et al. Informational - Expires August 2002 21