Internet Draft NSIS QoS Signalling Requirements February 2002
Internet Engineering Task Force D. Partain (ed.), Ericsson
INTERNET-DRAFT A. Bergsten, Telia
Expires August 2002 M. Greis, Nokia
G. Karagiannis, Ericsson
J. Manner, U. of Helsinki
J. Murphy, Juniper
P. Pan, Juniper
V. Rexhepi, Ericsson
L. Westberg, Ericsson
H. Zheng, Nokia
NSIS QoS Signalling Requirements
draft-partain-nsis-requirements-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.
Distribution of this memo is unlimited.
Partain, et al. Expires August 2002 [Page 1]
Internet Draft NSIS QoS Signalling Requirements February 2002
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo identifies a set of requirements that must be applied to
the development of the NSIS quality of service (QoS) signalling
protocol. These requirements are based upon the needs of various
kinds of applications that will utilize IP networks and need to be
able to signal their QoS needs.
1. Introduction
Some applications, such as real-time applications, impose strict QoS
requirements on the underlying transmission network. This level of
QoS can only be achieved with QoS management on an end-to-end basis
(i.e., end user to end user), from application to application. This
will potentially be across many domains since the Internet is a
concatenation of many domains, usually managed by different QoS
administrators (operators).
End-to-end QoS management does not necessarily mean that a single
one-size-fits-all QoS signalling protocol must be applied end-to-end.
In fact, it is most likely that the end-to-end QoS management
architecture will consist of many interoperable and concatenated QoS
management architectures rather than one global end-to-end QoS
infrastructure. While the NSIS QoS signalling protocol may indeed be
used end to end, it will also be necessary to interoperate with other
mechanisms which provide for end-to-end signalling (e.g., RSVP).
This memo begins by describing different IP scenarios and application
areas which support a large volume of real-time traffic (mixed with
best effort traffic). These applications need a simple, scalable and
very fast QoS signalling protocol. Given this set of applications,
we list a set of requirements to be fulfilled by the NSIS QoS
signalling protocol.
The requirements are built upon these various scenarios as "use
cases". Each of these scenarios has a set of requirements that needs
to be fulfilled in order for a QoS signalling protocol to be useful
within that context. Some of these requirements may be common to
other scenarios, while some may indeed be unique to that environment.
Partain, et al. Expires August 2002 [Page 2]
Internet Draft NSIS QoS Signalling Requirements February 2002
In any requirements discussion, there is always a risk that
everyone's favorite set of requirements will be pulled in to create a
union of all possible requirements. By using these scenarios as the
basis of requirements, we are trying to limit the requirements to a
reasonable subset that is applicable to the most acute QoS signalling
needs today. This in no way negates the validity of other
requirements but rather is an attempt to prioritize the work.
Typically an end-to-end QoS management architecture consists of many
interoperable and concatenated QoS management architectures. Each QoS
domain is responsible for taking its own decisions in its own domain-
specific ways. An example is shown in Figure 1, where the end-to-end
QoS management architecture consists of two concatenated QoS domains.
This QoS architecture uses different types of interfaces:
* interior <-> interior interface: provides basic QoS
functionality, such as scalable, simple and fast QoS
provisioning. Due to the fact that different networks have
different characteristics, such as cost of bandwidth and
performance, this basic QoS functionality may differ from
one QoS domain to another.
* BN <-> BN interface: provides the QoS functionality for
a complete QoS domain by interacting with the
interior <-> interior interfaces.
* Host <-> BN interface: in addition to the basic QoS
functionality, this interface has to provide a user with
secure access to the network. Therefore, this interface will
have to provide security functions, such as authentication
and authorization.
QoS domain QoS domain
|------------------| |------------------|
| | | |
|-----| |-----| |----| |-----| |-----| |----| |-----| |-----|
| |<->| |<->| |<->| |<->| |<->| |<->| |<->| |
|-----| |-----| |----| |-----| |-----| |----| |-----| |-----|
| | | |
|------------------| |------------------|
host BN interior BN BN interior BN host
(access w/in domain (edge) (edge) w/in domain (access
router) router)
Partain, et al. Expires August 2002 [Page 3]
Internet Draft NSIS QoS Signalling Requirements February 2002
Figure 1: The end-to-end QoS architecture
Different types of QoS requirements are imposed on these interfaces
due to the different characteristics of the interfaces used in the
QoS architecture. In addition, the different parts of the network
often have different service and billing structures, with different
trust models, all of which translate into signalling needs with
varying degrees of complexity. These are the reasons for separating
the generic QoS requirements into QoS requirements specific to a
particular interface.
2. Terminology
Editor: There is certainly going to be work that needs to be done on
this section.
- End-to-End QoS
QoS management applied in all the domains from end-host to
end-host. In some scenarios this can be the NSIS QoS protocol
and in other scenarios it might be an existing QoS protocol.
- QoS administrative domain
A network wherein the QoS provisioning is managed by one
administrator (or operator).
- Edge Node
Router on the boundary of a QoS administrative domain.
- Interior Node
Routers inside a single domain that are not edge nodes.
- Border node
A "box" that represents entities such as edge node (or edge
router), access router, border router, proxy, gateway,
inter-provider-router, CPE (customer provider equipment
edge), PE (provider equipment edge), but it does not
represent a host or an interior node. It provides interior
node functionality, as well as additional functions, such as:
Partain, et al. Expires August 2002 [Page 4]
Internet Draft NSIS QoS Signalling Requirements February 2002
* QoS functionality on a complete QoS domain, such as
an edge node. Note that the minimum functionality that
a border node can provide is the functionality that an
edge node (or edge router) provides.
* supports authentication, accounting, such as an access
router or a border router
* supports initiation and termination of the NSIS
protocol, and/or interworking with other QoS protocols,
such as proxies, BTSs, BSC/RNCs, and media gateways
- Single-domain
QoS domain administrated by a single administrator
(operator).
- Multi-domain
Multiple QoS domains managed by different administrators
(operators), but seen by the NSIS QoS protocol as a
single-domain.
3. IP scenarios and application areas
A number of different QoS solutions have been developed by the IETF.
However, there are IP scenarios and application areas that require a
different or at least modified QoS signalling protocol. Given the
framework above, this memo outlines a set of requirements for
different applications that will use these networks.
In all the scenarios (end-to-end, edge-to-edge or end-to-edge) where
the NSIS protocol is used for signalling and where it is processed by
the nodes along the communication path, the data MUST follow the same
path as the signalling messages.
3.1. Mobile IP
In this scenario, as shown in Figure 2, a mobile host can roam and
perform a handover procedure between Access Routers (i.e., border
Partain, et al. Expires August 2002 [Page 5]
Internet Draft NSIS QoS Signalling Requirements February 2002
nodes). In this scenario, the NSIS QoS protocol can be applied
between an Access Router and a proxy (i.e., border node) which we
denote as "Joint point of reservation"." The "Joint point of
reservation" router is located in the QoS aware segment that
maintains an end-to-end reservation, but due to handover it should
change/modify this reservation. Moreover, this router provides the
bridging function between a local NSIS QoS protocol and the end-to-
end QoS protocol (which could be the NSIS QoS protocol). In many
handover situations (e.g., when reverse tunneling and no route
optimization is used) an example of such a router would be the Home
Agent. As can be seen, the border nodes used in this QoS architecture
are the Access Routers and the "Joint point of reservation". There
are cases were the Access Router and the left most Edge Router shown
in the Figure 2 can be included in one entity (i.e., AR).
|--|
|MH|---/
|--| / |--------|
/--| Access | |--|
| Router |-|ER|.... |-------------|
|--------| |--| . |--| | Proxy | |----|
...|ER|..|(Joint point |...."Internet"..|host|
-- |--------| |--| . |--| |reservation: | |----|
|--| \ | |-|ER|.... | PROXY) |
|MH| \ | Access | |--| |-------------|
|--|--- | Router | MH = mobile host
|--------| ER = edge router
BN = border node
... = interior nodes
Figure 2: Mobile IP QoS Architecture
3.2. Wired part of wireless network
A wireless network, seen from a QoS domain perspective, usually
consists of three parts: a wireless interface part (the "radio
interface"), a wired part of the wireless network (i.e., Radio Access
Network) and the backbone of the wireless network, as shown in Figure
3. Note that this figure should not be seen as an architectural
overview of wireless networks but rather as showing the conceptual
QoS domains in a wireless network.
In this scenario, a mobile host can roam and perform a handover
Partain, et al. Expires August 2002 [Page 6]
Internet Draft NSIS QoS Signalling Requirements February 2002
procedure between base stations/access routers (i.e., border nodes).
In this scenario the NSIS QoS protocol can be applied between a base
station and the gateway (GW) (i.e., border node). In this case a GW
can also be considered as a local handover anchor point.
Furthermore, in this scenario the NSIS QoS protocol can also be
applied either between two GWs, or between two edge routers (ER)
(i.e, border nodes).
|--|
|GW|
|--| |--|
|MH|--- .
|--| / |-------| .
/--|base | |--| .
|station|-|ER|....
|-------| |--| . |--| back- |--| |---| |----|
...|ER|.......|ER|..|BGW|.."Internet"..|host|
-- |-------| |--| . |--| bone |--| |---| |----|
|--| \ |base |-|ER|... .
|MH| \ |station| |--| .
|--|--- |-------| . MH = mobile host
|--| ER = edge router
<----> |GW| GW = gateway
Wireless link |--| BGW = border gateway
... = interior nodes
<------------------->
Wired part of wireless network
<---------------------------------------->
Wireless Network
Figure 3. QoS architecture of wired part of wireless network
Each of these parts of the wireless network impose different
requirements on the QoS signalling solution being used:
* Wireless interface: The solution for the air interface link
has to ensure flexibility and spectrum efficient transmission
of IP packets. However, this link layer QoS can be solved in
the same way as any other last hop problem by allowing a
host to request the proper QoS profile.
* Wired part of the wireless network: This is the part of
the network that is closest to the base stations/access
Partain, et al. Expires August 2002 [Page 7]
Internet Draft NSIS QoS Signalling Requirements February 2002
routers. It is an IP network although some parts logically
perform tunneling of the end user data. In cellular networks,
the wired part of the wireless network is denoted as a
radio access network.
This part of the wireless network has different
characteristics when compared to traditional IP networks:
1. The network supports a high proportion of real-time
traffic. The majority of the traffic transported in the
wired part of the wireless network is speech, which is
very sensitive to delays and delay variation (jitter).
2. The network must support mobility. Many wireless
networks are able to provide a combination of soft
and hard handover procedures. When handover occurs,
reservations need to be established on new paths.
The establishment time has to be as short as possible
since long establishment times for reservations degrade
the performance of the wireless network. Moreover,
for maximal utilization of the radio spectrum, frequent
handover operations are required.
3. These links are typically rather bandwidth-limited.
4. The wired transmission in such a network contains a
relatively high volume of expensive leased lines.
Overprovisioning might therefore be prohibitively
expensive.
5. The radio base stations are spread over a wide
geographical area and are in general situated a large
distance from the backbone.
* Backbone of the wireless network: the requirements imposed
by this network are similar to the requirements imposed by
other types of backbone networks.
Due to these very different characteristics and requirements, often
contradictory, different QoS signalling solutions might be needed in
each of the three network parts.
Partain, et al. Expires August 2002 [Page 8]
Internet Draft NSIS QoS Signalling Requirements February 2002
3.3. QoS signalling between PSTN gateways and backbone routers
A PSTN gateway (i.e., host) requires information from the network
regarding its ability to transport voice traffic across the network.
The voice quality will suffer due to packet loss, latency and jitter.
Signalling is used to identify and admit a flow for which these
impairments are minimized. In addition, the disposition of the
signalling request is used to allow the PSTN GW to make a call
routing decision before the call is actually accepted and delivered
to the final destination.
PSTN gateways may handle thousands of calls simultaneously and there
may be hundreds of PSTN gateways in a single provider network. These
numbers are likely to increase as the size of the network increases.
The point being that scalability is a major issue.
There are several ways that a PSTN gateway can acquire assurances
that a network can carry its traffic across the network. These
include:
1. Over-provisioning a high availability network.
2. Handling admission control through some policy server
that has a global view of the network and its resources.
3. Per PSTN GW pair admission control.
4. Per call admission control (where a call is defined as
the 5 tuple used to carry a single RTP flow).
Item 1 requires no signalling at all and is therefore outside the
scope of this working group.
Item 2 is really a better informed version of 1, but it is also
outside the scope of this working group as it relies on a particular
telephony signalling protocol rather than a packet admission control
protocol.
Item 3 is initially attractive as it appears to have reasonable
scaling properties, however, its scaling properties only are
effective in cases where there are relatively few PSTN GWs. In the
more general case were a PSTN GW reduces to a single IP phone sitting
behind some access network, the opportunities for aggregation are
reduced and the problem reduces to item 4.
Item 4 is the most general case. However, it has the most difficult
scaling problems. The objective here is to place the requirements on
Partain, et al. Expires August 2002 [Page 9]
Internet Draft NSIS QoS Signalling Requirements February 2002
Item 4 such that a scalable per-flow admission control protocol or
protocol suite may be developed.
The case where per-flow signalling extends to individual IP end-
points allows the inclusion of IP phones on cable, DSL, wireless or
other access networks in this scenario.
Call Scenario -
A PSTN GW signals end-to-end for some 5 tuple defined flow a
bandwidth and QoS requirement.
The access network admits this flow according to its local policy and
the specific details of the access technology. Flow request may be
authenticated - access routers (i.e., border nodes) may need to
interwork with a policy server to admit the flow.
At the edge router (i.e., border node), the flow is admitted, again
with an optional authentication process, possibly involving an
external policy server. Note that the relationship between the PSTN
GW and the policy server and the routers and the policy server is
outside the scope of NSIS, the point is that the signalling protocol
should support any hooks required to make this authentication
possible. The edge router then admits the flow into the core of the
network, possibly using some aggregation technique.
The job of policing the actual packet flow may be performed by either
the access or edge router depending on where the trust border lies.
It is likely that whomever authenticates the request would also
police the flow.
For the purposes of accounting, the policing router should also
provide accounting data to some external server. Again the access or
edge router could perform this function, depending on the trust
border, etc.
At the interior nodes, the NSIS host-to-host signalling should either
be ignored or invisible as the Edge router performed the admission
control decision to some aggregate.
At the inter-provider router (i.e., border node), again the NSIS
host-to-host signalling should either be ignored or invisible as the
Edge router has performed an admission control decision about an
aggregate across a carriers network. The only requirement of the
inter-provider routers is to police the aggregate and to know what to
Partain, et al. Expires August 2002 [Page 10]
Internet Draft NSIS QoS Signalling Requirements February 2002
police it to. How inter-providers know the size of the aggregate is
outside the scope of NSIS, but suffice it to say that we can assume
that the Edge router can perform the admission control function into
some aggregate.
3.4. QoS for Virtual Private Networks
There are two types of L3 VPNs, distinguished by where the endpoints
of the tunnels exist. The endpoints of the tunnels may either be on
the customer (CPE) (i.e., Border Node), or the provider equipment or
provider edge (PE) (i.e., Border Node).
Virtual Private networks are also likely to request bandwidth for
Assured Forwarding style services in addition to the Expedited
Forwarding services the PSTN GW are likely to use.
3.4.1. Tunnel end points at the CPE
When the endpoints are the CPE, the CPE may want to signal across the
public IP network for a particular amount of bandwidth and QoS for
the tunnel aggregate. Such signalling may be useful when a customer
wants to vary their network cost with demand, rather than paying a
flat rate. Such signalling exists between the two CPE routers.
Intermediate access and edge routers perform the same exact call
admission control, authentication and aggregation functions performed
by the corresponding routers in the PSTN GW scenario with the
exception that the endpoints are the CPE tunnel endpoints rather than
PSTN GWs and the 5-tuple used to describe the RTP flow is replaced
with the corresponding flow spec to uniquely identify the tunnels.
Tunnels may be of any variety (eg. IP-Sec, GRE, IP-IP).
3.4.2. Tunnel end points at the PE
In the case were the tunnel end-points exist on the provider edge,
requests for bandwidth may be signaled either per flow, where a flow
is defined from a customers address space, or between customer sites.
In the case of per flow signalling, the PE router must map the
bandwidth request to the tunnel carrying traffic to the destination
specified in the flow spec. Such a tunnel is a member of an aggregate
to which the flow must be admitted. In this case, the operation of
admission control is very similar to the case of the PSTN GW with the
Partain, et al. Expires August 2002 [Page 11]
Internet Draft NSIS QoS Signalling Requirements February 2002
additional level of indirection imposed by the VPN tunnel.
Therefore, authentication, accounting and policing may be required on
the PE router.
In the case of per site signalling, a site would need to be
identified. This may be accomplished by specifying the network
serviced at that site through an IP prefix. In this case, the
admission control function is performed on the aggregate to the PE
router connected to the site in question.
4. Assumptions and non-goals of the QoS Signalling Protocol
In determining the requirements to be placed upon a QoS signalling
protocol, it is important that the assumptions of the work are
clearly stated. This section identifies a set of problems which are
specifically not targeted by the NSIS QoS signalling protocol.
- Multicast support introduces a significant level of
complexity to QoS signalling and should consequently be
left for future work.
- The user networks and IP backbone know how to manage their own
network resources and must satisfy QoS requirements
once packets are inside their network. More importantly,
it is not required to have a unified signal and resource
management technique in all networks.
- Though, in theory, the only applications that require
QoS guarantees are interactive real-time applications,
the signalling protocol MUST be independent of the
application type.
- Several groups have been and are working on the protocols used
by bandwidth brokers to manage resources within a QoS domain
and between domains. While it is possible that the NSIS QoS
signalling protocol may be useful in this scenario, bandwidth
brokering protocols is not the target of this work.
Specifically, NSIS signalling may be used by a border node to
admit a flow into its domain. This border node may interwork
with a bandwidth broker. However, the details of this
interworking are outside the scope of these requirements.
Partain, et al. Expires August 2002 [Page 12]
Internet Draft NSIS QoS Signalling Requirements February 2002
- Application-specific QoS signalling above layer 3. For
example, no attempt is made to infringe upon the applicability
of SIP.
Application signalling protocols may be used to set up
authentication servers, etc. But there is no assumption from
NSIS signalling that such application signalling exists or
is required.
- Layer 2 specific QoS work, such as the specific parameters
necessary for setting up the air interface in the most
efficient manner.
Indeed, the layer 3 information should be sufficient
to drive the layer 2 setup. How layer 3 information is
mapped to a specific layer 2 network is outside the scope
of these requirements. There should, though, be enough
layer 3 information available to the layer 2 entity.
- Receiver-initiated QoS signalling. While there are possible
scenarios where the receiver initiates the signalling,
such as a web QoS scenario, this should be solved at the
application layer for unicast flows. The host signalling
into the network should be sender-initiated.
5. QoS requirements
This section presents the QoS requirements imposed by the IP
scenarios described in the previous sections. In particular, the
following subsections present the QoS requirements that affect the
"host to border node", "border node to border node" and "interior -
interior" interfaces, respectively. Furthermore, additional QoS
requirements that affect these interfaces are described in Section
5.4, where the border node can initiate and terminate the NSIS QoS
signalling protocol.
5.1. QoS requirements on Host - BN interface
These QoS requirements affect only the Host to border node interface,
and therefore should be only processed by mobile hosts and/or border
nodes. Note that the only case considered in this section is when
the border node is not capable of initiating and terminating the NSIS
protocol.
Partain, et al. Expires August 2002 [Page 13]
Internet Draft NSIS QoS Signalling Requirements February 2002
5.1.1. Low overhead and allow for efficient bandwidth usage
The QoS signalling protocol should allow the processing of the QoS
signalling messages to be as simple as possible, and it should take
as few messages as possible to set up a reservation. This is
especially important on mobile hosts with limited resources and
power. This simplicity requirement may also help to reduce the delay
of the QoS signalling procedure.
Furthermore, the QoS parameters must be understandable, simple, but
also intuitive to the "user" (e.g. end user or API developer) or
communicating partners.
5.1.2. Flexible and extensible
It must be possible to include special parameters for different
access technologies in the QoS signalling protocol. Also, it must be
possible to extend the QoS signalling protocol to adapt to future
access technologies. This implies that the signalling protocol and
the information it carries must be de-coupled from each other.
5.1.3. Enable QoS negotiation between host and network in efficient
manner
"QoS negotiation" in this context describes the process of an actual
negotiation which may take place between a host and the network.
That is, the QoS request from the host would be seen as a proposal,
which can be either accepted, rejected or downgraded by the network.
This final option leaves it up to the host, whether it wants to
establish the communication based on the modified QoS.
The QoS signalling protocol should allow QoS negotiation between the
end node and the network or the remote endpoint in an efficient way.
The efficiency can be measured by delay, bandwidth required, etc.
Delay can in this context result from the number of round trip times,
the processing time, and the size of the signalling messages.
Partain, et al. Expires August 2002 [Page 14]
Internet Draft NSIS QoS Signalling Requirements February 2002
5.1.4. Allow the combination of soft state and explicit QoS release
principles
In designing the QoS signalling protocol that can be used for
signalling QoS needs, there needs to be a balance between how often a
request is refreshed and efficiency of utilization. If the refresh
timer is too long, this will result in poor utilization of the
network resources. If it is instead too short, this will result in a
potential signalling burden on the network. In order to achieve good
balance, the QoS signalling prototol SHOULD use both soft state and
an explicit release.
After call termination, unneeded states related to the QoS signalling
in the network should be released as soon as possible. Therefore, in
addition to the soft state release principle, the QoS signalling
protocol must allow a host to send a QoS release request explicitly.
Furthermore, if the host is a mobile node, it may be the
responsibility of the network to remove old reservations at the old
access point after handovers. It must be possible to implement such
mechanisms in the network.
5.1.5. Allow QoS authorization and policy control
QoS authorization and policy control provide operators with service
control. QoS signalling must include necessary information to be
used for the network to authorize the QoS request and perform policy
control.
5.1.6. Support common security features
This includes privacy and anonymity support as well as the integrity
of signalling packets.
5.1.7. Allow authentication of the QoS request
QoS requests need to be authenticated before QoS authorization is
performed. QoS signalling must be able to carry necessary
information used by the network to authenticate the QoS request.
Partain, et al. Expires August 2002 [Page 15]
Internet Draft NSIS QoS Signalling Requirements February 2002
5.1.8. Provide hooks for accounting
QoS signalling protocol should include necessary information for the
network to collect charging data for a specific user.
5.1.9. Independent of different mobility protocols
Although QoS signalling may be able to take advantage of specific
mobility protocols for optimized operation, it should be designed
independent of mobility protocols in the sense that it can still
perform the same functionality when one or more of these mobility
protocols are not used.
5.1.10. Network structure must be invisible to end hosts
End hosts MUST NOT be required to be aware of network topology in
order to be able to get the QoS that they desire. The implementation
of QoS in the network, including its topology, need not be visible to
the end hosts. The QoS interface shall only reflect the "bearer
requirements" that a host can request. Any mechanism or combination
of mechanisms can be used together to provide the overall QoS.
5.1.11. Interwork with IP tunneling
The QoS signalling and provisioning mechanisms must operate in
networks that make use of IP tunneling, but also IPSec. The
signalling messages need to be visible to the network QoS nodes, but
also the data packets that would need a specific QoS need to be
identified.
5.1.12. Support different types of QoS requests
It must be possible to signal different QoS service types, both flow-
based (per-single-flow or per-aggregated-flow) as well class-based
(e.g. priority based traffic classes, drop precedences traffic
Partain, et al. Expires August 2002 [Page 16]
Internet Draft NSIS QoS Signalling Requirements February 2002
classes).
5.1.13. Work with changing IP addresses of (mobile) hosts
Mobile hosts may need to change their CoA while QoS is provisioned
for them. The signalling mechanism must make it possible to change
the identification information related to provisioned QoS to keep the
QoS allocated to a mobile host's flows, either upstream or
downstream.
5.1.14. Deal with IP fragmentation gracefully
Signalling messages might be fragmented in transit from sender to
receiver. This has the potential of rendering that signalling
message useless. As such, care should be taken in designing the
protocol to minimize the possibility of fragmentation. Fragmentation
of signalling packet SHOULD be managed by the end host, as is done in
IPv6. This means that the sender SHOULD set the "Don't Fragment" bit
and react to possible ICMP messages.
5.1.15. Sender initiated
A sender-initiated QoS signalling protocol is a protocol where the
sender of the data is also the initiator of the QoS reservations.
This is unlike receiver-initiated procols, such as RSVP [RFC2205],
where the QoS reservations are initiated by the receiver of the user
data. What this means is that the admission control and the resource
allocation on all the nodes that process the signalling protocol in
the communication path from the sender to the receiver will be
initiated by the sender of the data.
However, the triggering of the sender-initiated QoS signalling
protocol can be done by either the sender or the receiver of the user
data. The triggering can be part of NSIS protocol or it may be
another protocol.
The scenarios described above require a QoS signalling protocol that
Partain, et al. Expires August 2002 [Page 17]
Internet Draft NSIS QoS Signalling Requirements February 2002
is initiated very quickly by either a fixed or a mobile host. A
sender-initiated QoS signalling protocol applied in these kinds of
scenarios operates more efficiently than a receiver initiated QoS
signalling protocol for the following reasons:
* Using a sender-initiated approach, the sender can be
informed faster when the reservation request is rejected,
than when using a receiver initiated approach. In other
words, when using a sender initiated approach, in the case of
an unsuccessful reservation, the reservation request response
time can be shorter than with a receiver initiated approach.
* When using a a sender-initiated approach, backward
routing is not necessary.
* In a sender initiated approach, a mobile node can
initiate a reservation as soon as it has moved to another
roaming subnetwork. In a receiver-initiated approach, a
mobile node has to inform the receiver about its handover
procedure, thus allowing the receiver to initiate a
reservation.
Therefore, a sender initiated QoS signalling protocol is required.
See [YESSIR] for further information.
5.1.16. Error handling and redundancy considerations
Border nodes should be able to notify the users if there is an error
inside the network. There are two types of network errors:
- Recoverable errors: this type error can be locally repaired
by the network nodes. The network nodes do not have to
notify the users of the error immediately.
- Unrecoverable errors: the network nodes cannot handle this
type of error, and have to notify the users as soon as
possible.
For example, when there is a network failure inside the backbone, if
the backbone routers can utilize redundancy functionality to protect
effected user flows, the routers have the option to notify or not
notify the users about the failure. On the other hand, if the
Partain, et al. Expires August 2002 [Page 18]
Internet Draft NSIS QoS Signalling Requirements February 2002
network failure is so severe that backbone routers have to terminate
some of the user flows, the routers must notify the users immediately
on the network failure. Upon receiving the error messages, the users
may have to rely on their own redundancy function to redirect user
flows.
Thus, the distinction of recoverable and unrecoverable errors is
fairly important in signalling protocol design. This can impact the
overall signalling process overhead.
5.1.17. Identification requirement
The host MUST be able to identify the first hop router (default
router). However, the identification of the first hop router may be
provided by various mechanisms, including DHCP and Router
Advertisements.
5.2. QoS requirements on BN - BN interface
These QoS requirements affect only the border node to border node
interface, and therefore should be only processed border nodes. Note
that the only case considered in this section is when the border node
is not capable of initiating and terminating the NSIS protocol.
5.2.1. Ability to traverse a border node transparently
In some networks the QoS signalling protocol should transparently be
forwarded through a border node, without taking any action.
5.2.2. Allow local QoS information exchange between two border nodes
The QoS signalling protocol must be able to exchange local QoS
information between edge nodes. Local QoS information might, for
example, be IP addresses, severe congestion notification,
notification of succesful or erroneous processing of QoS signalling
messages at one border node.
Partain, et al. Expires August 2002 [Page 19]
Internet Draft NSIS QoS Signalling Requirements February 2002
In some domains, the NSIS QoS signalling protocol MAY carry
identification of the ingress and egress edge between the ingress-
egress edges. However, the identification of edges should not be
visible to the end host and only applies within one QoS
administrative domain.
5.2.3. Allow generation of local QoS signalling messages
Any border node must be allowed to generate QoS signalling messages
that can be used locally within a QoS domain.
5.3. QoS requirements on Interior - Interior interface
The QoS requirements described in this section affect only the
"interior node to interior node" interface, and therefore, should be
only processed by interior nodes.
5.3.1. Modular, Simple, with Minimal Impact on Performance
Although obvious, it bears saying that any QoS signalling mechanism
must be as modular, simple, and scalable as possible and that it
should have a minimal effect on the overall performance of the
network.
5.3.1.1. Modular
While it is clear that a set of mechanisms will not be standardized
that is only applicable to the wired part of the wireless network, it
must be possible to use only a part of the QoS signalling mechanism
that is applicable to that network. That is, a standardized QoS
signalling mechanism should be a toolkit from which one can choose
the applicable tools in order to manage QoS in a particular
networking environment.
5.3.1.2. Simple
It is critical that the QoS signalling protocol be as simple as
possible to implement in the interior nodes since in most cases there
Partain, et al. Expires August 2002 [Page 20]
Internet Draft NSIS QoS Signalling Requirements February 2002
will be more interior routers (<= 10 depending on network structure)
in the path between the edges than there are edge nodes (there are
typically two edge nodes located in a communication path). As such,
the scheme must be optimized for the interior nodes and not for the
edge nodes, thus reducing the requirements placed on the
functionality of the interior routers.
5.3.1.3. Minimal Impact on Performance
In several networks, the interior nodes will have to support a higher
number of micro-flows (user connections) compared to the edge nodes.
Therefore, a QoS signalling protocol should be very simple at the
interior nodes while it might use more complex mechanisms at the edge
nodes. In particular, this means is that the interior nodes must not
be required to have per flow responsibilities.
The performance of each network node that is used in an end-to-end
communication path has an impact on the end-to-end performance. As
such, the end-to-end performance of the communication path can be
improved by optimizing the performance of interior nodes. One of the
factors that can contribute to this optimization is the minimization
of the QoS signalling protocol processing load on each device. When
the dynamic reservation of the resources is on a per micro-flow
basis, the QoS signalling protocol could easily overload a router,
causing severe performance degradation. The QoS signalling mechanism
must be designed to minimize the cycles spent on processing the
signalling messages.
One outcome of this requirement is that it uses a simplified
lightweight model in the interior nodes and places complex per-flow
handling at the edges. This requires mapping of per-flow traffic
parameters at the edges into a necessary set of parameters needed for
setting up reservations in interior nodes. The edge routers
typically already have to perform per-session management/control, and
hence complex per flow-handling is not a significant burden.
5.3.2. Ability to deal with mobility (handover)
In order to support mobile users, the QoS signalling mechanism must
be highly performant for at least the following reasons:
Partain, et al. Expires August 2002 [Page 21]
Internet Draft NSIS QoS Signalling Requirements February 2002
* Handover rates
In mobile networks, the admission control process has to cope
with far more admission requests than call setups alone would
generate. For example, in the GSM (Global System for Mobile
communications) case, mobility usually generates an average
of one to two handovers per call. For third generation
networks (such as UMTS), where it is necessary to keep radio
links to several cells simultaneously (macro-diversity),
the handover rate is significantly higher (see for example
[KeMc01]).
* Fast reservations
Handover can also cause packet losses. This happens when the
processing of an admission request causes a delayed handover
to the new base station. In this situation, some packets
might be discarded, and the overall speech quality might
be degraded significantly. Moreover, a delay in handover
may cause degradation for other users. In the worst case
scenario, a delay in handover may cause the connection to be
dropped if the handover occurred due to bad air link quality.
Therefore, it is critical that QoS signalling in connection with
handover be carried out very quickly.
Furthermore, when the network is overloaded, it is preferable to keep
reservations for previously established flows while blocking new
requests. Therefore, the resource reservation requests in connection
with handover should be given higher priority than new requests for
resource reservation.
5.3.3. On-demand, dynamic signalling for efficient network
utilization
There are networking environments that require high network
utilization for various reasons, and the signalling protocol should
to its best ability support high resource utilization while
maintaining appropriate QoS.
For example, wireless networks typically use a large number of
expensive leased lines, which means that efficient network
utilization has a direct economic impact on network operators. Real-
Partain, et al. Expires August 2002 [Page 22]
Internet Draft NSIS QoS Signalling Requirements February 2002
time services require that a portion of network resources is
available to them. These resources can be reserved on a static or
dynamic basis, or potentially based on some kind of measurement of
network load.
Both measurement-based and static reservations may result in a poorly
utilized network, primarily due to the fact that the network
resources are typically reserved for peak real-time traffic values.
Mobility in the network makes static configuration even less
desirable as the resources will be used even less effectively.
By using dynamic reservation, this problem will be avoided since the
resources are reserved on demand. There is, of course, a tradeoff.
Dynamic reservations will mean that the load from QoS signalling will
be much higher than if static reservation of resources is used. If
the dynamic reservation of the resources is done on a micro-flow
basis, the resulting network load from QoS signalling might be quite
high.
In networks where resources are very expensive (as is the case for
many wireless networks), efficient network utilization is of critical
financial importance. As such, static configuration is simply not an
option and an appropriately engineered solution allowing dynamic
resource reservation is needed.
On the other hand there are other parts of the network where high
utilization is not required. In these parts of the network, the
signalling protocol should be as "unobtrusive" as possible.
5.3.4. Ability to deal with severe congestion
In case of a route change or link failure a severe congestion
situation may occur in the network. Typically, routing algorithms are
able to adapt and change their routing decisions to reflect changes
in the topology and traffic volume. In such situations the re-routed
traffic will have to follow a new path. Interior nodes located on
this new path may become overloaded, since they suddenly might need
to support more traffic than they have capacity for. These severe
congestion situations will severely affect the overall performance of
the traffic passing through such nodes. Therefore, the QoS
signalling should exchange severe congestion information between
interior and edge nodes.
Partain, et al. Expires August 2002 [Page 23]
Internet Draft NSIS QoS Signalling Requirements February 2002
5.3.5. Optimize for unicast transport
The vast majority of the traffic in typical networks is point-to-
point unicast transport. As such, the QoS signalling mechanism must
deal with unicast effectively.
5.3.6. Ability to transparently traverse an interior node
In some networks the QoS signalling protocol should transparently be
forwarded through an interior node, without activating any resource
reservation procedure.
5.3.7. Use of a simple QoS parameter
In order to simplify and increase the processing speed of interior
nodes the QoS signalling protocol must be able to carry a simple (or
limited set of) QoS parameter(s).
5.4. BN as initiator and/or terminator of NSIS protocol
These additional QoS requirements affect either the "host to border
node" interface (see Section 5.1) or the "border to border" interface
(see Section 5.2) when the border node is able to initiate and/or
terminate the NSIS protocol.
5.4.1. Allow QoS setup for uni-directional and bi-directional
reservations
When QoS is only required in the upstream direction (i.e., the
direction from the end host towards the network), the QoS signalling
only needs to trigger QoS establishment in that direction. When QoS
is only required in the downstream direction (e.g., a streaming
application without a feedback channel), the QoS signalling only
needs to trigger QoS setup in that direction. Therefore, the QoS
signalling protocol should allow QoS setup for these uni-directional
reservations. Also, QoS setup for bi-directional reservations is
required, where applications require QoS setup in both directions.
Partain, et al. Expires August 2002 [Page 24]
Internet Draft NSIS QoS Signalling Requirements February 2002
5.4.2. Support end-to-end, edge-to-edge and end-to-edge signalling
The signalling mechanism must work end-to-end, but also, if needed,
more locally (i.e., end-to-edge as well as edge-to-edge).
The requirement also includes the potential need for signalling
towards "middle-boxes" on the transport layer, e.g. firewalls and
NATs.
5.4.3. Allow efficient QoS re-establishment after handover
Handover is an essential function in wireless networks. After
handover, QoS may need to be completely or partially re-established
due to route changes. The re-establishment may be requested by the
mobile node itself or triggered by the access point that the mobile
node is attached to. In the first case, the QoS signalling should
allow efficient QoS re-establishment after handover. Re-
establishment of QoS after handover should be as quick as possible so
that the mobile node does not experience service interruption or QoS
degradation. The re-establishment should be localized, and not
require end-to-end signalling, if possible.
5.4.4. Enable other network entities to generate QoS request behalf of
a node
A QoS request is normally generated by the node that requires QoS.
However, in some cases, it is beneficial to send a QoS request from a
different network entity (a proxy) on behalf of the node. As an
example, in a wireless network with limited bandwidth, the initial
QoS request may be sent from the node itself, while subsequent
requests are sent after handover or refresh messages may be generated
by the access router that keeps the QoS request state for the mobile
node. The QoS signalling protocol MUST allow such a scenario.
6. Conclusions
This memo outlines a set of requirements to be used in the design of
the NSIS QoS signalling protocol. These requirements, based on
various scenarios in which the protocol would be used, attempt to
focus the NSIS efforts on the most essential parts of the problem to
be solved.
Partain, et al. Expires August 2002 [Page 25]
Internet Draft NSIS QoS Signalling Requirements February 2002
7. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. References
More to be added later...
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A.,
Jamin, S., "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", IETF RFC
2205, 1997.
[YESSIR] YESSIR - YEt another Sender Session Internet Reservations,
http://www.cs.columbia.edupingpan/projects/yessir.html
[KeMc01] Kempf, J., McCann, P., Roberts, P., "IP Mobility
and the CDMA Radio Access Network", IETF Draft,
draft-kempf-cdma-appl-02.txt, Work in progress,
September 2001.
Partain, et al. Expires August 2002 [Page 26]
Internet Draft NSIS QoS Signalling Requirements February 2002
9. Acknowledgments
The editors wish to thank those providing feedback on this document,
including (but not limited to) Steven Blake, ...
10. Editors's Addresses
David Partain (editor)
Ericsson Radio Systems AB
P.O. Box 1248
SE-581 12 Linkoping
Sweden
E-mail: David.Partain@ericsson.com
Anders Bergsten
Telia Research AB
Aurorum 6
977 75 Lulea
Sweden
E-mail: Anders.P.Bergsten@telia.se
Marc Greis
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
E-mail: marc.greis@nokia.com
Georgios Karagiannis
Ericsson EuroLab Netherlands B.V.
Institutenweg 25
P.O.Box 645
7500 AP Enschede
The Netherlands
E-mail: Georgios.Karagiannis@eln.ericsson.se
Jukka Manner
University of Helsinki
P.O. Box 26, FIN-00014
Helsinki
Finland
E-mail: jukka.manner@cs.helsinki.fi
Jim Murphy
Partain, et al. Expires August 2002 [Page 27]
Internet Draft NSIS QoS Signalling Requirements February 2002
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
E-mail: murphy@juniper.net
Ping Pan
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
E-mail: pingpan@juniper.net
Vlora Rexhepi
Ericsson EuroLab Netherlands B.V.
Institutenweg 25
P.O.Box 645
7500 AP Enschede
The Netherlands
E-mail: Vlora.Rexhepi@eln.ericsson.se
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
E-mail: Lars.Westberg@era.ericsson.se
Haihong Zheng
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
E-mail: haihong.zheng@nokia.com
Table of Contents
1 Introduction .................................................... 2
2 Terminology ..................................................... 4
3 IP scenarios and application areas .............................. 5
3.1 Mobile IP ..................................................... 5
3.2 Wired part of wireless network ................................ 6
3.3 QoS signalling between PSTN gateways and backbone routers ..... 9
3.4 QoS for Virtual Private Networks .............................. 11
Partain, et al. Expires August 2002 [Page 28]
Internet Draft NSIS QoS Signalling Requirements February 2002
3.4.1 Tunnel end points at the CPE ................................ 11
3.4.2 Tunnel end points at the PE ................................. 11
4 Assumptions and non-goals of the QoS Signalling Protocol ........ 12
5 QoS requirements ................................................ 13
5.1 QoS requirements on Host - BN interface ....................... 13
5.1.1 Low overhead and allow for efficient bandwidth usage ........ 14
5.1.2 Flexible and extensible ..................................... 14
5.1.3 Enable QoS negotiation between host and network in effi
cient manner ................................................. 14
5.1.4 Allow the combination of soft state and explicit QoS re
lease principles ............................................. 15
5.1.5 Allow QoS authorization and policy control .................. 15
5.1.6 Support common security features ............................ 15
5.1.7 Allow authentication of the QoS request ..................... 15
5.1.8 Provide hooks for accounting ................................ 16
5.1.9 Independent of different mobility protocols ................. 16
5.1.10 Network structure must be invisible to end hosts ........... 16
5.1.11 Interwork with IP tunneling ................................ 16
5.1.12 Support different types of QoS requests .................... 16
5.1.13 Work with changing IP addresses of (mobile) hosts .......... 17
5.1.14 Deal with IP fragmentation gracefully ...................... 17
5.1.15 Sender initiated ........................................... 17
5.1.16 Error handling and redundancy considerations ............... 18
5.1.17 Identification requirement ................................. 19
5.2 QoS requirements on BN - BN interface ......................... 19
5.2.1 Ability to traverse a border node transparently ............. 19
5.2.2 Allow local QoS information exchange between two border
nodes ........................................................ 19
5.2.3 Allow generation of local QoS signalling messages ........... 20
5.3 QoS requirements on Interior - Interior interface ............. 20
5.3.1 Modular, Simple, with Minimal Impact on Performance ......... 20
5.3.1.1 Modular ................................................... 20
5.3.1.2 Simple .................................................... 20
5.3.1.3 Minimal Impact on Performance ............................. 21
5.3.2 Ability to deal with mobility (handover) .................... 21
5.3.3 On-demand, dynamic signalling for efficient network uti
lization ..................................................... 22
5.3.4 Ability to deal with severe congestion ...................... 23
5.3.5 Optimize for unicast transport .............................. 24
5.3.6 Ability to transparently traverse an interior node .......... 24
5.3.7 Use of a simple QoS parameter ............................... 24
5.4 BN as initiator and/or terminator of NSIS protocol ............ 24
5.4.1 Allow QoS setup for uni-directional and bi-directional
reservations ................................................. 24
5.4.2 Support end-to-end, edge-to-edge and end-to-edge sig
Partain, et al. Expires August 2002 [Page 29]
Internet Draft NSIS QoS Signalling Requirements February 2002
nalling ...................................................... 25
5.4.3 Allow efficient QoS re-establishment after handover ......... 25
5.4.4 Enable other network entities to generate QoS request be
half of a node ............................................... 25
6 Conclusions ..................................................... 25
7 Full Copyright Statement ........................................ 26
8 References ...................................................... 26
9 Acknowledgments ................................................. 27
10 Editors's Addresses ............................................ 27
Partain, et al. Expires August 2002 [Page 30]