NSIS Working Group
   Internet Draft                                   M. Brunner (Editor)
   Document: draft-ietf-nsis-req-02.txt draft-ietf-nsis-req-03.txt                             NEC
   Expires:  November 2002                                     May 2002

                 Requirements for QoS Signaling Protocols
                      <draft-ietf-nsis-req-02.txt>
                       <draft-ietf-nsis-req-03.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

                            Informational                    [Page 1]

               Requirements for QoS Signaling Protocols       May      July 2002

Abstract

   This document defines requirements for signaling QoS across
   different network environments. environments, where different network environments
   across administrative and technology domains. To achieve wide
   applicability of the requirements, the starting point is a diverse
   set of scenarios/use cases concerning various types of networks and
   application interactions.  We also provide an outline structure for
   the problem, including QoS related terminology. Taken with the
   scenarios, this allows us to focus more precisely on which parts of
   the overall QoS problem needs to be solved. We present the
   assumptions and the aspects not considered within scope before
   listing the requirements grouped according to areas such as
   architecture and design goals, signaling flows, layering,
   performance, flexibility, security, and mobility.

Table of Contents

Status of this Memo...................................................1
Abstract..............................................................2
Table of Contents.....................................................2
1  Introduction

   This document defines requirements 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 signaling QoS across different network environments. It does not list any problems 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 protocols such as RSVP.

   In order to derive requirements for and provisioning paradigm.........14
 5.2  Signaling Flows...............................................14
  5.2.1 Free placement of QoS signaling it is necessary to
   first have a clear idea Initiator and QoS Controllers functions14
  5.2.2 No constraint of the scope within which they are
   applicable.
   We describe a set of QoS signaling scenarios and use cases QoS Controllers to be in
  the
   Appendix of that document. These scenarios derive from a variety data path.....................................................14
  5.2.3 Concealment of
   backgrounds, topology and help obtain a clearer picture technology information..........15
  5.2.4 Optional transparency of what is in or out QoS signaling to network...........15
 5.3  Additional information beyond signaling of scope QoS information....16
  5.3.1 Explicit release of the NSIS work. They illustrate the problem resources...............................16
  5.3.2 Possibility for automatic release of resources after failure 16
  5.3.3 Prompt notification of QoS
   signaling from various perspectives (end-system, access network,
   core network) violation in case of error/failure
  to QoS Initiator and QoS Controllers..............................16
  5.3.4 Feedback about success of request for various areas (fixed line, mobile, wireless
   environments). As QoS guarantees........16
  5.3.5 Allow local QoS information exchange between nodes of the NSIS work becomes more clearly defined,
   scenarios will same
  administrative domain.............................................17
 5.4  Layering......................................................17
  5.4.1 The signaling protocol and QoS control information should be added or dropped, or defined in more detail.

   Based on these scenarios, we are able to define the
  application independent...........................................17
               Requirements for QoS signaling
   problem Signaling Protocols      July 2002

 5.5  QoS Control Information.......................................17
  5.5.1 Mutability information on a more abstract level. In Section 3, we thus present a
   simple conceptual model parameters........................17
  5.5.2 Possibility to add and remove local domain information......18
  5.5.3 Independence of reservation identifier......................18
  5.5.4 Seamless modification of already reserved QoS...............18
  5.5.5 Grouping of the QoS signaling problem, describe the
   entities involved for several microflows................18
 5.6  Performance...................................................18
  5.6.1 Scalability in QoS signaling, and typical the number of messages received by a signaling paths. In
   Section 4 we list assumptions
  communication partner (QoS initiator and exclusions.

   The model controller)..............19
  5.6.2 Scalability in number of Section 3 allows deriving requirements from hand-offs..........................19
  5.6.3 Scalability in the
   scenarios presented number of interactions for setting up a
  reservation.......................................................19
  5.6.4 Scalability in the appendix number of state per entity (QoS initiators
  and QoS controllers)..............................................19
  5.6.5 Scalability in a coherent CPU use (end terminal and consistent
   manner. Requirements are grouped according intermediate nodes) 19
  5.6.6 Low latency in setup........................................19
  5.6.7 Allow for low bandwidth consumption for signaling protocol..19
  5.6.8 Ability to areas such as
   Architecture and design goals, Signaling Flows, Layering,
   Performance, Flexibility, Security and Mobility.

   QoS is a pretty large field with a lot of interaction with other
   protocols, mechanisms, applications etc. In constrain load on devices........................19
  5.6.9 Highest possible network utilization........................19
 5.7  Flexibility...................................................20
  5.7.1 Aggregation capability, including the following, some
   thoughts from an end-system point of view capability to select and from a network point
  change the level of view.

   End-system perspective: In future mobile terminals, aggregation...................................20
  5.7.2 Flexibility in the support placement of
   adaptive applications is more and more important. Adaptively can be
   seen as an important technique to react to the QoS violations that may
   occur frequently, e.g., initiator...........20
  5.7.3 Flexibility in wireless environments due to changed

   Brunner, et al.          Informational                    [Page 2]
               Requirements for the initiation of re-negotiation (QoS change
  requests).........................................................20
  5.7.4 Uni / bi-directional reservation............................20
 5.8  Security......................................................20
  5.8.1 Authentication of signaling requests........................20
  5.8.2 Resource Authorization......................................21
  5.8.3 Integrity protection........................................21
  5.8.4 Replay protection...........................................21
  5.8.5 Hop-by-hop security.........................................21
  5.8.6 Identity confidentiality and location privacy...............21
  5.8.7 Denial-of-service attacks...................................22
  5.8.8 Confidentiality of signaling messages.......................22
  5.8.9 Ownership of a reservation..................................22
  5.8.10 Hooks with Authentication and Key Agreement protocols......22
 5.9  Mobility......................................................23
  5.9.1 Allow efficient QoS Signaling Protocols       May 2002

   environmental re-establishment after handover.........23
 5.10  Interworking with other protocols and network conditions. This may result in degraded
   end-to-end performance. It is then up to adaptive applications techniques............23
  5.10.1 Interworking with IP tunneling.............................23
  5.10.2 The solution should not constrain either to
   react IPv4 or IPv6...23
  5.10.3 Independence from charging model...........................24
  5.10.4 Hooks for AAA protocols....................................24
  5.10.5 Interworking with seamless handoff protocols...............24
  5.10.6 Interworking with non-traditional routing..................24
 5.11  Operational.................................................24
  5.11.1 Ability to the new resource availability. Therefore, it is essential assign transport quality to define interoperability between media-, mobility- signaling messages..24
  5.11.2 Graceful fail over.........................................24
6 The MUSTs, SHOULDs, and MAYs......................................24
7 References........................................................30
8 Acknowledgments...................................................30
               Requirements for QoS
   management. While most likely mobile terminals cannot assume, that
   explicit Signaling Protocols      July 2002

9 Author's Addresses................................................31
10  Appendix: Scenarios/Use cases...................................31
 10.1  Scenario: Terminal Mobility.................................32
 10.2  Scenario: Cellular Networks.................................34
 10.3  Scenario: UMTS access.......................................34
 10.4  Scenario: Wired part of wireless network....................36
 10.5  Scenario: Session Mobility..................................38
 10.6  Scenario: QoS reservation schemes are available, some reservations/negotiation from access networks
   nevertheless may offer such capabilities. Applications subscribed to
   an end-system core
 network............................................................38
 10.7  Scenario: QoS management system should be supported with a
   dedicated reservation/negotiation over administrative
 boundaries.........................................................39
 10.8  Scenario: QoS API to set-up, control signaling between PSTN gateways and adapt media sessions.

   Network perspective: backbone
 routers............................................................39
 10.9  Scenario: PSTN trunking gateway.............................41
 10.10 Scenario: Application request end-to-end QoS enabled IP networks are expected to handle
   two path from the
 network............................................................42
 10.11 Scenario: QOS for Virtual Private Networks..................42

1  Introduction

   This document defines requirements for signaling QoS across
   different kinds network environments. It does not list any problems of
   existing QoS granularities: per-flow signaling protocols such as RSVP.

   In order to derive requirements for QoS and per-
   trunk/per-class QoS. Per-flow signaling it is necessary to
   first have a clear idea of the scope within which they are
   applicable.
   We describe a set of QoS might be needed signaling scenarios and use cases in access networks the
   Appendix of that document. These scenarios derive from a variety of
   backgrounds, and may there be subject help obtain a clearer picture of QoS signaling. However, what is 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 out
   of scope of the network. In NSIS work. They illustrate the
   access network problem of QoS
   signaling is an interaction between end systems
   and access routers or from various perspectives (end-system, access network QoS managers (in network,
   core network) and for various areas (fixed line, mobile, wireless
   environments). As the following NSIS work becomes more clearly defined,
   scenarios will be added or dropped, or defined in more detail.

   Based on these scenarios, we call them QoS initiator and QoS controller). In are able to define the core network QoS signaling refers to trunks or classes
   problem on a more abstract level. In Section 3, we thus present a
   simple conceptual model of traffic between core
   and edge systems or between peering core systems. Please note that
   this does not exclude the transport of per-flow QoS signaling through
   core networks.

   It is clear from these descriptions that problem. Additionally,
   we describe the subject of entities involved in QoS is
   uniquely complex signaling and any investigation could potentially have a very
   broad scope - so broad that it is a challenge to focus work on an
   area which could lead to a concrete typical
   signaling paths. In Section 4 we list assumptions and useful result. This is our
   motivation for considering a set exclusions.

   The model of use cases, which map out Section 3 allows deriving requirements from the
   domain of application that we want to address. It is also
   scenarios presented in the
   motivation for defining appendix in a problem structure, which allows us to
   state the boundaries of what types of functionality to consider, coherent and
   to list background assumptions.

   There consistent
   manner. Requirements are several grouped according to areas such as
   Architecture and design goals, Signaling Flows, Layering,
   Performance, Flexibility, Security and Mobility.

   QoS is a pretty large field with a lot of the requirements related to networking
   aspects which are incomplete, for example, interaction with host and
   site multi-homing, use other
   protocols, mechanisms, applications etc. In the following, some
               Requirements for QoS Signaling Protocols      July 2002

   thoughts from an end-system point of anycast services, view and so on. These issues
   should be considered in any future requirement analysis work.

2  Terminology from a network point
   of view.

   End-system perspective: In future mobile terminals, the area of Qualiaty support of Service (QoS) it
   adaptive applications is quite difficult more and more important. Adaptively can be
   seen as an exercise for its own important technique to define terminology. Nevertheless, we
   tried react to list the most often used terms QoS violations that may
   occur frequently, e.g., in the draft and tried to
   explain them. However, don't be wireless environments due to religious about it, they are not
   meant to prescribe any thing 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 draft.

   Aggregate: a group of flows, usually with similar new resource availability. Therefore, it is essential
   to define interoperability between media-, mobility- and QoS requirements,
   which can
   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 treated together as a whole supported with a single overall
   dedicated QoS
   requirement for signaling and provisioning. Aggregates API to set-up, control and flows can
   be further aggregated together.

   Brunner, et al.          Informational                    [Page 3]
               Requirements for adapt media sessions.

   Network perspective: QoS Signaling Protocols       May 2002

   [QoS] Domain: a collection 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 under the same administrative
   control
   and grouped together for administrative purposes.

   Egress point: the router via which a path exits a domain/subdomain.

   End Host: may there be subject of QoS signaling. However, in the end system core
   network only per-trunk or host, per-class QoS can be considered for whose flows
   scalability reasons. Therefore there might be different requirements
   on QoS is being
   requested and provisioned.

   End-to-End QoS: signaling applying to different parts of the QoS delivered by network. In the
   access network QoS signaling is an interaction between two
   communicating end hosts.  End-to-end QoS co-ordinates systems
   and enforces
   predefined traffic management policies across multiple access routers or access network
   entities and administrative domains.

   Edge-to-edge QoS: QoS within an administrative domain that connects
   to other networks rather than hosts or end systems.

   Flow: a traffic stream (sequence of IP packets between two end
   systems) for which a specific level of QoS is to be provided. The
   flow can be unicast (uni- or bi-directional) or multicast.

   Flow Administration: represents the policy associated with how flows
   should be treated in the network, for example whether and how the
   flows should be aggregated.  It may consist of both user and local
   network management information.

   Higher Layers: managers (in the higher layer (transport protocol following
   we call them QoS initiator and application)
   functions that request QoS from controller). In the core network layer. The request might
   be a trigger generated within the end system,
   QoS signaling refers to trunks or the trigger might
   be provided by some entity within the network (e.g. application
   proxy classes of traffic between core
   and edge systems or policy server).

   Indication: feedback between peering core systems. Please note that
   this does not exclude the transport of per-flow signaling through
   core networks.

   It is clear from QoS provisioning to indicate these descriptions that the current subject of QoS being provided to a flow or aggregate, is
   uniquely complex and whether any
   violations investigation could potentially have been detected by the QoS technology being used
   within the local domain/subdomain.

   Ingress point: the router via a very
   broad scope - so broad that it is a challenge to focus work on an
   area, which could lead to a path enters concrete and useful result. This is our
   motivation for considering a
   domain/subdomain.

   Mapping: set of use cases, which map out the act
   domain of transforming parameters from QSCs to values application that
   are meaningful we want to address. It is also the actual QoS technology in use in the
   domain/subdomain.

   Path: the route across the networks taken by
   motivation for defining a flow or aggregate,
   i.e. problem structure, which domains/subdomains it passes through allows us to
   state the boundaries of what types of functionality to consider, and
   to list background assumptions.

   There are several areas of the
   egress/ingress points requirements related to networking
   aspects which are incomplete, for each.

   Path segment: example, interaction with host and
   site multi-homing, use of anycast services, and so on. These issues
   should be considered in any future requirement analysis work.

2  Terminology

   In the segment area of a path within a single
   domain/subdomain.

   QoS Administration Function: a generic term Qualiaty of Service (QoS) it is quite difficult and
   an exercise for all functions
   associated with admission control, policy control, traffic
   engineering etc.

   Brunner, et al.          Informational                    [Page 4] its own to define terminology. Nevertheless, we
   tried to list the most often used terms in the draft and tried to
   explain them. However, don't be to religious about it, they are not
   meant to prescribe any thing in the draft.

               Requirements for QoS Signaling Protocols       May      July 2002

   Aggregate: a group of flows, usually with similar QoS Control Information: the information the governs the QoS
   treatment to requirements,
   which can be applied to treated together as a flow or aggregate, including the QSC,
   flow administration, and any associated security or accounting
   information. whole with a single overall QoS Controller: this is responsible
   requirement 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 provisioning. Aggregates and
   signaling them to the network as well as invoking local QoS
   provisioning mechanisms.  This flows can
   be located in the end system, but
   may reside elsewhere in network.

   QoS Provisioning: the act of actually allocating resources to further aggregated together.

   [QoS] Domain: a flow
   or aggregate collection of flows, may include mechanisms such as LSP initiation networks under the same administrative
   control and grouped together for MPLS, packet scheduler configuration within administrative purposes.

   Egress point: the router via which a router, and so on.
   The mechanisms depend on path exits a domain/subdomain.

   End Host: the overall end system or host, for whose flows QoS technology is being used
   within
   requested and provisioned.

   End-to-End QoS: the [sub]domain. QoS Service Classes (QSC): specify delivered by 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, two
   communicating 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, hosts.  End-to-end QoS initiators co-ordinates and QoS controllers
   about current QoS levels, enforces
   predefined traffic management policies across multiple network
   entities and administrative domains.

   Edge-to-edge QoS: QoS querying facilities.

   [QoS] Subdomain: a network within an administrative domain using a
   uniform technology/QoS provisioning function that connects
   to provision resources.

   QoS Technology: other networks rather than hosts or end systems.

   Flow: a generic term traffic stream (sequence of IP packets between two end
   systems) for which a set specific level of protocols, standards QoS is to be provided. The
   flow can be unicast (uni- or bi-directional) or multicast.

   Flow Administration: represents the policy associated with how flows
   should be treated in the network, for example whether and
   mechanisms how the
   flows should be aggregated.  It may consist of both user and local
   network management information.

   Higher Layers: the higher layer (transport protocol and application)
   functions that can request QoS from the network layer. The request might
   be used within a QoS domain/subdomain to manage trigger generated within the QoS provided to flows end system, or aggregates that traverse the domain.
   Examples trigger might include MPLS, DiffServ, and so on. A QoS technology
   is associated with certain
   be provided by some entity within the network (e.g. application
   proxy or policy server).

   Indication: feedback from QoS provisioning techniques.

   QoS Violation: occurs when to indicate the current
   QoS applied being provided to a flow or aggregate
   does not meet the requested aggregate, and negotiated whether any
   violations have been detected by the QoS agreed for it.

   Resource: something of value in technology being used
   within the local domain/subdomain.

   Ingress point: the router via which a network infrastructure path enters a
   domain/subdomain.

   Mapping: the act of transforming parameters from QSCs to which
   rules or policy criteria values that
   are first applied before access is granted.
   Examples of resources include meaningful to the buffers actual QoS technology in use in the
   domain/subdomain.

   Path: the route across the networks taken by a router and bandwidth
   on an interface.

   Brunner, et al.          Informational                    [Page 5] flow or aggregate,
   i.e. which domains/subdomains it passes through and the
   egress/ingress points for each.

               Requirements for QoS Signaling Protocols       May      July 2002

   Resource Allocation: part of a resource that has been dedicated for

   Path segment: the use segment of a particular traffic type for path within a period of time through
   the application of policies.

   Sender-initiated QoS signaling protocol: A sender-initiated single
   domain/subdomain.

   QoS
   signaling protocol is Administration Function: a protocol (see e.g., YESSIR [8], RMD [10])
   where generic term for all functions
   associated with admission control, policy control, traffic
   engineering etc.

   QoS Control Information: the QI initiates information the signaling on behalf of governs the sender of QoS
   treatment to be applied to a flow or aggregate, including the
   data. What QSC,
   flow administration, and any associated security or accounting
   information.

   QoS Controller: this means is that admission control and resource
   allocation functions are processed from the data sender towards responsible for interpreting the
   data receiver. However, signaling
   carrying the triggering instance is not specified.

   Receiver-initiated user QoS signalling protocol: A receiver-initiated
   protocol, (see e.g., RSVP [9]) is a protocol where parameters, optionally inserting/modifying the
   parameters according to local network QoS
   reservations are initiated by the management policy, and
   invoking local QoS provisioning mechanisms. Note that q QoS Reiceiver
   controller might have very different functionality depending on behalf of the
   receiver of
   where in the user data. What this means is that admission control network and resource allocation functions in what environment they are processed from the data
   receiver back towards the data sender. However, the triggering
   instance implemented.

   QoS Initiator: this is not specified.

