< draft-ietf-nsis-req-03.txt   draft-ietf-nsis-req-04.txt >
NSIS Working Group Network Working Group M. Brunner (Editor)
Internet Draft M. Brunner (Editor) Internet Draft NEC
Document: draft-ietf-nsis-req-03.txt NEC Category: Informational August 2002
Expires: November 2002 May 2002
Requirements for QoS Signaling Protocols Requirements for Signaling Protocols
<draft-ietf-nsis-req-03.txt> <draft-ietf-nsis-req-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 1, line 30
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document defines requirements for signaling QoS across This document defines requirements for signaling across different
different network environments, where different network environments network environments, where different network environments across
across administrative and technology domains. To achieve wide administrative and technology domains. Signaling is mainly though
applicability of the requirements, the starting point is a diverse for QoS such as [1], however in recent year several other
set of scenarios/use cases concerning various types of networks and applications of signaling have been defined such as signaling for
application interactions. We also provide an outline structure for MPLS label distribution [2]. To achieve wide applicability of the
the problem, including QoS related terminology. Taken with the requirements, the starting point is a diverse set of scenarios/use
scenarios, this allows us to focus more precisely on which parts of cases concerning various types of networks and application
the overall QoS problem needs to be solved. We present the interactions. We also provide an outline structure for the problem,
assumptions and the aspects not considered within scope before including related terminology. Taken with the scenarios, this allows
listing the requirements grouped according to areas such as us to focus more precisely on which parts of the overall problem
architecture and design goals, signaling flows, layering, need to be solved. We present the assumptions and the aspects not
performance, flexibility, security, and mobility. considered within scope before listing the requirements grouped
according to areas such as architecture and design goals, signaling
flows, layering, performance, flexibility, security, and mobility.
Table of Contents 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.
Status of this Memo...................................................1 Table of Contents
Abstract..............................................................2
Table of Contents.....................................................2
1 Introduction.......................................................4
2 Terminology........................................................5
3 Problem Statement and Scope........................................8
4 Assumptions and Exclusions........................................10
4.1 Assumptions and Non-Assumptions...............................10
4.2 Exclusions....................................................11
5 Requirements......................................................12
5.1 Architecture and Design Goals.................................13
5.1.1 Applicability for different QoS technologies................13
5.1.2 Resource availability information on request................13
5.1.3 Modularity..................................................13
5.1.4 Decoupling of protocol and information it is carrying.......14
5.1.5 Reuse of existing QoS provisioning..........................14
5.1.6 Independence of signaling and provisioning paradigm.........14
5.2 Signaling Flows...............................................14
5.2.1 Free placement of QoS Initiator and QoS Controllers functions14
5.2.2 No constraint of the QoS signaling and QoS Controllers to be in
the data path.....................................................14
5.2.3 Concealment of topology and technology information..........15
5.2.4 Optional transparency of QoS signaling to network...........15
5.3 Additional information beyond signaling of QoS information....16
5.3.1 Explicit release of resources...............................16
5.3.2 Possibility for automatic release of resources after failure 16
5.3.3 Prompt notification of QoS violation in case of error/failure
to QoS Initiator and QoS Controllers..............................16
5.3.4 Feedback about success of request for QoS guarantees........16
5.3.5 Allow local QoS information exchange between nodes of the same
administrative domain.............................................17
5.4 Layering......................................................17
5.4.1 The signaling protocol and QoS control information should be
application independent...........................................17
5.5 QoS Control Information.......................................17 Status of this Memo................................................1
5.5.1 Mutability information on parameters........................17 Abstract...........................................................1
5.5.2 Possibility to add and remove local domain information......18 Table of Contents..................................................2
5.5.3 Independence of reservation identifier......................18 1 Introduction...................................................3
5.5.4 Seamless modification of already reserved QoS...............18 2 Terminology....................................................4
5.5.5 Grouping of signaling for several microflows................18 3 Problem Statement and Scope....................................6
5.6 Performance...................................................18 4 Assumptions and Exclusions.....................................8
5.6.1 Scalability in the number of messages received by a signaling 4.1 Assumptions and Non-Assumptions..............................8
communication partner (QoS initiator and controller)..............19 4.2 Exclusions...................................................9
5.6.2 Scalability in number of hand-offs..........................19 5 Requirements..................................................11
5.6.3 Scalability in the number of interactions for setting up a 5.1 Architecture and Design Goals...............................11
reservation.......................................................19 5.1.1 MUST be applicable for different technologies...............11
5.6.4 Scalability in the number of state per entity (QoS initiators 5.1.2 Resource availability information on request................12
and QoS controllers)..............................................19 5.1.3 NSIS MUST be designed modular...............................12
5.6.5 Scalability in CPU use (end terminal and intermediate nodes) 19 5.1.4 NSIS MUST decouple protocol and information.................12
5.6.6 Low latency in setup........................................19 5.1.5 NSIS MUST reuse existing QoS provisioning...................12
5.6.7 Allow for low bandwidth consumption for signaling protocol..19 5.1.6 Independence of signaling and provisioning paradigm.........12
5.6.8 Ability to constrain load on devices........................19 5.1.7 Application independence....................................13
5.6.9 Highest possible network utilization........................19 5.2 Signaling Flows.............................................13
5.7 Flexibility...................................................20 5.2.1 Free placement of NSIS Initiator, Forwarder, Responder......13
5.7.1 Aggregation capability, including the capability to select and 5.2.2 No constraint of the signaling and NSIS Forwarders to be in
change the level of aggregation...................................20 the data path.....................................................13
5.7.2 Flexibility in the placement of the QoS initiator...........20 5.2.3 Concealment of topology and technology information..........14
5.7.3 Flexibility in the initiation of re-negotiation (QoS change 5.2.4 Transparency of signaling to network........................14
requests).........................................................20 5.3 Additional information beyond signaling for a service.......14
5.7.4 Uni / bi-directional reservation............................20 5.3.1 Explicit release of resources...............................14
5.8 Security......................................................20 5.3.2 Possibility for automatic release of resources after failure15
5.8.1 Authentication of signaling requests........................20 5.3.3 Notifications sent upstream.................................15
5.8.2 Resource Authorization......................................21 5.3.4 Feedback about success of service request...................16
5.8.3 Integrity protection........................................21 5.3.5 Local information exchange..................................16
5.8.4 Replay protection...........................................21 5.4 Control Information.........................................16
5.8.5 Hop-by-hop security.........................................21 5.4.1 Mutability information on parameters........................16
5.8.6 Identity confidentiality and location privacy...............21 5.4.2 Possibility to add and remove local domain information......17
5.8.7 Denial-of-service attacks...................................22 5.4.3 Independence of reservation identifier......................17
5.8.8 Confidentiality of signaling messages.......................22 5.4.4 Seamless modification of already reserved resources.........17
5.8.9 Ownership of a reservation..................................22 5.4.5 Grouping of signaling for several microflows................17
5.8.10 Hooks with Authentication and Key Agreement protocols......22 5.5 Performance.................................................17
5.9 Mobility......................................................23 5.5.1 Scalability.................................................18
5.9.1 Allow efficient QoS re-establishment after handover.........23 5.5.2 Low latency in setup........................................18
5.10 Interworking with other protocols and techniques............23 5.5.3 Allow for low bandwidth consumption for signaling protocol..18
5.10.1 Interworking with IP tunneling.............................23 5.5.4 Ability to constrain load on devices........................18
5.10.2 The solution should not constrain either to IPv4 or IPv6...23 5.5.5 Highest possible network utilization........................19
5.10.3 Independence from charging model...........................24 5.6 Flexibility.................................................19
5.10.4 Hooks for AAA protocols....................................24 5.6.1 Flow aggregation............................................19
5.10.5 Interworking with seamless handoff protocols...............24 5.6.2 Flexibility in the placement of the NSIS Initiator..........19
5.10.6 Interworking with non-traditional routing..................24 5.6.3 Flexibility in the initiation of re-negotiation.............19
5.11 Operational.................................................24 5.6.4 Uni / bi-directional reservation............................19
5.11.1 Ability to assign transport quality to signaling messages..24 5.7 Security....................................................20
5.11.2 Graceful fail over.........................................24 5.7.1 Authentication of signaling requests........................20
6 The MUSTs, SHOULDs, and MAYs......................................24 5.7.2 Resource Authorization......................................20
7 References........................................................30 5.7.3 Integrity protection........................................20
8 Acknowledgments...................................................30 5.7.4 Replay protection...........................................20
9 Author's Addresses................................................31 5.7.5 Hop-by-hop security.........................................20
10 Appendix: Scenarios/Use cases...................................31 5.7.6 Identity confidentiality and location privacy...............21
10.1 Scenario: Terminal Mobility.................................32 5.7.7 Denial-of-service attacks...................................21
10.2 Scenario: Cellular Networks.................................34 5.7.8 Confidentiality of signaling messages.......................21
10.3 Scenario: UMTS access.......................................34 5.7.9 Ownership of a reservation..................................21
10.4 Scenario: Wired part of wireless network....................36 5.7.10 Hooks with Authentication and Key Agreement protocols......22
10.5 Scenario: Session Mobility..................................38 5.8 Mobility....................................................22
10.6 Scenario: QoS reservations/negotiation from access to core 5.8.1 Allow efficient QoS re-establishment after handover.........22
network............................................................38 5.9 Interworking with other protocols and techniques............23
10.7 Scenario: QoS reservation/negotiation over administrative 5.9.1 MUST interwork with IP tunneling............................23
boundaries.........................................................39 5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6......23
10.8 Scenario: QoS signaling between PSTN gateways and backbone 5.9.3 MUST be independent from charging model.....................23
routers............................................................39 5.9.4 SHOULD provide hooks for AAA protocols......................23
10.9 Scenario: PSTN trunking gateway.............................41 5.9.5 SHOULD interwork with seamless handoff protocols............23
10.10 Scenario: Application request end-to-end QoS path from the 5.9.6 MAY interwork with non-traditional routing..................23
network............................................................42 5.10 Operational................................................23
10.11 Scenario: QOS for Virtual Private Networks..................42 5.10.1 Ability to assign transport quality to signaling messages..23
5.10.2 Graceful fail over.........................................24
5.10.3 Graceful handling of NSIS entity problems..................24
6 Security Considerations.......................................24
7 Reference.....................................................24
8 Acknowledgments...............................................24
9 Author's Addresses............................................25
10 Appendix: Scenarios/Use cases.................................25
10.1 Terminal Mobility..........................................25
10.2 Cellular Networks..........................................27
10.3 UMTS access................................................28
10.4 Wired part of wireless network.............................30
10.5 Session Mobility...........................................31
10.6 QoS reservations/negotiation from access to core network...32
10.7 QoS reservation/negotiation over administrative boundaries.32
10.8 QoS signaling between PSTN gateways and backbone routers...33
10.9 PSTN trunking gateway......................................34
10.10 Application request end-to-end QoS path from the network...36
1 Introduction 1 Introduction
This document defines requirements for signaling QoS across This document defines requirements for signaling across different
different network environments. It does not list any problems of network environments. It does not list any problems of existing
existing QoS signaling protocols such as RSVP. signaling protocols such as RSVP [1].
In order to derive requirements for QoS signaling it is necessary to In order to derive requirements for signaling it is necessary to
first have a clear idea of the scope within which they are first have a clear idea of the scope within which they are
applicable. applicable.
We describe a set of QoS signaling scenarios and use cases in the We describe a set of QoS signaling scenarios and use cases in the
Appendix of that document. These scenarios derive from a variety of Appendix of that document. These scenarios derive from a variety of
backgrounds, and help obtain a clearer picture of what is in or out backgrounds, and help obtain a clearer picture of what is in or out
of scope of the NSIS work. They illustrate the problem of QoS of scope of the NSIS work. They illustrate the problem of QoS
signaling from various perspectives (end-system, access network, signaling from various perspectives (end-system, access network,
core network) and for various areas (fixed line, mobile, wireless core network) and for various areas (fixed line, mobile, wireless
environments). As the NSIS work becomes more clearly defined, environments).
scenarios will be added or dropped, or defined in more detail.
Based on these scenarios, we are able to define the QoS signaling Based on these scenarios, we are able to define the signaling
problem on a more abstract level. In Section 3, we thus present a problem on a more abstract level. In Section 3, we thus present a
simple conceptual model of the QoS signaling problem. Additionally, simple conceptual model of the signaling problem. Additionally, we
we describe the entities involved in QoS signaling and typical describe the entities involved in signaling and typical signaling
signaling paths. In Section 4 we list assumptions and exclusions. paths. In Section 4 we list assumptions and exclusions.
The model of Section 3 allows deriving requirements from the The model of Section 3 allows deriving requirements from the
scenarios presented in the appendix in a coherent and consistent scenarios presented in the appendix in a coherent and consistent
manner. Requirements are grouped according to areas such as manner. Requirements are grouped according to areas such as
Architecture and design goals, Signaling Flows, Layering, Architecture and design goals, Signaling Flows, Layering,
Performance, Flexibility, Security and Mobility. Performance, Flexibility, Security and Mobility.
QoS is a pretty large field with a lot of interaction with other QoS is a pretty large field with a lot of interaction with other
protocols, mechanisms, applications etc. In the following, some protocols, mechanisms, applications etc. However, it is not the
thoughts from an end-system point of view and from a network point only field where signaling is used in the Internet. Even if this
of view. requirement documents mainly used QoS as the sample application
other application should be possible.
End-system perspective: In future mobile terminals, the support of
adaptive applications is more and more important. Adaptively can be
seen as an important technique to react to QoS violations that may
occur frequently, e.g., in wireless environments due to changed
environmental and network conditions. This may result in degraded
end-to-end performance. It is then up to adaptive applications to
react to the new resource availability. Therefore, it is essential
to define interoperability between media-, mobility- and QoS
management. While most likely mobile terminals cannot assume, that
explicit QoS reservation schemes are available, some access networks
nevertheless may offer such capabilities. Applications subscribed to
an end-system QoS management system should be supported with a
dedicated QoS API to set-up, control and adapt media sessions.
Network perspective: QoS enabled IP networks are expected to handle
two different kinds of QoS granularities: per-flow QoS and per-
trunk/per-class QoS. Per-flow QoS might be needed in access networks
and may there be subject of QoS signaling. However, in the core
network only per-trunk or per-class QoS can be considered for
scalability reasons. Therefore there might be different requirements
on QoS signaling applying to different parts of the network. In the
access network QoS signaling is an interaction between end systems
and access routers or access network QoS managers (in the following
we call them QoS initiator and QoS controller). In the core network
QoS signaling refers to trunks or classes of traffic between core
and edge systems or between peering core systems. Please note that
this does not exclude the transport of per-flow signaling through
core networks.
It is clear from these descriptions that the subject of QoS is It is clear that the subject of QoS is uniquely complex and any
uniquely complex and any investigation could potentially have a very investigation could potentially have a very broad scope - so broad
broad scope - so broad that it is a challenge to focus work on an that it is a challenge to focus work on an area, which could lead to
area, which could lead to a concrete and useful result. This is our a concrete and useful result. This is our motivation for considering
motivation for considering a set of use cases, which map out the a set of use cases, which map out the domain of application that we
domain of application that we want to address. It is also the want to address. It is also the motivation for defining a problem
motivation for defining a problem structure, which allows us to structure, which allows us to state the boundaries of what types of
state the boundaries of what types of functionality to consider, and functionality to consider, and to list background assumptions.
to list background assumptions.
There are several areas of the requirements related to networking There are several areas of the requirements related to networking
aspects which are incomplete, for example, interaction with host and aspects which are incomplete, for example, interaction with host and
site multi-homing, use of anycast services, and so on. These issues site multi-homing, use of anycast services, and so on. These issues
should be considered in any future requirement analysis work. should be considered in any future analysis work.
2 Terminology 2 Terminology
In the area of Qualiaty of Service (QoS) it is quite difficult and In the area of Quality of Service (QoS) it is quite difficult and an
an exercise for its own to define terminology. Nevertheless, we exercise for its own to define terminology. Nevertheless, we tried
tried to list the most often used terms in the draft and tried to to list the most often used terms in the draft and tried to explain
explain them. However, don't be to religious about it, they are not them. However, don't be to religious about it, they are not meant to
meant to prescribe any thing in the draft. prescribe any thing in the draft.
Aggregate: a group of flows, usually with similar QoS requirements, NSIS Domain (ND) - Administrative domain where an NSIS protocol
which can be treated together as a whole with a single overall QoS signals for a resource or set of resources.
requirement for signaling and provisioning. Aggregates and flows can
be further aggregated together.
[QoS] Domain: a collection of networks under the same administrative NSIS Entity (NE) - the function within a node, which implements an
control and grouped together for administrative purposes. NSIS protocol.
NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR,
which may interact with local resource management function (RMF) for
this purpose. NSIS Forwarder also propagates NSIS signaling further
through the network. It is responsible for interpreting the
signaling carrying the user parameters, optionally inserting or
modifying the parameters according to domain network management
policy.
NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for
a network resource based on user or application requirements. This
can be located in the end system, but may reside elsewhere in
network.
NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and
can optionally interact with applications as well.
Resource Management Function (RMF) - an abstract concept,
representing the management of resources in a domain or a node.
Egress point: the router via which a path exits a domain/subdomain. Egress point: the router via which a path exits a domain/subdomain.
End Host: the end system or host, for whose flows QoS is being End Host: the end system or host, for whose flows QoS is being
requested and provisioned. requested and provisioned.
End-to-End QoS: the QoS delivered by the network between two End-to-End QoS: the QoS delivered by the network between two
communicating end hosts. End-to-end QoS co-ordinates and enforces communicating end hosts. End-to-end QoS co-ordinates and enforces
predefined traffic management policies across multiple network predefined traffic management policies across multiple network
entities and administrative domains. entities and administrative domains.
Edge-to-edge QoS: QoS within an administrative domain that connects Edge-to-edge QoS: QoS within an administrative domain that connects
to other networks rather than hosts or end systems. to other networks rather than hosts or end systems.
Flow: a traffic stream (sequence of IP packets between two end Flow: a traffic stream (sequence of IP packets between two end
systems) for which a specific level of QoS is to be provided. The systems) for which a specific level of QoS is to be provided. The
flow can be unicast (uni- or bi-directional) or multicast. flow can be unicast (uni- or bi-directional) or multicast.
Flow Administration: represents the policy associated with how flows
should be treated in the network, for example whether and how the
flows should be aggregated. It may consist of both user and local
network management information.
Higher Layers: the higher layer (transport protocol and application) Higher Layers: the higher layer (transport protocol and application)
functions that request QoS from the network layer. The request might functions that request QoS from the network layer. The request might
be a trigger generated within the end system, or the trigger might be a trigger generated within the end system, or the trigger might
be provided by some entity within the network (e.g. application be provided by some entity within the network (e.g. application
proxy or policy server). proxy or policy server).
Indication: feedback from QoS provisioning to indicate the current Indication: feedback from QoS provisioning to indicate the current
QoS being provided to a flow or aggregate, and whether any QoS being provided to a flow or aggregate, and whether any
violations have been detected by the QoS technology being used violations have been detected by the QoS technology is being used
within the local domain/subdomain. within the local domain/subdomain.
Ingress point: the router via which a path enters a Ingress point: the router via which a path enters a
domain/subdomain. domain/subdomain.
Mapping: the act of transforming parameters from QSCs to values that
are meaningful to the actual QoS technology in use in the
domain/subdomain.
Path: the route across the networks taken by a flow or aggregate, Path: the route across the networks taken by a flow or aggregate,
i.e. which domains/subdomains it passes through and the i.e. which domains/subdomains it passes through and the
egress/ingress points for each. egress/ingress points for each.
Path segment: the segment of a path within a single Path segment: the segment of a path within a single
domain/subdomain. domain/subdomain.
QoS Administration Function: a generic term for all functions Control Information: the information the governs for instance the
associated with admission control, policy control, traffic QoS treatment to be applied to a flow or aggregate, including the
engineering etc. service class, flow administration, and any associated security or
accounting information.
QoS Control Information: the information the governs the QoS
treatment to be applied to a flow or aggregate, including the QSC,
flow administration, and any associated security or accounting
information.
QoS Controller: this is responsible for interpreting the signaling
carrying the user QoS parameters, optionally inserting/modifying the
parameters according to local network QoS management policy, and
invoking local QoS provisioning mechanisms. Note that q QoS
controller might have very different functionality depending on
where in the network and in what environment they are implemented.
QoS Initiator: this is responsible for generating the QSCs for
traffic flow(s) based on user or application requirements and
signaling them to the network as well as invoking local QoS
provisioning mechanisms. This can be located in the end system, but
may reside elsewhere in network.
QoS Provisioning: the act of actually allocating resources to a flow QoS Provisioning: the act of actually allocating resources to a flow
or aggregate of flows, may include mechanisms such as LSP initiation or aggregate of flows, may include mechanisms such as LSP initiation
for MPLS, packet scheduler configuration within a router, and so on. for MPLS, packet scheduler configuration within a router, and so on.
The mechanisms depend on the overall QoS technology being used The mechanisms depend on the overall QoS technology being used
within the [sub]domain. within the domain.
QoS Service Classes (QSC): specify the QoS requirements of a traffic
flow or aggregate. Can be further sub-divided into user specific
and network related parameters
QoS Signaling: a way to communicate QSCs and QoS management
information between hosts, end systems and network devices etc. May
include request and response messages to facilitate negotiation/re-
negotiation, asynchronous feedback messages (not delivered upon
request) to inform End Hosts, QoS initiators and QoS controllers
about current QoS levels, and QoS querying facilities.
[QoS] Subdomain: a network within an administrative domain using a Subdomain: a network within an administrative domain using a uniform
uniform technology/QoS provisioning function to provision resources. technology, e.g., a single QoS provisioning function to provision
resources.
QoS Technology: a generic term for a set of protocols, standards and QoS Technology: a generic term for a set of protocols, standards and
mechanisms that can be used within a QoS domain/subdomain to manage mechanisms that can be used within a QoS domain/subdomain to manage
the QoS provided to flows or aggregates that traverse the domain. the QoS provided to flows or aggregates that traverse the domain.
Examples might include MPLS, DiffServ, and so on. A QoS technology Examples might include MPLS, DiffServ, and so on. A QoS technology
is associated with certain QoS provisioning techniques. is associated with certain QoS provisioning techniques.
QoS Violation: occurs when the QoS applied to a flow or aggregate
does not meet the requested and negotiated QoS agreed for it.
Resource: something of value in a network infrastructure to which Resource: something of value in a network infrastructure to which
rules or policy criteria are first applied before access is granted. rules or policy criteria are first applied before access is granted.
Examples of resources include the buffers in a router and bandwidth Examples of resources include the buffers in a router and bandwidth
on an interface. on an interface.
Resource Allocation: part of a resource that has been dedicated for Resource Allocation: part of a resource that has been dedicated for
the use of a particular traffic type for a period of time through the use of a particular traffic type for a period of time through
the application of policies. the application of policies.
Sender-initiated QoS signaling protocol: A sender-initiated QoS Sender-initiated signaling protocol: A sender-initiated signaling
signaling protocol is a protocol (see e.g., YESSIR [8], RMD [10]) protocol is a protocol where the NI initiates the signaling on
where the QI initiates the signaling on behalf of the sender of the behalf of the sender of the data. What this means is that admission
data. What this means is that admission control and resource control and resource allocation functions are processed from the
allocation functions are processed from the data sender towards the data sender towards the data receiver. However, the triggering
data receiver. However, the triggering instance is not specified.
Receiver-initiated QoS signaling protocol: A receiver-initiated
protocol, (see e.g., RSVP [9]) is a protocol where the QoS
reservations are initiated by the QoS Receiver on behalf of the
receiver of the user data. What this means is that admission control
and resource allocation functions are processed from the data
receiver back towards the data sender. However, the triggering
instance is not specified. instance is not specified.
Receiver-initiated signaling protocol: A receiver-initiated
protocol, (see e.g., RSVP [1]) is a protocol where the NSIS
Responder on behalf of the receiver of the user data initiates the
reservations. What this means is that admission control and resource
allocation functions are processed from the data receiver back
towards the data sender. However, the triggering instance is not
specified.
3 Problem Statement and Scope 3 Problem Statement and Scope
We provide in the following a preliminary architectural picture as a We provide in the following a preliminary architectural picture as a
basis for discussion. We will refer to it in the following basis for discussion. We will refer to it in the following
requirement section. requirement section.
A set of issues and problems to be solved has been given at a top A set of issues and problems to be solved has been given at a top
level by the use cases/scenarios of the appendix. However, the level by the use cases/scenarios of the appendix. However, the
problem of QoS has an extremely wide scope and there is a great deal problem of QoS has an extremely wide scope and there is a great deal
of work already done to provide different components of the of work already done to provide different components of the
solution, such as QoS technologies for example. A basic goal should solution, such as QoS technologies for example. A basic goal should
be to re-use these wherever possible, and to focus requirements work be to re-use these wherever possible, and to focus requirements work
at an early stage on those areas where a new solution is needed at an early stage on those areas where a new solution is needed
(e.g. an especially simple one). We also try to avoid defining (e.g. an especially simple one). We also try to avoid defining
requirements related to internal implementation aspects. requirements related to internal implementation aspects.
In this section, we present a simple conceptual model of the overall In this section, we present a simple conceptual model of the overall
QoS problem in order to identify the applicability to NSIS of problem in order to identify the applicability to NSIS of
requirements derived from the use cases, and to clarify the scope of requirements derived from the use cases, and to clarify the scope of
the work, including any open issues. This model also identifies the work, including any open issues. This model also identifies
further sources of requirements from external interactions with further sources of requirements from external interactions with
other parts of an overall QoS solution, clarifies the terminology other parts of an overall solution, clarifies the terminology used,
used, and allows the statement of design goals about the nature of and allows the statement of design goals about the nature of the
the solution (see section 5). solution (see section 5).
Note that this model is intended not to constrain the technical Note that this model is intended not to constrain the technical
approach taken subsequently, simply to allow concrete phrasing of approach taken subsequently, simply to allow concrete phrasing of
requirements (e.g. requirements about placement of the QoS requirements (e.g. requirements about placement of the NSIS
initiator, or ability to 'drive' particular QoS technologies.) Initiator, or ability to 'drive' particular QoS technologies.)
Roughly, the scope of NSIS is assumed to be the interaction between Roughly, the scope of NSIS is assumed to be the interaction between
the QoS initiator and QoS controller(s), including selection of the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder
signaling protocols to carry the QoS information, and the including a protocol to carry the information, and the
syntax/semantics of the information that is exchanged. Further syntax/semantics of the information that is exchanged. Further
statements on assumptions/exclusions are given in the next Section. statements on assumptions/exclusions are given in the next Section.
The main elements are: The main elements are:
1. Something that starts the request for QoS, the QoS Initiator. 1. Something that starts the request for resources, the NSIS
Initiator.
This might be in the end system or within some other part of the This might be in the end system or within some other part of the
network. The distinguishing feature of the QoS initiator is that it network. The distinguishing feature of the NSIS Initiator is that it
acts on triggers coming (directly or indirectly) from the higher acts on triggers coming (directly or indirectly) from the higher
layers in the end systems. It needs to map the QoS requested by layers in the end systems. It needs to map the resources requested
them, and also provides feedback information to the higher layers, by them, and also provides feedback information to the higher
which might be used by transport layer rate management or adaptive layers, which might be used by transport layer rate management or
applications. adaptive applications.
2. Something that assists in managing QoS further along the path, 2. Something that assists in managing resources further along the
the QoS controller. path, the NSIS Forwarder.
The QoS controller does not interact with higher layers, but The NSIS Forwarder does not interact with higher layers, but
interacts with the QoS initiator and possibly more QoS controllers interacts with the NSIS Initiator and possibly more NSIS Forwarders
on the path, edge to edge or possibly end to end. on the path, edge-to-edge or possibly end-to-end.
3. The QoS initiator and controller(s) interact with each other, 3. The NSIS Initiator and NSIS Forwarder(s) interact with each
path segment by path segment. This interaction involves the exchange other, path segment by path segment. This interaction involves the
of data (QoS control information) over some signaling protocol. exchange of data (resources control information) over some signaling
protocol.
4. The path segment traverses an underlying network (QoS domain or 4. The path segment traverses an underlying network covering one or
subdomain) covering one or more IP hops. The underlying network uses more IP hops. The underlying network uses some local QoS technology.
some local QoS technology. This QoS technology has to be provisioned This QoS technology has to be provisioned appropriately for the
appropriately for the flow, and the QoS initiator does this and service requested. An NSIS Forwarder maps service-specific
controller(s), mapping their QoS control information to technology- information to technology-related QoS parameters and receiving
related QoS parameters and receiving indications about success or indications about success or failure in response.
failure in response.
Now concentrating more on the overall end to end (multiple QoS Now concentrating more on the overall end to end (multiple domain)
domains) aspects, in particular: aspects, in particular:
1. The QoS initiator need not be located at an end system, and the 1. The NSIS Initiator need not be located at an end system, and the
QoS controllers are not assumed to be located on the flow's data NSIS Forwarders are not assumed to be located on the flow's data
path. However, they must be able to identify the ingress and egress path. However, they must be able to identify the ingress and egress
points for the flow path as it traverses the domain/subdomain. Any points for the flow path as it traverses the domain/subdomain. Any
signaling protocol must be able to find the appropriate QoS signaling protocol must be able to find the appropriate NSIS
controller and carry this ingress/egress point information. Forwarder and carry this ingress/egress point information.
2. We see the network at the level of domains/subdomains rather than 2. We see the network at the level of domains/subdomains rather than
individual routers (except in the special case that the domain individual routers (except in the special case that the domain
contains one link). Domains are assumed to be administrative contains one link). Domains are assumed to be administrative
entities, so security requirements apply to the signaling between entities, so security requirements apply to the signaling between
them. Subdomains are introduced to allow the fact a given QoS them.
provisioning mechanism may only be used within a part of a domain,
typically for a particular subnetwork technology boundary.
Aggregation can also take place at subdomain boundaries.
3. Any domain may contain QoS administration functions (e.g. to do 3. Any domain may contain Resource Management Function (e.g. to do
with traffic engineering, admission control, policy and so on). with traffic engineering, admission control, policy and so on).
These are assumed to interact with the QoS initiator and controllers These are assumed to interact with the NSIS Initiator and
(and end systems) using standard mechanisms. Controllers (and end systems) using standard mechanisms.
4. The placement of the QoS initiators and QoS controllers is not
fixed. Actually, there are two extreme cases:
- Each router on the data path implements a QoS controller and QoS
initiator.
- Only the end systems incorporate a QoS controller and QoS 4. The placement of the NSIS Initiators and NSIS Forwarders is not
initiator, which mean the end systems need to have QoS provisioning fixed.
capabilities. However this case does not seam to be realistic but
shows the flexible allocation of the controller and initiator
function.
4 Assumptions and Exclusions 4 Assumptions and Exclusions
4.1 Assumptions and Non-Assumptions 4.1 Assumptions and Non-Assumptions
1. The NSIS signaling could run end to end, end to edge, or edge to 1. The NSIS signaling could run end to end, end to edge, or edge to
edge, or network-to-network ((between providers), depending on what edge, or network-to-network ((between providers), depending on what
point in the network acts as the initiator, and how far towards the point in the network acts as the initiator, and how far towards the
other end of the network the signaling propagates. Although the other end of the network the signaling propagates. Although the
figures show QoS controllers at a very limited number of locations figures show NSIS Forwarders at a very limited number of locations
in the network (e.g. at domain or subdomain borders, or even in the network (e.g. at domain or subdomain borders, or even
controlling a complete domain), this is only one possible case. In controlling a complete domain), this is only one possible case. In
general, we could expect QoS controllers to become more 'dense' general, we could expect NSIS Forwarders to become more 'dense'
towards the edges of the network, but this is not a requirement. An towards the edges of the network, but this is not a requirement. An
overprovisioned domain might contain no QoS controllers at all (and over-provisioned domain might contain no NSIS Forwarders at all (and
be NSIS transparent); at the other extreme, QoS controllers might be be NSIS transparent); at the other extreme, NSIS Forwarders might be
placed at every router. In the latter case, QoS provisioning can be placed at every router. In the latter case, QoS provisioning can be
carried out in a local implementation-dependent way without further carried out in a local implementation-dependent way without further
signaling, whereas in the case of remote QoS controllers, a signaling, whereas in the case of remote NSIS Forwarders, a
provisioning protocol might be needed to control the routers along provisioning protocol might be needed to control the routers along
the path. This provisioning protocol is then independent of the end the path. This provisioning protocol is then independent of the end-
to end NSIS signaling. to-end NSIS signaling.
2. We do not consider 'pure' end-to-end QoS signaling that is not 2. We do not consider 'pure' end-to-end signaling that is not
interpreted anywhere within the network. Such signaling is an interpreted anywhere within the network. Such signaling is an
application-layer issue and IETF protocols such as SIP etc. can be application-layer issue and IETF protocols such as SIP etc. can be
used. used.
3. Where the signaling does cover several QoS domains or subdomains, 3. Where the signaling does cover several NSIS domains or
we do not exclude that different signaling protocols are used in subdomains, we do not exclude that different signaling protocols are
each path segment. We only place requirements on the universality of used in each path segment. We only place requirements on the
the QoS control information that is being transported. (The goals universality of the control information that is being transported.
here would be to allow the use of signaling protocols, which are (The goals here would be to allow the use of signaling protocols,
matched to the characteristics of the portion of the network being which are matched to the characteristics of the portion of the
traversed.) Note that the outcome of NSIS work might result in network being traversed.) Note that the outcome of NSIS work might
various protocols or various flavors of the same protocol. This result in various protocols or various flavors of the same protocol.
implies the need for the translation of information into QoS domain This implies the need for the translation of information into domain
specific format as well. specific format as well.
4. We assume that the service definitions a QoS initiator can ask 4. We assume that the service definitions a NSIS Initiator can ask
for are known in advance of the signaling protocol running. Service for are known in advance of the signaling protocol running. Service
definition includes QoS parameters, lifetime of QoS guarantee etc. definition includes QoS parameters, lifetime of QoS guarantee etc.,
or any other service-specific parameters.
There are many ways service requesters get to know about it. There There are many ways service requesters get to know about it. There
might be standardized services, the definition can be negotiated might be standardized services, the definition can be negotiated
together with a contract, the service definition is published at a together with a contract, the service definition is published at a
Web page, etc. Web page, etc.
5. We assume that there are means for the discovery of NSIS entities 5. We assume that there are means for the discovery of NSIS entities
in order to know the signaling peers (solutions include static in order to know the signaling peers (solutions include static
configuration, automatically discovered, or implicitly runs over the configuration, automatically discovered, or implicitly runs over the
right nodes, etc.) The discovery of the NSIS entities has security right nodes, etc.) The discovery of the NSIS entities has security
implications that need to be addressed properly. These implications implications that need to be addressed properly. These implications
largely depend on the chosen protocol. For some security mechanisms largely depend on the chosen protocol. For some security mechanisms
(i.e. Kerberos, pre-shared secret) it is required to know the (i.e. Kerberos, pre-shared secret) it is required to know the
identity of the other entity. Hence the discovery mechanism may identity of the other entity. Hence the discovery mechanism may
provide means to learn this identity, which is then later used to provide means to learn this identity, which is then later used to
retrieve the required keys and parameters. retrieve the required keys and parameters.
6. NSIS assumes to operate with networks using standard ("normal") 6. NSIS assumes to operate with networks using standard ("normal")
L3 routing. L3 routing. Where "normal" is not specified more exactly on purpose.
4.2 Exclusions 4.2 Exclusions
1. Development of specific mechanisms and algorithms for application 1. Development of specific mechanisms and algorithms for application
and transport layer adaptation are not considered, nor are the and transport layer adaptation are not considered, nor are the
protocols that would support it. protocols that would support it.
2. Specific mechanisms (APIs and so on) for interaction between 2. Specific mechanisms (APIs and so on) for interaction between
transport/applications and the network layer are not considered, transport/applications and the network layer are not considered,
except to clarify the requirements on the negotiation capabilities except to clarify the requirements on the negotiation capabilities
and information semantics that would be needed of the signaling and information semantics that would be needed of the signaling
protocol. The same applies to application adaptation mechanisms. protocol. The same applies to application adaptation mechanisms.
3. Specific mechanisms for QoS provisioning within a 3. Specific mechanisms for QoS provisioning within a
domain/subdomain are not considered. It should be possible to domain/subdomain are not considered. However, NSIS can be used for
exploit these mechanisms optimally within the end to end context. signaling within a domain/subdomain performing QoS provisioning. It
Consideration of how to do this might generate new requirements for should be possible to exploit these mechanisms optimally within the
NSIS however. For example, the information needed by a QoS end-to-end context. Consideration of how to do this might generate
controller to manage a radio subnetwork needs to be provided by the new requirements for NSIS however. For example, the information
NSIS solution. needed by a NSIS Forwarder to manage a radio subnetwork needs to be
provided by the NSIS solution.
4. Specific mechanisms (APIs and so on) for interaction between the 4. Specific mechanisms (APIs and so on) for interaction between the
network layer and underlying QoS provisioning mechanisms are not network layer and underlying QoS provisioning mechanisms are not
considered. considered.
5. Interaction with QoS administration capabilities is not 5. Interaction with resource management capabilities is not
considered. Standard protocols should be used for this (e.g. COPS). considered. Standard protocols should be used for this (e.g. COPS).
This may imply requirements for the sort of information that should This may imply requirements for the sort of information that should
be exchanged between the NSIS network QoS entities. be exchanged between the NSIS entities.
6. Security implications related to multicasting are outside the 6. Security implications related to multicasting are outside the
scope of the QoS signaling protocol. scope of the signaling protocol.
7. Protection of non-QoS signaling messages is outside the scope of 7. Protection of non-signaling messages is outside the scope of the
the QoS protocol protocol
The protection of non-signaling messages (including data traffic The protection of non-signaling messages (including data traffic
following a reservation) is not directly considered by a signaling following a reservation) is not directly considered by a signaling
protocol. The protection of data messages transmitted along the QoS protocol. The protection of data messages transmitted along the
provisioned path is outside the scope of a signaling protocol. provisioned path is outside the scope of a signaling protocol.
Regarding data traffic there is an interaction with accounting Regarding data traffic there is an interaction with accounting
(metering) and edge routers might require packets to be integrity (metering) and edge routers might require packets to be integrity
protected to be able to securely assign incoming data traffic to a protected to be able to securely assign incoming data traffic to a
particular user. particular user.
Additionally there might be an interaction with IPsec protected Additionally there might be an interaction with IPSec protected
traffic experiencing QoS treatment and the established state created traffic experiencing QoS treatment and the established state created
due to signaling. One example of such an interaction is the different due to signaling. One example of such an interaction is the different
flow identification with and without IPsec protection. flow identification with and without IPSec protection.
Many security properties are likely to be application specific and Many security properties are likely to be application specific and
may be provided by the corresponding application layer protocol. may be provided by the corresponding application layer protocol.
8. Service definitions and QoS classes are out of scope. Together 8. Service definitions and in particular QoS classes are out of
with the service definition any definition of service specific scope. Together with the service definition any definition of
parameters are not considered in this draft. Only the base NSIS service specific parameters are not considered in this draft. Only
signaling protocol for transporting the QoS/service information are the base NSIS signaling protocol for transporting the service
handled. information are handled.
9. Similarly, specific methods, protocols, and ways to express QoS 9. Similarly, specific methods, protocols, and ways to express
information in the Application/Session level are not considered QoS/service information in the Application/Session level are not
(e.g., SDP, SIP, RTSP, etc.). considered (e.g., SDP, SIP, RTSP, etc.).
10. The specification of any extensions needed to signal QoS 10. The specification of any extensions needed to signal information
information via application level protocols (e.g. SDP(ng)), and the via application level protocols (e.g. SDP), and the mapping on NSIS
mapping on NSIS information are considered outside of the scope of information are considered outside of the scope of NSIS working
NSIS working group, as this work is in the direct scope of other group, as this work is in the direct scope of other IETF working
IETF working groups (e.g. MMUSIC). groups (e.g. MMUSIC).
11. Handoff decision and trigger sources: An NSIS protocol is not 11. Handoff decision and trigger sources: An NSIS protocol is not
used to trigger handoffs in mobile IP, nor is it used to decide used to trigger handoffs in mobile IP, nor is it used to decide
whether to handoff or not. As soon as or in some situation even whether to handoff or not. As soon as or in some situation even
before a handoff happened, an NSIS protocol might be used for before a handoff happened, an NSIS protocol might be used for
signaling for QoS again. However, NSIS must interwork with several signaling for QoS again. However, NSIS MUST interwork with several
protocols for mobility management. protocols for mobility management.
12. QoS monitoring is out of scope. It is heavily dependent on the 12. QoS monitoring is out of scope. It is heavily dependent on the
type of the application and or transport service, and in what type of the application and or transport service, and in what
scenario it is used. scenario it is used.
5 Requirements 5 Requirements
This section defines more detailed requirements for a QoS signaling
solution, derived from consideration of the use cases/scenarios, and This section defines more detailed requirements for a signaling
respecting the framework, scoping assumptions, and terminology solution, derived from consideration of the use cases/scenarios
considered earlier. The requirements are in subsections, grouped described in the appendix, and respecting the framework, scoping
roughly according to general technical aspects: architecture and assumptions, and terminology considered earlier. The requirements
design goals, topology issues, QoS parameters, performance, are in subsections, grouped roughly according to general technical
security, information, and flexibility. aspects: architecture and design goals, topology issues, parameters,
performance, security, information, and flexibility.
Two general (and potentially contradictory) goals for the solution Two general (and potentially contradictory) goals for the solution
are that it should be applicable in a very wide range of scenarios, are that it should be applicable in a very wide range of scenarios,
and at the same time lightweight in implementation complexity and and at the same time lightweight in implementation complexity and
resource requirements in nodes. One approach to this is that the resource requirements in nodes. One approach to this is that the
solution could deal with certain requirements via modular components solution could deal with certain requirements via modular components
or capabilities, which are optional to implement in individual or capabilities, which are optional to implement in individual
nodes. nodes.
Some of the requirements are technically contradictory. Depending on Some of the requirements are technically contradictory. Depending on
the scenarios a solution applies to, one or the other requirement is the scenarios a solution applies to, one or the other requirement is
applicable. applicable.
Find in Section 6 the MUSTs, SHOULDs, and MAYs In order to prioritize the various requirements we define different
'parts of the network'. In the different parts of the network a
particular requirement might have a different priority.
The parts of the networks we differentiate are the host-to-first
router, the access network, and the core network. The host to first
router part includes all the layer 2 technologies to access to the
Internet. In many cases, there is an application and/or user running
on the host initiating signaling. The access network can be
characterized by low capacity links, medium speed IP processing
capabilities, and it might consist of a complete layer 2 network as
well. The core network characteristics include high-speed forwarding
capacities and inter-domain issues. All of them are not strictly
defined and should not be regarded as that, but should give a
feeling about where in the network we have different requirements
concerning signaling.
5.1 Architecture and Design Goals 5.1 Architecture and Design Goals
This section contains requirements related to desirable overall This section contains requirements related to desirable overall
characteristics of a solution, e.g. enabling flexibility, or characteristics of a solution, e.g. enabling flexibility, or
independence of parts of the framework. independence of parts of the framework.
5.1.1 Applicability for different QoS technologies. 5.1.1 MUST be applicable for different technologies.
The QoS signaling protocol must work with various QoS technologies. The signaling protocol MUST work with various QoS technologies as
The information exchanged over the signaling protocol must be in well as other technologies needing signaling. The information
such detail and quantity that it is useful for various QoS exchanged over the signaling protocol must be in such detail and
technologies. quantity that it is useful for various technologies.
5.1.2 Resource availability information on request 5.1.2 Resource availability information on request
In some scenarios, e.g., the mobile terminal scenario, it is In some scenarios, e.g., the mobile terminal scenario, it is
required to query, whether resources are available, without required to query, whether resources are available, without
performing a reservation on the resource. One solution might be a performing a reservation on the resource. One solution might be a
feedback mechanism based on which a QoS inferred handover can take feedback mechanism based on which a QoS inferred handover can take
place. place. So NSIS SHOULD provide a mechanism to check whether resources
are available without performing a reservation
5.1.3 Modularity 5.1.3 NSIS MUST be designed modular
A modular design allows for more lightweight implementations, if A modular design allows for more lightweight implementations, if
fewer features are needed. Mutually exclusive solutions are fewer features are needed. Mutually exclusive solutions are
supported. Examples for modularity: supported. Examples for modularity:
- Work over any kind of network (narrowband / broadband, error-prone - Work over any kind of network (narrowband versus broadband, error-
/ reliable...) - This implies low bandwidth signaling and redundant prone versus reliable, ...). This implies low bandwidth signaling
information must be supported if necessary. and redundant information MUST be supported if necessary.
- Uni- and bi-directional reservations are possible - Uni- and bi-directional reservations are possible
- Extensible in the future with different add-ons for certain - Extensible in the future with different add-ons for certain
environments or scenarios environments or scenarios
5.1.4 Decoupling of protocol and information it is carrying - Protocol layering, where appropriate. This means NSIS MUST provide
a base protocol, which can be adapted to different environments.
The signaling protocol(s) used must be clearly separated from the 5.1.4 NSIS MUST decouple protocol and information
QoS control information being transported. This provides for the
independent development of these two aspects of the solution, and
allows for this control information to be carried within other
protocols, including application layer ones, existing ones or those
being developed in the future. The gained flexibility in the
information transported allows for the applicability of the same
protocol in various scenarios.
However, note that the information carried needs to be the same.
Otherwise interoperability is difficult to achieve.
5.1.5 Reuse of existing QoS provisioning The signaling protocol MUST be clearly separated from the control
information being transported. This provides for the independent
development of these two aspects of the solution, and allows for
this control information to be carried within other protocols,
including application layer ones, existing ones or those being
developed in the future. The gained flexibility in the information
transported allows for the applicability of the same protocol in
various scenarios.
Reuse existing QoS functions and protocols for QoS provisioning However, note that the information carried needs to be the
within a domain/subdomain unchanged. (Motivation: 'Don't re-invent standardized; otherwise interoperability is difficult to achieve.
the wheel'.)
5.1.5 NSIS MUST reuse existing QoS provisioning
Reuse existing functions and protocols for QoS provisioning within a
domain/subdomain unchanged. (Motivation: 'Don't re-invent the
wheel'.)
5.1.6 Independence of signaling and provisioning paradigm 5.1.6 Independence of signaling and provisioning paradigm
The QoS signaling should be independent of the paradigm and The signaling MUST be independent of the paradigm and mechanism of
mechanism of QoS provisioning. The independence allows for using the provisioning. E.g., in the case of signaling for QoS, the
NSIS protocol together with various QoS technologies in various independence of the signaling protocol from the QoS provisioning
scenarios. allows for using the NSIS protocol together with various QoS
technologies in various scenarios.
5.1.7 Application independence
The signaling protocol MUST be independent of the application. The
control information SHOULD be application independent, because we
look into network level signaling.
The requirement relates to the way the signaling interacts with
upper layer functions (users, applications, and QoS administration),
and lower layer QoS technologies.
Opaque application information MAY get transported in the signaling
message, without being handled in the network. Development and
deployment of new applications SHOULD be possible without impacting
the network infrastructure.
5.2 Signaling Flows 5.2 Signaling Flows
This section contains requirements related to the possible signaling This section contains requirements related to the possible signaling
flows that should be supported, e.g. over what parts of the flow flows that should be supported, e.g. over what parts of the flow
path, between what entities (end-systems, routers, middle boxes, path, between what entities (end-systems, routers, middle boxes,
management systems), in which direction. management systems), in which direction.
5.2.1 Free placement of QoS Initiator and QoS Controllers functions 5.2.1 Free placement of NSIS Initiator, Forwarder, Responder
The protocol must work in various scenarios such as host-to-network- The protocol MUST work in various scenarios such as host-to-network-
to-host, edge-to-edge, (e.g., just within one providers domain), to-host, edge-to-edge, (e.g., just within one providers domain),
user-to-network (from end system into the network, ending, e.g., at user-to-network (from end system into the network, ending, e.g., at
the entry to the network and vice versa), network-to-network (e.g., the entry to the network and vice versa), and network-to-network
between providers). (e.g., between providers).
Placing the QoS controller and initiator functions at different Placing the NSIS Forwarder and NSIS Initiator functions at different
locations allows for various scenarios to work with the same or locations allows for various scenarios to work with the same
similar protocols. protocol.
5.2.2 No constraint of the QoS signaling and QoS Controllers to be in 5.2.2 No constraint of the signaling and NSIS Forwarders to be in the
the data path. data path.
There is a set of scenarios, where QoS signaling is not on the data There is a set of scenarios, where signaling is not on the data
path. The QoS Controller being in the data path is one extreme case path. The NSIS Forwarder being in the data path is one extreme case
and useful in certain cases. and useful in many cases. Therefore the case of having NSIS entities
on the data path only MUST be allowed.
There are going to be cases where a centralized entity will take a There are going to be cases where a centralized entity will take a
decision about QoS requests. In this case, there is no need to have decision about service requests. In this case, there is no need to
the data follow the signaling path. have the data follow the signaling path.
There are going to be cases without a centralized entity managing There are going to be cases without a centralized entity managing
resources and the signaling will be used as a tool for resource resources and the signaling will be used as a tool for resource
management. For various reasons (such as efficient use of expensive management. For various reasons (such as efficient use of expensive
bandwidth), one will want to have fine-grained, fast, and very bandwidth), one will want to have fine-grained, fast, and very
dynamic control of the resources in the network. dynamic control of the resources in the network.
There are going to be cases where there will be neither signaling There are going to be cases where there will be neither signaling
nor a centralized entity (overprovisioning). Nothing has to be done nor a centralized entity (over-provisioning). Nothing has to be done
anyway. anyway.
One can capture the requirement with the following, different One can capture the requirement with the following, different
wording: If one views the domain with a QoS technology as a virtual wording: If one views the domain with a QoS technology as a virtual
router then NSIS signaling used between those virtual routers must router then NSIS signaling used between those virtual routers MUST
follow the same path as the data. follow the same path as the data.
Routing the signaling protocol along an independent path is desired Routing the signaling protocol along an independent path is desired
by network operators/designers. Ideally, the capability to route the by network operators/designers. Ideally, the capability to route the
protocol along an independent path would give the network protocol along an independent path would give the network
designer/operator the option to manage bandwidth utilization through designer/operator the option to manage bandwidth utilization through
the topology. the topology.
There are other possibilities as well. An NSIS protocol must accept There are other possibilities as well. An NSIS protocol MUST accept
all of these possibilities. all of these possibilities with a strong focus on the on-path
signaling.
5.2.3 Concealment of topology and technology information 5.2.3 Concealment of topology and technology information
The QoS protocol should allow for hiding the internal structure of a The NSIS protocol SHOULD allow for hiding the internal structure of
QoS domain from end-nodes and from other networks. Hence an a NSIS domain from end-nodes and from other networks. Hence an
adversary should not be able to learn the internal structure of a adversary should not be able to learn the internal structure of a
network with the help of the QoS protocol. network with the help of the signaling protocol.
In various scenarios, topology information should be hidden for In various scenarios, topology information SHOULD be hidden for
various reasons. From a business point of view, some administrations various reasons. From a business point of view, some administrations
don't want to reveal the topology and technology used. don't want to reveal the topology and technology used.
5.2.4 Optional transparency of QoS signaling to network 5.2.4 Transparency of signaling to network
It should be possible that the QoS signaling for some flows traverse It SHOULD be possible that the signaling for some flows traverse
path segments transparently, i.e., without interpretation at QoS path segments transparently, i.e., without interpretation at NSIS
controllers within the network. An example would be a subdomain Forwarders within the network. An example would be a subdomain
within a core network, which only interpreted signaling for within a core network, which only interpreted signaling for
aggregates established at the domain edge, with the flow-related aggregates established at the domain edge, with the flow-related
signaling passing transparently through it. signaling passing transparently through it.
In other words, NSIS needs to work in hierarchical scenarios, where In other words, NSIS SHOULD work in hierarchical scenarios, where
big pipes/trunks are setup using NSIS signaling, but also flows big pipes/trunks are setup using NSIS signaling, but also flows
which run within that big pipe/trunk are setup using NSIS. which run within that big pipe/trunk are setup using NSIS.
5.3 Additional information beyond signaling of QoS information 5.3 Additional information beyond signaling for a service
This section contains the desired signaling (messages) for other
purposes other than that for conveying QoS parameters.
5.3.1 Explicit release of resources 5.3.1 Explicit release of resources
When a QoS reservation is no longer necessary, e.g. because the When a resource reservation is no longer necessary, e.g. because the
application terminates, or because a mobile host experienced a hand- application terminates, or because a mobile host experienced a hand-
off, it must be possible to explicitly release resources. In general off, it MUST be possible to explicitly release resources. In general
explicit release enhances the overall network utilization. explicit release enhances the overall network utilization.
5.3.2 Possibility for automatic release of resources after failure 5.3.2 Possibility for automatic release of resources after failure
When the QoS Initiator goes down, the resources it requested in the When the NSIS Initiator goes down, the resources it requested in the
network should be released, since they will no longer be necessary. network SHOULD be released, since they will no longer be necessary.
After detection of a failure in the network, any QoS After detection of a failure in the network, any NSIS
controller/initiator must be able to release a reservation it is Forwarder/Initiator MUST be able to release a reservation it is
involved in. For example, this may require signaling of the "Release involved in. For example, this may require signaling of the "Release
after Failure" message upstream as well as downstream, or soft state after Failure" message upstream as well as downstream, or soft state
timing out of reservations. timing out of reservations.
The goal is to prevent stale state within the network and adds The goal is to prevent stale state within the network and adds
robustness to the operation of NSIS. So in other words, an NSIS robustness to the operation of NSIS. So in other words, an NSIS
signaling protocol must provide means for an NSIS signaling unit to signaling protocol or mechanisms MUST provide means for an NSIS
discover and remove local stale state. entity to discover and remove local stale state.
Note that this might need to work together with a notification Note that this might need to work together with a notification
mechanism. mechanism.
5.3.3 Prompt notification of QoS violation in case of error/failure to 5.3.3 Notifications sent upstream
QoS Initiator and QoS Controllers
QoS Controllers should be able to notify the QoS Initiator, if there NSIS Forwarders SHOULD be able to notify the NSIS Initiator or any
is an error inside the network. There are two types of network other NSIS Forwarder upstream, if there is a state change inside the
errors: network. There are various types of network changes for instance
among them:
Recoverable errors: the network nodes can locally repair this type Recoverable errors: the network nodes can locally repair this type
error. The network nodes do not have to notify the users of the error. The network nodes do not have to notify the users of the
error immediately. This is a condition when the danger of error immediately. This is a condition when the danger of
degradation (or actual short term degradation) of the provided QoS degradation (or actual short term degradation) of the provided QoS
was overcome by the network (QoS controller) itself. was overcome by the network (NSIS Forwarder) itself.
Unrecoverable errors: the network nodes cannot handle this type of Unrecoverable errors: the network nodes cannot handle this type of
error, and have to notify the users as soon as possible. error, and have to notify the users as soon as possible.
5.3.4 Feedback about success of request for QoS guarantees QoS degradation/severe congestion: In case the service cannot be
A request for QoS must be answered at least with yes or no. However, provided completely but partially only.
it might be useful in case of a negative answer to also get a
description of what might be the QoS one can successfully request
etc. So it might be useful to include an opaque element into the
answer. The element heavily depends on the service requested.
5.3.5 Allow local QoS information exchange between nodes of the same Repair indication: If an error occurred and it has been fixed, this
administrative domain triggers the sending of a notification.
The QoS signaling protocol must be able to exchange local QoS Service upgrade available: If a previously requested better service
information between QoS controllers located within one single becomes available.
domain. Local QoS information might, for example, be IP addresses,
severe congestion notification, notification of successful or
erroneous processing of QoS signaling messages.
In some cases, the NSIS QoS signaling protocol may carry The content of the notification is very service specific, but it is
identification of the QoS controllers located at the boundaries of a must at least carry type information. Additionally, it may carry the
domain. However, the identification of edge should not be visible to location of the state change.
the end host (QoS initiator) and only applies within one QoS
administrative domain.
5.4 Layering The notifications may or may not be in response to a NSIS message.
This means an NSIS entity has to be able to handle notifications at
any time.
This section contains requirements related to the way the signaling Note however, that there are a number of security consideration
being considered interacts with upper layer functions (users, needs to be solved with notification, even more important if the
applications, and QoS administration), and lower layer QoS notification is sent without prior request (asynchronously). The
technologies. problem basically is, that everybody could send notifications to any
NSIS entity and the NSIS entity most likely reacts on the
notification. E.g., if it gets an error notification it might
teardown the reservation, even if everything is ok. So the
notification might depend on security associations between the
sender of the notification and its receiver. If a hop-by-hop
security mechanism is chosen, this implies also that notifications
need to be sent on the reverse path.
5.4.1 The signaling protocol and QoS control information should be 5.3.4 Feedback about success of service request
application independent.
However, opaque application information might get transported in the A request for service MUST be answered at least with yes or no.
signaling message, without being handled in the network. Development However, it MAY be useful in case of a negative answer to also get a
and deployment of new applications should be possible without description of what amount of resources a request is possible. So an
impacting the network infrastructure. Additionally, QoS protocols opaque element MAY be included into the answer. The element heavily
are expected to conform to the Internet principles. depends on the service requested.
5.5 QoS Control Information 5.3.5 Local information exchange
This section contains requirements related to the QoS control The signaling protocol MUST be able to exchange local information
between NSIS Forwarders located within one single administrative
domain. Local information might, for example, be IP addresses,
severe congestion notification, notification of successful or
erroneous processing of signaling messages.
In some cases, the NSIS signaling protocol MAY carry identification
of the NSIS Forwarders located at the boundaries of a domain.
However, the identification of edge should not be visible to the end
host (NSIS Initiator) and only applies within one administrative
domain.
5.4 Control Information
This section contains requirements related to the control
information that needs to be exchanged. information that needs to be exchanged.
5.5.1 Mutability information on parameters 5.4.1 Mutability information on parameters
It should be possible for the initiator to control the mutability of It SHOULD be possible for the NSIS initiator to control the
the QSC information. This prevents from being changed in a non- mutability of the signaled information. This prevents from being
recoverable way. The initiator should be able to control what is changed in a non-recoverable way. The NSIS initiator SHOULD be able
requested end to end, without the request being gradually mutated as to control what is requested end to end, without the request being
it passes through a sequence of domains. This implies that in case gradually mutated as it passes through a sequence of domains. This
of changes made on the parameters, the original requested ones must implies that in case of changes made on the parameters, the original
still be available. requested ones must still be available.
Note that we do not require anything about particular QoS parameters Note that we do not require anything about particular parameters
being changed. being changed.
Additionally, note that a provider or that particular QoS requested, Additionally, note that a provider or that particular services
can still influence the QoS provisioning but in the signaling requested, can still influence the QoS provisioning but in the
message the request should stay the same. signaling message the request should stay the same.
5.5.2 Possibility to add and remove local domain information 5.4.2 Possibility to add and remove local domain information
It should be possible for the QoS control functions to add and It SHOULD be possible for the Resource Management Function to add
remove local scope elements. E.g., at the entrance to a QoS domain and remove local scope elements. E.g., at the entrance to a domain
domain-specific information is added, which is used in this domain domain-specific information is added, which is used in this domain
only, and the information is removed again when a signaling message only, and the information is removed again when a signaling message
leaves the domain. The motivation is in the economy of re-use the leaves the domain. The motivation is in the economy of re-use the
protocol for domain internal signaling of various information protocol for domain internal signaling of various information
pieces. Where additional information is needed for QoS control pieces. Where additional information is needed within a particular
within a particular domain, it should be possible to carry this at domain, it should be possible to carry this at the same time as the
the same time as the 'end to end' information.) end-to-end information.
5.5.3 Independence of reservation identifier 5.4.3 Independence of reservation identifier
A reservation identifier must be used, which is independent of the A reservation identifier, which is independent of the flow
flow identifier, the IP address of the QoS Initiator, and the flow identifier (flow end-points), MUST be used. Various scenarios in the
end-points. Various scenarios in the mobility area require this mobility area require this independence because flows resulting from
independence because flows resulting from handoff might have changed handoff might have changed end-points etc. but still have the same
end-points etc. but still have the same QoS requirement. service requirement. Also several proxy-based signaling methods
might profit from such as independence.
5.5.4 Seamless modification of already reserved QoS 5.4.4 Seamless modification of already reserved resources
In many case, the reservation needs to be updated (up or downgrade). In many case, the reservation needs to be updated (up or downgrade).
This must happen seamlessly without service interruption. At least This SHOULD happen seamlessly without service interruption. At least
the signaling protocol must allow for it, even if some data path the signaling protocol should allow for it, even if some data path
elements might not be capable of doing so. elements might not be capable of doing so.
5.5.5 Grouping of signaling for several microflows 5.4.5 Grouping of signaling for several micro-flows
NSIS may group signaling information for several microflow into one NSIS MAY group signaling information for several micro-flow into one
signaling message. The goal of this is the optimization in terms of signaling message. The goal of this is the optimization in terms of
setup delay, which can happen in parallel. This helps applications setup delay, which can happen in parallel. This helps applications
requesting several flows at once. Also potential refreshes (in case requesting several flows at once. Also potential refreshes (in case
of a soft state solution) might profit of grouping. of a soft state solution) might profit of grouping.
However, the network must not know that a relationship between the However, the network MUST NOT know that a relationship between the
grouped flows exists. Nor is there any transactional semantic grouped flows exists. There MUST NOT be any transactional semantic
allowed. It is only meant for optimization purposes and each associated with the grouping. It is only meant for optimization
reservation is handled separately from each other. purposes and each reservation MUST be handled separately from each
other.
5.6 Performance 5.5 Performance
This section discusses performance requirements and evaluation This section discusses performance requirements and evaluation
criteria and the way in which these could and should be traded off criteria and the way in which these could and should be traded off
against each other in various parts of the solution. against each other in various parts of the solution.
Scalability is a must anyway. However, depending on the scenario the Scalability is a must anyway. However, depending on the scenario the
question to which extends the protocol must be scalable. question to which extends the protocol must be scalable.
5.6.1 Scalability in the number of messages received by a signaling Note that many of the performance issues are heavily dependent on
communication partner (QoS initiator and controller) the scenario assumed and are normally a trade-off between speed,
reliability, complexity, and scalability. The trade-off varies in
different parts of the network. For example, in radio access
networks low bandwidth consumption will overweight the low latency
requirement, while in core networks it may be reverse.
5.6.2 Scalability in number of hand-offs 5.5.1 Scalability
5.6.3 Scalability in the number of interactions for setting up a NSIS MUST be scalable in the number of messages received by a
reservation signaling communication partner (NSIS Initiator, NSIS Forwarder, and
NSIS Responder). The major concern lies in the core of the network,
where large numbers of messages arrive.
5.6.4 Scalability in the number of state per entity (QoS initiators and It MUST be scalable in number of hand-offs in mobile environments.
QoS controllers) This mainly applies in access networks, because the core is
transparent to mobility in most cases.
5.6.5 Scalability in CPU use (end terminal and intermediate nodes) It MUST be scalable in the number of interactions for setting up a
reservation. This applies for end-systems setting up several
reservations. Some servers might be expected to setup a large number
of reservations.
5.6.6 Low latency in setup Scalability in the number of state per entity MUST be achieved for
NSIS Forwarders in the core of the network.
Low latency is only needed in scenarios, where reservations are in a And Scalability in CPU use MUST be achieved on end terminals in case
short time scale (e.g. handover in mobile environments), or where of many reservations at the same time and intermediate nodes mainly
human interaction is immediately concerned (e.g., voice in the core.
communication setup delay)
5.6.7 Allow for low bandwidth consumption for signaling protocol 5.5.2 Low latency in setup
Again only small sets of scenarios call for low bandwidth, mainly NSIS SHOULD allow for low latency setup of reservations. This is
those where wireless links are involved. only needed in scenarios, where reservations are in a short time
scale (e.g. handover in mobile environments), or where human
interaction is immediately concerned (e.g., voice communication
setup delay).
Note that many of the performance issues are heavily dependent on 5.5.3 Allow for low bandwidth consumption for signaling protocol
the scenario assumed and are normally a trade-off between speed,
reliability, complexity, and scalability. The trade-off varies in
different parts of the network. For example, in radio access
networks low bandwidth consumption will overweight the low latency
requirement, while in core networks it may be reverse.
5.6.8 Ability to constrain load on devices NSIS MUST allow for low bandwidth consumption in certain access
networks. Again only small sets of scenarios call for low bandwidth,
mainly those where wireless links are involved.
The NSIS architecture should give the ability to constrain the load 5.5.4 Ability to constrain load on devices
The NSIS architecture SHOULD give the ability to constrain the load
(CPU load, memory space, signaling bandwidth consumption and (CPU load, memory space, signaling bandwidth consumption and
signaling intensity) on devices where it is needed. One of the signaling intensity) on devices where it is needed. One of the
reasons is that the protocol handling should have a minimal impact reasons is that the protocol handling should have a minimal impact
on interior (core) nodes. on interior (core) nodes.
This can be achieved by many different methods. Examples, and this This can be achieved by many different methods. Examples, and this
are only examples, include message aggregation, by ignoring are only examples, include message aggregation, by ignoring
signaling message, header compression, or minimizing functionality. signaling message, header compression, or minimizing functionality.
The framework may choose any method as long as the requirement is The framework may choose any method as long as the requirement is
met. met.
5.6.9 Highest possible network utilization 5.5.5 Highest possible network utilization
There are networking environments that require high network There are networking environments that require high network
utilization for various reasons, and the signaling protocol should utilization for various reasons, and the signaling protocol SHOULD
to its best ability support high resource utilization while to its best ability support high resource utilization while
maintaining appropriate QoS. maintaining appropriate QoS.
In networks where resources are very expensive (as is the case for In networks where resources are very expensive (as is the case for
many wireless networks), efficient network utilization is of many wireless networks), efficient network utilization is of
critical financial importance. On the other hand there are other critical financial importance. On the other hand there are other
parts of the network where high utilization is not required. parts of the network where high utilization is not required.
5.7 Flexibility 5.6 Flexibility
This section lists the various ways the protocol can flexibly be This section lists the various ways the protocol can flexibly be
employed. employed.
5.7.1 Aggregation capability, including the capability to select and 5.6.1 Flow aggregation
change the level of aggregation.
5.7.2 Flexibility in the placement of the QoS initiator NSIS MUST allow for flow aggregation, including the capability to
select and change the level of aggregation.
It might be the sender or the receiver of content. But also network- 5.6.2 Flexibility in the placement of the NSIS Initiator
initiated reservations are required in various scenarios such as
PSTN gateways, some VPNs, mobility.
5.7.3 Flexibility in the initiation of re-negotiation (QoS change NSIS MUST be flexible in placing an NSIS Initiator. The NSIS
requests) Initiator might be the sender or the receiver of content. But also
network-initiated reservations MUST be available in various
scenarios such as PSTN gateways, some VPNs, and mobility.
Again the sender or the receiver of content might initiate a re- 5.6.3 Flexibility in the initiation of re-negotiation
negotiation due to various reasons, such as local resource shortage
(CPU, memory on end-system) or a user changed application
preference/profiles. But also network-initiated re-negotiation is
required in cases, where the network is not able to further
guarantee resources etc.
5.7.4 Uni / bi-directional reservation The sender or the receiver of content SHOULD be able to initiate a
re-negotiation or change the reservation due to various reasons,
such as local resource shortage (CPU, memory on end-system) or a
user changed application preference/profiles. But also network-
initiated re-negotiation SHOULD be supported in cases, where the
network is not able to further guarantee resources etc.
Both unidirectional as well as bi-direction reservations must be 5.6.4 Uni / bi-directional reservation
Both unidirectional as well as bi-direction reservations SHOULD be
possible. With bi-directional reservations we mean here reservations possible. With bi-directional reservations we mean here reservations
having the same end-points. But the path in the two directions does having the same end-points. But the path in the two directions does
not need to be the same. not need to be the same.
The goal of a bi-directional reservation is mainly an optimization The goal of a bi-directional reservation is mainly an optimization
in terms of setup delay. There is no requirements on constrains such in terms of setup delay. There is no requirements on constrains such
as use the same data path etc. as use the same data path etc.
5.8 Security 5.7 Security
This section discusses security-related requirements. For a This section discusses security-related requirements. For a
discussion of security threats see [12]. discussion of security threats see [3]. The NSIS protocol MUST
provide means for security, but it MUST be allowed that nodes
implementing NSIS signaling do not need use the security means.
5.8.1 Authentication of signaling requests 5.7.1 Authentication of signaling requests
A signaling protocol must make provision for enabling various A signaling protocol MUST make provision for enabling various
entities to be authenticated against each other using strong entities to be authenticated against each other using strong
authentication mechanisms. The term strong authentication points to authentication mechanisms. The term strong authentication points to
the fact that weak plain-text password mechanisms must not be used the fact that weak plain-text password mechanisms must not be used
for authentication. for authentication.
5.8.2 Resource Authorization 5.7.2 Resource Authorization
The signaling protocol must provide means to authorize resource The signaling protocol MUST provide means to authorize resource
requests. This requirement demands a hook to interact with a policy requests. This requirement demands a hook to interact with a policy
entity to request authorization data. This allows an authenticated entity to request authorization data. This allows an authenticated
entity to be associated with authorization data and to verify the entity to be associated with authorization data and to verify the
resource request. Authorization prevents reservations by unauthorized resource request. Authorization prevents reservations by unauthorized
entities, reservations violating policies, theft of service and entities, reservations violating policies, and theft of service.
additionally limits denial of service attacks against parts of the Additionally it limits denial of service attacks against parts of the
network or the entire network caused by unrestricted reservations. network or the entire network caused by unrestricted reservations.
Additionally it might be helpful to provide some means to inform Additionally it might be helpful to provide some means to inform
other protocols of participating nodes within the same administrative other protocols of participating nodes within the same administrative
domain about a previous successful authorization event. domain about a previous successful authorization event.
5.8.3 Integrity protection 5.7.3 Integrity protection
The signaling protocol must provide means to protect the message The signaling protocol MUST provide means to protect the message
payloads against modifications. Integrity protection prevents an payloads against modifications. Integrity protection prevents an
adversary from modifying with parts of the signaling message and from adversary from modifying parts of the signaling message and from
mounting denial of service or theft of service type of attacks mounting denial of service or theft of service type of attacks
against network elements participating in the protocol execution. against network elements participating in the protocol execution.
5.8.4 Replay protection 5.7.4 Replay protection
To prevent replay of previous signaling messages the signaling To prevent replay of previous signaling messages the signaling
protocol must provide means to detect old i.e. already transmitted protocol MUST provide means to detect old i.e. already transmitted
signaling messages. A solution must cover issues of synchronization signaling messages. A solution must cover issues of synchronization
problems in the case of a restart or a crash of a participating problems in the case of a restart or a crash of a participating
network element. The use of replay mechanism apart from sequence network element. The use of replay mechanism apart from sequence
numbers should be investigated. numbers should be investigated.
5.8.5 Hop-by-hop security 5.7.5 Hop-by-hop security
Hop-by-Hop security is a well known and proven concept in Quality-of-
Service and other signaling protocols that allows intermediate nodes
that actively participate in the protocol to modify the messages as
it is required by processing rule. Note that this requirement does
not exclude end-to-end or network-to-network security of a signaling
message. End-to-end security between the initiator and the responder
may be used to provide protection of non-mutable data fields.
Network-to-network security refers to the protection of messages over
various hops but not in an end-to-end manner i.e. protected over a
particular network.
5.8.6 Identity confidentiality and location privacy Hop-by-Hop security SHOULD be supported. It is a well known and
proven concept in Quality-of-Service and other signaling protocols
that allows intermediate nodes that actively participate in the
protocol to modify the messages as it is required by processing rule.
Note that this requirement does not exclude end-to-end or network-to-
network security of a signaling message. End-to-end security between
the initiator and the responder may be used to provide protection of
non-mutable data fields. Network-to-network security refers to the
protection of messages over various hops but not in an end-to-end
manner i.e. protected over a particular network.
Identity confidentiality enables privacy and avoids profiling of 5.7.6 Identity confidentiality and location privacy
entities by adversary eavesdropping the signaling traffic along the
path. The identity used in the process of authentication may also be
hidden to a limited extent from a network to which the initiator is
attached. It is however required that the identity provides enough
information for the nodes in the access network to collect accounting
data.
Location privacy is an issue for the initiator who triggers the Identity confidentiality SHOULD be supported. It enables privacy and
signaling protocol. In some scenarios the initiator may not be avoids profiling of entities by adversary eavesdropping the signaling
willing to reveal location information to the responder as part the traffic along the path. The identity used in the process of
signaling procedure. authentication may also be hidden to a limited extent from a network
The signaling protocol should provide means to protect the identity to which the initiator is attached. However the identity MUST provide
confidentiality and as far as possible location privacy. enough information for the nodes in the access network to collect
accounting data.
Location privacy MAY be supported. It is an issue for the initiator
who triggers the signaling protocol. In some scenarios the initiator
may not be willing to reveal location information to the responder as
part the signaling procedure.
5.8.7 Denial-of-service attacks 5.7.7 Denial-of-service attacks
A signaling protocol SHOULD provide prevention of DoS attacks.
To effectively prevent denial-of-service attacks it is necessary that To effectively prevent denial-of-service attacks it is necessary that
the used security and protocol mechanisms should not require the the used security and protocol mechanisms MUST have low computation
execution of heavy computation to verify a resource request prior complexity to verify a resource request prior authenticating the
authenticating the requesting entity. Additionally the signaling requesting entity. Additionally the signaling protocol and the used
protocol and the used security mechanisms should not require large security mechanisms SHOULD NOT require large resource consumption
resource consumption (for example main memory or other additional (for example main memory or other additional message exchanges)
message exchanges) before a successful authentication was done. A before a successful authentication was done.
signaling protocol should provide prevention of DoS attacks.
5.8.8 Confidentiality of signaling messages 5.7.8 Confidentiality of signaling messages
Based on the signaling information exchanged between nodes Based on the signaling information exchanged between nodes
participating in the signaling protocol an adversary may learn both participating in the signaling protocol an adversary may learn both
the identities and the content of the signaling messages. To prevent the identities and the content of the signaling messages. To prevent
this from happening, confidentiality of the signaling message in a this from happening, confidentiality of the signaling message in a
hop-by-hop manner may be provided. Note that the protection can be hop-by-hop manner MAY be provided. Note that the protection can be
provided on a hop-by-hop basis for most message payloads since it is provided on a hop-by-hop basis for most message payloads since it is
required that entities which actively participating in the signaling required that entities which actively participating in the signaling
protocol must be able to read and eventually modify the content of protocol must be able to read and eventually modify the content of
the signaling messages. the signaling messages.
5.8.9 Ownership of a reservation 5.7.9 Ownership of a reservation
When existing reservations have to be modified then there is a need When existing reservations have to be modified then there is a need
to use a reservation identifier to uniquely identify the established to use a reservation identifier to uniquely identify the established
state. A signaling protocol must provide the appropriate security state. A signaling protocol MUST provide the appropriate security
protection to prevent other entities to modify state without having protection to prevent other entities to modify state without having
the proper ownership. the proper ownership.
5.8.10 Hooks with Authentication and Key Agreement protocols 5.7.10 Hooks with Authentication and Key Agreement protocols
This requirement covers two subsequent steps before a signaling This requirement covers two subsequent steps before a signaling
protocol is executed and the required hooks. First there is a need to protocol is executed and the required hooks. First there is a need to
agree on a specific authentication protocol. Later this protocol is agree on a specific authentication protocol. Later this protocol is
executed and provides authentication and establishes the desired executed and provides authentication and establishes the desired
security associations. Using these security associations it is then security associations. Using these security associations it is then
possible to exchange secured signaling messages. possible to exchange secured signaling messages.
The signaling protocol should provide hooks to interact with The signaling protocol implementation SHOULD provide hooks to
protocols that allow the negotiation of authentication and key interact with protocols that allow the negotiation of authentication
agreement protocols. Although the negotiation of an authentication and key agreement protocols. Although the negotiation of an
and key management protocol within the signaling protocol may be authentication and key management protocol within the signaling
outside the scope it is still required to trigger this exchange in protocol may be outside the scope it is still required to trigger
case that no such security association is available. this exchange in case that no such security association is available.
This requirement originates from the fact that more than one key This requirement originates from the fact that more than one key
management protocol may be used to provide a security association for management protocol may be used to provide a security association for
the signaling protocol. Hence the communicating entities must be the signaling protocol. Hence the communicating entities must be
capable to agree on a specific authentication. The selected capable to agree on a specific authentication. The selected
authentication and key agreement protocol must however be able to authentication and key agreement protocol must however be able to
create a security association that can be used within the signaling create a security association that can be used within the signaling
protocol. protocol.
Key management protocols typically require a larger number of Key management protocols typically require a larger number of
messages to be transmitted to allow a session key and the messages to be transmitted to allow a session key and the
corresponding security association to be derived. To avoid the corresponding security association to be derived. To avoid the
complex issue of embedding individual authentication and key complex issue of embedding individual authentication and key
agreement protocols into a specific signaling protocol it is required agreement protocols into a specific signaling protocol it is required
that most of these protocols are executed independently (prior to the that most of these protocols are executed independently (prior to the
signaling protocol) and although the key management protocol may be signaling protocol) and although the key management protocol may be
independent there must be a way for the signaling protocol to access independent there must be a way for the signaling protocol to access
and use available (i.e. already established) security associations to and use available (i.e. already established) security associations to
avoid executing a separate key management protocol (or instance of avoid executing a separate key management protocol (or instance of
the same protocol) for protocols that closely operate together. If no the same protocol) for protocols that closely operate together. If no
such security association exists then there should be means for the such security association exists then there SHOULD be means for the
signaling protocol to dynamically trigger such a protocol. signaling protocol to dynamically trigger such a protocol.
5.9 Mobility 5.8 Mobility
5.9.1 Allow efficient QoS re-establishment after handover 5.8.1 Allow efficient QoS re-establishment after handover
Handover is an essential function in wireless networks. After Handover is an essential function in wireless networks. After
handover, QoS may need to be completely or partially re-established handover, the reservation may need to be completely or partially re-
due to route changes. The re-establishment may be requested by the established due to route changes. The re-establishment may be
mobile node itself or triggered by the access point that the mobile requested by the mobile node itself or triggered by the access point
node is attached to. In the first case, the QoS signaling should that the mobile node is attached to. In the first case, the
allow efficient QoS re-establishment after handover. Re- signaling MUST allow efficient re-establishment after handover. Re-
establishment of QoS after handover should be as quick as possible establishment after handover MUST be as quick as possible so that
so that the mobile node does not experience service interruption or the mobile node does not experience service interruption or service
QoS degradation. The re-establishment should be localized, and not degradation. The re-establishment SHOULD be localized, and not
require end-to-end signaling, if possible. require end-to-end signaling.
5.10 Interworking with other protocols and techniques 5.9 Interworking with other protocols and techniques
Hooks must be provided to enable efficient interworking between Hooks SHOULD be provided to enable efficient interworking between
various protocols and techniques including: various protocols and techniques including:
5.10.1 Interworking with IP tunneling 5.9.1 MUST interwork with IP tunneling
IP tunneling for various applications must be supported. More IP tunneling for various applications MUST be supported. More
specifically tunneling for IPSec tunnels are of importance. This specifically tunneling for IPSec tunnels are of importance as
mainly impacts the identification of flows. Using IPsec parts of discussed in Section 4.2. This mainly impacts the identification of
information for flow identification (e.g. transport protocol flows. Using IPSec parts of information used for flow identification
information), this information is not accessible for classification (e.g. transport protocol information and ports) may not be accessible
etc. due to encryption.
5.10.2 The solution should not constrain either to IPv4 or IPv6 5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6
5.10.3 Independence from charging model
Signaling must not be constrained by charging models or the charging 5.9.3 MUST be independent from charging model
Signaling MUST NOT be constrained by charging models or the charging
infrastructure used. infrastructure used.
5.10.4 Hooks for AAA protocols 5.9.4 SHOULD provide hooks for AAA protocols
The security mechanism should be developed with respect to be able The security mechanism SHOULD be developed with respect to be able
to collect usage records from one or more network elements. to collect usage records from one or more network elements.
5.10.5 Interworking with seamless handoff protocols 5.9.5 SHOULD interwork with seamless handoff protocols
An NSIS protocol should interwork with seamless handoff protocols An NSIS protocol SHOULD interwork with seamless handoff protocols
such as context transfer and candidate access router (CAR) such as context transfer and candidate access router (CAR)
discovery. The goal to achieve is that signaling for QoS works fast discovery. The goal to achieve is that signaling works fast enough
enough in case of a handoff, where that protocols might help in one in case of a handoff, where that protocols might help in one way or
way or the other. the other.
5.10.6 Interworking with non-traditional routing 5.9.6 MAY interwork with non-traditional routing
NSIS assumes traditional routing, but networks, which do non- NSIS assumes traditional routing, but networks, which do non-
traditional L3 routing, should not break it. traditional L3 routing, should not break it.
5.11 Operational 5.10 Operational
5.11.1 Ability to assign transport quality to signaling messages. 5.10.1 Ability to assign transport quality to signaling messages.
The NSIS architecture should allow the network operator to assign The NSIS architecture SHOULD allow the network operator to assign
the NSIS protocol messages a certain transport quality. As signaling the NSIS protocol messages a certain transport quality. As signaling
opens up for possible denial-of-service attacks, this requirement opens up for possible denial-of-service attacks, this requirement
gives the network operator a mean, but also the obligation, to gives the network operator a mean, but also the obligation, to
trade-off between signaling latency and the impact (from the trade-off between signaling latency and the impact (from the
signaling messages) on devices within his/her network. From protocol signaling messages) on devices within his/her network. From protocol
design this requirement states that the protocol messages should be design this requirement states that the protocol messages SHOULD be
detectable, at least where the control and assignment of the detectable, at least where the control and assignment of the
messages priority is done. messages priority is done.
Furthermore, the protocol design must take into account reliability Furthermore, the protocol design must take into account reliability
concerns. concerns. Communication reliability is seen as part of the quality
assigned to signaling messages. So procedures MUST be defined how an
Communication reliability is seen as part of the quality assigned to NSIS signaling system behaves if some kind of request it sent stays
signaling messages. So procedures must define how an NSIS signaling without answer. The basic transport protocol to be used between
systems behaves if some kind of request it sent stays without adjacent NSIS units MAY ensure message integrity and reliable
answer. The basic transport protocol to be used between adjacent transport.
NSIS units must ensure message integrity and reliable transport.
5.11.2 Graceful fail over 5.10.2 Graceful fail over
Any unit participating in NSIS signaling must not cause further Any unit participating in NSIS signaling MUST NOT cause further
damage to other systems involved in NSIS signaling when it has to go damage to other systems involved in NSIS signaling when it has to go
out of service. out of service.
6 The MUSTs, SHOULDs, and MAYs 5.10.3 Graceful handling of NSIS entity problems
In order to prioritize the various requirements from Section 5, we
define different 'parts of the network'. In the different parts of
the network a particular requirement might have a different
priority.
The parts of the networks we differentiate are the host-to-first
router, the access network, and the core network. The host to first
router part includes all the layer 2 technologies to access to the
Internet. In many cases, there is an application and/or user running
on the host initiating QoS signaling. The access network can be
characterized by low capacity links, medium speed IP processing
capabilities, and it might consist of a complete layer 2 networks as
well. The core network characteristics include high-speed forwarding
capacities and interdomain QoS issues. All of them are not strictly
defined and should not be regarded as that, but should give a
feeling about where in the network we have different requirements
concerning QoS signaling.
Note that the requirement titles are listed for better reading.
5.1 Architecture and Design Goals
5.1.1 Applicability for different QoS technologies.
5.1.2 Resource availability information on request
5.1.3 Modularity
5.1.4 Decoupling of protocol and information it is carrying
5.1.5 Reuse of existing QoS provisioning
5.1.6 Independence of signaling and provisioning paradigm
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.1.1 | | | |
----------------------+-------------+-------------+------------+
5.1.2 | | | |
----------------------+-------------+-------------+------------+
5.1.3 | | | |
----------------------+-------------+-------------+------------+
5.1.4 | | | |
----------------------+-------------+-------------+------------+
5.1.5 | | | |
----------------------+-------------+-------------+------------+
5.1.6 | | | |
----------------------+-------------+-------------+------------+
5.2 Signaling Flows
5.2.1 Free placement of QoS Initiator and QoS Controllers functions
5.2.2 No constraint of the QoS signaling and QoS Controllers to be
in the data path.
5.2.3 Concealment of topology and technology information
5.2.4 Optional transparency of QoS signaling to network
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.2.1 | | | |
----------------------+-------------+-------------+------------+
5.2.2 | | | |
----------------------+-------------+-------------+------------+
5.2.3 | | | |
----------------------+-------------+-------------+------------+
5.2.4 | | | |
----------------------+-------------+-------------+------------+
5.3 Additional information beyond signaling of QoS information
5.3.1 Explicit release of resources
5.3.2 Possibility for automatic release of resources after failure
5.3.3 Possibility for automatic re-setup of resources after recovery
5.3.4 Prompt notification of QoS violation in case of error /
failure to QoS Initiator and QoS Controllers
5.3.5 Feedback about success of request for QoS guarantees
5.3.6 Allow local QoS information exchange between nodes of the same
administrative domain
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.3.1 | | | |
----------------------+-------------+-------------+------------+
5.3.2 | | | |
----------------------+-------------+-------------+------------+
5.3.3 | | | |
----------------------+-------------+-------------+------------+
5.3.4 | | | |
----------------------+-------------+-------------+------------+
5.3.5 | | | |
----------------------+-------------+-------------+------------+
5.3.6 | | | |
----------------------+-------------+-------------+------------+
5.4 Layering
5.4.1 The signaling protocol and QoS control information should be
application independent.
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.4.1 | | | |
----------------------+-------------+-------------+------------+
5.5 QoS Control Information
5.5.1 Mutability information on parameters
5.5.2 Possibility to add and remove local domain information
5.5.3 Independence of reservation identifier
5.5.4 Seamless modification of already reserved QoS
5.5.5 Signaling must support quantitative, qualitative, and relative
QoS specifications
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.5.1 | | | |
----------------------+-------------+-------------+------------+
5.5.2 | | | |
----------------------+-------------+-------------+------------+
5.5.3 | | | |
----------------------+-------------+-------------+------------+
5.5.4 | | | |
----------------------+-------------+-------------+------------+
5.5.5 | | | |
----------------------+-------------+-------------+------------+
5.6 Performance
5.6.1 Scalability in the number of messages received by a signaling
communication partner (QoS initiator and controller)
5.6.2 Scalability in number of hand-offs
5.6.3 Scalability in the number of interactions for setting up a
reservation
5.6.4 Scalability in the number of state per entity (QoS initiators
and QoS controllers)
5.6.5 Scalability in CPU use (end terminal and intermediate nodes)
5.6.6 Low latency in setup
5.6.7 Allow for low bandwidth consumption for signaling protocol
5.6.8 Ability to constrain load on devices
5.6.9 Highest possible network utilization
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.6.1 | | | |
----------------------+-------------+-------------+------------+
5.6.2 | | | |
----------------------+-------------+-------------+------------+
5.6.3 | | | |
----------------------+-------------+-------------+------------+
5.6.4 | | | |
----------------------+-------------+-------------+------------+
5.6.5 | | | |
----------------------+-------------+-------------+------------+
5.6.6 | | | |
----------------------+-------------+-------------+------------+
5.6.7 | | | |
----------------------+-------------+-------------+------------+
5.6.8 | | | |
----------------------+-------------+-------------+------------+
5.6.9 | | | |
----------------------+-------------+-------------+------------+
5.7 Flexibility
5.7.1 Aggregation capability, including the capability to select and
change the level of aggregation.
5.7.2 Flexibility in the placement of the QoS initiator
5.7.3 Flexibility in the initiation of re-negotiation (QoS change
requests)
5.7.4 Uni / bi-directional reservation
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.7.1 | | | |
----------------------+-------------+-------------+------------+
5.7.2 | | | |
----------------------+-------------+-------------+------------+
5.7.3 | | | |
----------------------+-------------+-------------+------------+
5.7.4 | | | |
----------------------+-------------+-------------+------------+
5.8 Security
5.8.1 The QoS protocol must provide strong authentication
5.8.2 The QoS protocol must provide means to authorize resource
requests
5.8.3 The QoS signaling messages must provide integrity protection.
5.8.4 The QoS signaling messages must be replay protected.
5.8.5 The QoS signaling protocol must allow for hop-by-hop security.
5.8.6 The QoS protocol should allow identity confidentiality and
location privacy.
5.8.7 The QoS protocol should prevent denial-of-service attacks
against signaling entities.
5.8.8 The QoS protocol should support confidentiality of signaling
messages.
5.8.9 The QoS protocol should provide hooks to interact with
protocols that allow the negotiation of authentication and key
management protocols.
5.8.10 The QoS protocol should provide means to interact with key
management protocols.
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.8.1 | | | |
----------------------+-------------+-------------+------------+
5.8.2 | | | |
----------------------+-------------+-------------+------------+
5.8.3 | | | |
----------------------+-------------+-------------+------------+
5.8.4 | | | |
----------------------+-------------+-------------+------------+
5.8.5 | | | |
----------------------+-------------+-------------+------------+
5.8.6 | | | |
----------------------+-------------+-------------+------------+
5.8.7 | | | |
----------------------+-------------+-------------+------------+
5.8.8 | | | |
----------------------+-------------+-------------+------------+
5.8.9 | | | |
----------------------+-------------+-------------+------------+
5.8.10 | | | |
----------------------+-------------+-------------+------------+
5.9 Mobility
5.9.1 Allow efficient QoS re-establishment after handover
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.9.1 | | | |
----------------------+-------------+-------------+------------+
5.10 Interworking with other protocols and techniques
5.10.1 Interworking with IP tunneling
5.10.2 The solution should not constrain either to IPv4 or IPv6
5.10.3 Independence from charging model
5.10.4 The QoS protocol should provide hooks for AAA protocols
5.10.5 Interworking with seamless handoff protocols
5.10.6 Interworking with non-traditional routing
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.10.1 | | | |
----------------------+-------------+-------------+------------+
5.10.2 | | | |
----------------------+-------------+-------------+------------+
5.10.3 | | | |
----------------------+-------------+-------------+------------+
5.10.4 | | | |
----------------------+-------------+-------------+------------+
5.10.5 | | | |
----------------------+-------------+-------------+------------+
5.10.6 | | | |
----------------------+-------------+-------------+------------+
5.11 Operational
5.11.1 Ability to assign transport quality to signaling messages
----------------------+-------------+-------------+------------+
| host-to-net | access | core |
----------------------+-------------+-------------+------------+
5.11.1 | | | |
----------------------+-------------+-------------+------------+
7 References
[1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem
Statement", RFC 3132, June 2001.
[2] Chaskar, H., "Requirements of a QoS Solution for Mobile IP",
draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress,
August 2001
[3] Manner. J., et al, "Mobility Related Terminology", draft-manner-
seamoby-terms-02.txt, Work In Progress, July 2001.
[4] 3GPP, "General Packet Radio Service (GPRS); Service Description
Stage 2 v 7.7.0", TS 03.60, June 2001
[5] 3GPP2, "Network Reference Model for cdma2000 Spread Spectrum NSIS peers SHOULD be able to detect the malfunctioning peer. It may
System, revision B", S.R0005-B, May 2001 notify the NSIS Initiator or another NSIS entity involved in the
signaling process. The NSIS peer may handle the problem itself e.g.
switching to a backup NSIS entity. In the latter case note that
synchronization of state between the primary and the backup entity
is needed.
[6] Bradner, S., Mankin, A., "Report of the Next Steps in Signaling 6 Security Considerations
BOF", draft-bradner-nsis-bof-00.txt, Work in Progress, July 2001
[7] Partain, D., et al, "Resource Reservation Issues in Cellular Section 5.8 of this draft provides security related requirements of
Radio Access Networks", draft-westberg-rmd-cellular-issues-00.txt, a signaling protocol. Another document describes security threads
Work in Progress, June 2001. for NSIS [3].
[8] YESSIR - YEt another Sender Session Internet Reservations, 7 Reference
http://www.cs.columbia.edupingpan/projects/yessir.html
[9] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., [1] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", IETF RFC 2205, 1997. Specification", RFC 2205, September 1997.
[10] Westberg, L., Jacobsson, M., Partain, D., Karagiannis, G.,
Oosthoek, S., Rexhepi, V., Szabo, R., Wallentin, P., "Resource
Management in Diffserv Framework", Internet draft, work in progress,
draft-westberg-rmd-framework-xx.txt, 2002.
[11] Kempf, J., McCann, P., Roberts, P., "IP Mobility and the CDMA [2] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow,
Radio Access Network", IETF Draft, draft-kempf-cdma-appl-02.txt, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December
Work in progress, September 2001. 2001.
[12] Tschofenig, H., "NSIS Threats", <draft-tschofenig-nsis-threats- [3] Tschofenig, H., "NSIS Threats", <draft-tschofenig-nsis-threats-
00.txt>, May 2002. 00.txt>, May 2002.
8 Acknowledgments 8 Acknowledgments
Quite a number of people have been involved in the discussion of the Quite a number of people have been involved in the discussion of the
draft, adding some ideas, requirements, etc. We list them without a draft, adding some ideas, requirements, etc. We list them without a
guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul
(NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas
Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC),
Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical
skipping to change at page 32, line 7 skipping to change at page 25, line 53
Germany Germany
Email: Hannes.Tschofenig@mchp.siemens.de Email: Hannes.Tschofenig@mchp.siemens.de
10 Appendix: Scenarios/Use cases 10 Appendix: Scenarios/Use cases
In the following we describe scenarios, which are important to In the following we describe scenarios, which are important to
cover, and which allow us to discuss various requirements. Some cover, and which allow us to discuss various requirements. Some
regard this as use cases to be covered defining the use of a QoS regard this as use cases to be covered defining the use of a QoS
signaling protocol. signaling protocol.
10.1 Scenario: Terminal Mobility 10.1 Terminal Mobility
The scenario we are looking at is the case where a mobile terminal The scenario we are looking at is the case where a mobile terminal
(MT) changes from one access point to another access point. The (MT) changes from one access point to another access point. The
access points are located in separate QoS domains. We assume Mobile access points are located in separate QoS domains. We assume Mobile
IP to handle mobility on the network layer in this scenario and IP to handle mobility on the network layer in this scenario and
consider the various extensions (i.e., IETF proposals) to Mobile IP, consider the various extensions (i.e., IETF proposals) to Mobile IP,
in order to provide 'fast handover' for roaming Mobile Terminals. in order to provide 'fast handover' for roaming Mobile Terminals.
The goal to be achieved lies in providing, keeping, and adapting the The goal to be achieved lies in providing, keeping, and adapting the
requested QoS for the ongoing IP sessions in case of handover. requested QoS for the ongoing IP sessions in case of handover.
Furthermore, the negotiation of QoS parameters with the new domain Furthermore, the negotiation of QoS parameters with the new domain
skipping to change at page 33, line 9 skipping to change at page 27, line 4
- This scenario shows that local decisions might not be enough. The - This scenario shows that local decisions might not be enough. The
rest of the path to the other end of the communication needs to be rest of the path to the other end of the communication needs to be
considered as well. Hand-off decisions in a QoS domain, does not considered as well. Hand-off decisions in a QoS domain, does not
only depend on the local resource availability, e.g., the wireless only depend on the local resource availability, e.g., the wireless
part, but involves the rest of the path as well. Additionally, part, but involves the rest of the path as well. Additionally,
decomposition of an end-to-end reservation might be needed, in order decomposition of an end-to-end reservation might be needed, in order
to change only parts of it. to change only parts of it.
2) Trigger sources 2) Trigger sources
- Mobile terminal: If the end-system QoS management identifies - Mobile terminal: If the end-system QoS management identifies
another (better-suited) access point, it will request the handoff another (better-suited) access point, it will request the handoff
from the terminal itself. This will be especially likely in the case from the terminal itself. This will be especially likely in the case
that two different provider networks are involved. Another important that two different provider networks are involved. Another important
example is when the current access point bearer disappears (e.g. example is when the current access point bearer disappears (e.g.
removing the Ethernet cable). In this case, the QoS initiator is removing the Ethernet cable). In this case, the NSIS Initiator is
basically located on the mobile terminal. basically located on the mobile terminal.
- Network (access network manager): Sometimes, the handoff trigger - Network (access network manager): Sometimes, the handoff trigger
will be issued from the network management to optimize the overall will be issued from the network management to optimize the overall
load situation. Most likely this will result in changing the base- load situation. Most likely this will result in changing the base-
station of a single providers network. Most likely the QoS initiator station of a single providers network. Most likely the NSIS
is located on a system within the network. Initiator is located on a system within the network.
3) Integration with other protocols 3) Integration with other protocols
- Interworking with other protocol must be considered in one or the - Interworking with other protocol must be considered in one or the
other form. E.g., it might be worth combining QoS signaling between other form. E.g., it might be worth combining QoS signaling between
different QoS domains with mobility signaling at hand-over. different QoS domains with mobility signaling at hand-over.
4) Handover rates 4) Handover rates
In mobile networks, the admission control process has to cope with In mobile networks, the admission control process has to cope with
far more admission requests than call setups alone would generate. far more admission requests than call setups alone would generate.
For example, in the GSM (Global System for Mobile communications) For example, in the GSM (Global System for Mobile communications)
case, mobility usually generates an average of one to two handovers case, mobility usually generates an average of one to two handovers
per call. For third generation networks (such as UMTS), where it is per call. For third generation networks (such as UMTS), where it is
necessary to keep radio links to several cells simultaneously necessary to keep radio links to several cells simultaneously
(macro-diversity), the handover rate is significantly higher (see (macro-diversity), the handover rate is significantly higher.
for example [11])
5) Fast reservations 5) Fast reservations
Handover can also cause packet losses. This happens when the Handover can also cause packet losses. This happens when the
processing of an admission request causes a delayed handover to the processing of an admission request causes a delayed handover to the
new base station. In this situation, some packets might be new base station. In this situation, some packets might be
discarded, and the overall speech quality might be degraded discarded, and the overall speech quality might be degraded
significantly. Moreover, a delay in handover may cause degradation significantly. Moreover, a delay in handover may cause degradation
for other users. In the worst-case scenario, a delay in handover may 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 cause the connection to be dropped if the handover occurred due to
skipping to change at page 34, line 7 skipping to change at page 27, line 54
in connection with handover be carried out very quickly. in connection with handover be carried out very quickly.
6) Call blocking in case of overload 6) Call blocking in case of overload
Furthermore, when the network is overloaded, it is preferable to Furthermore, when the network is overloaded, it is preferable to
keep reservations for previously established flows while blocking keep reservations for previously established flows while blocking
new requests. Therefore, the resource reservation requests in new requests. Therefore, the resource reservation requests in
connection with handover should be given higher priority than new connection with handover should be given higher priority than new
requests for resource reservation. requests for resource reservation.
10.2 Scenario: Cellular Networks 10.2 Cellular Networks
In this scenario, the user is using the packet service of a 3rd In this scenario, the user is using the packet service of a 3rd
generation cellular system, e.g. UMTS. The region between the End generation cellular system, e.g. UMTS. The region between the End
Host and the edge node connecting the cellular network to another Host and the edge node connecting the cellular network to another
QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is
considered to be a single QoS domain [4][5]. considered to be a single QoS domain.
The issues in such an environment regarding QoS include: The issues in such an environment regarding QoS include:
1) Cellular systems provide their own QoS technology with 1) Cellular systems provide their own QoS technology with
specialized parameters to co-ordinate the QoS provided by both the specialized parameters to co-ordinate the QoS provided by both the
radio access and wired access network. For example, in a UMTS radio access and wired access network. For example, in a UMTS
network, one aspect of GPRS is that it can be considered as a QoS network, one aspect of GPRS is that it can be considered as a QoS
technology; provisioning of QoS within GPRS is described mainly in technology; provisioning of QoS within GPRS is described mainly in
terms of calling UMTS bearer classes. This QoS technology needs to terms of calling UMTS bearer classes. This QoS technology needs to
be invoked with suitable parameters when higher layers trigger a be invoked with suitable parameters when higher layers trigger a
request for QoS, and this therefore involves mapping the requested request for QoS, and this therefore involves mapping the requested
IP QoS onto these UMTS bearer classes. This request for resources IP QoS onto these UMTS bearer classes. This request for resources
might be triggered by IP signaling messages that pass across the might be triggered by IP signaling messages that pass across the
cellular system, and possibly other QoS domains, to negotiate for cellular system, and possibly other QoS domains, to negotiate for
network resources. Typically, cellular system specific messages network resources. Typically, cellular system specific messages
invoke the underlying cellular system QoS technology in parallel invoke the underlying cellular system QoS technology in parallel
with the IP QoS negotiation, to allocate the resources within the with the IP QoS negotiation, to allocate the resources within the
cellular system. cellular system.
2) The placement of QoS initiators and QoS controllers (terminology 2) The placement of NSIS Initiators and NSIS Forwarders (terminology
in the framework given here). The QoS initiator could be located at in the framework given here). The NSIS Initiator could be located at
the End Host (triggered by applications), the GGSN/PDSN, or at a the End Host (triggered by applications), the GGSN/PDSN, or at a
node not directly on the data path, such as a bandwidth broker. In node not directly on the data path, such as a bandwidth broker. In
the second case, the GGSN/PDSN could either be acting as a proxy on the second case, the GGSN/PDSN could either be acting as a proxy on
behalf of an End Host with little capabilities, and/or managing behalf of an End Host with little capabilities, and/or managing
aggregate resources within its QoS domain (the UMTS core network). aggregate resources within its QoS domain (the UMTS core network).
The IP signaling messages are interpreted by the QoS controllers, The IP signaling messages are interpreted by the NSIS Forwarders,
which may be located at the GGSN/PDSN, and in any QoS sub-domains which may be located at the GGSN/PDSN, and in any QoS sub-domains
within the cellular system. within the cellular system.
3) Initiation of IP-level QoS negotiation. IP-level QoS re- 3) Initiation of IP-level QoS negotiation. IP-level QoS re-
negotiation may be initiated by either the End Host, or by the negotiation may be initiated by either the End Host, or by the
network, based on current network loads, which might change network, based on current network loads, which might change
depending on the location of the end host. depending on the location of the end host.
4) The networks are designed and mainly used for speech 4) The networks are designed and mainly used for speech
communication (at least so far). communication (at least so far).
Note that in comparison to the former scenario, the emphasis is much Note that in comparison to the former scenario, the emphasis is much
less on the mobility aspects, because mobility is mainly handled on less on the mobility aspects, because mobility is mainly handled on
the lower layer. the lower layer.
10.3 Scenario: UMTS access 10.3 UMTS access
The UMTS access scenario is shown in figure 3. The Proxy-Call State The UMTS access scenario is shown in figure 3. The Proxy-Call State
Control Function/Policy Control Function (P-CSCF/PCF) is the Control Function/Policy Control Function (P-CSCF/PCF) is the
outbound SIP proxy of the visited domain, i.e. the domain where 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 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 (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 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 P-CSCF/PCF communicates with the GGSN via the COPS protocol. The
User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal
Equipment (TE), e.g. a laptop. Equipment (TE), e.g. a laptop.
+--------+ +--------+
+----------| P-CSCF |-------> SIP signaling +----------| P-CSCF |-------> SIP signaling
/ +--------+ / +--------+
/ SIP : / SIP :
: +--------+ NSIS +----------------+ : +--------+ NSIS +----------------+
: | PCF |---------| QoS Controller | : | PCF |---------| NSIS Forwarder |
: +--------+ +----------------+ : +--------+ +----------------+
: : : :
: : COPS : : COPS
: : : :
+----+ +--------+ +----+ +----+ +--------+ +----+
| UE |----------| GGSN |------| ER | | UE |----------| GGSN |------| ER |
+----+ +--------+ +----+ +----+ +--------+ +----+
Figure 1: UMTS access scenario Figure 1: UMTS access scenario
In this scenario the GGSN has the role of Access Gate. According to In this scenario the GGSN has the role of Access Gate. According to
3GPP standardization, the PCF is responsible for the policy-based 3GPP standardization, the PCF is responsible for the policy-based
control of the end-user service in the UMTS access network (i.e. 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 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 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 may evolve to an open standardized interface. In any case the PCF
has all required QoS information for per-flow admission control in 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). 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 Thus the PCF would be the appropriate entity to host the
functionality of QI, initiating the "NSIS" QoS signaling towards the functionality of NSIS Initiator, initiating the "NSIS" QoS signaling
core IP network. The PCF/P-CSCF has to do the mapping from codec towards the core IP network. The PCF/P-CSCF has to do the mapping
type (derived from SIP/SDP signaling) to IP traffic descriptor. SDP from codec type (derived from SIP/SDP signaling) to IP traffic
extensions to explicitly signal QoS information [7] are useful to descriptor. SDP extensions to explicitly signal QoS information are
avoid the need to store codec information in the PCF and to allow useful to avoid the need to store codec information in the PCF and
for more flexibility and accurate description of the QoS traffic to allow for more flexibility and accurate description of the QoS
parameters. The PCF also controls the GGSN to open and close the traffic parameters. The PCF also controls the GGSN to open and close
gates and to configure per-flow policers, i.e. to authorize or the gates and to configure per-flow policers, i.e. to authorize or
forbid user traffic. forbid user traffic.
The QC is (of course) not part of the standard UMTS architecture. The NSIS Forwarder is (of course) not part of the standard UMTS
However, to achieve end-to-end QoS a QC is needed such that the PCF architecture. However, to achieve end-to-end QoS a NSIS Forwarder is
can request a QoS connection to the IP network. As in the previous needed such that the PCF can request a QoS connection to the IP
example, the QC could manage a set of pre-provisioned resources in network. As in the previous example, the NSIS Forwarder could manage
the IP network, i.e. bandwidth pipes, and the QC performs per-flow a set of pre-provisioned resources in the IP network, i.e. bandwidth
admission control into these pipes. In this way, a connection can be pipes, and the NSIS Forwarder performs per-flow admission control
made between two UMTS access networks, and hence, end-to-end QoS can into these pipes. In this way, a connection can be made between two
be achieved. In this case the QI and QC are clearly two separate UMTS access networks, and hence, end-to-end QoS can be achieved. In
entities. this case the NSIS Initiator and NSIS Forwarder are clearly two
separate entities.
This use case clearly illustrates the need for an "NSIS" QoS This use case clearly illustrates the need for an "NSIS" QoS
signaling protocol between QI and QC. An important application of signaling protocol between NSIS Initiator and NSIS Forwarder. An
such a protocol may be its use in the inter-connection of UMTS important application of such a protocol may be its use in the
networks over an IP backbone. inter-connection of UMTS networks over an IP backbone.
10.4 Scenario: Wired part of wireless network 10.4 Wired part of wireless network
A wireless network, seen from a QoS domain perspective, usually A wireless network, seen from a QoS domain perspective, usually
consists of three parts: a wireless interface part (the "radio consists of three parts: a wireless interface part (the "radio
interface"), a wired part of the wireless network (i.e., Radio interface"), a wired part of the wireless network (i.e., Radio
Access Network) and the backbone of the wireless network, as shown Access Network) and the backbone of the wireless network, as shown
in Figure 2. Note that this figure should not be seen as an in Figure 2. Note that this figure should not be seen as an
architectural overview of wireless networks but rather as showing architectural overview of wireless networks but rather as showing
the conceptual QoS domains in a wireless network. the conceptual QoS domains in a wireless network.
In this scenario, a mobile host can roam and perform a handover In this scenario, a mobile host can roam and perform a handover
procedure between base stations/access routers. In this scenario the procedure between base stations/access routers. In this scenario the
NSIS QoS protocol can be applied between a base station and the NSIS QoS protocol can be applied between a base station and the
gateway (GW). In this case a GW can also be considered as a local gateway (GW). In this case a GW can also be considered as a local
handover anchor point. Furthermore, in this scenario the NSIS QoS handover anchor point. Furthermore, in this scenario the NSIS QoS
protocol can also be applied either between two GWs, or between two protocol can also be applied either between two GWs, or between two
edge routers (ER). edge routers (ER).
|--| |--|
|GW| |GW|
|--| |--| |--| |--|
|MH|--- . |MH|--- .
|--| / |-------| . |--| / |-------| .
/--|base | |--| . /--|base | |--| .
|station|-|ER|.... |station|-|ER|...
|-------| |--| . |--| back- |--| |---| |-------| |--| . |--| back- |--| |---| |----|
|----| ..|ER|.......|ER|..|BGW|.."Internet"..|host|
-- |-------| |--| . |--| bone |--| |---| |----|
...|ER|.......|ER|..|BGW|.."Internet"..|host| |--| \ |base |-|ER|... .
-- |-------| |--| . |--| bone |--| |---| |MH| \ |station| |--| .
|----| |--|--- |-------| . MH = mobile host
|--| \ |base |-|ER|... . |--| ER = edge router
|MH| \ |station| |--| . <----> |GW| GW = gateway
|--|--- |-------| . MH = mobile host Wireless link |--| BGW = border gateway
|--| ER = edge router ... = interior nodes
<----> |GW| GW = gateway <------------------->
Wireless link |--| BGW = border gateway Wired part of wireless network
... = interior nodes
<------------------->
Wired part of wireless network
<----------------------------------------> <---------------------------------------->
Wireless Network Wireless Network
Figure 2. QoS architecture of wired part of wireless network Figure 2. QoS architecture of wired part of wireless network
Each of these parts of the wireless network impose different issues Each of these parts of the wireless network impose different issues
to be solved on the QoS signaling solution being used: to be solved on the QoS signaling solution being used:
* Wireless interface: The solution for the air interface link - Wireless interface: The solution for the air interface link
has to ensure flexibility and spectrum efficient transmission has to ensure flexibility and spectrum efficient transmission
of IP packets. However, this link layer QoS can be solved in of IP packets. However, this link layer QoS can be solved in
the same way as any other last hop problem by allowing a the same way as any other last hop problem by allowing a
host to request the proper QoS profile. host to request the proper QoS profile.
* Wired part of the wireless network: This is the part of - Wired part of the wireless network: This is the part of
the network that is closest to the base stations/access the network that is closest to the base stations/access
routers. It is an IP network although some parts logically routers. It is an IP network although some parts logically
perform tunneling of the end user data. In cellular networks, perform tunneling of the end user data. In cellular networks,
the wired part of the wireless network is denoted as a the wired part of the wireless network is denoted as a
radio access network. radio access network.
This part of the wireless network has different This part of the wireless network has different
characteristics when compared to traditional IP networks: characteristics when compared to traditional IP networks:
1. The network supports a high proportion of real-time 1. The network supports a high proportion of real-time
skipping to change at page 37, line 50 skipping to change at page 31, line 39
4. The wired transmission in such a network contains a 4. The wired transmission in such a network contains a
relatively high volume of expensive leased lines. relatively high volume of expensive leased lines.
Overprovisioning might therefore be prohibitively Overprovisioning might therefore be prohibitively
expensive. expensive.
5. The radio base stations are spread over a wide 5. The radio base stations are spread over a wide
geographical area and are in general situated a large geographical area and are in general situated a large
distance from the backbone. distance from the backbone.
* Backbone of the wireless network: the requirements imposed - Backbone of the wireless network: the requirements imposed
by this network are similar to the requirements imposed by by this network are similar to the requirements imposed by
other types of backbone networks. other types of backbone networks.
Due to these very different characteristics and requirements, often Due to these very different characteristics and requirements, often
contradictory, different QoS signaling solutions might be needed in contradictory, different QoS signaling solutions might be needed in
each of the three network parts. each of the three network parts.
10.5 Scenario: Session Mobility 10.5 Session Mobility
In this scenario, a session is moved from one end-system to another. In this scenario, a session is moved from one end-system to another.
Ongoing sessions are kept and QoS parameters need to be adapted, Ongoing sessions are kept and QoS parameters need to be adapted,
since it is very likely that the new device provides different since it is very likely that the new device provides different
capabilities. Note that it is open which entity initiates the move, capabilities. Note that it is open which entity initiates the move,
which implies that the QoS initiator might be triggered by different which implies that the NSIS Initiator might be triggered by
entities. different entities.
User mobility (i.e., a user changing the device and therefore moving User mobility (i.e., a user changing the device and therefore moving
the sessions to the new device) is considered to be a special case the sessions to the new device) is considered to be a special case
within the session mobility scenario. within the session mobility scenario.
Note that this scenario is different from terminal mobility. Not the Note that this scenario is different from terminal mobility. Not the
terminal (end-system) has moved to a different access point. Both terminal (end-system) has moved to a different access point. Both
terminals are still connected to an IP network at their original terminals are still connected to an IP network at their original
points. points.
The issues include: The issues include:
1) Keeping the QoS guarantees negotiated implies that the end- 1) Keeping the QoS guarantees negotiated implies that the end-
point(s) of communication are changed without changing the point(s) of communication are changed without changing the
reservations. reservations.
2) The trigger of the session move might be the user or any other 2) The trigger of the session move might be the user or any other
party involved in the session. party involved in the session.
10.6 Scenario: QoS reservations/negotiation from access to core 10.6 QoS reservations/negotiation from access to core network
network
The scenario includes the signaling between access networks and core The scenario includes the signaling between access networks and core
networks in order to setup and change reservations together with networks in order to setup and change reservations together with
potential negotiation. potential negotiation.
The issues to be solved in this scenario are different from previous The issues to be solved in this scenario are different from previous
ones. ones.
1) The entity of reservation is most likely an aggregate. 1) The entity of reservation is most likely an aggregate.
skipping to change at page 39, line 5 skipping to change at page 32, line 47
3) The specification of the traffic (amount of traffic), a 3) The specification of the traffic (amount of traffic), a
particular QoS is guaranteed for, needs to be changed. E.g., in case particular QoS is guaranteed for, needs to be changed. E.g., in case
additional flows are added to the aggregate, the traffic additional flows are added to the aggregate, the traffic
specification of the flow needs to be added if it is not already specification of the flow needs to be added if it is not already
included in the aggregates specification. included in the aggregates specification.
4) The flow specification is more complex including network 4) The flow specification is more complex including network
addresses and sets of different address for the source as well as addresses and sets of different address for the source as well as
for the destination of the flow. for the destination of the flow.
10.7 Scenario: QoS reservation/negotiation over administrative 10.7 QoS reservation/negotiation over administrative boundaries
boundaries
Signaling between two or more core networks to provide QoS is Signaling between two or more core networks to provide QoS is
handled in this scenario. This might also include access to core handled in this scenario. This might also include access to core
signaling over administrative boundaries. Compared to the previous signaling over administrative boundaries. Compared to the previous
one it adds the case, where the two networks are not in the same one it adds the case, where the two networks are not in the same
administrative domain. Basically, it is the inter-domain/inter administrative domain. Basically, it is the inter-domain/inter
provider signaling which is handled in here. provider signaling which is handled in here.
The domain boundary is the critical issue to be resolved. Which as The domain boundary is the critical issue to be resolved. Which as
various flavors of issues a QoS signaling protocol has to be various flavors of issues a QoS signaling protocol has to be
skipping to change at page 39, line 30 skipping to change at page 33, line 16
should be exchanged, if the signaling is between competing should be exchanged, if the signaling is between competing
administrations. Specifically information about core network administrations. Specifically information about core network
internals (e.g., topology, technology, etc.) should not be internals (e.g., topology, technology, etc.) should not be
exchanged. Some information exchange about the "access points" of exchanged. Some information exchange about the "access points" of
the core networks (which is topology information as well) may need the core networks (which is topology information as well) may need
to be exchanged, because it is needed for proper signaling. to be exchanged, because it is needed for proper signaling.
2) Additionally, as in scenario 4, signaling most likely is based on 2) Additionally, as in scenario 4, signaling most likely is based on
aggregates, with all the issues raise there. aggregates, with all the issues raise there.
3) Authorization: It is critical that the QoS initiator is 3) Authorization: It is critical that the NSIS Initiator is
authorized to perform a QoS path setup. authorized to perform a QoS path setup.
4) Accountability: It is important to notice that signaling might be 4) Accountability: It is important to notice that signaling might be
used as an entity to charge money for, therefore the interoperation used as an entity to charge money for, therefore the interoperation
with accounting needs to be available. with accounting needs to be available.
10.8 Scenario: QoS signaling between PSTN gateways and backbone 10.8 QoS signaling between PSTN gateways and backbone routers
routers
A PSTN gateway (i.e., host) requires information from the network A PSTN gateway (i.e., host) requires information from the network
regarding its ability to transport voice traffic across the network. regarding its ability to transport voice traffic across the network.
The voice quality will suffer due to packet loss, latency and The voice quality will suffer due to packet loss, latency and
jitter. Signaling is used to identify and admit a flow for which jitter. Signaling is used to identify and admit a flow for which
these impairments are minimized. In addition, the disposition of these impairments are minimized. In addition, the disposition of
the signaling request is used to allow the PSTN GW to make a call the signaling request is used to allow the PSTN GW to make a call
routing decision before the call is actually accepted and delivered routing decision before the call is actually accepted and delivered
to the final destination. to the final destination.
skipping to change at page 40, line 4 skipping to change at page 33, line 44
PSTN gateways may handle thousands of calls simultaneously and there PSTN gateways may handle thousands of calls simultaneously and there
may be hundreds of PSTN gateways in a single provider network. These may be hundreds of PSTN gateways in a single provider network. These
numbers are likely to increase as the size of the network increases. numbers are likely to increase as the size of the network increases.
The point being that scalability is a major issue. The point being that scalability is a major issue.
There are several ways that a PSTN gateway can acquire assurances There are several ways that a PSTN gateway can acquire assurances
that a network can carry its traffic across the network. These that a network can carry its traffic across the network. These
include: include:
1. Over-provisioning a high availability network. 1. Over-provisioning a high availability network.
2. Handling admission control through some policy server 2. Handling admission control through some policy server
that has a global view of the network and its resources. that has a global view of the network and its resources.
3. Per PSTN GW pair admission control. 3. Per PSTN GW pair admission control.
4. Per call admission control (where a call is defined as 4. Per call admission control (where a call is defined as
the 5 tuple used to carry a single RTP flow). the 5 tuple used to carry a single RTP flow).
Item 1 requires no signaling at all and is therefore outside the Item 1 requires no signaling at all and is therefore outside the
scope of this working group. scope of this working group.
Item 2 is really a better informed version of 1, but it is also 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 outside the scope of this working group as it relies on a particular
telephony signaling protocol rather than a packet admission control telephony signaling protocol rather than a packet admission control
protocol. protocol.
Item 3 is initially attractive as it appears to have reasonable Item 3 is initially attractive, as it appears to have reasonable
scaling properties, however, its scaling properties only are scaling properties, however, its scaling properties only are
effective in cases where there are relatively few PSTN GWs. In the 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 more general case were a PSTN GW reduces to a single IP phone
sitting behind some access network, the opportunities for sitting behind some access network, the opportunities for
aggregation are reduced and the problem reduces to item 4. aggregation are reduced and the problem reduces to item 4.
Item 4 is the most general case. However, it has the most difficult Item 4 is the most general case. However, it has the most difficult
scaling problems. The objective here is to place the requirements on scaling problems. The objective here is to place the requirements on
Item 4 such that a scalable per-flow admission control protocol or Item 4 such that a scalable per-flow admission control protocol or
protocol suite may be developed. protocol suite may be developed.
skipping to change at page 41, line 5 skipping to change at page 34, line 45
At the interior nodes, the NSIS host-to-host signaling should either At the interior nodes, the NSIS host-to-host signaling should either
be ignored or invisible as the Edge router performed the admission be ignored or invisible as the Edge router performed the admission
control decision to some aggregate. control decision to some aggregate.
At the inter-provider router (i.e., border node), again the NSIS At the inter-provider router (i.e., border node), again the NSIS
host-to-host signaling should either be ignored or invisible as the host-to-host signaling should either be ignored or invisible as the
Edge router has performed an admission control decision about an Edge router has performed an admission control decision about an
aggregate across a carrier network. aggregate across a carrier network.
10.9 Scenario: PSTN trunking gateway 10.9 PSTN trunking gateway
One of the use cases for the NSIS signaling protocol is the scenario One of the use cases for the NSIS signaling protocol is the scenario
of interconnecting PSTN gateways with an IP network that supports of interconnecting PSTN gateways with an IP network that supports
QoS. QoS.
Four different scenarios are considered here. Four different scenarios are considered here.
1. In-band QoS signaling is used. In this case the Media Gateway 1. In-band QoS signaling is used. In this case the Media Gateway
(MG) will be acting as the QoS Initiator and the Edge Router (MG) will be acting as the NSIS Initiator and the Edge Router
(ER) will be the QoS Controller. Hence, the ER should do (ER) will be the NSIS Forwarder. Hence, the ER should do
admission control (into pre-provisioned traffic trunks) for the admission control (into pre-provisioned traffic trunks) for the
individual traffic flows. This scenario is not further individual traffic flows. This scenario is not further
considered here. considered here.
2. Out-of-band signaling in a single domain, the QoS Controller is
2. Out-of-band signaling in a single domain, the NSIS Forwarder is
integrated in the MGC. In this case no NSIS protocol is integrated in the MGC. In this case no NSIS protocol is
required. required.
3. Out-of-band signaling in a single domain, the QoS Controller is 3. Out-of-band signaling in a single domain, the NSIS Forwarder is
a separate box. In this case NSIS signaling is used between the a separate box. In this case NSIS signaling is used between the
MGC and the QoS Controller. MGC and the NSIS Forwarder.
4. Out-of-band signaling between multiple domains, the QoS 4. Out-of-band signaling between multiple domains, the NSIS
Controller (which may be integrated in the MGC) triggers the Forwarder (which may be integrated in the MGC) triggers the
QoS Controller of the next domain. NSIS Forwarder of the next domain.
When the out-of-band QoS signaling is used the Media Gateway When the out-of-band QoS signaling is used the Media Gateway
Controller (MGC) will be acting as the QoS Initiator. Controller (MGC) will be acting as the NSIS Initiator.
In the second scenario the voice provider manages a set of traffic In the second scenario the voice provider manages a set of traffic
trunks that are leased from a network provider. The MGC does the trunks that are leased from a network provider. The MGC does the
admission control in this case. Since the QoS Controller acts both admission control in this case. Since the NSIS Forwarder acts both
as a QoS Initiator and a QoS Controller, no NSIS signaling is as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is
required. This scenario is shown in figure 1. required. This scenario is shown in figure 1.
+-------------+ ISUP/SIGTRAN +-----+ +-----+ +-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 | | SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+ +-------------+ +-------+-----+---------+ +-----+
: / : \ : / : \
: / : \ : / : \
: / +--------:----------+ \ : / +--------:----------+ \
: MEGACO / / : \ \ : MEGACO / / : \ \
: / / +-----+ \ \ : / / +-----+ \ \
skipping to change at page 41, line 57 skipping to change at page 35, line 45
+--------------+ +----+ | bandwidth pipe (SLS) | +----+ +--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |-- | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
+--------------+ +----+ \ / +----+ +--------------+ +----+ \ / +----+
\ QoS network / \ QoS network /
+-------------------+ +-------------------+
Figure 1: PSTN trunking gateway scenario Figure 1: PSTN trunking gateway scenario
In the third scenario, the voice provider does not lease traffic In the third scenario, the voice provider does not lease traffic
trunks in the network. Another entity may lease traffic trunks and trunks in the network. Another entity may lease traffic trunks and
may use a QoS Controller to do per-flow admission control. In this may use a NSIS Forwarder to do per-flow admission control. In this
case the NSIS signaling is used between the MGC and the QoS case the NSIS signaling is used between the MGC and the NSIS
Controller, which is a separate box here. Hence, the MGC acts only Forwarder, which is a separate box here. Hence, the MGC acts only as
as a QoS Initiator. This scenario is depicted in figure 2. a NSIS Initiator. This scenario is depicted in figure 2.
+-------------+ ISUP/SIGTRAN +-----+ +-----+ +-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 | | SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+ +-------------+ +-------+-----+---------+ +-----+
: / : \ : / : \
: / +-----+ \ : / +-----+ \
: / | QC | \ : / | NSIS Forwarder |
\
: / +-----+ \ : / +-----+ \
: / : \ : / : \
: / +--------:----------+ \ : / +--------:----------+ \
: MEGACO : / : \ : : MEGACO : / : \ :
: : / +-----+ \ : : : / +-----+ \ :
: : / | NMS | \ : : : / | NMS | \ :
: : | +-----+ | : : : | +-----+ | :
: : | | : : : | | :
+--------------+ +----+ | bandwidth pipe (SLS) | +----+ +--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |-- | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
+--------------+ +----+ \ / +----+ +--------------+ +----+ \ / +----+
\ QoS network / \ QoS network /
+-------------------+ +-------------------+
Figure 2: PSTN trunking gateway scenario Figure 2: PSTN trunking gateway scenario
In the fourth scenario multiple transport domains are involved. In In the fourth scenario multiple transport domains are involved. In
the originating network either the MGC may have an overview on the the originating network either the MGC may have an overview on the
resources of the overlay network or a separate QoS Controller will resources of the overlay network or a separate NSIS Forwarder will
have the overview. Hence, depending on this either the MGC or the have the overview. Hence, depending on this either the MGC or the
QoS Controller of the originating domain will contact the QoS NSIS Forwarder of the originating domain will contact the NSIS
Controller of the next domain. The MGC always acts as a QoS Forwarder of the next domain. The MGC always acts as a NSIS
Initiator and may also be acting as a QoS Controller in the first Initiator and may also be acting as a NSIS Forwarder in the first
domain. domain.
10.10 Scenario: Application request end-to-end QoS path from the 10.10 Application request end-to-end QoS path from the network
network
This is actually the easiest case, nevertheless might be most often This is actually the easiest case, nevertheless might be most often
used in terms of number of users. So multimedia application requests used in terms of number of users. So multimedia application requests
a guaranteed service from an IP network. We assume here that the a guaranteed service from an IP network. We assume here that the
application is somehow able to specify the network service. The application is somehow able to specify the network service. The
characteristics here are that many hosts might do it, but that the characteristics here are that many hosts might do it, but that the
requested service is low capacity (bounded by the access line). requested service is low capacity (bounded by the access line).
Additionally, we assume no mobility and standard devices. Additionally, we assume no mobility and standard devices.
10.11 Scenario: QOS for Virtual Private Networks QOS for Virtual Private Networks
In a Virtual Private Network (VPN) a variety of tunnels might be In a Virtual Private Network (VPN) a variety of tunnels might be
used between its edges. These tunnels could be for example, IP-Sec, used between its edges. These tunnels could be for example, IP-Sec,
GRE, and IP-IP. One of the most significant issues in VPNs is GRE, and IP-IP. One of the most significant issues in VPNs is
related to how a flow is identified and what quality a flow gets. A related to how a flow is identified and what quality a flow gets. A
flow identification might consist among others of the transport flow identification might consist among others of the transport
protocol port numbers. In an IP-Sec tunnel this will be problematic protocol port numbers. In an IP-Sec tunnel this will be problematic
since the transport protocol information is encrypted. since the transport protocol information is encrypted.
There are two types of L3 VPNs, distinguished by where the endpoints There are two types of L3 VPNs, distinguished by where the endpoints
skipping to change at page 44, line 7 skipping to change at page 37, line 47
required on the PE router. required on the PE router.
In the case of per site signaling, a site would need to be In the case of per site signaling, a site would need to be
identified. This may be accomplished by specifying the network identified. This may be accomplished by specifying the network
serviced at that site through an IP prefix. In this case, the serviced at that site through an IP prefix. In this case, the
admission control function is performed on the aggregate to the PE admission control function is performed on the aggregate to the PE
router connected to the site in question. router connected to the site in question.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
skipping to change at page 44, line 21 skipping to change at page 38, line 8
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Open Issues/To Dos
2) (OPEN) Sender/receiver initiation
What is the requirement concerning data sender or data receiver or
both to initiate a QoS request.
Terminology text added
open issue, what is a potential req (currently we say "both must be
possible")
Proposals:
1)should be optimized for sender initiated
2) remove the requirement, because it is not relevant if we allow
for third party QoS initiators
3) SHOULD support sender initiated, MAY support reciever initiated
Issues:
- does it matter who pays?
- for sender initiated, can we support implicit signaling
(bundling the QoS requests with other signaling - registration,
etc.)?
- For reciever initiated, do we need protection against spamming -
how do we protect against unwanted changes?
4) (OPEN) MUSTs, SHOULDs, MAY needs discussion
28) (OPEN) new requirement on "asynchronous events from the network"
The content of the message might be very service specific, but the
protocol support for asynchronous events from the network might be a
valuable requirement. We have something about notification in case
of errors/failures.
Asynchronous notification of QoS Initiator, Controller, Receiver,
there are security issues related. Basically, an ownership issue.
Nevertheless, an asynch notifcation in case of an error, network
failure etc. is specifically in areas, where longer lived sessions
are setup, essential in order to notify upper layers.
44) (OPEN) req resource availability info on request come back to it
as soon as we have a more clear idea about service description issue
53) (OPEN) Error handling
Comments:
1) notification of user in case of unrecoverable errors (has been
done by notification requirement, or will be done by asynch
notification, issue 43)
A description of both types of errors (recoverable, unrecoverable)
are listed in Section 5.3.4.
2) hop-by-hop? OR right to the end?
3) What is potential value to notify about recoverable errors?
Proposal: not hop by hop, but QoS controller to QoS initiator
59) (OPEN) add req: ability to deal with severe congestion (req
5.3.4 of draft-partain-..-00
issues are:
- occurs in a highly utilised network and if it is not solved very
fast then the network performance will quickly collapse
- deos it belong to failure recovery (I would assume from a service
point of view this is failure
- hop by hop problem (issue from Jorge)
- What difference does it make (from the QoS perspective) if the
provided QoS degraded due to hardware failure on a device or due to
congestion caused by failures on some other devices? What is
required from the protocol is to signal this failure to other
participants (QCs or QI) in the hope that they can do something
meaningful (e.g. re-routing) to correct the problem or tear down the
flow.
65) (OPEN) Request to add req: Unexpected situations and error
restistance
An NSIS protocol must define behaviour of NSIS signaling units
during unexpected situations. Unexpected situtions are unknown
messages, parameters and parameter settings as well as receiption of
unexpected messages (e.g. a "Reservation Confirmation" without prior
"Reservation Request").
Related to Open issues (53) and requirement 5.3.4.
This requirement is emphasizing to many details that might not be
necessary
Req 5.3.4 refers to behaviour in the case of problems in the data
plane. My suggestion here is about unexpected events/errors in the
control plane. If you think that this point carries to many details,
let's split it up in several individual requirements.
72) (OPEN) request to add "Error notification and error location"
"An NSIS signaling node rejecting or releasing a reservation must
indicate its identity. NSIS signalling should indicate why a
requested resource is not or no longer available. "
Compared to 5.3.4 this is about problems on the control plane
Closed Issues
1) (CLOSED) add Scenarios
Do we need to add, remove, or change the scenarios?
- added scenario on QoS signalling between PSTN gateways and
backbone routers
- added: Application request end-to-end QoS path from the network
- added VPN scenario
We can add what ever scenario we want. The more the better to
understand the issues. Nevertheless, we have to take care that we
are future prove as well.
3) (CLOSED) Draft organization
The proposed changes include
- put all the scenarios into an appendix
- In Section 6 add text describing 3 different "parts of the
network"
-Host to first hop
-access network
-core networks
better names are welcome, but I don't want to be religious about
it
- Prioritize the requirements according to the "parts of the
network" (This means the the tables in Section 6 of the current
draft will get three colums with the MUST, SHOULDs, and MAYs for
each requirement
5) (CLOSED) Framework text.
The figures have been removed, because they seamed to be misleading.
the text has been revisited. I regard the issue closed until we have
a clear picture about what the NSIS framework draft is about.
6) (CLOSED) The requirement organization
I heard some voices on the list that the grouping should be more
along the lines of host-to-edge, edge to edge etc.
So far I have not changed it, because I though that the requirements
heavily depend on the scenario we are looking at.
closed, by the change in the draft organisation (issue 3)
7) (CLOSED) Hemant Chaskar: Section 3.1, items 1) Handoff decision
and 2) Trigger sources: The handoff decision and trigger sources
should be out of scope of NSIS. NSIS should rather focus only on
"establishing" QoS along the packet path after handoff.
added exclusion
8) (CLOSED) bi-directional data path setup with one QoS request
I have not seen consensus on whether to require bi-directional data
path setup with QoS.
Q: How can we actually perform bi-directional reservations when the
forward and reverse paths are not reciprocal, with respect to
routing topology and routing policy of network domains between
sender and receiver?
A: bi-directional data path setup does not need to use the same
return path as the forwarding path. The only requirement to achieve
a bi-directional reservation is that the sender for the forwarding
path is also the receiver for the return path and that the receiver
for the forwarding path is also the sender for the return path.
- The need to ensure that the return path is the same as the
forwarding path is one of the problems with RSVP, particularly in a
mobile environment.
added some explanations that we do not require the same path, and
that the goal is an optimization of the setup delay
9) (CLOSED) Potential requirement: must be implementable in user
space (on end hosts)
has not been included in the req list because it seams to be
implementation specific.
10) (CLOSED) Potential requirement: must provide support for
globally defined services as well as private services (Ruediger)
replaced by issue 17 and 18, closed
11) (CLOSED) Potential requirement: Flexibility in the granularity
of reservation (I don't remember who brought it up, but I assume it
refers to the flexibility in terms of what size the flow has. Where
size can be bandwidth etc.)
The assumption that QoS classes as well as service definitions are
out of scope for this draft, also the flexibility is.
12) (CLOSED) text replacing scalability reqs
"The nsis architecture should give the ability to constrain the load
(CPU load, memory space, signaling bandwidth consumption and
signaling intensity) on devices where it is needed. This can be
achieved by many different methods, for example message aggregation,
by ignoring signaling message, header compression or minimizing
functionality. The architecture may choose any of these methods as
long as the requirement is met."
Editor: added the draft text, but did not remove scalability reqs
13) (CLOSED) add operator req "Ability to assign transport quality
to signaling messages"
"The nsis architecture should allow the network operator to assign
the nsis protocol messages a certain transport quality. As signaling
opens up for possible denial-of-service attacks, this requirement
gives the network operator a mean, but also the obligation, to
trade-off between signaling latency and the impact (from the
signaling messages) on devices within his/her network. From protocol
design this requirement states that the protocol messages should be
detectable, at least where the control and assignment of the
messages priority is done."
text has been added
14) (CLOSED) proposal to add "support grouping of microflows
(possibly only for feedback)"
"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."
Should not be restrict to teardown and/or notification, it might be
useful also for the procedure that refreshes reservation states
added that requirement.
15) (CLOSED) Support for preemption of sessions
-might play into the fault/ error handling case
-is regarded as service-specific, whether existing sessions can be
pre-empted
Conclusion: it is network policy to determine how to do pre-emption,
not a protocol issue.
16) (CLOSED) Req: 5.1.9 change provisioning into better term, since
different people understand different thing with provisioning
we did not find a better word
17) (CLOSED) add assumption that QoS classes/service definitions are
already known to all the parties involved in signaling before hand
(before a signalling session even starts
added text in Section 4.1
18) (CLOSED) add exclusion of methods, protocols, and ways to
express QoS
Even so, this might be covered by saying that we are independent of
QoS classes and service description etc. (see issue 17), I added two
points to the exclusion Section 4.2.
Implications: issue 20, 23,
19) (CLOSED) remove req 5.2.5 IP fragmentation
20) (CLOSED) remove req 5.3.2 Ability to signal life-time of a
reservation
is regarded service-specific therefore part of the service
description
added some reservation life time text service description assumption
text and removed the req
21) (CLOSED) remove req 5.5.4 Aggregation method specification
Concerns
-QI not able to know the impact of aggregation
-to far down the implementation/ service definition road
-leave it to the provider how a service is realized
removed
22) (CLOSED) remove 5.3.7 Automatic notification on available
resources not been granted before
regarded to complex and is heavily dependend on the service
description
removed
23) (CLOSED) remove 5.5.3 Simple mapping to lower-layer QoS
provisioning parameters
this heavily depends on service definition and therefore is out of
scope of this document
removed
24) (CLOSED) Replacing req 5.3.6 "Feedback about the actually
received level of QoS guarantees" with two requirements: 1) the
feedback of a request MUST include yes and no (MUST respond yes or
no) 2) in case of no it MAY include an opaque service-specific
information about what would be possible
It is still only one requirement, but the text has been replaced.
25) (CLOSED) remove req 5.10.3 Combination with Mobility management
However the integration should not be a priori excluded, there is
explicitly no statemant about independence of mobility management.
There is more discussion for the mobility case needed anyway.
26) (CLOSED) interaction of NSIS with seamoby (context transfer and
CAR discovery)
added requirement, that NSIS should interwork with seamoby protocols
27) (CLOSED) remove req 5.5.10 QoS conformance specification
Motivation: this heavily depends on the service definition and is
therefore out of scope
removed
29) (CLOSED) NSIS in case of handovers
issue 26, mentions that NSIS should interwork with handoffs
30) (CLOSED) remove 5.1.7 Avoid modularity with large overhead (in
various dimensions)
removed because it seams to be obvious
31) (CLOSED) remove 5.1.8 Possibility to use the signaling protocol
for existing local technologies
It is contradictory to 5.1.9 and the intention behind the
requirement is covered by the requierement that the QoS controller
can be placed wherever needed.
32) (CLOSED) add assumption: there are means for discovery of nsis
entities in order to know the signaling peers (solutions include
static configuration, or automatically discovered etc.)
33) (CLOSED) add req " highest possible network utilization"
"There are networking environments that require high network
utilization for various reasons, and the signaling protocol should
to its best ability support high resource utilization while
maintaining appropriate QoS.
In networks where resources are very expensive (as is the case for
many wireless networks), efficient network utilization is of
critical financial importance. On the other hand there are other
parts of the network where high utilization is not required.
"
req added
34) (CLOSED)_difference between "UMTS access scenario" "cellular
network scenario", and "Wired part of wireless network" (Section
8.2, 8.3, and 8.4)
all three are included.
The only common point between the three scenarios is that they are
related to cellular networks. Section 8.4 is introducing the
scenario used in the radio access network of cellular networks.
Sections 8.2 and Section 8.3 are discussing other parts of the
cellular network.
35) (CLOSED) difference between the two PSTN gateway scenarios
(Section 8.8 and 8.9)
currently both are included, they might be merged, sionce one seams
to be more general than the other
36) (CLOSED) req "Independence of reservation identifier"
issue here is that this might only be valuable in mobile
environments, and complicate the protocol for other environments.
there are related issues (37,38,
37) (CLOSED) ownership of a reservation
The issue here is that a known party owns reservations done in the
network. (which might include that the party also pays). The
question arose who is allowed to tear-down, receive asynchronous
notifications in case of network initiated tear-down, etc.
This also relates to how certain service granted is
named/identified.
req 5.8.9 added (renamed)
38) (CLOSED) definition of security threats
handled in draft-tschofenig-nsis-threats-00.txt
39) (CLOSED) simplify security requirements section
done
40) (CLOSED) add mobility related requirements
we have some mobility related requirements, but do not need to add
more
41) (CLOSED) remove req 5.5.1 Mutability information on parameters
removed because it is service-specific
42) (CLOSED) add an assumption that QoS monitoring is application-
specific and with it out of scope of the WG (done)
43) (CLOSED) asynchronous notification of QoS Initiator, Controller,
Receiver, there are security issues related. Basically, an ownership
issue. Nevertheless, an asynch notifcation in case of an error,
network failure etc. is specifically in areas, where longer lived
sessions are setup, essential in order to notify upper layers,
applications etc. as well.
45) (CLOSED) 5.3.4 Possibility for automatic re-setup of resources
after recovery
- more thoughts in failure conditions potentially
- better text
- operation under overload
plays into issue 46)
The requirement has been removed:
"Possibility for automatic re-setup of resources after recovery
In case of a failure, the reservation can get setup again
automatically. It enables sort of a persistent reservation, if the
QoS Initiator requests it. In scenarios where the reservations are
on a longer time scale, this could make sense to reduce the
signaling load in case of failure and recovery."
46) (CLOSED) we might need multiple scenarios for failure and
recovery cases to derive requirements. Or a list of failure cases
might be a start as well.
47) (CLOSED) traffic engineering and route pinning
added Assumption: NSIS should work with networks using standard L3
routing.
added requirement: NSIS should not be broken by networks which do
non-traditional L3 routing.
48) (CLOSED) req 5.5.5 remove Multiple levels of detail
"The QSC should allow for multiple levels of detail in description.
(Motivation: someone interpreting the request can tune its own level
of complexity by going down to more or less levels of detail. A
lightweight implementation within the core could consider only the
coarsest level.)"
removed, because it is service-specific
49) (CLOSED) remove req 5.5.9 Signaling must support quantitative,
qualitative, and relative QoS specifications
removed because it is service-specific
50) (CLOSED) req 5.5.6 remove Ranges in specification
The QSC should allow for specification of minimum required QoS
and/or desirable QoS. (Motivation: The QoS Service Classes should
allow for ranges to be indicated, to minimize negotiation latency
and suppress error notifications during handover events.)
removed, is service specific
51) (CLOSED) remove 5.1.6 Avoid duplication of [sub]domain signaling
functions
we might use the requirement text somewhere else:
Heading: Avoid duplication of [sub]domain signaling functions
The specification of the NSIS signaling protocol should be optimized
to avoid duplication of existing [sub]domain QoS signaling and to
minimize the overall complexity. (Motivation: we don't want to
introduce duplicate feedback or negotiation mechanisms, or
complicate the work by including all possible existing QoS signaling
in some form. The function will be placed in the new part if it has
to be end-to-end, universal to all network types
('simple/lightweight'), or if it has to be protected by upper layer
security mechanisms.)
The point here is that the QoS technology (lower layer stuff) gets
re-used unchanged, and we have new signaling above it. But, in many
cases the local QoS technology will contain equivalent functions to
the NSIS-required ones, just in a technology specific form. Examples
of these functions would be error/QoS violation notifications,
ability to query for resources and so on. So, there is a danger that
our 'lightweight' signaling ends up trying to carry all this
information all over again, and (even worse) that the
initiator/controller functions have to weigh up nearly equivalent
information coming from two directions. However, the basic problem
here is that the boundary between new and re-used stuff is pretty
shaky. The requirement is trying to scope our problem (a) to
eliminate the potential overlap, and (b) to keep the new NSIS stuff
simple.
However, we are aware that it is very difficult to judge what is
duplicated, if we want to run the protocol in various environments.
52) (CLOSED) New requirement: interaction with policy
Is part of the AAA solution or service definition, and we require
that NSIS interworks with AAA
54) (CLOSED) add req 5.1.17. to assumption "Identification
requirement"
assumption say that the discovery of QI, QC, QR is out-of-scope of
the draft
55) (CLOSED) add from draft-partain-nsis-requirements-00.txt req
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.
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.
"
Comments:
- service mapping is more service-specific (layering,tunneling)
- the scenario to look at is a complicated service description -> in
part of the network you want to change the message to something more
easy, and at the other end go back to the more complicated part.
-QI being everywhere might be enough
-and we have already a requirement saying that intermediate node
MUST be able to add/remove domain-specific information to/from
signaling messages
56) (CLOSED) add req 5.3.1.3 of draft-partain-..-00
-already added a req to the scalability section (issue ???), which
has been provided by Anders
57) (CLOSED) potentially better title for text from issue 56) e.g.
(ææminimal impact on coreÆÆ)
58) (CLOSED) add req 5.3.2 from draft-partain-...-00
- the fast establishment req is handled by the low setup latency
req, and the scalability in handover req
- added the text to the teminal mobility scenario
- added text " time scale (e.g., handover in mobile environments),"
to req
60) (CLOSED) add req 5.4.3. from draft-partain-...-00 "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."
- most likely it is already cover, please check again, whether there
is something missing
- added it again under the mobility requiremments
61) (CLOSED) add req: 6.1.8 from draft-bucheli-...-00 on multicast
"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."
not added
---------------------------------------------------
starting from -02 version
---------------------------------------------------
62) (CLOSED) Request to add VPN scenario
- Related to issue 1)
- Difference of VPN scenario compared to what we already have is
missing
added the scenario
63) (CLOSED) added Sven Van den Bosch, Maarten Buchli, and Danny
Goderis to acknowledgement section.
64) (CLOSED) Request to add req: Backwards compatibility
A later version of an NSIS protocol must be backwards compatible
with earlier versions of an NSIS protocol.
we can take of this if we have NSIS.
66) (CLOSED) Request to add req: Default behaviour
An NSIS protocol must define default behaviours and parameter
settings wherever applicable.
Is assumed to be normal practice.
67) (CLOSED) Request to add req: Extendability
An NSIS protocol must provide means to enhance a protocol with
future procedures, messages, parameters and parameter settings.
This was refering mostly to the service specific part of the
protocol.
could be a part of the modularity requirement 5.1.3
68) (CLOSED) Request to add req: Preventation of stale state
An NSIS signalling protocol must provide means for an NSIS signaling
unit to discover and remove local stale state. This may for example
be done by means like soft state and periodic flooding or by a
polling mechanism and hard state signaling.
Might already be covered in other requirements, could also be that
the solutions known are solutions for different problems. I think
distributed garbage collection could also be a solution.
merged this text into requirement 5.3.2
69) (CLOSED) Request to add req: Reliable Communication
NSIS signaling procedures, connectivity between units involved in
NSIS signaling as well as the basic transport protocol used by NSIS
must provide a maximum of communication reliability. Procedures must
define how an NSIS signaling systems behaves if some kind of request
it sent stays without answer (this could require e.g. be timers,
number of message retransmits and release messages).
An NSIS signaling unit must be able to check its connectivity to an
adjacent NSIS signaling unit at any time (this requirement must
however not result in a DoS attack tool - the frequency of these
checks must be limited, and flow control may be useful).
The basic transport protocol to be used between adjacent NSIS units
must ensure message integrity and reliable transport.
MUST/SHOULD ensure error- and loss free transmission of signaling
information.
Added some of the text to req 5.11.1
70) (CLOSED) Request to add req: Smooth breakdown
A unit participating in NSIS signaling must no cause further damage
to other systems involved in NSIS signaling when it has to go out of
service.
added as requirement 5.11.2
71) (CLOSED) Changed text "5.6.8: Ability to constrain load on
devices" to
The NSIS architecture should give the ability to constrain the load
(CPU load, memory space, signaling bandwidth consumption and
signaling intensity) on devices where it is needed. This can be
achieved by many different methods. Examples, and this are only
examples, include message aggregation, by ignoring signaling
message, header compression, or minimizing functionality. The
framework may choose any method as long as the requirement is met.
--------------------------
starting from -03 version
--------------------------
73) (CLOSED) add table of contents
------------------------------------------------------
Change Log Version 01 -> 02
- added issues 62-72
- added some discussion text to open issues
- req " highest possible network utilization" added (issue 33,
closed)
- issues closed: 34 (UMTS scenarios), 35 (PSTN gatway scenarios),
- removed req "Avoid duplication of [sub]domain signaling
functions", issue 51
- Section 5.3.4: added explanation of recoverable and unrecoverable
errors (issue 53)
- added the following requirement: (closed issue 55) Allow local QoS
information exchange between nodes of the saeme administrative
domain
The QoS signaling protocol must be able to exchange local QoS
information between QoS controllers located within one single
domain. Local QoS information might, for example, be IP addresses,
severe congestion notification, notification of successful or
erroneous processing of QoS signaling messages.
In some cases, the NSIS QoS signalling protocol may carry
identification of the QoS controllers located at the boundaries of a
domain. However, the identification of edge should not be visible to
the end host (QoS initiator) and only applies within one QoS
administrative domain.
- closed issue 57: add text about "Minimal impact on interior (core)
nodes" to requirement 5.6.8 "Ability to constrain load on devices"
- added requirement "Allow efficient QoS re-establishment after
handover", closed issue 60.
- changed text in 5.3.2
------------------------------------------------------
Change Log Version 02 -> 03 ([X] specify the open issue above)
[1] Scenarios add/change/remove (e.g. VPN).
Question: scenarios covering signalling for things other than QoS?
Georgios/Lars will provide justification & if successful Marcus will
add it. (done)
[7] Handoff decision and trigger sources (in or out of scope).
Agreed: NSIS is not going to solve this problem, has to interact
with protocols that do. Add text to exclusions section. (done)
[8] NSIS should allow bidirectional reservations as an optimisation
where the network topology allows it. (done)
[14] Grouping of microflows. Added (as a MAY, probably). Network
does not need to know relationship exists. Add justification of why
this is an optimization. (done)
[16] Closed. (done)
[26] Interaction with seamoby. Add requirement to say that we are
interworking in the area of mobility protocols (e.g. CT and CAR
discovery). (done)
[28] Asynchronous events from the network. REH & Sven to propose
wording including some motivation as examples. Issues to do with
locality and scenarios. (resilience draft from Sven)
[29] NSIS in case of handovers. No change needed concerning
handovers. (closed the issue: done)
[37] Ownership of a reservation. Close issue and handle it within
security section. (done, changed security req text)
[39] Simplify security section. (done)
[40] Mobility requirements - don't add. Closed. (done)
[42] Add assumption that QoS monitoring is application/service
specific and out of scope. (done)
[43] Notification of QI/QC/QR. Closed earlier. (done, put together
with issue 28)
[44] Resource availability query. Query not as 'real' reservation
is part of service definition. May need new requirement about
endpoint controlling locality of signalling.
[45] Automatic re-installation. Removed, leave open option to supply
text for new requirement. (done)
[46] Scenarios for failure and recovery cases. Remove, invite
individual contributions. (done)
[47] Traffic engineering and route pinning issues. Assumption: NSIS
should work with networks using standard L3 routing. NSIS should not
be broken by networks which do non-traditional L3 routing. (done)
[52] Closed. Aspect of AAA (authentication --> authorisation)
solution or service definition. (done)
[53] Sven et al. to write submissions.
[59] Covered under [53].
[61] Closed. (done)
[64] Closed (no new text except maybe motherhood statements). (done)
[65] Considered [53].
[66] Closed (not included elsewhere).(done)
[67] Closed (already covered). (done)
[68] Merge with 5.3.2 to reflect wanting to avoid stale state
(somehow). (done)
[69] Closed (already covered in transport service quality
requirement). Protocol design must take into account reliability
concerns. (done)
[70] Add something about graceful failover to general protocol
requirements section. (done)
[72] Closed. Should be possible for NSIS to transport useful error
messages.
- changed security text
- rearranged open issues (open ones on top)
 End of changes. 257 change blocks. 
1047 lines changed or deleted 756 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/