3  Problem Statement and Scope

   We provide in the following a preliminary architectural picture as a
   basis responsible for discussion. We will refer to it in generating the following
   requirement section.

   A set of issues QSCs for
   traffic flow(s) based on user or application requirements and problems
   signaling them to be solved has been given at a top
   level by the use cases/scenarios of the appendix. However, network as well as invoking local QoS
   provisioning mechanisms.  This can be located in the
   problem of end system, but
   may reside elsewhere in network.

   QoS has an extremely wide scope and there is a great deal Provisioning: the act of work already done actually allocating resources to provide different components a flow
   or aggregate of the
   solution, flows, may include mechanisms such as QoS technologies LSP initiation
   for example. A basic goal should
   be to re-use these wherever possible, MPLS, packet scheduler configuration within a router, and to focus requirements work
   at an early stage so on.
   The mechanisms depend on those areas where a new solution is needed
   (e.g. an especially simple one). We also try to avoid defining
   requirements related to internal implementation aspects.

   In this section, we present a simple conceptual model of the overall QoS problem in order to identify the applicability to NSIS of
   requirements derived from the use cases, and to clarify technology being used
   within the scope of [sub]domain.

   QoS Service Classes (QSC): specify the work, including any open issues. This model also identifies
   further sources of QoS requirements from external interactions with
   other parts of an overall a traffic
   flow or aggregate.  Can be further sub-divided into user specific
   and network related parameters

   QoS solution, clarifies the terminology
   used, Signaling: a way to communicate QSCs and allows the statement of design goals about the nature of
   the solution (see section 5).

   Note that this model is intended not QoS management
   information between hosts, end systems and network devices etc.  May
   include request and response messages to constrain the technical
   approach taken subsequently, simply facilitate negotiation/re-
   negotiation, asynchronous feedback messages (not delivered upon
   request) to allow concrete phrasing of
   requirements (e.g. requirements inform End Hosts, QoS initiators and QoS controllers
   about placement of the current QoS
   initiator, or ability to 'drive' particular levels, and QoS technologies.)

   Roughly, the scope of NSIS is assumed querying facilities.

   [QoS] Subdomain: a network within an administrative domain using a
   uniform technology/QoS provisioning function to be the interaction between
   the provision resources.

   QoS initiator Technology: a generic term for a set of protocols, standards and
   mechanisms that can be used within a QoS controller(s), including selection of
   signaling protocols domain/subdomain to carry manage
   the QoS information, provided to flows or aggregates that traverse the domain.
   Examples might include MPLS, DiffServ, and so on. A QoS technology
   is associated with certain QoS provisioning techniques.

   QoS Violation: occurs when the
   syntax/semantics of QoS applied to a flow or aggregate
   does not meet the information that is exchanged. Further

   Brunner, et al.          Informational                    [Page 6] requested and negotiated QoS agreed for it.

               Requirements for QoS Signaling Protocols       May      July 2002

   statements on assumptions/exclusions are given

   Resource: something of value in a network infrastructure to which
   rules or policy criteria are first applied before access is granted.
   Examples of resources include the next Section.
   The main elements are:

   1. Something buffers in a router and bandwidth
   on an interface.

   Resource Allocation: part of a resource that starts the request has been dedicated for QoS,
   the QoS Initiator.

   This might be in use of a particular traffic type for a period of time through
   the end system or within some other part application of policies.

   Sender-initiated QoS signaling protocol: A sender-initiated QoS
   signaling protocol is a protocol (see e.g., YESSIR [8], RMD [10])
   where the QI initiates the signaling on behalf of the
   network. The distinguishing feature sender of the QoS initiator
   data. What this means is that it
   acts on triggers coming (directly or indirectly) admission control and resource
   allocation functions are processed from the higher
   layers in data sender towards the end systems. It needs to map
   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 requested
   reservations are initiated by
   them, the QoS Receiver on behalf of the
   receiver of the user data. What this means is that admission control
   and also provides feedback information 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

   We provide in the following a preliminary architectural picture as a
   basis for discussion. We will refer to it in the higher layers
   which might following
   requirement section.

   A set of issues and problems to be used solved has been given at a top
   level by transport layer rate management or adaptive
   applications.

   2. Something that assists in managing QoS further along the path, use cases/scenarios of the QoS controller.

   The QoS controller does not interact with higher layers, but
   interacts with appendix. However, the
   problem of QoS initiator has an extremely wide scope and possibly more QoS controllers
   on the path, edge to edge or possibly end to end.

   3. The QoS initiator and controller(s) interact with each other,
   path segment by path segment. This interaction involves the exchange
   of data (QoS control information) over some signaling protocol.

   4. The path segment traverses an underlying network (QoS domain or
   subdomain) covering one or more IP hops. The underlying network uses
   some local QoS technology. This QoS technology has to be provisioned
   appropriately for the flow, and this there is a great deal
   of work already done by to provide different components of the
   solution, such as QoS initiator
   and controller(s), mapping their QoS control information technologies for example. A basic goal should
   be to
   technology-related QoS parameters re-use these wherever possible, and receiving indications about
   success or failure in response.

   Now concentrating more on the overall end to end (multiple QoS
   domains) aspects, in particular:

   1. The QoS initiator need not be located focus requirements work
   at an end system, and early stage on those areas where a new solution is needed
   (e.g. an especially simple one). We also try to avoid defining
   requirements related to internal implementation aspects.

   In this section, we present a simple conceptual model of the overall
   QoS controllers are not assumed problem in order to be located on identify the flow's data
   path. However, they must be able applicability to identify NSIS of
   requirements derived from the ingress use cases, and egress
   points for the flow path as it traverses the domain/subdomain. Any
   signaling protocol must be able to find clarify the appropriate QoS
   controller and carry this ingress/egress point information.

   2. We see scope of
   the network at work, including any open issues. This model also identifies
   further sources of requirements from external interactions with
   other parts of an overall QoS solution, clarifies the level terminology
   used, and allows the statement of domains/subdomains rather than
   individual routers (except in design goals about the special case that nature of
   the domain
   contains one link). Domains are assumed to be administrative
   entities, so security requirements apply solution (see section 5).

   Note that this model is intended not to constrain the signaling between
   them. Subdomains are introduced technical
   approach taken subsequently, simply to allow concrete phrasing of
   requirements (e.g. requirements about placement of the fact a given QoS
   provisioning mechanism may only be used within a part of a domain,
   typically for a
   initiator, or ability to 'drive' particular subnetwork technology boundary.
   Aggregation can also take place at subdomain boundaries.

   3. Any domain may contain QoS administration functions (e.g. to do
   with traffic engineering, admission control, policy and so on).

   Brunner, et al.          Informational                    [Page 7] technologies.)
               Requirements for QoS Signaling Protocols       May      July 2002

   These are

   Roughly, the scope of NSIS is assumed to interact with be the interaction between
   the QoS initiator and controllers
   (and end systems) using standard mechanisms.

   4. The placement QoS controller(s), including selection of
   signaling protocols to carry the QoS initiators information, and QoS controllers the
   syntax/semantics of the information that is not
   fixed. Actually, there are two extreme cases:

   - Each router exchanged. Further
   statements on assumptions/exclusions are given in the data path implements a QoS controller and QoS
   initiator.

   - Only next Section.
   The main elements are:

   1. Something that starts the request for QoS, the end systems incorporate a QoS controller and QoS
   initiator, which means Initiator.

   This might be in the end systems need to have QoS provisioning
   capabilities. However this case does not seam to be realistic but
   shows system or within some other part of the flexible allocation
   network. The distinguishing feature of the controller and QoS initiator
   function.

4  Assumptions and Exclusions

4.1 Assumptions and Non-Assumptions

   1. The NSIS signaling could run end to end, end to edge, or edge to
   edge, or network-to-network ((between providers), depending is that it
   acts on what
   point triggers coming (directly or indirectly) from the higher
   layers in the network acts as end systems. It needs to map the initiator, QoS requested by
   them, and how far towards also provides feedback information to the
   other end of higher layers,
   which might be used by transport layer rate management or adaptive
   applications.

   2. Something that assists in managing QoS further along the network path,
   the signaling propagates. Although QoS controller.

   The QoS controller does not interact with higher layers, but
   interacts with the
   figures show QoS initiator and possibly more QoS controllers at a very limited number of locations
   in
   on the path, edge to edge or possibly end to end.

   3. The QoS initiator and controller(s) interact with each other,
   path segment by path segment. This interaction involves the exchange
   of data (QoS control information) over some signaling protocol.

   4. The path segment traverses an underlying network (e.g. at (QoS domain or subdomain borders, or even
   controlling a complete domain), this is only
   subdomain) covering one possible case. In
   general, we could expect or more IP hops. The underlying network uses
   some local QoS controllers technology. This QoS technology has to become more 'dense'
   towards be provisioned
   appropriately for the edges of flow, and the network, but this is not a requirement. An
   overprovisioned domain might contain no QoS controllers at all (and
   be NSIS transparent); at the other extreme, initiator does this and
   controller(s), mapping their QoS controllers might be
   placed at every router. In the latter case, control information to technology-
   related QoS provisioning can be
   carried out in a local implementation-dependent way without further
   signalling, whereas parameters and receiving indications about success or
   failure in response.

   Now concentrating more on the case of remote QoS controllers, a
   provisioning protocol might be needed to control the routers along
   the path. This provisioning protocol is then independent of the overall end to end NSIS signalling.

   2. We do not consider 'pure' end-to-end (multiple QoS signaling that is
   domains) aspects, in particular:

   1. The QoS initiator need not
   interpreted anywhere within the network. Such signaling is be located at an
   application-layer issue end system, and IETF protocols such as SIP etc. can be
   used.

   3. Where the signaling does cover several
   QoS domains or subdomains,
   we do not exclude that different signaling protocols controllers are used in
   each path segment. We only place requirements not assumed to be located on the universality of
   the QoS control information that is being transported. (The goals
   here would flow's data
   path. However, they must be able to allow identify the use of ingress and egress
   points for the flow path as it traverses the domain/subdomain. Any
   signaling protocols which are
   matched protocol must be able to find the characteristics of appropriate QoS
   controller and carry this ingress/egress point information.

   2. We see the portion network at the level of domains/subdomains rather than
   individual routers (except in the network being
   traversed.) Note special case that the outcome of NSIS work might result in
   various protocols or various flavors of the same protocol. This
   implies domain
   contains one link). Domains are assumed to be administrative
   entities, so security requirements apply to the need for signaling between
   them. Subdomains are introduced to allow the translation of information into fact a given QoS domain
   specific format as well.

   Brunner, et al.          Informational                    [Page 8]
   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.

               Requirements for QoS Signaling Protocols       May      July 2002

   4. We assume that

   3. Any domain may contain QoS administration functions (e.g. to do
   with traffic engineering, admission control, policy and so on).
   These are assumed to interact with the service definitions a QoS initiator can ask
   for are known in advance and controllers
   (and end systems) using standard mechanisms.

   4. The placement of the signaling protocol running. Service
   definition includes QoS parameters, life-time of initiators and QoS guarantee etc.
   There controllers is not
   fixed. Actually, there are many ways a service requester get to know about it. There
   might be standardized services, two extreme cases:

   - Each router on the definition can be negotiated
   together with data path implements a contract, QoS controller and QoS
   initiator.

   - Only the service definition is published at end systems incorporate a
   Web-page, etc.

   5. We assume that there are means for QoS controller and QoS
   initiator, which mean the discovery of NSIS entities
   in order end systems need to know have QoS provisioning
   capabilities. However this case does not seam to be realistic but
   shows the signaling peers (solutions include static
   configuration, automatically discovered, or implicitly runs over the
   right nodes, etc.)

4.2 Exclusions

   1. Development flexible allocation of specific mechanisms and algorithms for application
   and transport layer adaptation are not considered, nor are the
   protocols that would support it.

   2. Specific mechanisms (APIs controller and so on) for interaction between
   transport/applications initiator
   function.

4  Assumptions and the network layer are not considered,
   except Exclusions

4.1 Assumptions and Non-Assumptions

   1. The NSIS signaling could run end to clarify the requirements end, end to edge, or edge to
   edge, or network-to-network ((between providers), depending on what
   point in the negotiation capabilities network acts as the initiator, and information semantics that would be needed how far towards the
   other end of the network the signaling
   protocol. The same applies to application adaptation mechanisms.

   3. Specific mechanisms for propagates. Although the
   figures show QoS provisioning within controllers at a
   domain/subdomain are not considered. It should be very limited number of locations
   in the network (e.g. at domain or subdomain borders, or even
   controlling a complete domain), this is only one possible case. In
   general, we could expect QoS controllers to
   exploit these mechanisms optimally within become more 'dense'
   towards the end to end context.
   Consideration edges of how to do the network, but this is not a requirement. An
   overprovisioned domain might generate new requirements for contain no QoS controllers at all (and
   be NSIS however. For example, transparent); at the information needed by an other extreme, QoS
   controller to manage a radio subnetwork needs to controllers might be provided by the
   NSIS solution.

   4. Specific mechanisms (APIs and so on) for interaction between
   placed at every router. In the
   network layer and underlying latter case, QoS provisioning mechanisms are not
   considered.

   5. Interaction with QoS administration capabilities is not
   considered. Standard protocols should can be used for this (e.g. COPS).
   This may imply requirements for
   carried out in a local implementation-dependent way without further
   signaling, whereas in the sort case of information that should
   be exchanged between the NSIS network remote QoS entities.

   6. Security issues related controllers, a
   provisioning protocol might be needed to multicasting are outside control the scope routers along
   the path. This provisioning protocol is then independent of the end
   to end NSIS signaling.

   2. We do not consider 'pure' end-to-end QoS signaling protocol.

   Since multicasting that is currently not
   interpreted anywhere within the network. Such signaling is an
   application-layer issue for and IETF protocols such as SIP etc. can be
   used.

   3. Where the signaling does cover several QoS protocol,
   security issues related to multicast domains or subdomains,
   we do not exclude that different signaling protocols are outside used in
   each path segment. We only place requirements on the scope.
   Multicast security may additionally be an application issue universality of
   the QoS control information that is
   also outside being transported. (The goals
   here would be to allow the scope use of signaling protocols, which are
   matched to the QoS protocol.

   7. Protection characteristics of non-QoS signaling messages is outside the scope portion of the QoS protocol

   Brunner, et al.          Informational                    [Page 9] network being
   traversed.) Note that the outcome of NSIS work might result in
   various protocols or various flavors of the same protocol. This
               Requirements for QoS Signaling Protocols       May      July 2002

   Security protection of data messages transmitted along

   implies the
   established QoS path is outside need for the scope translation of the information into QoS protocol. These
   security properties are likely to be application domain
   specific and may be
   provided by the corresponding application layer protocol.

   8. Service definitions and QoS classes are out of scope. Together
   with format as well.

   4. We assume that the service definition any definition of service specific
   parameters definitions a QoS initiator can ask
   for are not considered known in this draft. Only advance of the base NSIS signaling protocol for transporting the QoS/service information running. Service
   definition includes QoS parameters, lifetime of QoS guarantee etc.
   There are
   handled.

   9. Similarly, specific methods, protocols, and many ways service requesters get to express QoS
   information in know about it. There
   might be standardized services, the Application/Session level definition can be negotiated
   together with a contract, the service definition is published at a
   Web page, etc.

   5. We assume that there are not considered
   (e.g., SDP, SIP, RTSP, etc.).

   10. The specification means for the discovery of any extensions needed NSIS entities
   in order to signal QoS
   information via application level protocols (e.g. SDP(ng)), and know the
   mapping on NSIS information are considered outside of signaling peers (solutions include static
   configuration, automatically discovered, or implicitly runs over the scope
   right nodes, etc.) The discovery of the NSIS working group, as this work entities has security
   implications that need to be addressed properly. These implications
   largely depend on the chosen protocol. For some security mechanisms
   (i.e. Kerberos, pre-shared secret) it is in required to know the direct scope
   identity of the other
   IETF working groups (e.g. MMUSIC).

5  Requirements

   This section defines more detailed requirements for a QoS signaling
   solution, derived from consideration of entity. Hence the use cases/scenarios, and
   respecting discovery mechanism may
   provide means to learn this identity, which is then later used to
   retrieve the framework, scoping assumptions, required keys and terminology
   considered earlier. The requirements are in subsections, grouped
   roughly according to general technical aspects: architecture parameters.

   6. NSIS assumes to operate with networks using standard ("normal")
   L3 routing.

4.2 Exclusions

   1. Development of specific mechanisms and
   design goals, topology issues, QoS parameters, performance,
   security, information, algorithms for application
   and flexibility.

   Two general (and potentially contradictory) goals transport layer adaptation are not considered, nor are the
   protocols that would support it.

   2. Specific mechanisms (APIs and so on) for interaction between
   transport/applications and the solution network layer are not considered,
   except to clarify the requirements on the negotiation capabilities
   and information semantics that it should would be applicable in a very wide range needed of scenarios,
   and at the signaling
   protocol. The same time lightweight in implementation complexity and
   resource requirements in nodes. One approach applies to this is that the
   solution could deal with certain requirements via modular components
   or capabilities, which application adaptation mechanisms.

   3. Specific mechanisms for QoS provisioning within a
   domain/subdomain are optional not considered. It should be possible to implement in individual
   nodes.

   Some of
   exploit these mechanisms optimally within the end to end context.
   Consideration of how to do this might generate new requirements are technically contradictory. Depending on for
   NSIS however. For example, the scenarios information needed by a solution applies to, one or the other requirement is
   applicable.

   Find in Section 6 the MUSTs, SHOULDs, and MAYs

5.1 Architecture and Design Goals

   This section contains requirements related QoS
   controller to desirable overall
   characteristics of manage a solution, e.g. enabling flexibility, or
   independence of parts of radio subnetwork needs to be provided by the framework.

5.1.1 Applicability
   NSIS solution.

   4. Specific mechanisms (APIs and so on) for different interaction between the
   network layer and underlying QoS technologies.

   Brunner, et al.          Informational                   [Page 10] provisioning mechanisms are not
   considered.

   5. Interaction with QoS administration capabilities is not
   considered. Standard protocols should be used for this (e.g. COPS).
   This may imply requirements for the sort of information that should
   be exchanged between the NSIS network QoS entities.

               Requirements for QoS Signaling Protocols       May      July 2002

   The

   6. Security implications related to multicasting are outside the
   scope of the QoS signaling protocol must work with various QoS technologies.
   The information exchanged over the protocol.

   7. Protection of non-QoS signaling protocol must be in
   such detail and quantity that it messages is useful for various QoS
   technologies.

5.1.2 Resource availability information on request

   In some scenarios, e.g., outside the mobile terminal scenario, it is
   required to query, whether resources are available, without
   performing a reservation on scope of
   the resource. One solution might be QoS protocol

   The protection of non-signaling messages (including data traffic
   following a
   feedback mechanism based on which reservation) is not directly considered by a signaling
   protocol. The protection of data messages transmitted along the QoS inferred handover can take
   place.

5.1.3 Modularity

   A modular design allows for more lightweight implementations, if
   fewer features are needed. Mutually exclusive solutions are
   supported. Examples for modularity:

   - Work over any kind
   provisioned path is outside the scope of network (narrowband / broadband, error-prone
   / reliable...) - This implies low bandwidth a signaling protocol.
   Regarding data traffic there is an interaction with accounting
   (metering) and redundant
   information must edge routers might require packets to be supported if necessary.

   - In case integrity
   protected to be able to securely assign incoming data traffic to a
   particular user.

   Additionally there might be an interaction with IPsec protected
   traffic experiencing QoS requirements are soft (e.g. banking transactions,
   gaming), fast and lightweight signaling (e.g., not more than one
   round-trip time)

   - Uni- and bi-directional reservations are possible

5.1.4 Decoupling of protocol treatment and information it is carrying

   The signaling protocol(s) used must be clearly separated from the
   QoS control information being transported. This provides for the
   independent development of these two aspects established state created
   due to signaling. One example of such an interaction is the solution, different
   flow identification with and
   allows for this control information without IPsec protection.

   Many security properties are likely to be carried within other
   protocols, including application layer ones, existing ones or those
   being developed in the future. The gained flexibility in specific and
   may be provided by the
   information transported allows for corresponding application layer protocol.

   8. Service definitions and QoS classes are out of scope. Together
   with the applicability service definition any definition of service specific
   parameters are not considered in this draft. Only the same base NSIS
   signaling protocol in various scenarios.
   However, note that for transporting the QoS/service information carried needs are
   handled.

   9. Similarly, specific methods, protocols, and ways to be express QoS
   information in the same.
   Otherwise interoperability is difficult to achieve.

5.1.5 Reuse Application/Session level are not considered
   (e.g., SDP, SIP, RTSP, etc.).

   10. The specification of existing QoS provisioning

   Reuse existing any extensions needed to signal QoS functions and
   information via application level protocols for QoS provisioning
   within a domain/subdomain unchanged. (Motivation: 'Don't re-invent
   the wheel'.)

5.1.6 Independence of signaling (e.g. SDP(ng)), and provisioning paradigm

   The QoS signaling should be independent of the paradigm and
   mechanism
   mapping on NSIS information are considered outside of QoS provisioning. The independence allows for using the scope of
   NSIS protocol together with various QoS technologies.

   Brunner, et al.          Informational                   [Page 11] working group, as this work is in the direct scope of other
   IETF working groups (e.g. MMUSIC).

   11. Handoff decision and trigger sources: An NSIS protocol is not
   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
   before a handoff happened, an NSIS protocol might be used for
   signaling for QoS again. However, NSIS must interwork with several
   protocols for mobility management.

   12. QoS monitoring is out of scope. It is heavily dependent on the
   type of the application and or transport service, and in what
   scenario it is used.

5  Requirements
               Requirements for QoS Signaling Protocols       May      July 2002

5.2 Signaling Flows

   This section contains defines more detailed requirements related to the possible for a QoS signaling
   flows that should be supported, e.g. over what parts
   solution, derived from consideration of the flow
   path, between what entities (end-systems, routers, middleboxes,
   management systems), in which direction.

5.2.1 Free placement of QoS Initiator use cases/scenarios, and QoS Controllers functions
   respecting the framework, scoping assumptions, and terminology
   considered earlier. The protocol(s) must work requirements are in various scenarios such as host-to-
   network-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 the entry subsections, grouped
   roughly according to the network general technical aspects: architecture and vice versa), network-to-
   network (e.g., between providers).

   Placing the
   design goals, topology issues, QoS controller parameters, performance,
   security, information, and initiator functions at different
   locations allows flexibility.

   Two general (and potentially contradictory) goals for various scenarios to work with the same or
   similar protocols.

5.2.2 No constraint of the QoS signaling and QoS Controllers to solution
   are that it should be applicable in
     the data path.

   There is a set very wide range of scenarios, where QoS signaling is not on
   and at the data
   path. The QoS Controller being same time lightweight in the data path is one extreme case implementation complexity and useful
   resource requirements in certain cases.

   There are going nodes. One approach to be cases where a centralized entity will take a
   decision about QoS requests. In this case, there's no question there is no need to have data follow that the signalling path.

   There
   solution could deal with certain requirements via modular components
   or capabilities, which are going optional to be cases wiout a centralized entity managing
   resources and implement in individual
   nodes.

   Some of the signaling will be used as requirements are technically contradictory. Depending on
   the scenarios a tool for resource
   management. For various reasons (such as efficient use of expensive
   bandwidth), solution applies to, one will want to have fine-grained, fast, and very
   dynamic control of or the resources other requirement is
   applicable.

   Find in Section 6 the network. -

   There are going MUSTs, SHOULDs, and MAYs

5.1 Architecture and Design Goals

   This section contains requirements related to be cases where there will be neither signaling
   nor desirable overall
   characteristics of a centralized entity (overprovisioning). Nothing has to be done
   anyway.

   One can capture the requirement with the following wording: If one
   views solution, e.g. enabling flexibility, or
   independence of parts of the domain with a framework.

5.1.1 Applicability for different QoS technologies.

   The QoS technology as a virtual router then NSIS signaling used between those virtual routers protocol must follow the same
   path as the data.

   Routing work with various QoS technologies.
   The information exchanged over the signaling protocol along an independent path must be in
   such detail and quantity that it is desired
   by network operators/designers. Ideally, useful for various QoS
   technologies.

5.1.2 Resource availability information on request

   In some scenarios, e.g., the capability mobile terminal scenario, it is
   required to route the
   protocol along an independent path would give query, whether resources are available, without
   performing a reservation on the resource. One solution might be a
   feedback mechanism based on which a QoS inferred handover can take
   place.

5.1.3 Modularity

   A modular design allows for more lightweight implementations, if
   fewer features are needed. Mutually exclusive solutions are
   supported. Examples for modularity:

   - Work over any kind of network
   designer/operator the option to manage (narrowband / broadband, error-prone
   / reliable...) - This implies low bandwidth utilization through
   the topology.

   There are other possibilities as well. An NSIS protocol signaling and redundant
   information must accept
   all of these possibilities.

   Brunner, et al.          Informational                   [Page 12] be supported if necessary.

   - Uni- and bi-directional reservations are possible
               Requirements for QoS Signaling Protocols       May      July 2002

5.2.3 Concealment

   - Extensible in the future with different add-ons for certain
   environments or scenarios

5.1.4 Decoupling of topology protocol and technology information it is carrying

   The QoS protocol should allow hiding signaling protocol(s) used must be clearly separated from the internal structure of a
   QoS
   domain from end-nodes and from other networks. Hence an adversary
   should not be able to learn control information being transported. This provides for the internal structure
   independent development of a network with
   the help these two aspects of the QoS protocol.

   In various scenarios, topology solution, and
   allows for this control information should to be hidden for
   various reasons. From a business point of view, some administrations
   don't want to reveal carried within other
   protocols, including application layer ones, existing ones or those
   being developed in the topology and technology used.

5.2.4 Optional transparency future. The gained flexibility in the
   information transported allows for the applicability of QoS signaling the same
   protocol in various scenarios.
   However, note that the information carried needs to network

   It should be possible that the same.
   Otherwise interoperability is difficult to achieve.

5.1.5 Reuse of existing QoS signaling provisioning

   Reuse existing QoS functions and protocols for some flows traverse
   path segments transparently, i.e., without interpretation at QoS
   controllers within the network. An example would be a subdomain provisioning
   within a core network, which only interpreted signaling for
   aggregates established at the domain edge, with domain/subdomain unchanged. (Motivation: 'Don't re-invent
   the flow-related wheel'.)

5.1.6 Independence of signaling passing transparently through it.

5.3 Additional information beyond and provisioning paradigm

   The QoS signaling should be independent of QoS information

   This section contains the desired signaling (messages) for other
   purposes other than that for conveying QoS parameters.

5.3.1 Explicit release paradigm and
   mechanism of resources

   When a QoS reservation is no longer necessary, e.g. because the
   application terminates, or because a mobile host experienced a hand-
   off, it must be possible to explicitly release resources.

5.3.2 Possibility provisioning. The independence allows for automatic release of resources after failure

   When using the
   NSIS protocol together with various QoS Initiator goes down, the resources it requested technologies in various
   scenarios.

5.2 Signaling Flows

   This section contains requirements related to the
   network possible signaling
   flows that should be released, since they will no longer be necessary.

   After detection supported, e.g. over what parts of a failure in the network, any flow
   path, between what entities (end-systems, routers, middle boxes,
   management systems), in which direction.

5.2.1 Free placement of QoS
   controller/initiator Initiator and QoS Controllers functions

   The protocol must be able work in various scenarios such as host-to-network-
   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
   the entry to release a reservation it is
   involved in. For example, this may require signaling of the "Release
   after Failure" message upstream as well as downstream, or soft state
   timing out of reservations.

   Note that this might need network and vice versa), network-to-network (e.g.,
   between providers).

   Placing the QoS controller and initiator functions at different
   locations allows for various scenarios to work together with a notification
   mechanism.

5.3.3 Possibility for automatic re-setup of resources after recovery

   In case of a failure, the reservation can get setup again
   automatically. It enables sort same or
   similar protocols.

5.2.2 No constraint of a persistent reservation, if the QoS Initiator requests it. In scenarios where signaling and QoS Controllers to be in
     the reservations are

   Brunner, et al.          Informational                   [Page 13] data path.

               Requirements for QoS Signaling Protocols       May      July 2002

   on

   There is a longer time scale, this could make sense to reduce the set of scenarios, where QoS signaling load is not on the data
   path. The QoS Controller being in the data path is one extreme case of failure
   and recovery.

5.3.4 Prompt notification of QoS violation useful in case of error/failure certain cases.

   There are going to
     QoS Initiator and QoS Controllers

   QoS Controllers should be able to notify the cases where a centralized entity will take a
   decision about QoS Initiator, if requests. In this case, there is an error inside no need to have
   the network. There are two types of network
   errors:

   Recoverable errors: This type error can be locally repaired by data follow the
   network nodes. The network nodes do not have signaling path.

   There are going to notify the users of
   the error immediately. This is be cases without a condition when centralized entity managing
   resources and the danger signaling will be used as a tool for resource
   management. For various reasons (such as efficient use of
   degradation (or actual short term degradation) expensive
   bandwidth), one will want to have fine-grained, fast, and very
   dynamic control of the provided QoS
   was overcome by the network (QoS controller) itself.

   Unrecoverable errors: resources in the network nodes cannot handle this type of
   error, and have network.

   There are going to notify the users as soon as possible.

5.3.5 Feedback about success of request for QoS guarantees

   A request for QoS must be answered at least with yes or no. However,
   it might cases where there will be useful in case of neither signaling
   nor a negative answer centralized entity (overprovisioning). Nothing has to also get a
   description of what might be the QoS one done
   anyway.

   One can successfully request
   etc. So it might be useful to include an opaque element into capture the
   answer. The element heavily depends on requirement with the service requested.

5.3.6 Allow local following, different
   wording: If one views the domain with a QoS information exchange technology as a virtual
   router then NSIS signaling used between nodes of those virtual routers must
   follow the same
     administrative domain

   The QoS path as the data.

   Routing the 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, along an independent path is desired
   by network operators/designers. Ideally, the capability to route the
   protocol along an independent path would give the network
   designer/operator the option to manage bandwidth utilization through
   the topology.

   There are other possibilities as well. An NSIS QoS signalling protocol may carry
   identification must accept
   all of these possibilities.

5.2.3 Concealment of topology and technology information

   The QoS protocol should allow for hiding the internal structure of a
   QoS controllers located at domain from end-nodes and from other networks. Hence an
   adversary should not be able to learn the boundaries internal structure of a
   domain. However,
   network with the identification help of edge the QoS protocol.

   In various scenarios, topology information should not be visible hidden for
   various reasons. From a business point of view, some administrations
   don't want to reveal the end host (QoS initiator) topology and only applies within one technology used.

5.2.4 Optional transparency of QoS
   administrative domain.

5.4 Layering

   This section contains requirements related signaling to network

   It should be possible that the way the signaling
   being considered interacts with upper layer functions (users,
   applications, and QoS administration), and lower layer QoS
   technologies.

5.4.1 The signaling protocol and for some flows traverse
   path segments transparently, i.e., without interpretation at QoS control information should
   controllers within the network. An example would be
     application independent.

   Brunner, et al.          Informational                   [Page 14] a subdomain
   within a core network, which only interpreted signaling for
   aggregates established at the domain edge, with the flow-related
   signaling passing transparently through it.

               Requirements for QoS Signaling Protocols       May      July 2002

   However, opaque application information might get transported

   In other words, NSIS needs to work in the hierarchical scenarios, where
   big pipes/trunks are setup using NSIS signaling, but also flows
   which run within that big pipe/trunk are setup using NSIS.

5.3 Additional information beyond signaling message, without being handled in the network. Development
   and deployment of new applications should be possible without
   impacting the network infrastructure. Additionally, QoS protocols
   are expected to conform to the Internet principles.

5.5 QoS Control Information information

   This section contains requirements related to the QoS control
   information desired signaling (messages) for other
   purposes other than that needs to be exchanged.

5.5.1 Mutability information on parameters

   It should be possible for the initiator to control the mutability conveying QoS parameters.

5.3.1 Explicit release of resources

   When a QoS reservation is no longer necessary, e.g. because the QSC information. This prevents from being changed in
   application terminates, or because a non-
   recoverable way. The initiator should mobile host experienced a hand-
   off, it must be able to control what is
   requested end possible to end, without explicitly release resources. In general
   explicit release enhances the request being gradually mutated as
   it passes through a sequence of domains. This implies that in case overall network utilization.

5.3.2 Possibility for automatic release of changes made on resources after failure

   When the parameters, QoS Initiator goes down, the original resources it requested ones must
   still be available.

   Note that we do not require anything about particular QoS paramters
   being changed.

5.5.2 Possibility to add and remove local domain information

   It in the
   network should be possible for released, since they will no longer be necessary.

   After detection of a failure in the network, any QoS control functions to add and
   remove local scope elements. E.g., at the entrance
   controller/initiator must be able to release a QoS domain
   domain-specific information is added, which reservation it is used in
   involved in. For example, this domain
   only, and the information is removed again when a may require signaling message
   leaves of the domain. "Release
   after Failure" message upstream as well as downstream, or soft state
   timing out of reservations.

   The motivation goal is in to prevent stale state within the economy of re-use network and adds
   robustness to the operation of NSIS. So in other words, an NSIS
   signaling protocol must provide means for domain internal an NSIS signaling unit to
   discover and remove local stale state.

   Note that this might need to work together with a notification
   mechanism.

5.3.3 Prompt notification of various information. Where
   additional information is needed for QoS control within a particular
   domain, it violation in case of error/failure to
     QoS Initiator and QoS Controllers

   QoS Controllers should be possible able to carry this at notify the same time as QoS Initiator, if there
   is an error inside the
   'end to end' information.)

5.5.3 Independence network. There are two types of reservation identifier

   A reservation identifier must be used, which is independent network
   errors:

   Recoverable errors: the network nodes can locally repair this type
   error. The network nodes do not have to notify the users of the
   flow identifier,
   error immediately. This is a condition when the IP address danger of
   degradation (or actual short term degradation) of the provided QoS Initiator, and
   was overcome by the flow
   end-points. Various scenarios in network (QoS controller) itself.

   Unrecoverable errors: the mobility area require network nodes cannot handle this
   independence because flows resulting from handoff might type of
   error, and have changed
   end-points etc. but still have the same QoS requirement.

5.5.4 Seamless modification of already reserved QoS

   In many case, the reservation needs to be updated (up or downgrade).
   This must happen seamlessly without service interruption. At least notify the signaling protocol must allow for it, even if some data path
   elements might not be capable users as soon as possible.

5.3.4 Feedback about success of doing so.

5.5.5 Signaling must support quantitative, qualitative, and relative request for QoS specifications

   Brunner, et al.          Informational                   [Page 15] guarantees
               Requirements for QoS Signaling Protocols       May      July 2002

5.6 Performance

   This section discusses performance requirements and evaluation
   criteria and the way in which these could and should

   A request for QoS must be traded off
   against each other answered at least with yes or no. However,
   it might be useful in various parts case of the solution.

   Scalability is a must anyway. However, depending on the scenario negative answer to also get a
   description of what might be the
   question QoS one can successfully request
   etc. So it might be useful to which extends 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
     administrative domain

   The QoS signaling protocol must be scalable.

5.6.1 Scalability in the number 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 messages received by a signaling
     communication partner (QoS initiator and controller)

5.6.2 Scalability in number successful or
   erroneous processing of hand-offs

5.6.3 Scalability in QoS signaling messages.

   In some cases, the number of interactions for setting up a
     reservation

5.6.4 Scalability in the number of state per entity (QoS initiators and NSIS QoS controllers)

5.6.5 Scalability in CPU use (end terminal and intermediate nodes)

5.6.6 Low latency in setup

   Low latency is 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)

5.6.7 Allow for low bandwidth consumption for signaling protocol

   Again only small sets of scenarios call for low bandwidth, mainly
   those where wireless links are involved.

   Note that many may carry
   identification of the performance issues are heavily dependent on QoS controllers located at the scenario assumed and are normally a trade-off between speed,
   reliability, complexity, and scalability. The trade-off varies in
   different parts boundaries of a
   domain. However, the network. For example, in radio access
   networks low bandwidth consumption will overweight the low latency
   requirement, while in core networks it may identification of edge should not be reverse.

5.6.8 Ability visible to constrain load on devices

   The NSIS architecture should give
   the ability end host (QoS initiator) and only applies within one QoS
   administrative domain.

5.4 Layering

   This section contains requirements related to constrain the load
   (CPU load, memory space, way the signaling bandwidth consumption
   being considered interacts with upper layer functions (users,
   applications, and QoS administration), and lower layer QoS
   technologies.

5.4.1 The signaling intensity) on devices where it is needed. One of the
   reasons is that the protocol handling and QoS control information should have a minimal impact
   on interior (core) nodes.

   This can be achieved by many different methods. Examples, and this
   are only examples, include message aggregation, by ignoring
     application independent.

   However, opaque application information might get transported in the
   signaling message, header compression, or minimizing functionality.
   The framework may choose any method as long as without being handled in the requirement is
   met.

   Brunner, et al.          Informational                   [Page 16]
               Requirements for QoS Signaling Protocols       May 2002

5.6.9 Highest possible network utilization

   There are networking environments that require high network
   utilization for various reasons, network. Development
   and the signaling protocol deployment of new applications should
   to its best ability support high resource utilization while
   maintaining appropriate QoS.

   In networks where resources are very expensive (as is be possible without
   impacting the case for
   many wireless networks), efficient network utilization is of
   critical financial importance.  On the other hand there infrastructure. Additionally, QoS protocols
   are other
   parts of expected to conform to the network where high utilization is not required.

5.7 Flexibility Internet principles.

5.5 QoS Control Information

   This section lists the various ways contains requirements related to the protocol can flexibly QoS control
   information that needs to be
   employed.

5.7.1 Aggregation capability, including exchanged.

5.5.1 Mutability information on parameters

   It should be possible for the capability initiator to select and
     change the level of aggregation.

5.7.2 Flexibility in control the placement mutability of
   the QoS QSC information. This prevents from being changed in a non-
   recoverable way. The initiator

   It might should be able to control what is
   requested end to end, without the sender or the receiver request being gradually mutated as
   it passes through a sequence of content. But also network-
   initiated reservations are required in various scenarios.

5.7.3 Flexibility domains. This implies that in the initiation case
   of re-negotiation (QoS change
     requests)

   Again changes made on the sender or the receiver of content might initiate a re-
   negotiation due to various reasons, such as local resource shortage
   (CPU, memory on end-system) or a user changed application
   preference/profiles. But also network-initiated re-negotiation is
   required in cases, where parameters, the network is not able to further
   guarantee resources etc.

5.7.4 Uni / bi-directional reservation

   Both uni-directonal as well as bi-direction reservations original requested ones must
   still be
   possible.

5.8 Security

   This section discusses security-related requirements. First a list
   of security threats is given.

5.8.1 The QoS protocol must provide strong authentication

   A available.

   Note that we do not require anything about particular QoS protocol must make provision for enabling various entities to

   Brunner, et al.          Informational                   [Page 17] parameters
   being changed.

               Requirements for QoS Signaling Protocols       May      July 2002

   be authenticated against each other using data origin and/or entity
   authentication. The

   Additionally, note that a provider or that particular QoS protocol must enable mutual authentication
   between requested,
   can still influence the two communicating entities.  The term strong
   authentication points to QoS provisioning but in the fact that weak plain-text password
   mechanisms must not signaling
   message the request should stay the same.

5.5.2 Possibility to add and remove local domain information

   It should be used possible for authentication.

5.8.2 The the QoS protocol must provide means control functions to authorize resource
     requests

   This requirement demands a hook add and
   remove local scope elements. E.g., at the entrance to interact with a policy entity to
   request authorization data. This allows an authenticated entity to
   be associated with authorization data QoS domain
   domain-specific information is added, which is used in this domain
   only, and to verify the resource
   request. Authorization prevents reservations by unauthorized
   entities, reservations violating policies, theft of service and
   additionally limits denial of service attacks against parts of information is removed again when a signaling message
   leaves the
   network or domain. The motivation is in the entire network. Additionally economy of re-use the
   protocol for domain internal signaling of various information
   pieces. Where additional information is needed for QoS control
   within a particular domain, it might should be helpful to
   provide some means possible to inform other protocols of participating nodes
   within carry this at
   the same administrative domain about a previous successful
   authorization event.

5.8.3 The QoS signaling messages time as the 'end to end' information.)

5.5.3 Independence of reservation identifier

   A reservation identifier must provide integrity protection.

   The integrity protection be used, which is independent of the transmitted signaling messages
   prevent an adversary from modifying parts
   flow identifier, the IP address of the QoS signaling
   message Initiator, and from mounting denial of service attacks against network
   elements participating the flow
   end-points. Various scenarios in the mobility area require this
   independence because flows resulting from handoff might have changed
   end-points etc. but still have the same QoS protocol.

5.8.4 The QoS signaling messages must be replay protected.

   To prevent replay requirement.

5.5.4 Seamless modification of previous signaling messages the already reserved QoS protocol
   must provide means

   In many case, the reservation needs to detect old messages. A solution be updated (up or downgrade).
   This must cover
   issues of synchronization problems in happen seamlessly without service interruption. At least
   the case of a restart or a
   crash of a participating network element. The use of replay
   mechanism apart from sequence numbers should be investigated.

5.8.5 The QoS signaling protocol must allow for hop-by-hop security.

   Hop-by-Hop security is a well known and proven concept it, even if some data path
   elements might not be capable of doing so.

5.5.5 Grouping of signaling for several microflows

   NSIS may group signaling information for several microflow into one
   signaling message. The goal of this is the optimization in QoS
   protocols that allows intermediate nodes that actively participate terms of
   setup delay, which can happen in parallel. This helps applications
   requesting several flows at once. Also potential refreshes (in case
   of a soft state solution) might profit of grouping.

   However, the QoS protocol to modify the messages as required by the QoS
   processing. Note that this requirement does network must not exclude end-to-end
   or network-to-network security of know that a QoS reservation request. End-to-
   end security relationship between the initiator
   grouped flows exists. Nor is there any transactional semantic
   allowed. It is only meant for optimization purposes and each
   reservation is handled separately from each other.

5.6 Performance

   This section discusses performance requirements and evaluation
   criteria and the responder may way in which these could and should be used to
   provide protection traded off
   against each other in various parts 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 solution.

   Scalability is a particular
   network.

5.8.6 The QoS protocol should allow identity confidentiality and
     location privacy.

   Identity confidentiality enables privacy and avoids profiling of
   entities by adversary eavesdropping must anyway. However, depending on the signaling traffic along scenario the
   path. The identity used in
   question to which extends the process of authentication may also protocol must be

   Brunner, et al.          Informational                   [Page 18] scalable.

               Requirements for QoS Signaling Protocols       May      July 2002

   hidden to a limited extent from a network to which

5.6.1 Scalability in the initiator is
   attached. It is however required that 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 identity provide enough
   information number of interactions for setting up a
     reservation

5.6.4 Scalability in the access network to collect accounting data.
   Location privacy 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

   Low latency is an issue 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)

5.6.7 Allow for low bandwidth consumption for signaling protocol

   Again only small sets of scenarios call for low bandwidth, mainly
   those where wireless links are involved.

   Note that many of the initiator who triggers performance issues are heavily dependent on
   the QoS
   protocol. In some scenarios scenario assumed and are normally a trade-off between speed,
   reliability, complexity, and scalability. The trade-off varies in
   different parts of the initiator network. For example, in radio access
   networks low bandwidth consumption will overweight the low latency
   requirement, while in core networks it may not be willing to
   reveal location information reverse.

5.6.8 Ability to the responder.

5.8.7 constrain load on devices

   The QoS protocol NSIS architecture should prevent denial-of-service attacks against
     signaling entities.

   To effectively prevent denial-of-service attacks the QoS protocol
   and give the used security mechanisms should not force to do heavy
   computation ability to verify a resource request prior authenticating the
   requesting entity. Additionally constrain the QoS protocol load
   (CPU load, memory space, signaling bandwidth consumption and the used
   security mechanisms should not require large resource consumption
   (for example main memory or other additional message exchanges)
   before a successful authentication was done.

5.8.8 The QoS protocol should support confidentiality of
   signaling
     messages.

   Based intensity) on devices where it is needed. One of the signaling information exchanged between nodes
   participating in
   reasons is that the QoS protocol an adversary handling should have a minimal impact
   on interior (core) nodes.

   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 learn both choose any method as long as the
   identities requirement is
   met.

5.6.9 Highest possible network utilization

   There are networking environments that require high network
   utilization for various reasons, and the content signaling protocol should
   to its best ability support high resource utilization while
   maintaining appropriate QoS.

               Requirements for QoS Signaling Protocols      July 2002

   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 QoS messages. To prevent this from
   happening, confidentiality other hand there are other
   parts of the QoS requests in a hop-by-hop
   manner should be provided. Note that hop-by-hop network where high utilization is always required
   whenever entities actively participating in not required.

5.7 Flexibility

   This section lists the various ways the protocol must can flexibly be
   able
   employed.

5.7.1 Aggregation capability, including the capability to read select and eventually modify
     change the content level of aggregation.

5.7.2 Flexibility in the placement of the QoS messages.
   This does not exclude initiator

   It might be the case where one sender or more network elements
   are not the receiver of content. But also network-
   initiated reservations are required to read in various scenarios such as
   PSTN gateways, some VPNs, mobility.

5.7.3 Flexibility in the information initiation of re-negotiation (QoS change
     requests)

   Again the transmitted QoS
   messages.

5.8.9 The QoS protocol should provide hooks to interact with protocols
     that allow sender or the negotiation receiver of authentication and key management
     protocols.

   The content might initiate a re-
   negotiation of an authentication and key management protocols
   within the QoS protocol 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 outside the scope of the QoS protocol.
   This requirement originates from
   required in cases, where the fact that more than one key
   management protocol may be used network is not able to provide security associations. So
   both entities further
   guarantee resources etc.

5.7.4 Uni / bi-directional reservation

   Both unidirectional as well as bi-direction reservations must be capable to use
   possible. With bi-directional reservations we mean here reservations
   having the same protocol which may be
   difficult end-points. But the path in a mobile environment with different requirements and
   different protocols. the two directions does
   not need to be the same.

   The goal of such a negotiation step bi-directional reservation is to
   determine which authentication and key management protocol to use mainly an optimization
   in terms of setup delay. There is
   executed prior to no requirements on constrains such
   as use the execution same data path etc.

5.8 Security

   This section discusses security-related requirements. For a
   discussion of the chosen key management
   protocol. The used key management security threats see [12].

5.8.1 Authentication of signaling requests

   A signaling protocol must however make provision for enabling various
   entities to be able authenticated against each other using strong
   authentication mechanisms. The term strong authentication points to
   create a security association that matches with
   the one fact that weak plain-text password mechanisms must not be used in the
   QoS protocol. A
   for authentication.

               Requirements for QoS protocol should however provide a way to
   interact with these negotiation protocols.

5.8.10 Signaling Protocols      July 2002

5.8.2 Resource Authorization

   The QoS signaling protocol should must provide means to authorize resource
   requests. This requirement demands a hook to interact with key
     management protocols

   Brunner, et al.          Informational                   [Page 19]
               Requirements for QoS Signaling Protocols       May 2002

   Key management protocols typically require a larger number of
   messages policy
   entity to be transmitted request authorization data. This allows an authenticated
   entity to allow a session key be associated with authorization data and the
   corresponding security association to be derived. To avoid verify the
   complex issue
   resource request. Authorization prevents reservations by unauthorized
   entities, reservations violating policies, theft of mapping individual authentication service and key
   management protocols to a QoS protocol such a protocol is outside
   the scope
   additionally limits denial of service attacks against parts of the QoS protocol. Although
   network or the key management protocol
   may be independent there must entire network caused by unrestricted reservations.
   Additionally it might be a way for the QoS protocol helpful to
   exploit existing security associations provide some means to avoid executing a separate
   key management protocol (or instance inform
   other protocols of participating nodes within the same protocol) for
   protocols that closely operate together. If no such security
   association exists then there should be means for the QoS protocol
   to trigger administrative
   domain about a key management previous successful authorization event.

5.8.3 Integrity protection

   The signaling protocol must provide means to dynamically create protect the
   required security associations.

5.9 Mobility

5.9.1 Allow efficient QoS re-establishment after handover

   Handover is message
   payloads against modifications. Integrity protection prevents 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
   adversary from modifying with parts of the
   mobile node itself signaling message and from
   mounting denial of service or triggered by the access point that the mobile
   node is attached to.  In theft of service type of attacks
   against network elements participating in the first case, protocol execution.

5.8.4 Replay protection

   To prevent replay of previous signaling messages the QoS signalling should
   allow efficient QoS re-establishment after handover.  Re-
   establishment signaling
   protocol must provide means to detect old i.e. already transmitted
   signaling messages. A solution must cover issues of QoS after handover should be as quick as possible
   so that synchronization
   problems in the mobile node does not experience service interruption case of a restart or
   QoS degradation. a crash of a participating
   network element. The re-establishment use of replay mechanism apart from sequence
   numbers should be localized, investigated.

5.8.5 Hop-by-hop security

   Hop-by-Hop security is a well known and proven concept in Quality-of-
   Service and not
   require end-to-end signalling, if possible.

TBD

5.10    Interworking with other signaling protocols and techniques

   Hooks must be provided that allows intermediate nodes
   that actively participate in the protocol to enable efficient interworking 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
   various protocols the initiator and techniques including:

5.10.1 Interworking with IP tunneling

   IP tunneling for various applications must the responder
   may be supported. More
   specifically tunneling for IPSec tunnels are used to provide protection of importance. This
   mainly impacts non-mutable data fields.
   Network-to-network security refers to the identification protection of flows. Additionally, care needs
   to be taken using IPSec for signaling message.

5.10.2 The solution should not constrain either to IPv4 or IPv6

5.10.3 Independence from charging model

   Signaling must messages over
   various hops but not be constrained in an end-to-end manner i.e. protected over a
   particular network.

5.8.6 Identity confidentiality and location privacy

   Identity confidentiality enables privacy and avoids profiling of
   entities by charging models or adversary eavesdropping the charging
   infrastructure used. However, signaling traffic along the end-system should
   path. The identity used in the process of authentication may also be able
   hidden to query
   current pay statistics and a limited extent from a network to specify user cost functions.

5.10.4 The QoS protocol should provide hooks which the initiator is
   attached. It is however required that the identity provides enough
   information for AAA protocols

   Brunner, et al.          Informational                   [Page 20] the nodes in the access network to collect accounting
   data.

               Requirements for QoS Signaling Protocols       May      July 2002

   The security mechanism should be developed with respect to

   Location privacy is an issue for the initiator who triggers the
   signaling protocol. In some scenarios the initiator may not be able
   to collect usage records from one or more network elements.

5.11    Operational

5.11.1 Ability
   willing to assign transport quality reveal location information to the responder as part the
   signaling messages procedure.
   The NSIS architecture signaling protocol should allow the network operator provide means to assign protect the NSIS protocol messages a certain transport quality. As signaling
   opens up for identity
   confidentiality and as far as possible denial-of-service attacks, this requirement
   gives location privacy.

5.8.7 Denial-of-service attacks

   To effectively prevent denial-of-service attacks it is necessary that
   the network operator a mean, but also used security and protocol mechanisms should not require the obligation,
   execution of heavy computation to
   trade-off between signaling latency and verify a resource request prior
   authenticating the impact (from requesting entity. Additionally the signaling messages) on devices within his/her network. From
   protocol
   design this requirement states that and the used security mechanisms should not require large
   resource consumption (for example main memory or other additional
   message exchanges) before a successful authentication was done. A
   signaling protocol messages should be
   detectable, at least where the control and assignment provide prevention of the DoS attacks.

5.8.8 Confidentiality of signaling messages priority is done.

6  The MUSTs, SHOULDs, and MAYs

   In order to prioritize

   Based on the various requirements from Section 5, we
   define different 'parts of signaling information exchanged between nodes
   participating in the network'. In signaling protocol an adversary may learn both
   the different parts identities and the content of the network a particular requirement might have a different
   priority.

   The parts signaling messages. To prevent
   this from happening, confidentiality of the networks we differentiate are signaling message in a
   hop-by-hop manner may be provided. Note that the host-to-first
   router, protection can be
   provided on a hop-by-hop basis for most message payloads since it is
   required that entities which actively participating in the access network, signaling
   protocol must be able to read and eventually modify the core network. The host to first
   router part includes all content of
   the layer 2 technologies to access signaling messages.

5.8.9 Ownership of a reservation

   When existing reservations have to the
   Internet. In many cases, be modified then there is an application and/or user running
   on the host initiating QoS signaling. The access network can be
   characterized by low capacity links, meadium 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 interdomain QoS issues. All of them are not strictly
   defined and should not be regarded as that, but should give need
   to use a
   feeling about where in reservation identifier to uniquely identify the network we have different requirements
   concerning QoS signaling.

   Note that established
   state. A signaling protocol must provide the appropriate security
   protection to prevent other entities to modify state without having
   the proper ownership.

5.8.10 Hooks with Authentication and Key Agreement protocols

   This requirement titles are listed for better reading.

   5.1  Architecture covers two subsequent steps before a signaling
   protocol is executed and Design Goals
   5.1.1 Applicability for different QoS technologies.
   5.1.2 Resource availability information the required hooks. First there is a need to
   agree on request
   5.1.3 Modularity
   5.1.4 Decoupling of a specific authentication protocol. Later this protocol is
   executed and information provides authentication and establishes the desired
   security associations. Using these security associations it is carrying
   5.1.5 Reuse then
   possible to exchange secured signaling messages.

   The signaling protocol should provide hooks to interact with
   protocols   that allow the negotiation of existing QoS provisioning
   5.1.6 Independence authentication and key
   agreement   protocols. Although the negotiation of signaling an authentication
   and provisioning paradigm

   ----------------------+-------------+-------------+------------+
                         | host-to-net |   access    |   core     |
   ----------------------+-------------+-------------+------------+
   5.1.1                 |             |             |            |
   ----------------------+-------------+-------------+------------+
   5.1.2                 |             |             |            |
   ----------------------+-------------+-------------+------------+
   5.1.3                 |             |             |            |

   Brunner, et al.          Informational                   [Page 21]
               Requirements for QoS Signaling Protocols       May 2002

   ----------------------+-------------+-------------+------------+
   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 key management protocol within the QoS signaling and QoS Controllers to protocol may be
   in
   outside the data path.
   5.2.3 Concealment of topology and technology information
   5.2.4 Optional transparency of QoS signaling scope it is still required 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 trigger this exchange 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                 |             |             |            |
   ----------------------+-------------+-------------+------------+

   Brunner, et al.          Informational                   [Page 22] that no such security association is available.

               Requirements for QoS Signaling Protocols       May      July 2002

   5.4  Layering

   5.4.1  The signaling

   This requirement originates from the fact that more than one key
   management protocol and QoS control information should may 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 used 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 provide a security association for
   the signaling protocol. Hence the communicating entities must support quantitative, qualitative, be
   capable to agree on a specific authentication. The selected
   authentication 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 key agreement protocol must however be able to
   create a security association that can be used within the signaling
   protocol.

   Key management protocols typically require a larger number of
   messages received by to be transmitted to allow a signaling
   communication partner (QoS initiator session key 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
   corresponding security association to be derived. To avoid the number
   complex issue of state per entity (QoS initiators embedding individual authentication and QoS controllers)
   5.6.5 Scalability in CPU use (end terminal key
   agreement protocols into a specific signaling protocol it is required
   that most of these protocols are executed independently (prior to the
   signaling protocol) and intermediate nodes)
   5.6.6 Low latency in setup
   5.6.7 Allow for low bandwidth consumption although the key management protocol may be
   independent there must be a way for the 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                 |             |             |            |

   Brunner, et al.          Informational                   [Page 23]
               Requirements for QoS Signaling Protocols       May 2002

   ----------------------+-------------+-------------+------------+
   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 use available (i.e. already established) security associations to
   avoid executing a separate key management protocol (or instance of
   the QoS initiator
   5.7.3 Flexibility in same protocol) for protocols that closely operate together. If no
   such security association exists then there should be means for 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
   signaling protocol must provide means to authorize resource
   requests
   5.8.3 The dynamically trigger such a protocol.

5.9 Mobility

5.9.1 Allow efficient QoS signaling messages must provide integrity protection.
   5.8.4 The re-establishment after handover

   Handover is an essential function in wireless networks. After
   handover, QoS signaling messages must may need to be replay protected.
   5.8.5 The QoS signaling protocol must allow for hop-by-hop security.
   5.8.6 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 protocol signaling 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 efficient QoS protocol should support confidentiality re-establishment after handover.  Re-
   establishment of signaling
   messages.

   Brunner, et al.          Informational                   [Page 24]
               Requirements for QoS Signaling Protocols       May 2002

   5.8.9 The QoS protocol after handover should provide hooks to interact with
   protocols be as quick as possible
   so 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 mobile node does not experience service interruption or
   QoS degradation. The re-establishment after handover
   ----------------------+-------------+-------------+------------+
                         | host-to-net |   access    |   core     |
   ----------------------+-------------+-------------+------------+
   5.9.1                 |             |             |            |
   ----------------------+-------------+-------------+------------+ should be localized, and not
   require end-to-end signaling, if possible.

5.10    Interworking with other protocols and techniques

   Hooks must be provided to enable efficient interworking between
   various protocols and techniques including:

5.10.1 Interworking with IP tunneling

   IP tunneling for various applications must be supported. More
   specifically tunneling for IPSec tunnels are of importance. This
   mainly impacts the identification of flows. Using IPsec parts of
   information for flow identification (e.g. transport protocol
   information), this information is not accessible for classification
   etc.

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

   ----------------------+-------------+-------------+------------+
                         | host-to-net |   access    |   core     |
   ----------------------+-------------+-------------+------------+
   5.10.1                |             |             |            |
   ----------------------+-------------+-------------+------------+
   5.10.2                |             |             |            |

   Brunner, et al.          Informational                   [Page 25] The solution should not constrain either to IPv4 or IPv6
               Requirements for QoS Signaling Protocols       May      July 2002

   ----------------------+-------------+-------------+------------+

5.10.3                |             |             |            |
   ----------------------+-------------+-------------+------------+ Independence from charging model

   Signaling must not be constrained by charging models or the charging
   infrastructure used.

5.10.4                |             |             |            |
   ----------------------+-------------+-------------+------------+ Hooks for AAA protocols

   The security mechanism should be developed with respect to be able
   to collect usage records from one or more network elements.

5.10.5 Interworking with seamless handoff protocols

   An NSIS protocol should interwork with seamless handoff protocols
   such as context transfer and candidate access router (CAR)
   discovery. The goal to achieve is that signaling for QoS works fast
   enough in case of a handoff, where that protocols might help in one
   way or the other.

5.10.6 Interworking with non-traditional routing

   NSIS assumes traditional routing, but networks, which do non-
   traditional L3 routing, should not break it.

5.11    Operational

5.11.1 Ability to assign transport quality to signaling messages.

   The NSIS architecture should allow the network operator to assign
   the NSIS protocol 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 certain transport quality. As signaling
   opens up for Mobile IP",
   draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress,
   August 2001

   [3] Manner. J., 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.

   Furthermore, the protocol design must take into account reliability
   concerns.

   Communication reliability is seen as part of the quality assigned to
   signaling messages. So procedures must define how an NSIS signaling
   systems behaves if some kind of request it sent stays without
   answer. The basic transport protocol to be used between adjacent
   NSIS units must ensure message integrity and reliable transport.

5.11.2 Graceful fail over

   Any unit participating in NSIS signaling must not cause further
   damage to other systems involved in NSIS signaling when it has to go
   out of service.

6  The MUSTs, SHOULDs, and MAYs
               Requirements for QoS Signaling Protocols      July 2002

   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

   ----------------------+-------------+-------------+------------+
               Requirements for QoS Signaling Protocols      July 2002

                         | 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
               Requirements for QoS Signaling Protocols      July 2002

   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                 |             |             |            |
   ----------------------+-------------+-------------+------------+
               Requirements for QoS Signaling Protocols      July 2002

   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                 |             |             |            |
   ----------------------+-------------+-------------+------------+
               Requirements for QoS Signaling Protocols      July 2002

   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     |
   ----------------------+-------------+-------------+------------+
               Requirements for QoS Signaling Protocols      July 2002

   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
   System, revision B", S.R0005-B, May 2001

   [6] Bradner, S., Mankin, A., "Report of the Next Steps in Signaling
   BOF", draft-bradner-nsis-bof-00.txt, Work in Progress, July 2001

   [7] Partain, D., et al, "Resource Reservation Issues in Cellular
   Radio Access Networks", draft-westberg-rmd-cellular-issues-00.txt,
   Work in Progress, June 2001.

   [8] YESSIR - YEt another Sender Session Internet Reservations,
   http://www.cs.columbia.edupingpan/projects/yessir.html

   [9] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S.,
   "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
   Specification", IETF RFC 2205, 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.

   Brunner, et al.          Informational                   [Page 26]
               Requirements for QoS Signaling Protocols       May 2002

   [11] Kempf, J., McCann, P., Roberts, P., "IP Mobility and the CDMA
   Radio Access Network", IETF Draft, draft-kempf-cdma-appl-02.txt,
   Work in progress, September 2001.

   [12] Tschofenig, H., "NSIS Threats", <draft-tschofenig-nsis-threats-
   00.txt>, May 2002.

8  Acknowledgments

   Quite a number of people have been involved in the discussion of the
   draft, adding some ideas, requirements, etc. We list them without a
   guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul
   (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas
               Requirements for QoS Signaling Protocols      July 2002

   Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC),
   Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical
   University Berlin), Xiaoming Fu (Technical University Berlin), Hans-
   Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph
   Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya
   Freytsis.

   Some text and/or ideas for text, requirements, scenarios have been
   taken from a draft written by the following authors: David Partain
   (Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia),
   Georgios Karagiannis (Ericsson), Jukka Manner (University of
   Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars
   Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have
   actively contributed new text to the draft as well.

   Another draft impacting this draft has been written by Sven Van den
   Bosch, Maarten Buchli, and Danny Goderis. These people contributed
   also with new text.

9  Author's Addresses

   Marcus Brunner (Editor)
   NEC Europe Ltd.
   Network Laboratories
   Adenauerplatz 6
   D-69115 Heidelberg
   Germany
   E-Mail: brunner@ccrle.nec.de (contact)

   Robert Hancock, Eleanor Hepworth
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom
   E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk

   Cornelia Kappler
   Siemens AG
   Berlin  13623
   Germany
   E-Mail: cornelia.kappler@icn.siemens.de

   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munchen
   Germany
   Email: Hannes.Tschofenig@mchp.siemens.de

10 Appendix: Scenarios/Use cases

   In the following we describe scenarios, which are important to
   cover, and which allow us to discuss various requirements. Some
               Requirements for QoS Signaling Protocols      July 2002

   regard this as use cases to be covered defining the use of a QoS
   signaling protocol.

8.1

10.1    Scenario: Terminal Mobility

   The scenario we are looking at is the case where a mobile terminal
   (MT) changes from one access point to another access point. The
   access points are located in separate QoS domains. We assume Mobile
   IP to handle mobility on the network layer in this scenario and
   consider the various extensions (i.e., IETF proposals) to Mobile IP,
   in order to provide 'fast handover' for roaming Mobile Terminals.
   The goal to be achieved lies in providing, keeping, and adapting the
   requested QoS for the ongoing IP sessions in case of handover.
   Furthermore, the negotiation of QoS parameters with the new domain
   via the old connection might be needed, in order to support the
   different 'fast handover' proposals within the IETF.

   The entities involved in this scenario include a mobile terminal,
   access points, an access network manager, communication partners of
   the MT (the other end(s) of the communication association).
   From a technical point of view, terminal mobility means changing the
   access point of a mobile terminal (MT). However, technologies might
   change in various directions (access technology, QoS technology,
   administrative domain). If the access points are within one specific
   QoS technology (independent of access technology) we call this
   intra-QoS technology handoff. In the case of an inter-QoS technology
   handoff, one changes from e.g. a DiffServ to an IntServ domain,
   however still using the same access technology. Finally, if the
   access points are using different access technologies we call it
   inter-technology hand-off.

   The following issues are of special importance in this scenario:

   1) Handoff decision

   - The QoS management requests handoff. The QoS management can decide
   to change the access point, since the traffic conditions of the new
   access point are better supporting the QoS requirements. The metric
   may be different (optimized towards a single or a group/class of
   users). Note that the MT or the network (see below) might trigger
   the handoff.

   - The mobility management forces handoff. This can have several
   reasons. The operator optimizes his network, admission is no longer

   Brunner, et al.          Informational                   [Page 27]
               Requirements for QoS Signaling Protocols       May 2002
   granted (e.g. emptied prepaid condition). Or another example is when
   the MT is reaching the focus of another base station. However, this
   might be detected via measurements of QoS on the physical layer and
   is therefore out of scope of QoS signaling in IP. Note again that
   the MT or the network (see below) might trigger the handoff.

   - This scenario shows that local decisions might not be enough. The
   rest of the path to the other end of the communication needs to be
   considered as well. Hand-off decisions in a QoS domain, does not
   only depend on the local resource availability, e.g., the wireless
               Requirements for QoS Signaling Protocols      July 2002

   part, but involves the rest of the path as well. Additionally,
   decomposition of an end-to-end reservation might be needed, in order
   to change only parts of it.

   2) Trigger sources

   - Mobile terminal: If the end-system QoS management identifies
   another (better-suited) access point, it will request the handoff
   from the terminal itself. This will be especially likely in the case
   that two different provider networks are involved. Another important
   example is when the current access point bearer disappears (e.g.
   removing the Ethernet cable). In this case, the QoS initiator is
   basically located on the mobile terminal.

   - Network (access network manager): Sometimes, the handoff trigger
   will be issued from the network management to optimize the overall
   load situation. Most likely this will result in changing the base-
   station of a single providers network. Most likely the QoS initiator
   is located on a system within the network.

   3) Integration with other protocols

   - Interworking with other protocol must be considered in one or the
   other form. E.g., it might be worth combining QoS signaling between
   different QoS domains with mobility signaling at hand-over.

   4) Handover rates

   In mobile networks, the admission control process has to cope with
   far more admission requests than call setups alone would generate.
   For example, in the GSM (Global System for Mobile communications)
   case, mobility usually generates an average of one to two handovers
   per call. For third generation networks (such as UMTS), where it is
   necessary to keep radio links to several cells simultaneously
   (macro-diversity), the handover rate is significantly higher (see
   for example [11])

   5) Fast reservations

   Handover can also cause packet losses. This happens when the
   processing of an admission request causes a delayed handover to the
   new base station. In this situation, some packets might be
   discarded, and the overall speech quality might be degraded
   significantly. Moreover, a delay in handover may cause degradation

   Brunner, et al.          Informational                   [Page 28]
               Requirements for QoS Signaling Protocols       May 2002
   for other users. In the worst case worst-case scenario, a delay in handover may
   cause the connection to be dropped if the handover occurred due to
   bad air link quality. Therefore, it is critical that QoS signalling signaling
   in connection with handover be carried out very quickly.

   6) Call blocking in case of overload

   Furthermore, when the network is overloaded, it is preferable to
   keep reservations for previously established flows while blocking
   new requests. Therefore, the resource reservation requests in
               Requirements for QoS Signaling Protocols      July 2002

   connection with handover should be given higher priority than new
   requests for resource reservation.

8.2

10.2    Scenario: Cellular Networks

   In this scenario, the user is using user is using the packet service of a 3rd
   generation cellular system, e.g. UMTS. The region between the End
   Host and the edge node connecting the cellular network to another
   QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is
   considered to be a single QoS domain [4][5].

   The issues in such an environment regarding QoS include:

   1) Cellular systems provide their own QoS technology with
   specialized parameters to co-ordinate the QoS provided by both the
   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
   technology; provisioning of QoS within GPRS is described mainly in
   terms of calling UMTS bearer classes.  This QoS technology needs to
   be invoked with suitable parameters when higher layers trigger a
   request for QoS, and this therefore involves mapping the requested
   IP QoS onto these UMTS bearer classes. This request for resources
   might be triggered by IP signaling messages that pass across the
   cellular system, and possibly other QoS domains, to negotiate for
   network resources. Typically, cellular system specific messages
   invoke the underlying cellular system QoS technology in parallel
   with the IP QoS negotiation, to allocate the resources within the packet service of a 3rd
   generation
   cellular system, e.g. UMTS. system.

   2) The region between placement of QoS initiators and QoS controllers (terminology
   in the framework given here). The QoS initiator could be located at
   the End Host and (triggered by applications), the edge GGSN/PDSN, or at a
   node connecting not directly on the cellular network to another
   QoS domain (e.g. data path, such as a bandwidth broker. In
   the GGSN in UMTS or second case, the PDSN in 3GPP2) is
   considered to GGSN/PDSN could either be acting as a single proxy on
   behalf of an End Host with little capabilities, and/or managing
   aggregate resources within its QoS domain [4][5]. (the UMTS core network).
   The issues in such an environment regarding IP signaling messages are interpreted by the QoS include:

   1) Cellular systems provide their own controllers,
   which may be located at the GGSN/PDSN, and in any QoS technology with
   specialized parameters to co-ordinate sub-domains
   within the cellular system.

   3) Initiation of IP-level QoS provided negotiation. IP-level QoS re-
   negotiation may be initiated by either the End Host, or by both the
   radio access and wired access network. For example, in a UMTS
   network, one aspect based on current network loads, which might change
   depending on the location of GPRS is the end host.

   4) The networks are designed and mainly used for speech
   communication (at least so far).

   Note that it can be considered as a QoS
   technology; provisioning of in comparison to the former scenario, the emphasis is much
   less on the mobility aspects, because mobility is mainly handled on
   the lower layer.

10.3    Scenario: UMTS access
               Requirements for QoS within GPRS Signaling Protocols      July 2002

   The UMTS access scenario is described mainly shown in
   terms figure 3. The Proxy-Call State
   Control Function/Policy Control Function (P-CSCF/PCF) is the
   outbound SIP proxy of calling UMTS bearer classes.  This QoS technology needs the visited domain, i.e. the domain where the
   mobile user wants to
   be invoked with suitable parameters when set-up a request for QoS call. The Gateway GPRS Support Node
   (GGSN) is
   triggered by higher layers, the egress router of the UMTS domain and this therefore involves mapping connects the
   requested IP QoS onto these UMTS bearer classes. This request for
   resources might be triggered by
   access network to the Edge Router (ER) of the core IP signaling messages that pass
   across network. The
   P-CSCF/PCF communicates with the cellular system, GGSN via the COPS protocol [4]. The
   User Equipment (UE) consists of a Mobile Terminal (MT) and possibly other Terminal
   Equipment (TE), e.g. a laptop.

                           +--------+
                +----------| P-CSCF |-------> SIP signaling
               /           +--------+
              / SIP            :
             :             +--------+   NSIS  +----------------+
             :             |  PCF   |---------| QoS domains, Controller |
             :             +--------+         +----------------+
             :                 :
             :                 : COPS
             :                 :
           +----+          +--------+      +----+
           | UE |----------|  GGSN  |------| ER |
           +----+          +--------+      +----+

                      Figure 1: UMTS access scenario

   In this scenario the GGSN has the role of Access Gate. According to
   negotiate
   3GPP standardization, the PCF is responsible for the policy-based
   control of the end-user service in the UMTS access network resources. Typically, cellular system specific
   messages invoke (i.e.
   from UE to GGSN). In the underlying cellular system QoS technology current UMTS release R.5, the PCF is part
   of the P-CSCF, but in
   parallel with UMTS R.6 the IP QoS negotiation, interface between P-CSCF and PCF
   may evolve to allocate the resources
   within an open standardized interface. In any case the cellular system.

   2) The placement of QoS initiators and PCF
   has all required QoS controllers (terminology information for per-flow admission control in
   the framework given here). The QoS initiator could be located at
   the End Host (triggered by applications), UMTS access network (which it gets from the GGSN/PDSN, or at a
   node not directly on P-CSCF and/or GGSN).
   Thus the data path, such as a bandwidth broker. In PCF would be the second case, appropriate entity to host the GGSN/PDSN could either be acting as a proxy on
   behalf
   functionality of an End Host with little capabilities, and/or managing
   aggregate resources within its QI, initiating the "NSIS" QoS domain (the UMTS signaling towards the
   core network). IP network. The PCF/P-CSCF has to do the mapping from codec
   type (derived from SIP/SDP signaling) to IP signaling messages traffic descriptor. SDP
   extensions to explicitly signal QoS information [7] are interpreted by useful to
   avoid the QoS controllers,
   which may be located at need to store codec information in the GGSN/PDSN, PCF and in any to allow
   for more flexibility and accurate description of the QoS sub-domains
   within traffic
   parameters. The PCF also controls the cellular system.

   3) Initiation GGSN to open and close the
   gates and to configure per-flow policers, i.e. to authorize or
   forbid user traffic.

   The QC is (of course) not part of IP-level QoS negotiation. IP-level the standard UMTS architecture.
   However, to achieve end-to-end QoS re-
   negotiation may be initiated by either a QC is needed such that the PCF
   can request a QoS connection to the End Host, or by IP network. As in the
   network, based on current network loads, which might change
   depending on previous
   example, the location QC could manage a set of pre-provisioned resources in
   the end host.

   Brunner, et al.          Informational                   [Page 29] IP network, i.e. bandwidth pipes, and the QC performs per-flow
   admission control into these pipes. In this way, a connection can be
   made between two UMTS access networks, and hence, end-to-end QoS can
               Requirements for QoS Signaling Protocols       May      July 2002

   4) The networks are designed

   be achieved. In this case the QI and mainly used QC are clearly two separate
   entities.
   This use case clearly illustrates the need for speech
   communication (at least so far).

   Note that an "NSIS" QoS
   signaling protocol between QI and QC. An important application of
   such a protocol may be its use in comparison to the former scenario, the emphasis is much
   less on the mobility aspects, because mobility is mainly handled on the lower layer.

8.3 Scenario: UMTS access

   The inter-connection of UMTS access scenario is shown in figure 3. The Proxy-Call State
   Control Function/Policy Control Function (P-CSCF/PCF) is the
   outbound SIP proxy
   networks over an IP backbone.

10.4    Scenario: Wired part of the visited domain, i.e. the wireless network

   A wireless network, seen from a QoS domain where the
   mobile user wants to set-up perspective, usually
   consists of three parts: a call. The Gateway GPRS Support Node
   (GGSN) is the egress router wireless interface part (the "radio
   interface"), a wired part of the UMTS domain wireless network (i.e., Radio
   Access Network) and connects the UMTS
   access network to backbone of the Edge Router (ER) wireless network, as shown
   in Figure 2. Note that this figure should not be seen as an
   architectural overview of wireless networks but rather as showing
   the core IP conceptual QoS domains in a wireless network. The
   P-CSCF/PCF communicates with the GGSN via

   In this scenario, a mobile host can roam and perform a handover
   procedure between base stations/access routers. In this scenario the COPS
   NSIS QoS protocol [4]. The
   User Equipment (UE) consists of can be applied between a Mobile Terminal (MT) base station and Terminal
   Equipment (TE), e.g. the
   gateway (GW).  In this case a laptop.

                           +--------+
                +----------| P-CSCF |-------> SIP signaling
               /           +--------+
              / SIP            :
             :             +--------+ GW can also be considered as a local
   handover anchor point. Furthermore, in this scenario the NSIS  +----------------+
             :             |  PCF   |---------| QoS Controller |
             :             +--------+         +----------------+
             :                 :
             :                 : COPS
             :                 :
           +----+          +--------+      +----+
   protocol can also be applied either between two GWs, or between two
   edge routers (ER).

                             |--|
                             |GW|
      |--|                   |--|
      |MH|---                  .
      |--|  / |-------|        .
           /--|base   | UE |----------|  GGSN  |------| |--|   .
              |station|-|ER|....
              |-------| |--|   .  |--| back- |--|  |---|
   |----|

   ...|ER|.......|ER|..|BGW|.."Internet"..|host|
           -- |-------| |--|   .  |--| bone  |--|  |---|
   |----|
      |--| \  |base   |-|ER|...     .
      |MH|  \ |station| |--|        .
      |--|--- |-------|             .          MH  = mobile host
                                 |--|          ER |
           +----+          +--------+      +----+  = edge router
         <---->                  |GW|          GW  = gateway
        Wireless link            |--|          BGW = border gateway
                                               ... = interior nodes
               <------------------->
         Wired part of wireless network

      <---------------------------------------->
                   Wireless Network

      Figure 1: UMTS access scenario

   In this scenario the GGSN has the role 2. QoS architecture of wired part of wireless network
               Requirements for QoS Signaling Protocols      July 2002

   Each of Access Gate. According these parts of the wireless network impose different issues
   to
   3GPP standardization, be solved on the PCF is responsible QoS signaling solution being used:

   * Wireless interface: The solution for the policy-based
   control air interface link
     has to ensure flexibility and spectrum efficient transmission
     of the end-user service IP packets.  However, this link layer QoS can be solved in
     the UMTS access network (i.e.
   from UE same way as any other last hop problem by allowing a
     host to GGSN). In request the current UMTS release R.5, proper QoS profile.

   * Wired part of the PCF wireless network:  This is the part of
     the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF
   may evolve network that is closest to the base stations/access
     routers.  It is an open standardized interface. IP network although some parts logically
     perform tunneling of the end user data. In any case cellular networks,
     the PCF
   has all required QoS information for per-flow admission control in wired part of the UMTS wireless network is denoted as a
     radio access network.

     This part of the wireless network (which it gets from has different
     characteristics when compared to traditional IP networks:

         1. The network supports a high proportion of real-time
            traffic.  The majority of the P-CSCF and/or GGSN).
   Thus traffic transported in the PCF would be
            wired part of the appropriate entity wireless network is speech, which is
            very sensitive to delays and delay variation (jitter).

         2. The network must support mobility.  Many wireless
            networks are able to provide a combination of soft
            and hard handover procedures.  When handover occurs,
            reservations need to be established on new paths.
            The establishment time has to host be as short as possible
            since long establishment times for reservations degrade
            the
   functionality performance of QI, initiating the "NSIS" QoS signaling towards the
   core IP wireless network. The PCF/P-CSCF has to do  Moreover,
            for maximal utilization of the mapping from codec
   type (derived from SIP/SDP signaling) to IP traffic descriptor. SDP
   extensions to explicitly signal QoS information [7] radio spectrum, frequent
            handover operations are useful to
   avoid the need to store codec information required.

         3. These links are typically rather bandwidth-limited.

         4. The wired transmission in the PCF and to allow
   for more flexibility such a network contains a
            relatively high volume of expensive leased lines.
            Overprovisioning might therefore be prohibitively
            expensive.

         5. The radio base stations are spread over a wide
            geographical area and accurate description are in general situated a large
            distance from the backbone.

   * Backbone of the QoS traffic
   parameters. The PCF also controls wireless network: the GGSN requirements imposed
     by this network are similar to open the requirements imposed by
     other types of backbone networks.

   Due to these very different characteristics and close requirements, often
   contradictory, different QoS signaling solutions might be needed in
   each of the

   Brunner, et al.          Informational                   [Page 30] three network parts.

               Requirements for QoS Signaling Protocols       May      July 2002

   gates and

10.5    Scenario: Session Mobility

   In this scenario, a session is moved from one end-system to configure per-flow policers, i.e. another.
   Ongoing sessions are kept and QoS parameters need to authorize or
   forbid user traffic.

   The QC be adapted,
   since it is (of course) not part of very likely that the standard UMTS architecture.
   However, to achieve end-to-end QoS a QC new device provides different
   capabilities. Note that it is needed such open which entity initiates the move,
   which implies that the PCF
   can request a QoS connection to the IP network. As in the previous
   example, the QC could manage initiator might be triggered by different
   entities.

   User mobility (i.e., a set of pre-provisioned resources in user changing the IP network, i.e. bandwidth pipes, device and therefore moving
   the QC performs per-flow
   admission control into these pipes. In this way, a connection can be
   made between two UMTS access networks, and hence, end-to-end QoS can sessions to the new device) is considered to be achieved. In this a special case
   within the QI and QC are clearly two separate
   entities.
   This use case clearly illustrates session mobility scenario.

   Note that this scenario is different from terminal mobility. Not the need for an "NSIS" QoS
   signaling protocol between QI and QC. An important application of
   such
   terminal (end-system) has moved to a protocol may be its use in the inter-connection of UMTS
   networks over different access point. Both
   terminals are still connected to an IP backbone.

8.4 Wired part of wireless network

   A wireless network, seen from a QoS domain perspective, usually
   consists of three parts: a wireless interface part (the "radio
   interface"), a wired part of at their original
   points.

   The issues include:

   1) Keeping the wireless network (i.e., Radio
   Access Network) and QoS guarantees negotiated implies that the backbone end-
   point(s) of communication are changed without changing the wireless network, as shown
   in Figure 2. Note that this figure should not be seen as an
   architectural overview
   reservations.

   2) The trigger of wireless networks but rather as showing the conceptual QoS domains session move might be the user or any other
   party involved in a wireless network.

   In this scenario, a mobile host can roam and perform a handover
   procedure between base stations/access routers. In this scenario the
   NSIS session.

10.6    Scenario: QoS protocol can be applied reservations/negotiation from access to core
    network

   The scenario includes the signaling between a base station access networks and the
   gateway (GW).  In this case a GW can also core
   networks in order to setup and change reservations together with
   potential negotiation.

   The issues to be considered as a local
   handover anchor point. Furthermore, solved in this scenario are different from previous
   ones.

   1) The entity of reservation is most likely an aggregate.

   2) The time scales of reservations might be different (long living
   reservations of aggregates, rarer re-negotiation).

   3) The specification of the NSIS traffic (amount of traffic), a
   particular QoS
   protocol can also is guaranteed for, needs to be applied either between two GWs, or between two
   edge routers (ER).

                             |--|
                             |GW|
      |--|                   |--|
      |MH|---                  .
      |--|  / |-------|        .
           /--|base   | |--|   .
              |station|-|ER|....
              |-------| |--|   .  |--| back- |--|  |---|
   |----|

   ...|ER|.......|ER|..|BGW|.."Internet"..|host|
           -- |-------| |--|   .  |--| bone  |--|  |---|
   |----|
      |--| \  |base   |-|ER|...     .
      |MH|  \ |station| |--|        .
      |--|--- |-------|             .          MH  = mobile host
                                 |--|          ER  = edge router
         <---->                  |GW|          GW  = gateway
        Wireless link            |--|          BGW = border gateway

   Brunner, et al.          Informational                   [Page 31] changed. E.g., in case
   additional flows are added to the aggregate, the traffic
   specification of the flow needs to be added if it is not already
   included in the aggregates specification.

   4) The flow specification is more complex including network
   addresses and sets of different address for the source as well as
   for the destination of the flow.

               Requirements for QoS Signaling Protocols       May      July 2002

                                               ... = interior nodes
               <------------------->
         Wired part of wireless network

      <---------------------------------------->
                   Wireless Network

      Figure 2.

10.7    Scenario: QoS architecture of wired part reservation/negotiation over administrative
    boundaries

   Signaling between two or more core networks to provide QoS is
   handled in this scenario. This might also include access to core
   signaling over administrative boundaries. Compared to the previous
   one it adds the case, where the two networks are not in the same
   administrative domain. Basically, it is the inter-domain/inter
   provider signaling which is handled in here.

   The domain boundary is the critical issue to be resolved. Which as
   various flavors of wireless issues a QoS signaling protocol has to be
   concerned with.

   1) Competing administrations: Normally, only basic information
   should be exchanged, if the signaling is between competing
   administrations. Specifically information about core network

   Each of these parts
   internals (e.g., topology, technology, etc.) should not be
   exchanged. Some information exchange about the "access points" of
   the wireless network impose different issues core networks (which is topology information as well) may need
   to be solved exchanged, because it is needed for proper signaling.

   2) Additionally, as in scenario 4, signaling most likely is based on
   aggregates, with all the QoS signaling solution being used:

   * Wireless interface: The solution for issues raise there.

   3) Authorization: It is critical that the air interface link
     has QoS initiator is
   authorized to ensure flexibility and spectrum efficient transmission
     of IP packets.  However, this link layer perform a QoS can path setup.

   4) Accountability: It is important to notice that signaling might be solved in
     the same way
   used as any other last hop problem by allowing a
     host an entity to request charge money for, therefore the proper interoperation
   with accounting needs to be available.

10.8    Scenario: QoS profile.

   * Wired part of the wireless network:  This is the part of signaling between PSTN gateways and backbone
    routers

   A PSTN gateway (i.e., host) requires information from the network that is closest
   regarding its ability to transport voice traffic across the base stations/access
     routers.  It network.
   The voice quality will suffer due to packet loss, latency and
   jitter. Signaling is an IP network although some parts logically
     perform tunneling of the end user data. used to identify and admit a flow for which
   these impairments are minimized.  In cellular networks, addition, the wired part disposition of
   the wireless network signaling request is denoted as a
     radio access network.

     This part of used to allow the wireless network has different
     characteristics when compared PSTN GW to traditional IP networks:

         1. The network supports make a high proportion of real-time
            traffic.  The majority of the traffic transported in the
            wired part of call
   routing decision before the wireless network is speech, which call is
            very sensitive to delays actually accepted and delay variation (jitter).

         2. The network must support mobility.  Many wireless
            networks are able delivered
   to provide a combination the final destination.

   PSTN gateways may handle thousands of soft calls simultaneously and hard handover procedures.  When handover occurs,
            reservations need to there
   may be established on new paths.
            The establishment time has hundreds of PSTN gateways in a single provider network. These
   numbers are likely to be as short increase as possible
            since long establishment times for reservations degrade the performance of the wireless network.  Moreover,
            for maximal utilization size of the radio spectrum, frequent
            handover operations are required.

         3. These links are typically rather bandwidth-limited.

         4. The wired transmission in such a network contains a
            relatively high volume of expensive leased lines.
            Overprovisioning might therefore be prohibitively
            expensive.

         5. increases.
   The radio base stations are spread over point being that scalability is a wide
            geographical area and major issue.

   There are in general situated several ways that a large
            distance from PSTN gateway can acquire assurances
   that a network can carry its traffic across the backbone.

   Brunner, et al.          Informational                   [Page 32] network. These
   include:

     1. Over-provisioning a high availability network.

               Requirements for QoS Signaling Protocols       May      July 2002

   * Backbone

     2. Handling admission control through some policy server
        that has a global view of the wireless network: the requirements imposed
     by this network are similar and its resources.
     3. Per PSTN GW pair admission control.
     4. Per call admission control (where a call is defined as
        the 5 tuple used to carry a single RTP flow).

   Item 1 requires no signaling at all and is therefore outside the requirements imposed by
     other types
   scope of backbone networks.

   Due this working group.

   Item 2 is really a better informed version of 1, but it is also
   outside the scope of this working group as it relies on a particular
   telephony signaling protocol rather than a packet admission control
   protocol.

   Item 3 is initially attractive as it appears to these very different characteristics and requirements, often
   contradictory, different QoS signalling solutions might be needed have reasonable
   scaling properties, however, its scaling properties only are
   effective in
   each of the three network parts.

8.5 Scenario: Session Mobility cases where there are relatively few PSTN GWs. In this scenario, the
   more general case were a session is moved from one end-system PSTN GW reduces to another.
   Ongoing sessions a single IP phone
   sitting behind some access network, the opportunities for
   aggregation are kept reduced and QoS parameters need the problem reduces to be adapted,
   since it item 4.

   Item 4 is very likely that the new device provides different
   capabilities. Note that most general case. However, it has the most difficult
   scaling problems. The objective here is open which entity initiates to place the move,
   which implies requirements on
   Item 4 such that the QoS initiator might be triggered by different
   entities.

   User mobility (i.e., a user changing scalable per-flow admission control protocol or
   protocol suite may be developed.

   The case where per-flow signaling extends to individual IP end-
   points allows the device inclusion of IP phones on cable, DSL, wireless or
   other access networks in this scenario.

   Call Scenario

   A PSTN GW signals end-to-end for some 5 tuple defined flow a
   bandwidth and therefore moving QoS requirement. Note that the sessions 5 tuple might include
   masking/wildcarding. The access network admits this flow according
   to its local policy and the new device) is considered to be a special case
   within specific details of the session mobility scenario. access
   technology.

   At the edge router (i.e., border node), the flow is admitted, again
   with an optional authentication process, possibly involving an
   external policy server.  Note that this scenario the relationship between the PSTN
   GW and the policy server and the routers and the policy server is different from terminal mobility. Not
   outside the
   terminal (end-system) has moved to a different access point. Both
   terminals are still connected to an IP network at their original
   points. scope of NSIS. The issues include:

   1) Keeping edge router then admits the QoS guarantees negotiated implies that flow into
   the end-
   point(s) core of communication are changed without changing the
   reservations.

   2) The trigger of network, possibly using some aggregation technique.

   At the session move might be interior nodes, the user NSIS host-to-host signaling should either
   be ignored or any other
   party involved in invisible as the session.

8.6 Scenario: QoS reservations/negotiation from access Edge router performed the admission
   control decision to core network

   The scenario includes some aggregate.

   At the inter-provider router (i.e., border node), again the NSIS
   host-to-host signaling between access networks and core
   networks in order to setup and change reservations together with
   potential negotiation.

   The issues to should either be solved in this scenario are different from previous
   ones.

   1) The entity of reservation is most likely ignored or invisible as the
   Edge router has performed an aggregate.

   2) The time scales of reservations might be different (long living
   reservations of aggregates, rarer re-negotiation).

   3) The specification admission control decision about an
   aggregate across a carrier network.

               Requirements for QoS Signaling Protocols      July 2002

10.9    Scenario: PSTN trunking gateway

   One of the traffic (amount use cases for the NSIS signaling protocol is the scenario
   of traffic), a
   particular interconnecting PSTN gateways with an IP network that supports
   QoS.
   Four different scenarios are considered here.
     1. In-band QoS is guaranteed for, needs to be changed. E.g., in signaling is used. In this case
   additional flows are added to the aggregate, Media Gateway
        (MG) will be acting as the traffic

   Brunner, et al.          Informational                   [Page 33]
               Requirements for QoS Signaling Protocols       May 2002

   specification of Initiator and the flow needs to Edge Router
        (ER) will be added if it is not already
   included in the aggregates specification.

   4) The flow specification is more complex including network
   addresses and sets of different address for QoS Controller. Hence, the source as well as ER should do
        admission control (into pre-provisioned traffic trunks) for the destination of
        individual traffic flows. This scenario is not further
        considered here.
     2. Out-of-band signaling in a single domain, the flow.

8.7 Scenario: QoS reservation/negotiation over administrative
    boundaries

   Signaling between two or more core networks to provide QoS Controller is
   handled
        integrated in the MGC. In this scenario. This might also include access to core case no NSIS protocol is
        required.
     3. Out-of-band signaling over administrative boundaries. Compared to the previous
   one it adds the case, where the two networks are not in a single domain, the same
   administrative domain. Basically, it QoS Controller is the inter-domain/inter
   provider
        a separate box. In this case NSIS signaling which is handled in here.

   The domain boundary is used between the critical issue to be resolved. Which as
   various flavors of issues a QoS signaling protocol has to be
   concerned with.

   1) Competing administrations: Normally, only basic information
   should be exchanged, if
        MGC and the QoS Controller.
     4. Out-of-band signaling is between competing
   administrations. Specifically information about core network
   internals (e.g., topology, technology, etc.) should not multiple domains, the QoS
        Controller (which may be
   exchanged. Some information exchange about integrated in the "access points" MGC) triggers the
        QoS Controller of the core networks (which next domain.

   When the out-of-band QoS signaling is topology information as well) may need
   to used the Media Gateway
   Controller (MGC) will be exchanged, because it is needed for proper signaling.

   2) Additionally, acting as in the QoS Initiator.

   In the second scenario 4, signaling most likely is based on
   aggregates, with all the issues raise there.

   3) Authorization: It is critical voice provider manages a set of traffic
   trunks that are leased from a network provider. The MGC does the
   admission control in this case. Since the QoS initiator is
   authorized to perform Controller acts both
   as a QoS path setup.

   4) Accountability: It is important to notice that signaling might be
   used as an entity to charge money for, therefore the interoperation
   with accounting needs to be available.

8.8 Scenario: Initiator and a QoS Controller, no NSIS signaling between is
   required. This scenario is shown in figure 1.

      +-------------+    ISUP/SIGTRAN     +-----+              +-----+
      | SS7 network |---------------------| MGC |--------------| SS7 |
      +-------------+             +-------+-----+---------+    +-----+
            :                    /           :             \
            :                   /            :              \
            :                  /    +--------:----------+    \
            :          MEGACO /    /         :           \    \
            :                /    /       +-----+         \    \
            :               /    /        | NMS |          \    \
            :              /     |        +-----+          |     \
            :              :     |                         |     :
     +--------------+  +----+    |   bandwidth pipe (SLS)  |  +----+
     | PSTN gateways and backbone routers

   A network |--| MG |--|ER|======================|ER|-| MG |--
     +--------------+  +----+     \                       /   +----+
                                   \     QoS network     /
                                    +-------------------+

                 Figure 1: PSTN trunking gateway (i.e., host) requires information from scenario

   In the third scenario, the network
   regarding its ability to transport voice provider does not lease traffic across
   trunks in the network.
   The voice quality will suffer due to packet loss, latency and
   jitter. Signaling is used to identify Another entity may lease traffic trunks and admit
   may use a flow for which
   these impairments are minimized. QoS Controller to do per-flow admission control. In addition, the disposition of this
   case the NSIS signaling request is used to allow the PSTN GW to make a call
   routing decision before the call is actually accepted and delivered
   to between the final destination.

   PSTN gateways may handle thousands of calls simultaneously MGC and there
   may be hundreds of PSTN gateways in a single provider network. These
   numbers are likely to increase as the size of the network increases.
   The point being that scalability is a major issue.

   Brunner, et al.          Informational                   [Page 34] QoS
               Requirements for QoS Signaling Protocols       May      July 2002

   There are several ways that

   Controller, which is a separate box here. Hence, the MGC acts only
   as a QoS Initiator. This scenario is depicted in figure 2.

      +-------------+    ISUP/SIGTRAN     +-----+              +-----+
      | SS7 network |---------------------| MGC |--------------| SS7 |
      +-------------+             +-------+-----+---------+    +-----+
            :                    /           :             \
            :                   /         +-----+           \
            :                  /          | QC  |            \
            :                 /           +-----+             \
            :                /               :                 \
            :               /       +--------:----------+       \
            :       MEGACO :       /         :           \       :
            :              :      /       +-----+         \      :
            :              :     /        | NMS |          \     :
            :              :     |        +-----+          |     :
            :              :     |                         |     :
     +--------------+  +----+    |   bandwidth pipe (SLS)  |  +----+
     | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
     +--------------+  +----+     \                       /   +----+
                                   \     QoS network     /
                                    +-------------------+

                 Figure 2: PSTN trunking gateway can acquire assurances
   that a scenario

   In the fourth scenario multiple transport domains are involved. In
   the originating network can carry its traffic across either the network. These
   include:

     1. Over-provisioning a high availability network.
     2. Handling admission control through some policy server
        that has a global view MGC may have an overview on the
   resources of the overlay network and its resources.
     3. Per PSTN GW pair admission control.
     4. Per call admission control (where a call is defined as
        the 5 tuple used to carry or a single RTP flow).

   Item 1 requires no signaling at all and is therefore outside separate QoS Controller will
   have the
   scope of overview. Hence, depending on this working group.

   Item 2 is really a better informed version either the MGC or the
   QoS Controller of 1, but it is also
   outside the scope originating domain will contact the QoS
   Controller of this working group the next domain. The MGC always acts as it relies on a particular
   telephony signaling protocol rather than a packet admission control
   protocol.

   Item 3 is initially attractive QoS
   Initiator and may also be acting as it appears to have reasonable
   scaling properties, however, its scaling properties only are
   effective a QoS Controller in cases where there are relatively few PSTN GWs. In the
   more general case were a PSTN GW reduces to first
   domain.

10.10   Scenario: Application request end-to-end QoS path from the
    network

   This is actually the easiest case, nevertheless might be most often
   used in terms of number of users. So multimedia application requests
   a single guaranteed service from an IP phone
   sitting behind some access network, network. We assume here that the
   application is somehow able to specify the opportunities for
   aggregation network service. The
   characteristics here are reduced and that many hosts might do it, but that the problem reduces to item 4.

   Item 4
   requested service is low capacity (bounded by the most general case. However, it has access line).
   Additionally, we assume no mobility and standard devices.

10.11   Scenario: QOS for Virtual Private Networks

   In a Virtual Private Network (VPN) a variety of tunnels might be
   used between its edges. These tunnels could be for example, IP-Sec,
   GRE, and IP-IP. One of the most difficult
   scaling problems. The objective here significant issues in VPNs is
   related to place the requirements on
   Item 4 such that how a scalable per-flow admission control protocol or flow is identified and what quality a flow gets. A
   flow identification might consist among others of the transport
               Requirements for QoS Signaling Protocols      July 2002

   protocol suite may port numbers. In an IP-Sec tunnel this will be developed.

   The case problematic
   since the transport protocol information is encrypted.

   There are two types of L3 VPNs, distinguished by where per-flow signaling extends to individual IP end-
   points allows the inclusion endpoints
   of IP phones the tunnels exist. The endpoints of the tunnels may either be on cable, DSL, wireless
   the customer (CPE) or
   other access the provider equipment or provider edge (PE).

   Virtual Private networks are also likely to request bandwidth or
   other type of service in this scenario.

   Call Scenario

   A addition to the premium services the PSTN
   GW signals end-to-end are likely to use.

   Tunnel end points at the Customer premises

   When the endpoints are the CPE, the CPE may want to signal across
   the public IP network for some 5 tuple defined flow a particular amount of bandwidth and QoS requirement. Note that
   for the 5 tuple might include
   masking/wildcarding. The access network admits this flow according tunnel aggregate. Such signaling may be useful when a
   customer wants to its local policy and the specific details of vary their network cost with demand, rather than
   paying a flat rate. Such signaling exists between the two CPE
   routers. Intermediate access
   technology.

   At the and edge router (i.e., border node), routers perform the flow is admitted, again
   with an optional same exact
   call admission control, authentication process, possibly involving an
   external policy server.  Note that and aggregation functions
   performed by the relationship between corresponding routers in the PSTN GW and scenario with
   the policy server and exception that the routers endpoints are the CPE tunnel endpoints rather
   than PSTN GWs and the policy server is
   outside 5-tuple used to describe the scope of NSIS. The edge router then admits RTP flow is
   replaced with the corresponding flow into spec to uniquely identify the core
   tunnels. Tunnels may be of the network, possibly using some aggregation technique.

   At the interior nodes, the any variety (e.g. IP-Sec, GRE, IP-IP).

   In such a scenario, NSIS would actually allow partly for customer
   managed VPNs, which means a customer can setup VPNs by subsequent
   NSIS host-to-host signaling should either
   be ignored or invisible as the Edge router performed the admission
   control decision to some aggregate.

   Brunner, et al.          Informational                   [Page 35]
               Requirements for QoS Signaling Protocols       May 2002

   At various end-point. Plus the inter-provider router (i.e., border node), again tunnel end-points are
   not necessarily bound to an application. The customer administrator
   might be the one triggering NSIS
   host-to-host signaling should either be ignored or invisible as signaling.

   Tunnel end points at the
   Edge router has performed an admission control decision about an
   aggregate across a carrier network.

8.9 PSTN trunking gateway

   One of provider premises

   In the use cases for case were the NSIS signaling protocol is tunnel end-points exist on the scenario
   of interconnecting PSTN gateways with an IP network that supports
   QoS.
   Four different scenarios are considered here.
     1.        In-band QoS signaling provider edge,
   requests for bandwidth may be signaled either per flow, where a flow
   is used. defined from a customers address space, or between customer
   sites.

   In this case the Media Gateway
        (MG) will be acting as the QoS Initiator and case of per flow signaling, the Edge Router
        (ER) will be PE router must map the QoS Controller. Hence,
   bandwidth request to the ER should do
        admission control (into pre-provisioned tunnel carrying traffic trunks) for to the
        individual traffic flows. This scenario is not further
        considered here.
     2.        Out-of-band signaling destination
   specified in a single domain, the QoS Controller flow spec. Such a tunnel is
        integrated in a member of an
   aggregate to which the MGC. flow must be admitted. In this case no NSIS protocol is
        required.
     3.        Out-of-band signaling in a single domain, case, the QoS Controller
   operation of admission control is very similar to the case of the
   PSTN GW with the additional level of indirection imposed by the VPN
   tunnel. Therefore, authentication, accounting and policing may be
   required on the PE router.

   In the case of per site signaling, a separate box. site would need to be
   identified. This may be accomplished by specifying the network
   serviced at that site through an IP prefix. In this case NSIS signaling case, the
   admission control function is used between performed on the
        MGC and aggregate to the QoS Controller.
     4.        Out-of-band signaling between multiple domains, PE
   router connected to the site in question.

               Requirements for QoS
        Controller (which Signaling Protocols      July 2002

Full Copyright Statement

  Copyright (C) The Internet Society (2000). All Rights Reserved.
  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works. However, this
  document itself may not be integrated modified in the MGC) triggers the
        QoS Controller of the next domain.

   When the out-of-band QoS signaling is used the Media Gateway
   Controller (MGC) will be acting any way, such as by removing
  the QoS Initiator.

   In copyright notice or references to the second scenario Internet Society or other
  Internet organizations, except as needed for the voice provider manages a set purpose of traffic
   trunks that are leased from a network provider. The MGC does the
   admission control
  developing Internet standards in this case. Since which case the QoS Controller acts both
   as a QoS Initiator and a QoS Controller, no NSIS signaling is
   required. This scenario is shown in figure 1.

      +-------------+    ISUP/SIGTRAN     +-----+              +-----+
      | SS7 network |---------------------| MGC |--------------| SS7 |
      +-------------+             +-------+-----+---------+    +-----+
            :                    /           :             \
            :                   /            :              \
            :                  /    +--------:----------+    \
            :          MEGACO /    /         :           \    \
            :                /    /       +-----+         \    \
            :               /    /        | NMS |          \    \
            :              /     |        +-----+          |     \
            :              :     |                         |     :
     +--------------+  +----+    |   bandwidth pipe (SLS)  |  +----+
     | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
     +--------------+  +----+     \                       /   +----+
                                   \     QoS network     /
                                    +-------------------+

   Brunner, et al.          Informational                   [Page 36]
               Requirements procedures for QoS Signaling Protocols       May 2002

                 Figure 1: PSTN trunking gateway scenario

   In the third scenario, the voice provider does not lease traffic
   trunks
  copyrights defined in the network. Another entity may lease traffic trunks Internet Standards process must be
  followed, or as required to translate it into languages other than
  English.
  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.
  This document and
   may use a QoS Controller to do per-flow admission control. In this
   case the NSIS signaling information contained herein is used between the MGC provided on an
  "AS IS" basis and the QoS
   Controller, which THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN
  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Open Issues/To Dos

   2) (OPEN) Sender/receiver initiation

   What is a separate box here. Hence, the MGC acts only
   as requirement concerning data sender or data receiver or
   both to initiate a QoS Initiator. This scenario is depicted in figure 2.

      +-------------+    ISUP/SIGTRAN     +-----+              +-----+
      | SS7 network |---------------------| MGC |--------------| SS7 |
      +-------------+             +-------+-----+---------+    +-----+
            :                    /           :             \
            :                   /         +-----+           \
            :                  /          | QC  |            \
            :                 /           +-----+             \
            :                /               :                 \
            :               /       +--------:----------+       \
            :       MEGACO :       /         :           \       :
            :              :      /       +-----+         \      :
            :              :     /        | NMS |          \     :
            :              :     |        +-----+          |     :
            :              :     |                         |     :
     +--------------+  +----+    |   bandwidth pipe (SLS)  |  +----+
     | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
     +--------------+  +----+     \                       /   +----+
                                   \     QoS network     /
                                    +-------------------+

                 Figure 2: PSTN trunking gateway scenario

   In the fourth scenario multiple transport domains are involved. In 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 originating network either 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 MGC may have an overview QoS requests with other signaling - registration,
   etc.)?

   - For reciever initiated, do we need protection against spamming -
   how do we protect against unwanted changes?
               Requirements for QoS Signaling Protocols      July 2002

   4) (OPEN) MUSTs, SHOULDs, MAY needs discussion

   28) (OPEN) new requirement on "asynchronous events from the
   resources network"

   The content of the overlay message might be very service specific, but the
   protocol support for asynchronous events from the network or might be a separate QoS Controller will
   valuable requirement. We have the overview. Hence, depending on this either the MGC or the
   QoS Controller something about notification in case
   of errors/failures.

   Asynchronous notification of the originating domain will contact the QoS
   Controller Initiator, Controller, Receiver,
   there are security issues related. Basically, an ownership issue.
   Nevertheless, an asynch notifcation in case of the next domain. The MGC always acts 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 a QoS
   Initiator and may also be acting soon as we have a QoS Controller more clear idea about service description issue

   53) (OPEN) Error handling

   Comments:
   1) notification of user in the first
   domain.

8.10    Scenario: Application request end-to-end QoS path from the
    network

   This is actually the most easy case, nevertheless might case of unrecoverable errors (has been
   done by notification requirement, or will be most
   often used in terms done by asynch
   notification, issue 43)
   A description of number both types of users. So multimedia application
   requests a guaranteed service from an IP network. We assume here
   that the application is somehow able to specify the network service.
   The characteristics here errors (recoverable, unrecoverable)
   are that many hosts might do it, but that listed in Section 5.3.4.

   2) hop-by-hop? OR right to the requested service end?

   3) What is low capacity (bounded potential value to notify about recoverable errors?
   Proposal: not hop by the access line).
   Additionally, we assume no mobility and standard devices.

   Brunner, et al.          Informational                   [Page 37]
               Requirements for hop, but QoS Signaling Protocols       May 2002

9  Acknowledgments

   Quite a number of people have been involved in the discussion of the
   draft, adding some ideas, requirements, etc. We list them without a
   guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul
   (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas
   Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC),
   Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical
   University Berlin), Xiaoming Fu (Technical University Berlin), Hans-
   Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph
   Niedermeier (Siemens), Andreas Kassler (University controller to QoS initiator

   59) (OPEN) add req: ability to deal with severe congestion (req
   5.3.4 of Ulm), Ilya
   Freytsis.

   Some text and/or ideas for text, requirements, scenarios have been
   taken 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 draft written service
   point of view this is failure
   - hop by hop problem (issue from Jorge)
   - What difference does it make (from the following authors: David Partain
   (Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia),
   Georgios Karagiannis (Ericsson), Jukka Manner (University of
   Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars
   Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have
   actively contributed new text 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 draft as well.

   Another draft impacting protocol is to signal this draft has been written by Sven Van den
   Bosch, Maarten Buchli, 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 Danny Goderis. These people contributed
   also with new text.

10 Author's Addresses

   Marcus Brunner (Editor)
   NEC Europe Ltd.
   Network Laboratories
   Adenauerplatz 6
   D-69115 Heidelberg
   Germany
   E-Mail: brunner@ccrle.nec.de (contact)

   Robert Hancock, Eleanor Hepworth
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom
   E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk

   Cornelia Kappler
   Siemens AG
   Berlin  13623
   Germany
   E-Mail: cornelia.kappler@icn.siemens.de

   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munchen
   Germany
   Email: Hannes.Tschofenig@mchp.siemens.de

   Brunner, et al.          Informational                   [Page 38] error
   restistance
   An NSIS protocol must define behaviour of NSIS signaling units
   during unexpected situations. Unexpected situtions are unknown
               Requirements for QoS Signaling Protocols       May      July 2002

Full Copyright Statement
  Copyright (C) The Internet Society (2000). All Rights Reserved.
  This document

   messages, parameters and translations parameter settings as well as receiption of it may be copied and furnished
   unexpected messages (e.g. a "Reservation Confirmation" without prior
   "Reservation Request").

   Related to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published Open issues (53) and distributed, in whole or in part, without restriction of any
  kind, provided requirement 5.3.4.
   This requirement is emphasizing to many details that the above copyright notice and this paragraph are
  included on all such copies and derivative works. However, this
  document itself may might not be modified in any way, such as by removing
  the copyright notice or references
   necessary

   Req 5.3.4 refers to behaviour in the Internet Society or other
  Internet organizations, except as needed for the purpose case of
  developing Internet standards problems in which case the procedures for
  copyrights defined data
   plane. My suggestion here is about unexpected events/errors in the Internet Standards process must be
  followed, or as required
   control plane. If you think that this point carries to translate many details,
   let's split it into languages other than
  English.
  The limited permissions granted above are perpetual up in several individual requirements.

   72) (OPEN) request to add "Error notification and will not be
  revoked by the Internet Society error location"

   "An NSIS signaling node rejecting or releasing a reservation must
   indicate its successors identity. NSIS signalling should indicate why a
   requested resource is not or assigns.
  This document and the information contained herein no longer available. "

   Compared to 5.3.4 this is provided about problems on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN
  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Open Issues/To Dos the control plane

Closed Issues

   1) (OPEN) (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.

   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:

   Brunner, et al.          Informational                   [Page 39]
               Requirements for QoS Signaling Protocols       May 2002

   - 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?

   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

   4) (OPEN) MUSTs, SHOULDs, MAY needs discussion

   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.

               Requirements for QoS Signaling Protocols      July 2002

   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) (OPEN) (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.

   needs more WG discussion, potentially even cross-WG

   added exclusion

   8) (OPEN) (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.

   Brunner, et al.          Informational                   [Page 40]
               Requirements for QoS Signaling Protocols       May 2002

   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 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 problems with RSVP, particularly in a
   mobile environment. 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.)
               Requirements for QoS Signaling Protocols      July 2002

   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

   Brunner, et al.          Informational                   [Page 41]
               Requirements for QoS Signaling Protocols       May 2002
   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) (OPEN, dependend on resolution of bi-directional) (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."

   open issue: first resolve the bi-directional issue which is somewhat
   related, because it seams to be an optimization as well

   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.

               Requirements for QoS Signaling Protocols      July 2002

   16) (OPEN) (CLOSED) Req: 5.1.9 change provisioning into better term, since
   different people understand different thing with provisioning

   open action for Anders

   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

   Brunner, et al.          Informational                   [Page 42]
               Requirements for QoS Signaling Protocols       May 2002

   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
               Requirements for QoS Signaling Protocols      July 2002

   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) (OPEN) (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

   Brunner, et al.          Informational                   [Page 43]
               Requirements for QoS Signaling Protocols       May 2002
   Motivation: this heavily depends on the service definition and is
   therefore out of scope

   removed

   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.

   29) (OPEN) (CLOSED) NSIS in case of handovers
   The whole mobility area needs to be defined
   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.

               Requirements for QoS Signaling Protocols      July 2002

   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.

   Brunner, et al.          Informational                   [Page 44]
               Requirements for QoS Signaling Protocols       May 2002
   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) (OPEN) (CLOSED) req "Independence of reservation identifier"
   issue here is that this might only be valuable in mobile
   environments, and complicate the protocol for other environemnts. environments.

   there are related issues (37,38,

   37) (OPEN) (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) (OPEN) (CLOSED) definition of security threats
   handled in draft-tschofenig-nsis-threats-00.txt

   39) (OPEN) (CLOSED) simplify security requirements section
   done

   40) (OPEN) (CLOSED) add mobility related requirements
   we have some mobility related requirements, but do not need to add
   more
               Requirements for QoS Signaling Protocols      July 2002

   41) (CLOSED) remove req 5.5.1 Mutability information on parameters
   removed because it is service-specific

   42) (OPEN) (CLOSED) add an assumption that QoS nmonitoring monitoring is application-
   specific and with it out of scope of the WG (done)

   43) (OPEN) (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 layes
   (appluications etc. as well.

   44) (OPEN) req 5.1.2 resource availability info on request come back
   to it as soon as we have a more clear idea about service description
   issue to notify upper layers,
   applications etc. as well.

   45) (OPEN) (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)

   Brunner, et al.          Informational                   [Page 45]
               Requirements

   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 Signaling Protocols       May 2002 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) (OPEN) (CLOSED) we might need multiple scenario scenarios for failure and
   recovery cases to derive requirements. Or a list failre of failure cases
   might be a start as well.

   47) (OPEN) (CLOSED) traffic engineering  and route pinning
   I assume this would result in operational type of requirements
   Opinions on that?
   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
               Requirements for QoS Signaling Protocols      July 2002

   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

   Brunner, et al.          Informational                   [Page 46]
               Requirements for QoS Signaling Protocols       May 2002
   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) (OPEN) New requirement: interaction with policy
   this most likely is covered by an opaque token for authentication
   dependency on security changes

   53) (OPEN) Section 5.3. 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 that the end?

   3) What boundary between new and re-used stuff is pretty
   shaky. The requirement is trying to scope our problem (a) to
   eliminate the potential value overlap, and (b) to notify about recoverable errors?
   Proposal: not hop by hop, but QoS controller keep the new NSIS stuff
   simple.

   However, we are aware that it is very difficult to QoS initiator 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"
               Requirements for QoS Signaling Protocols      July 2002

    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.

   Brunner, et al.          Informational                   [Page 47]
               Requirements for QoS Signaling Protocols       May 2002
   "

   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
   (śśminimal impact on coreŲ) 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

   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 (CLOSED) add req 5.3.2 from draft-partain-...-00

   - the protocol fast establishment req is to signal this failure to other
   participants (QCs or QI) handled by the low setup latency
   req, and the scalability in handover req

   - added the hope that they can do something
   meaningful (e.g. re-routing) text to correct the problem or tear down the
   flow. 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
               Requirements for QoS Signaling Protocols      July 2002

   mobile node itself or triggered by the access point that the mobile
   node is attached to.  In the first case, the QoS signalling should

   Brunner, et al.          Informational                   [Page 48]
               Requirements for QoS Signaling Protocols       May 2002
   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) (OPEN) (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."

   Opinions?

   not added
   ---------------------------------------------------
   starting from -02 version
   ---------------------------------------------------

   62) (OPEN) (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) (OPEN) (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.

   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

   we can take 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.

   Brunner, et al.          Informational                   [Page 49]
               Requirements for QoS Signaling Protocols       May 2002 if we have NSIS.

   66) (OPEN) (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) (OPEN) (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) (OPEN) (CLOSED) Request to add req: Preventation of stale state
               Requirements for QoS Signaling Protocols      July 2002

   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) (OPEN) (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.

   Do we really require this? Isn't this a soft state versus hard state
   issue? transmission of signaling
   information.

   Added some of the text to req 5.11.1

   70) (OPEN) (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

   Brunner, et al.          Informational                   [Page 50]
               Requirements for QoS Signaling Protocols       May 2002
   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.

   72) (OPEN) request to

   --------------------------
   starting from -03 version
   --------------------------

   73) (CLOSED) 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 table of contents
               Requirements for QoS Signaling Protocols      July 2002

   ------------------------------------------------------
   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, 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)
               Requirements for QoS Signaling Protocols      July 2002

   [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 NSIS QoS signalling protocol may carry
   identification area of mobility protocols (e.g. CT and CAR
   discovery). (done)

   [28] Asynchronous events from the QoS controllers located at 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 boundaries issue: done)

   [37] Ownership of a
   domain. However, the identification 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 edge 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 visible 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
   the end host (QoS initiator) and only applies within one QoS
   administrative domain.

   - closed issue 57: add write submissions.
   [59] Covered under [53].
   [61] Closed. (done)
   [64] Closed (no new text except maybe motherhood statements). (done)
               Requirements for QoS Signaling Protocols      July 2002

   [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 "Minimal impact on interior (core)
   nodes" graceful failover to requirement 5.6.8 "Ability general protocol
   requirements section. (done)
   [72] Closed. Should be possible for NSIS to constrain load on devices"

   - added requirement "Allow efficient QoS re-establishment after
   handover", closed issue 60. transport useful error
   messages.

   - changed security text in 5.3.2

   Brunner, et al.          Informational                   [Page 51]
   - rearranged open issues (open ones on top)