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

                   Requirements for QoS Signaling Protocols
                       <draft-ietf-nsis-req-03.txt>
                       <draft-ietf-nsis-req-04.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.

               Requirements for QoS Signaling Protocols      July 2002

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines requirements for signaling QoS across different
   network environments, where different network environments across
   administrative and technology domains. Signaling is mainly though
   for QoS such as [1], however in recent year several other
   applications of signaling have been defined such as signaling for
   MPLS label distribution [2]. 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
   need to be solved. We present the assumptions and the aspects not
   considered within scope before listing the requirements grouped
   according to areas such as architecture and design goals, signaling
   flows, layering, performance, flexibility, security, and mobility.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119.

Table of Contents

   Status of this Memo...................................................1
Abstract..............................................................2 Memo................................................1
   Abstract...........................................................1
   Table of Contents.....................................................2 Contents..................................................2
   1 Introduction.......................................................4  Introduction...................................................3
   2 Terminology........................................................5  Terminology....................................................4
   3  Problem Statement and Scope........................................8 Scope....................................6
   4  Assumptions and Exclusions........................................10 Exclusions.....................................8
   4.1  Assumptions and Non-Assumptions...............................10 Non-Assumptions..............................8
   4.2  Exclusions....................................................11  Exclusions...................................................9
   5 Requirements......................................................12  Requirements..................................................11
   5.1  Architecture and Design Goals.................................13 Goals...............................11
   5.1.1 Applicability MUST be applicable for different QoS technologies................13 technologies...............11
   5.1.2 Resource availability information on request................13 request................12
   5.1.3 Modularity..................................................13 NSIS MUST be designed modular...............................12
   5.1.4 Decoupling of NSIS MUST decouple protocol and information it is carrying.......14 information.................12
   5.1.5 Reuse of NSIS MUST reuse existing QoS provisioning..........................14 provisioning...................12
   5.1.6 Independence of signaling and provisioning paradigm.........14 paradigm.........12
   5.1.7 Application independence....................................13
   5.2  Signaling Flows...............................................14 Flows.............................................13
   5.2.1 Free placement of QoS Initiator and QoS Controllers functions14 NSIS Initiator, Forwarder, Responder......13
   5.2.2 No constraint of the QoS signaling and QoS Controllers NSIS Forwarders to be in
   the data path.....................................................14 path.....................................................13
   5.2.3 Concealment of topology and technology information..........15 information..........14
   5.2.4 Optional transparency Transparency of QoS signaling to network...........15 network........................14
   5.3  Additional information beyond signaling of QoS information....16 for a service.......14
   5.3.1 Explicit release of resources...............................16 resources...............................14
   5.3.2 Possibility for automatic release of resources after failure 16 failure15
   5.3.3 Prompt notification of QoS violation in case of error/failure
  to QoS Initiator and QoS Controllers..............................16 Notifications sent upstream.................................15
   5.3.4 Feedback about success of request for QoS guarantees........16 service request...................16
   5.3.5 Allow local QoS Local information exchange between nodes of the same
  administrative domain.............................................17 exchange..................................16
   5.4  Layering......................................................17
  5.4.1 The signaling protocol and QoS control information should be
  application independent...........................................17
               Requirements for QoS Signaling Protocols      July 2002

 5.5  QoS  Control Information.......................................17
  5.5.1 Information.........................................16
   5.4.1 Mutability information on parameters........................17
  5.5.2 parameters........................16
   5.4.2 Possibility to add and remove local domain information......18
  5.5.3 information......17
   5.4.3 Independence of reservation identifier......................18
  5.5.4 identifier......................17
   5.4.4 Seamless modification of already reserved QoS...............18
  5.5.5 resources.........17
   5.4.5 Grouping of signaling for several microflows................18
 5.6  Performance...................................................18
  5.6.1 Scalability in the number of messages received by a signaling
  communication partner (QoS initiator and controller)..............19
  5.6.2 Scalability in number of hand-offs..........................19
  5.6.3 Scalability in the number of interactions for setting up a
  reservation.......................................................19
  5.6.4 Scalability in the number of state per entity (QoS initiators
  and QoS controllers)..............................................19
  5.6.5 Scalability in CPU use (end terminal and intermediate nodes) 19
  5.6.6 microflows................17
   5.5  Performance.................................................17
   5.5.1 Scalability.................................................18
   5.5.2 Low latency in setup........................................19
  5.6.7 setup........................................18
   5.5.3 Allow for low bandwidth consumption for signaling protocol..19
  5.6.8 protocol..18
   5.5.4 Ability to constrain load on devices........................19
  5.6.9 devices........................18
   5.5.5 Highest possible network utilization........................19
 5.7  Flexibility...................................................20
  5.7.1 Aggregation capability, including the capability to select and
  change the level of aggregation...................................20
  5.7.2
   5.6  Flexibility.................................................19
   5.6.1 Flow aggregation............................................19
   5.6.2 Flexibility in the placement of the QoS initiator...........20
  5.7.3 NSIS Initiator..........19
   5.6.3 Flexibility in the initiation of re-negotiation (QoS change
  requests).........................................................20
  5.7.4 re-negotiation.............19
   5.6.4 Uni / bi-directional reservation............................20
 5.8  Security......................................................20
  5.8.1 reservation............................19
   5.7  Security....................................................20
   5.7.1 Authentication of signaling requests........................20
  5.8.2
   5.7.2 Resource Authorization......................................21
  5.8.3 Authorization......................................20
   5.7.3 Integrity protection........................................21
  5.8.4 protection........................................20
   5.7.4 Replay protection...........................................21
  5.8.5 protection...........................................20
   5.7.5 Hop-by-hop security.........................................21
  5.8.6 security.........................................20
   5.7.6 Identity confidentiality and location privacy...............21
  5.8.7
   5.7.7 Denial-of-service attacks...................................22
  5.8.8 attacks...................................21
   5.7.8 Confidentiality of signaling messages.......................22
  5.8.9 messages.......................21
   5.7.9 Ownership of a reservation..................................22
  5.8.10 reservation..................................21
   5.7.10 Hooks with Authentication and Key Agreement protocols......22
 5.9  Mobility......................................................23
  5.9.1
   5.8  Mobility....................................................22
   5.8.1 Allow efficient QoS re-establishment after handover.........23
 5.10 handover.........22
   5.9  Interworking with other protocols and techniques............23
  5.10.1 Interworking
   5.9.1 MUST interwork with IP tunneling.............................23
  5.10.2 tunneling............................23
   5.9.2 The solution should not MUST NOT constrain either to IPv4 or IPv6...23
  5.10.3 Independence IPv6......23
   5.9.3 MUST be independent from charging model...........................24
  5.10.4 Hooks model.....................23
   5.9.4 SHOULD provide hooks for AAA protocols....................................24
  5.10.5 Interworking protocols......................23
   5.9.5 SHOULD interwork with seamless handoff protocols...............24
  5.10.6 Interworking protocols............23
   5.9.6 MAY interwork with non-traditional routing..................24
 5.11  Operational.................................................24
  5.11.1 routing..................23
   5.10  Operational................................................23
   5.10.1 Ability to assign transport quality to signaling messages..24
  5.11.2 messages..23
   5.10.2 Graceful fail over.........................................24
   5.10.3 Graceful handling of NSIS entity problems..................24
   6 The MUSTs, SHOULDs, and MAYs......................................24  Security Considerations.......................................24
   7 References........................................................30  Reference.....................................................24
   8 Acknowledgments...................................................30
               Requirements for QoS Signaling Protocols      July 2002  Acknowledgments...............................................24
   9  Author's Addresses................................................31 Addresses............................................25
   10 Appendix: Scenarios/Use cases...................................31 cases.................................25
   10.1  Scenario:  Terminal Mobility.................................32 Mobility..........................................25
   10.2  Scenario:  Cellular Networks.................................34 Networks..........................................27
   10.3  Scenario:  UMTS access.......................................34 access................................................28
   10.4  Scenario:  Wired part of wireless network....................36 network.............................30
   10.5  Scenario:  Session Mobility..................................38 Mobility...........................................31
   10.6  Scenario:  QoS reservations/negotiation from access to core
 network............................................................38 network...32
   10.7  Scenario:  QoS reservation/negotiation over administrative
 boundaries.........................................................39 boundaries.32
   10.8  Scenario:  QoS signaling between PSTN gateways and backbone
 routers............................................................39 routers...33
   10.9  Scenario:  PSTN trunking gateway.............................41 gateway......................................34
   10.10 Scenario: Application request end-to-end QoS path from the
 network............................................................42
 10.11 Scenario: QOS for Virtual Private Networks..................42 network...36

1  Introduction

   This document defines requirements for signaling QoS across different
   network environments. It does not list any problems of existing QoS
   signaling protocols such as RSVP. RSVP [1].

   In order to derive requirements for QoS signaling it is necessary to
   first have a clear idea of the scope within which they are
   applicable.

   We describe a set of QoS signaling scenarios and use cases in the
   Appendix of that document. These scenarios derive from a variety of
   backgrounds, and help obtain a clearer picture of what is in or out
   of scope of the NSIS work. They illustrate the problem of QoS
   signaling from various perspectives (end-system, access network,
   core network) and for various areas (fixed line, mobile, wireless
   environments). As the NSIS work becomes more clearly defined,
   scenarios will be added or dropped, or defined in more detail.

   Based on these scenarios, we are able to define the QoS signaling
   problem on a more abstract level. In Section 3, we thus present a
   simple conceptual model of the QoS signaling problem. Additionally, we
   describe the entities involved in QoS signaling and typical signaling
   paths. In Section 4 we list assumptions and exclusions.

   The model of Section 3 allows deriving requirements from the
   scenarios presented in the appendix in a coherent and consistent
   manner. Requirements are grouped according to areas such as
   Architecture and design goals, Signaling Flows, Layering,
   Performance, Flexibility, Security and Mobility.

   QoS is a pretty large field with a lot of interaction with other
   protocols, mechanisms, applications etc. In  However, it is not the following, some
               Requirements for
   only field where signaling is used in the Internet. Even if this
   requirement documents mainly used QoS Signaling Protocols      July 2002

   thoughts from an end-system point of view and from a network point
   of view.

   End-system perspective: In future mobile terminals, as the support sample application
   other application should be possible.

   It is clear that the subject of
   adaptive applications QoS is more uniquely complex and more important. Adaptively can be
   seen as an important technique to react to QoS violations any
   investigation could potentially have a very broad scope - so broad
   that may
   occur frequently, e.g., in wireless environments due it is a challenge to changed
   environmental focus work on an area, which could lead to
   a concrete and network conditions. useful result. This may result in degraded
   end-to-end performance. is our motivation for considering
   a set of use cases, which map out the domain of application that we
   want to address. It is then up also the motivation for defining a problem
   structure, which allows us to adaptive applications state the boundaries of what types of
   functionality to
   react consider, and to list background assumptions.

   There are several areas of the new resource availability. Therefore, it is essential requirements related to define interoperability between media-, mobility- networking
   aspects which are incomplete, for example, interaction with host and QoS
   management. While most likely mobile terminals cannot assume, that
   explicit QoS reservation schemes are available, some access networks
   nevertheless may offer such capabilities. Applications subscribed to
   an end-system QoS management system should be supported with a
   dedicated QoS API to set-up, control and adapt media sessions.

   Network perspective: QoS enabled IP networks are expected to handle
   two different kinds
   site multi-homing, use of QoS granularities: per-flow QoS anycast services, and per-
   trunk/per-class QoS. Per-flow QoS might so on. These issues
   should be needed considered in access networks
   and may there be subject any future analysis work.

2  Terminology

   In the area of QoS signaling. However, Quality of Service (QoS) it is quite difficult and an
   exercise for its own to define terminology. Nevertheless, we tried
   to list the most often used terms in the core
   network only per-trunk or per-class QoS can be considered for
   scalability reasons. Therefore there might draft and tried to explain
   them. However, don't be different requirements
   on QoS signaling applying to different parts of the network. In religious about it, they are not meant to
   prescribe any thing in the
   access network QoS signaling is draft.

   NSIS Domain (ND) - Administrative domain where an interaction between end systems
   and access routers NSIS protocol
   signals for a resource or access network QoS managers (in set of resources.

   NSIS Entity (NE) - the following
   we call them QoS initiator and QoS controller). In function within a node, which implements an
   NSIS protocol.

   NSIS Forwarder (NF) - NSIS Entity on the core network
   QoS signaling refers to trunks or classes of traffic path between core a NI and edge systems or between peering core systems. Please note that NR,
   which may interact with local resource management function (RMF) for
   this does not exclude the transport of per-flow purpose. NSIS Forwarder also propagates NSIS signaling further
   through
   core networks. the network. It is clear from these descriptions that responsible for interpreting the subject of QoS is
   uniquely complex and any investigation could potentially have a very
   broad scope
   signaling carrying the user parameters, optionally inserting or
   modifying the parameters according to domain network management
   policy.

   NSIS Initiator (NI) - so broad NSIS Entity that it is initiates NSIS signaling for
   a challenge to focus work network resource based on user or application requirements. This
   can be located in the end system, but may reside elsewhere in
   network.

   NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and
   can optionally interact with applications as well.

   Resource Management Function (RMF) - an
   area, which could lead to abstract concept,
   representing the management of resources in a concrete and useful result. This is our
   motivation for considering domain or a set of use cases, node.

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

   End Host: the
   domain of application that we want to address. It end system or host, for whose flows QoS is also being
   requested and provisioned.

   End-to-End QoS: the
   motivation for defining a problem structure, which allows us to
   state QoS delivered by the boundaries of what types of functionality to consider, network between two
   communicating end hosts.  End-to-end QoS co-ordinates and enforces
   predefined traffic management policies across multiple network
   entities and administrative domains.

   Edge-to-edge QoS: QoS within an administrative domain that connects
   to list background assumptions.

   There are several areas other networks rather than hosts or end systems.

   Flow: a traffic stream (sequence of the requirements related to networking
   aspects which are incomplete, IP packets between two end
   systems) for example, interaction with host and
   site multi-homing, use of anycast services, and so on. These issues
   should be considered in any future requirement analysis work.

2  Terminology

   In the area of Qualiaty of Service (QoS) it is quite difficult and
   an exercise for 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      July 2002

   Aggregate: a group of flows, usually with similar QoS requirements,
   which can be treated together as a whole with a single overall QoS
   requirement for signaling and provisioning. Aggregates and flows can
   be further aggregated together.

   [QoS] Domain: a collection of networks under the same administrative
   control and grouped together for administrative purposes.

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

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

   End-to-End QoS: the QoS delivered by the network between two
   communicating end hosts.  End-to-end QoS co-ordinates and enforces
   predefined traffic management policies across multiple network
   entities and administrative domains.

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

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

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

   Higher Layers: the higher layer (transport protocol and application)
   functions that request QoS from the network layer. The request might
   be a trigger generated within the end system, or the trigger might
   be provided by some entity within the network (e.g. application
   proxy or policy server).

   Indication: feedback from QoS provisioning to indicate the current
   QoS being provided to a flow or aggregate, and whether any
   violations have been detected by the QoS technology is being used
   within the local domain/subdomain.

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

   Mapping: the act of transforming parameters from QSCs to values that
   are meaningful to the actual QoS technology in use in the
   domain/subdomain.

   Path:

   Path: the route across the networks taken by a flow or aggregate,
   i.e. which domains/subdomains it passes through and the
   egress/ingress points for each.

               Requirements for QoS Signaling Protocols      July 2002

   Path segment: the segment of a path within a single
   domain/subdomain.

   QoS Administration Function: a generic term for all functions
   associated with admission control, policy control, traffic
   engineering etc.

   QoS

   Control Information: the information the governs for instance the
   QoS treatment to be applied to a flow or aggregate, including the QSC,
   service class, flow administration, and any associated security or
   accounting information.

   QoS Controller: this is responsible for interpreting the signaling
   carrying the user QoS parameters, optionally inserting/modifying the
   parameters according to local network QoS management policy, and
   invoking local QoS provisioning mechanisms. Note that q QoS
   controller might have very different functionality depending on
   where in the network and in what environment they are implemented.

   QoS Initiator: this is responsible for generating the QSCs for
   traffic flow(s) based on user or application requirements and
   signaling them to the network as well as invoking local QoS
   provisioning mechanisms.  This can be located in the end system, but
   may reside elsewhere in network.

   QoS Provisioning: the act of actually allocating resources to a flow
   or aggregate of flows, may include mechanisms such as LSP initiation
   for MPLS, packet scheduler configuration within a router, and so on.
   The mechanisms depend on the overall QoS technology being used
   within the [sub]domain.

   QoS Service Classes (QSC): specify the QoS requirements of a traffic
   flow or aggregate.  Can be further sub-divided into user specific
   and network related parameters

   QoS Signaling: a way to communicate QSCs and QoS management
   information between hosts, end systems and network devices etc.  May
   include request and response messages to facilitate negotiation/re-
   negotiation, asynchronous feedback messages (not delivered upon
   request) to inform End Hosts, QoS initiators and QoS controllers
   about current QoS levels, and QoS querying facilities.

   [QoS] domain.

   Subdomain: a network within an administrative domain using a uniform technology/QoS
   technology, e.g., a single QoS provisioning function to provision
   resources.

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

   QoS Violation: occurs when the QoS applied to a flow or aggregate
   does not meet the requested and negotiated QoS agreed for it.

               Requirements for QoS Signaling Protocols      July 2002

   Resource: something of value in a network infrastructure to which
   rules or policy criteria are first applied before access is granted.
   Examples of resources include the buffers in a router and bandwidth
   on an interface.

   Resource Allocation: part of a resource that has been dedicated for
   the use of a particular traffic type for a period of time through
   the application of policies.

   Sender-initiated QoS signaling protocol: A sender-initiated QoS signaling
   protocol is a protocol (see e.g., YESSIR [8], RMD [10]) where the QI NI initiates the signaling on
   behalf of the sender of the data. What this means is that admission
   control and resource allocation functions are processed from the
   data sender towards the data receiver. However, the triggering
   instance is not specified.

   Receiver-initiated QoS signaling protocol: A receiver-initiated
   protocol, (see e.g., RSVP [9]) [1]) is a protocol where the QoS
   reservations are initiated by the QoS Receiver NSIS
   Responder on behalf of the receiver of the user data. data initiates the
   reservations. What this means is that admission control and resource
   allocation functions are processed from the data receiver back
   towards the data sender. However, the triggering instance is not
   specified.

3  Problem Statement and Scope

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

   A set of issues and problems to be solved has been given at a top
   level by the use cases/scenarios of the appendix. However, the
   problem of QoS has an extremely wide scope and there is a great deal
   of work already done to provide different components of the
   solution, such as QoS technologies for example. A basic goal should
   be to re-use these wherever possible, and to focus requirements work
   at an early stage on those areas where a new solution is needed
   (e.g. an especially simple one). We also try to avoid defining
   requirements related to internal implementation aspects.

   In this section, we present a simple conceptual model of the overall
   QoS
   problem in order to identify the applicability to NSIS of
   requirements derived from the use cases, and to clarify the scope of
   the work, including any open issues. This model also identifies
   further sources of requirements from external interactions with
   other parts of an overall QoS solution, clarifies the terminology used,
   and allows the statement of design goals about the nature of the
   solution (see section 5).

   Note that this model is intended not to constrain the technical
   approach taken subsequently, simply to allow concrete phrasing of
   requirements (e.g. requirements about placement of the QoS
   initiator, NSIS
   Initiator, or ability to 'drive' particular QoS technologies.)
               Requirements for QoS Signaling Protocols      July 2002

   Roughly, the scope of NSIS is assumed to be the interaction between
   the QoS initiator NSIS Initiator and QoS controller(s), NSIS Forwarder(s), and NSIS Responder
   including selection of
   signaling protocols a protocol to carry the QoS information, and the
   syntax/semantics of the information that is exchanged. Further
   statements on assumptions/exclusions are given in the next Section.

   The main elements are:

   1. Something that starts the request for QoS, resources, the QoS NSIS
   Initiator.

   This might be in the end system or within some other part of the
   network. The distinguishing feature of the QoS initiator NSIS Initiator is that it
   acts on triggers coming (directly or indirectly) from the higher
   layers in the end systems. It needs to map the QoS resources requested
   by them, and also provides feedback information to the higher
   layers, which might be used by transport layer rate management or
   adaptive applications.

   2. Something that assists in managing QoS resources further along the
   path, the QoS controller. NSIS Forwarder.

   The QoS controller NSIS Forwarder does not interact with higher layers, but
   interacts with the QoS initiator NSIS Initiator and possibly more QoS controllers NSIS Forwarders
   on the path, edge to edge edge-to-edge or possibly end to end. end-to-end.

   3. The QoS initiator NSIS Initiator and controller(s) NSIS Forwarder(s) interact with each
   other, path segment by path segment. This interaction involves the
   exchange of data (QoS (resources 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 the QoS initiator does this and
   controller(s), mapping their QoS control
   service requested. An NSIS Forwarder maps service-specific
   information to technology-
   related technology-related QoS parameters and receiving
   indications about success or failure in response.

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

   1. The QoS initiator NSIS Initiator need not be located at an end system, and the
   QoS controllers
   NSIS Forwarders are not assumed to be located on the flow's data
   path. However, they must be able to identify the ingress and egress
   points for the flow path as it traverses the domain/subdomain. Any
   signaling protocol must be able to find the appropriate QoS
   controller NSIS
   Forwarder and carry this ingress/egress point information.

   2. We see the network at the level of domains/subdomains rather than
   individual routers (except in the special case that the domain
   contains one link). Domains are assumed to be administrative
   entities, so security requirements apply to the signaling between
   them. Subdomains are introduced to allow the fact a given QoS
   provisioning mechanism may only be used within a part of a domain,
   typically for a particular subnetwork technology boundary.
   Aggregation can also take place at subdomain boundaries.

               Requirements for QoS Signaling Protocols      July 2002

   3. Any domain may contain QoS administration functions Resource Management Function (e.g. to do
   with traffic engineering, admission control, policy and so on).
   These are assumed to interact with the QoS initiator NSIS Initiator and controllers
   Controllers (and end systems) using standard mechanisms.

   4. The placement of the QoS initiators NSIS Initiators and QoS controllers NSIS Forwarders is not
   fixed. Actually, there are two extreme cases:

   - Each router on the data path implements a QoS controller and QoS
   initiator.

   - Only the end systems incorporate a QoS controller and QoS
   initiator, which mean the end systems need to have QoS provisioning
   capabilities. However this case does not seam to be realistic but
   shows the flexible allocation of the controller and initiator
   function.

4  Assumptions and Exclusions

4.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 on what
   point in the network acts as the initiator, and how far towards the
   other end of the network the signaling propagates. Although the
   figures show QoS controllers NSIS Forwarders at a 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 NSIS Forwarders to become more 'dense'
   towards the edges of the network, but this is not a requirement. An
   overprovisioned
   over-provisioned domain might contain no QoS controllers NSIS Forwarders at all (and
   be NSIS transparent); at the other extreme, QoS controllers NSIS Forwarders might be
   placed at every router. In the latter case, QoS provisioning can be
   carried out in a local implementation-dependent way without further
   signaling, whereas in the case of remote QoS controllers, NSIS Forwarders, a
   provisioning protocol might be needed to control the routers along
   the path. This provisioning protocol is then independent of the end
   to end end-
   to-end NSIS signaling.

   2. We do not consider 'pure' end-to-end QoS signaling that is not
   interpreted anywhere within the network. Such signaling is an
   application-layer issue and IETF protocols such as SIP etc. can be
   used.

   3. Where the signaling does cover several QoS NSIS domains or
   subdomains, we do not exclude that different signaling protocols are
   used in each path segment. We only place requirements on the
   universality of the QoS control information that is being transported.
   (The goals here would be to allow the use of signaling protocols,
   which are matched to the characteristics of the portion of the
   network being traversed.) Note that the outcome of NSIS work might
   result in various protocols or various flavors of the same protocol.
   This
               Requirements for QoS Signaling Protocols      July 2002 implies the need for the translation of information into QoS domain
   specific format as well.

   4. We assume that the service definitions a QoS initiator NSIS Initiator can ask
   for are known in advance of the signaling protocol running. Service
   definition includes QoS parameters, lifetime of QoS guarantee etc. etc.,
   or any other service-specific parameters.

   There are many ways service requesters get to know about it. There
   might be standardized services, the definition can be negotiated
   together with a contract, the service definition is published at a
   Web page, etc.

   5. We assume that there are means for the discovery of NSIS entities
   in order to know the signaling peers (solutions include static
   configuration, automatically discovered, or implicitly runs over the
   right nodes, etc.) The discovery of the NSIS 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 required to know the
   identity of the other entity. Hence the discovery mechanism may
   provide means to learn this identity, which is then later used to
   retrieve the required keys and parameters.

   6. NSIS assumes to operate with networks using standard ("normal")
   L3 routing. Where "normal" is not specified more exactly on purpose.

4.2 Exclusions

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

   2. Specific mechanisms (APIs and so on) for interaction between
   transport/applications and the network layer are not considered,
   except to clarify the requirements on the negotiation capabilities
   and information semantics that would be needed of the signaling
   protocol. The same applies to application adaptation mechanisms.

   3. Specific mechanisms for QoS provisioning within a
   domain/subdomain are not considered. However, NSIS can be used for
   signaling within a domain/subdomain performing QoS provisioning. It
   should be possible to exploit these mechanisms optimally within the end to end
   end-to-end context. Consideration of how to do this might generate
   new requirements for NSIS however. For example, the information
   needed by a QoS
   controller NSIS Forwarder to manage a radio subnetwork needs to be
   provided by the NSIS solution.

   4. Specific mechanisms (APIs and so on) for interaction between the
   network layer and underlying QoS provisioning mechanisms are not
   considered.

   5. Interaction with QoS administration resource management 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      July 2002

   6. Security implications related to multicasting are outside the
   scope of the QoS signaling protocol.

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

   The protection of non-signaling messages (including data traffic
   following a reservation) is not directly considered by a signaling
   protocol. The protection of data messages transmitted along the QoS
   provisioned path is outside the scope of a signaling protocol.
   Regarding data traffic there is an interaction with accounting
   (metering) and edge routers might require packets to be integrity
   protected to be able to securely assign incoming data traffic to a
   particular user.

   Additionally there might be an interaction with IPsec IPSec protected
   traffic experiencing QoS treatment and the established state created
   due to signaling. One example of such an interaction is the different
   flow identification with and without IPsec IPSec protection.

   Many security properties are likely to be application specific and
   may be provided by the corresponding application layer protocol.

   8. Service definitions and in particular QoS classes are out of
   scope. Together with the service definition any definition of
   service specific parameters are not considered in this draft. Only
   the base NSIS signaling protocol for transporting the QoS/service service
   information are handled.

   9. Similarly, specific methods, protocols, and ways to express QoS
   QoS/service information in the Application/Session level are not
   considered (e.g., SDP, SIP, RTSP, etc.).

   10. The specification of any extensions needed to signal QoS information
   via application level protocols (e.g. SDP(ng)), SDP), and the mapping on NSIS
   information are considered outside of the scope of NSIS 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 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      July 2002

   This section defines more detailed requirements for a QoS signaling
   solution, derived from consideration of the use cases/scenarios, cases/scenarios
   described in the appendix, and respecting the framework, scoping
   assumptions, and terminology considered earlier. The requirements
   are in subsections, grouped roughly according to general technical
   aspects: architecture and design goals, topology issues, QoS parameters,
   performance, security, information, and flexibility.

   Two general (and potentially contradictory) goals for the solution
   are that it should be applicable in a very wide range of scenarios,
   and at the same time lightweight in implementation complexity and
   resource requirements in nodes. One approach to this is that the
   solution could deal with certain requirements via modular components
   or capabilities, which are optional to implement in individual
   nodes.

   Some of the requirements are technically contradictory. Depending on
   the scenarios a solution applies to, one or the other requirement is
   applicable.

   Find in Section 6

   In order to prioritize the various requirements we define different
   'parts of the network'. In the different parts of the network a
   particular requirement might have a different priority.

   The parts of the networks we differentiate are the host-to-first
   router, the access network, and the core network. The host to first
   router part includes all the layer 2 technologies to access to the
   Internet. In many cases, there is an application and/or user running
   on the MUSTs, SHOULDs, host initiating signaling. The access network can be
   characterized by low capacity links, medium speed IP processing
   capabilities, and it might consist of a complete layer 2 network as
   well. The core network characteristics include high-speed forwarding
   capacities and inter-domain issues. All of them are not strictly
   defined and MAYs should not be regarded as that, but should give a
   feeling about where in the network we have different requirements
   concerning signaling.

5.1 Architecture and Design Goals

   This section contains requirements related to desirable overall
   characteristics of a solution, e.g. enabling flexibility, or
   independence of parts of the framework.

5.1.1 Applicability MUST be applicable for different QoS technologies.

   The QoS signaling protocol must MUST work with various QoS technologies. technologies as
   well as other technologies needing signaling. The information
   exchanged over the signaling protocol must be in such detail and
   quantity that it is useful for various QoS technologies.

5.1.2 Resource availability information on request

   In some scenarios, e.g., the mobile terminal scenario, it is
   required to query, whether resources are available, without
   performing a reservation on the resource. One solution might be a
   feedback mechanism based on which a QoS inferred handover can take
   place. So NSIS SHOULD provide a mechanism to check whether resources
   are available without performing a reservation

5.1.3 Modularity NSIS MUST be designed modular

   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 (narrowband / versus broadband, error-prone
   / reliable...) - error-
   prone versus reliable, ...). This implies low bandwidth signaling
   and redundant information must MUST be supported if necessary.

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

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

   - Protocol layering, where appropriate. This means NSIS MUST provide
   a base protocol, which can be adapted to different environments.

5.1.4 Decoupling of NSIS MUST decouple protocol and information it is carrying

   The signaling protocol(s) used must protocol MUST be clearly separated from the
   QoS control
   information being transported. This provides for the independent
   development of these two aspects of the solution, and allows for
   this control information to be carried within other protocols,
   including application layer ones, existing ones or those being
   developed in the future. The gained flexibility in the information
   transported allows for the applicability of the same protocol in
   various scenarios.

   However, note that the information carried needs to be the same.
   Otherwise
   standardized; otherwise interoperability is difficult to achieve.

5.1.5 Reuse of NSIS MUST reuse existing QoS provisioning

   Reuse existing QoS functions and protocols for QoS provisioning within a
   domain/subdomain unchanged. (Motivation: 'Don't re-invent the
   wheel'.)

5.1.6 Independence of signaling and provisioning paradigm

   The QoS signaling should MUST be independent of the paradigm and mechanism of QoS
   provisioning. The independence allows E.g., in the case of signaling for using QoS, the
   independence of the signaling protocol from the QoS provisioning
   allows for using the NSIS protocol together with various QoS
   technologies in various scenarios.

5.1.7 Application independence

   The signaling protocol MUST be independent of the application. The
   control information SHOULD be application independent, because we
   look into network level signaling.

   The requirement relates to the way the signaling interacts with
   upper layer functions (users, applications, and QoS administration),
   and lower layer QoS technologies.

   Opaque application information MAY get transported in the signaling
   message, without being handled in the network. Development and
   deployment of new applications SHOULD be possible without impacting
   the network infrastructure.

5.2 Signaling Flows

   This section contains requirements related to the possible signaling
   flows that should be supported, e.g. over what parts of the flow
   path, between what entities (end-systems, routers, middle boxes,
   management systems), in which direction.

5.2.1 Free placement of QoS Initiator and QoS Controllers functions NSIS Initiator, Forwarder, Responder

   The protocol must MUST 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 the network and vice versa), and network-to-network
   (e.g., between providers).

   Placing the QoS controller NSIS Forwarder and initiator NSIS Initiator functions at different
   locations allows for various scenarios to work with the same or
   similar protocols.
   protocol.

5.2.2 No constraint of the QoS signaling and QoS Controllers NSIS Forwarders to be in the
     data path.

               Requirements for QoS Signaling Protocols      July 2002

   There is a set of scenarios, where QoS signaling is not on the data
   path. The QoS Controller NSIS Forwarder being in the data path is one extreme case
   and useful in certain many cases. Therefore the case of having NSIS entities
   on the data path only MUST be allowed.

   There are going to be cases where a centralized entity will take a
   decision about QoS service requests. In this case, there is no need to
   have the data follow the signaling path.

   There are going to be cases without a centralized entity managing
   resources and the signaling will be used as a tool for resource
   management. For various reasons (such as efficient use of expensive
   bandwidth), one will want to have fine-grained, fast, and very
   dynamic control of the resources in the network.

   There are going to be cases where there will be neither signaling
   nor a centralized entity (overprovisioning). (over-provisioning). Nothing has to be done
   anyway.

   One can capture the requirement with the following, different
   wording: If one views the domain with a QoS technology as a virtual
   router then NSIS signaling used between those virtual routers must MUST
   follow the same path as the data.

   Routing the signaling protocol 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 protocol must MUST accept
   all of these possibilities. possibilities with a strong focus on the on-path
   signaling.

5.2.3 Concealment of topology and technology information

   The QoS NSIS protocol should SHOULD allow for hiding the internal structure of
   a
   QoS NSIS domain from end-nodes and from other networks. Hence an
   adversary should not be able to learn the internal structure of a
   network with the help of the QoS signaling protocol.

   In various scenarios, topology information should SHOULD be hidden for
   various reasons. From a business point of view, some administrations
   don't want to reveal the topology and technology used.

5.2.4 Optional transparency Transparency of QoS signaling to network

   It should SHOULD be possible that the QoS signaling for some flows traverse
   path segments transparently, i.e., without interpretation at QoS
   controllers NSIS
   Forwarders within the network. An example would be a subdomain
   within a core network, which only interpreted signaling for
   aggregates established at the domain edge, with the flow-related
   signaling passing transparently through it.

               Requirements for QoS Signaling Protocols      July 2002

   In other words, NSIS needs to SHOULD work in 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 of QoS information

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

5.3.1 Explicit release of resources

   When a QoS resource reservation is no longer necessary, e.g. because the
   application terminates, or because a mobile host experienced a hand-
   off, it must MUST be possible to explicitly release resources. In general
   explicit release enhances the overall network utilization.

5.3.2 Possibility for automatic release of resources after failure

   When the QoS NSIS Initiator goes down, the resources it requested in the
   network should SHOULD be released, since they will no longer be necessary.

   After detection of a failure in the network, any QoS
   controller/initiator must NSIS
   Forwarder/Initiator MUST be able 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.

   The goal is to prevent stale state within the network and adds
   robustness to the operation of NSIS. So in other words, an NSIS
   signaling protocol must or mechanisms MUST provide means for an NSIS signaling unit
   entity 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 QoS violation in case of error/failure to
     QoS Initiator and QoS Controllers

   QoS Controllers should Notifications sent upstream

   NSIS Forwarders SHOULD be able to notify the QoS Initiator, NSIS Initiator or any
   other NSIS Forwarder upstream, if there is an error a state change inside the
   network. There are two various types of network
   errors:

   Recoverable errors: the changes for instance
   among them:

   Recoverable errors: the network nodes can locally repair this type
   error. The network nodes do not have to notify the users of the
   error immediately. This is a condition when the danger of
   degradation (or actual short term degradation) of the provided QoS
   was overcome by the network (QoS controller) (NSIS Forwarder) itself.

   Unrecoverable errors: the network nodes cannot handle this type of
   error, and have to notify the users as soon as possible.

   QoS degradation/severe congestion: In case the service cannot be
   provided completely but partially only.

   Repair indication: If an error occurred and it has been fixed, this
   triggers the sending of a notification.

   Service upgrade available: If a previously requested better service
   becomes available.

   The content of the notification is very service specific, but it is
   must at least carry type information. Additionally, it may carry the
   location of the state change.

   The notifications may or may not be in response to a NSIS message.
   This means an NSIS entity has to be able to handle notifications at
   any time.

   Note however, that there are a number of security consideration
   needs to be solved with notification, even more important if the
   notification is sent without prior request (asynchronously). The
   problem basically is, that everybody could send notifications to any
   NSIS entity and the NSIS entity most likely reacts on the
   notification. E.g., if it gets an error notification it might
   teardown the reservation, even if everything is ok. So the
   notification might depend on security associations between the
   sender of the notification and its receiver. If a hop-by-hop
   security mechanism is chosen, this implies also that notifications
   need to be sent on the reverse path.

5.3.4 Feedback about success of service request for QoS guarantees
               Requirements for QoS Signaling Protocols      July 2002

   A request for QoS must service MUST be answered at least with yes or no.
   However, it might MAY be useful in case of a negative answer to also get a
   description of what might be the QoS one can successfully amount of resources a request
   etc. is possible. So it might be useful to include an
   opaque element MAY be included into the answer. The element heavily
   depends on the service requested.

5.3.5 Allow local QoS Local information exchange between nodes of the same
     administrative domain

   The QoS signaling protocol must MUST be able to exchange local QoS information
   between QoS controllers NSIS Forwarders located within one single administrative
   domain. Local QoS information might, for example, be IP addresses,
   severe congestion notification, notification of successful or
   erroneous processing of QoS signaling messages.

   In some cases, the NSIS QoS signaling protocol may MAY carry identification
   of the QoS controllers NSIS Forwarders located at the boundaries of a domain.
   However, the identification of edge should not be visible to the end
   host (QoS initiator) (NSIS Initiator) and only applies within one QoS administrative
   domain.

5.4 Layering

   This section contains requirements related to the way the signaling
   being considered interacts with upper layer functions (users,
   applications, and QoS administration), and lower layer QoS
   technologies.

5.4.1 The signaling protocol and QoS control information should be
     application independent.

   However, opaque application information might get transported in the
   signaling message, without being handled in the network. Development
   and deployment of new applications should be possible without
   impacting the network infrastructure. Additionally, QoS protocols
   are expected to conform to the Internet principles.

5.5 QoS Control Information

   This section contains requirements related to the QoS control
   information that needs to be exchanged.

5.5.1

5.4.1 Mutability information on parameters

   It should SHOULD be possible for the NSIS initiator to control the
   mutability of the QSC signaled information. This prevents from being
   changed in a non-
   recoverable non-recoverable way. The NSIS initiator should SHOULD be able
   to control what is requested end to end, without the request being
   gradually mutated as it passes through a sequence of domains. This
   implies that in case of changes made on the parameters, the original
   requested ones must still be available.

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

               Requirements for QoS Signaling Protocols      July 2002

   Additionally, note that a provider or that particular QoS services
   requested, can still influence the QoS provisioning but in the
   signaling message the request should stay the same.

5.5.2

5.4.2 Possibility to add and remove local domain information

   It should SHOULD be possible for the QoS control functions Resource Management Function to add
   and remove local scope elements. E.g., at the entrance to a QoS domain
   domain-specific information is added, which is used in this domain
   only, and the information is removed again when a signaling message
   leaves the domain. The motivation is in the economy of re-use the
   protocol for domain internal signaling of various information
   pieces. Where additional information is needed for QoS control within a particular
   domain, it should be possible to carry this at the same time as the 'end to end' information.)

5.5.3
   end-to-end information.

5.4.3 Independence of reservation identifier

   A reservation identifier must be used, identifier, which is independent of the flow identifier, the IP address of the QoS Initiator, and the flow
   end-points.
   identifier (flow end-points), MUST be used. 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
   service requirement.

5.5.4 Also several proxy-based signaling methods
   might profit from such as independence.

5.4.4 Seamless modification of already reserved QoS resources

   In many case, the reservation needs to be updated (up or downgrade).
   This must SHOULD happen seamlessly without service interruption. At least
   the signaling protocol must should allow for it, even if some data path
   elements might not be capable of doing so.

5.5.5

5.4.5 Grouping of signaling for several microflows micro-flows

   NSIS may MAY group signaling information for several microflow micro-flow into one
   signaling message. The goal of this is the optimization in 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 network must not MUST NOT know that a relationship between the
   grouped flows exists. Nor is there There MUST NOT be any transactional semantic
   allowed.
   associated with the grouping. It is only meant for optimization
   purposes and each reservation is MUST be handled separately from each
   other.

5.6

5.5 Performance

   This section discusses performance requirements and evaluation
   criteria and the way in which these could and should be traded off
   against each other in various parts of the solution.

   Scalability is a must anyway. However, depending on the scenario the
   question to which extends the protocol must be scalable.

               Requirements for QoS Signaling Protocols      July 2002

5.6.1

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

5.5.1 Scalability

   NSIS MUST be scalable in the number of messages received by a
   signaling communication partner (QoS initiator (NSIS Initiator, NSIS Forwarder, and controller)

5.6.2 Scalability
   NSIS Responder). The major concern lies in the core of the network,
   where large numbers of messages arrive.

   It MUST be scalable in number of hand-offs

5.6.3 Scalability in mobile environments.
   This mainly applies in access networks, because the core is
   transparent to mobility in most cases.

   It MUST be scalable in the number of interactions for setting up a
     reservation

5.6.4
   reservation. This applies for end-systems setting up several
   reservations. Some servers might be expected to setup a large number
   of reservations.

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

5.6.5 MUST be achieved for
   NSIS Forwarders in the core of the network.

   And Scalability in CPU use (end terminal MUST be achieved on end terminals in case
   of many reservations at the same time and intermediate nodes)

5.6.6 nodes mainly
   in the core.

5.5.2 Low latency in setup

   Low

   NSIS SHOULD allow for low latency setup of reservations. This 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 delay).

5.5.3 Allow for low bandwidth consumption for signaling protocol

   NSIS MUST allow for low bandwidth consumption in certain access
   networks. Again only small sets of scenarios call for low bandwidth,
   mainly those where wireless links are involved.

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

5.6.8

5.5.4 Ability to constrain load on devices

   The NSIS architecture should SHOULD give the ability to constrain the load
   (CPU load, memory space, signaling bandwidth consumption and
   signaling intensity) on devices where it is needed. One of the
   reasons is that the protocol 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 choose any method as long as the requirement is
   met.

5.6.9

5.5.5 Highest possible network utilization

   There are networking environments that require high network
   utilization for various reasons, and the signaling protocol should 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.

5.7

5.6 Flexibility

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

5.7.1 Aggregation capability,

5.6.1 Flow aggregation

   NSIS MUST allow for flow aggregation, including the capability to
   select and change the level of aggregation.

5.7.2

5.6.2 Flexibility in the placement of the QoS initiator

   It NSIS Initiator

   NSIS MUST be flexible in placing an NSIS Initiator. The NSIS
   Initiator might be the sender or the receiver of content. But also network-
   initiated
   network-initiated reservations are required MUST be available in various
   scenarios such as PSTN gateways, some VPNs, and mobility.

5.7.3

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

   Again the

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

5.7.4

5.6.4 Uni / bi-directional reservation

   Both unidirectional as well as bi-direction reservations must SHOULD be
   possible. With bi-directional reservations we mean here reservations
   having the same end-points. But the path in the two directions does
   not need to be the same.

   The goal of a bi-directional reservation is mainly an optimization
   in terms of setup delay. There is no requirements on constrains such
   as use the same data path etc.

5.8

5.7 Security

   This section discusses security-related requirements. For a
   discussion of security threats see [12].

5.8.1 [3]. The NSIS protocol MUST
   provide means for security, but it MUST be allowed that nodes
   implementing NSIS signaling do not need use the security means.

5.7.1 Authentication of signaling requests

   A signaling protocol must MUST make provision for enabling various
   entities to be authenticated against each other using strong
   authentication mechanisms. The term strong authentication points to
   the fact that weak plain-text password mechanisms must not be used
   for authentication.

               Requirements for QoS Signaling Protocols      July 2002

5.8.2

5.7.2 Resource Authorization

   The signaling protocol must MUST provide means to authorize resource
   requests. This requirement demands a hook to interact with a policy
   entity to request authorization data. This allows an authenticated
   entity to be associated with authorization data and to verify the
   resource request. Authorization prevents reservations by unauthorized
   entities, reservations violating policies, and theft of service and
   additionally service.
   Additionally it limits denial of service attacks against parts of the
   network or the entire network caused by unrestricted reservations.
   Additionally it might be helpful to provide some means to inform
   other protocols of participating nodes within the same administrative
   domain about a previous successful authorization event.

5.8.3

5.7.3 Integrity protection

   The signaling protocol must MUST provide means to protect the message
   payloads against modifications. Integrity protection prevents an
   adversary from modifying with parts of the signaling message and from
   mounting denial of service or theft of service type of attacks
   against network elements participating in the protocol execution.

5.8.4

5.7.4 Replay protection

   To prevent replay of previous signaling messages the signaling
   protocol must MUST provide means to detect old i.e. already transmitted
   signaling messages. A solution must cover issues of synchronization
   problems in 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

5.7.5 Hop-by-hop security

   Hop-by-Hop security SHOULD be supported. It is a well known and
   proven concept in Quality-of-
   Service Quality-of-Service and other signaling protocols
   that allows intermediate nodes that actively participate in the
   protocol to modify the messages as it is required by processing rule.
   Note that this requirement does not exclude end-to-end or network-to-network network-to-
   network security of a signaling message. End-to-end security between
   the initiator and the responder may be used to provide protection of
   non-mutable data fields. Network-to-network security refers to the
   protection of messages over various hops but not in an end-to-end
   manner i.e. protected over a particular network.

5.8.6

5.7.6 Identity confidentiality and location privacy

   Identity confidentiality SHOULD be supported. It enables privacy and
   avoids profiling of entities by adversary eavesdropping the signaling
   traffic along the path. The identity used in the process of
   authentication may also be hidden to a limited extent from a network
   to which the initiator is attached. It is however required that However the identity provides MUST provide
   enough information for the nodes in the access network to collect
   accounting data.

               Requirements for QoS Signaling Protocols      July 2002
   Location privacy MAY be supported. It is an issue for the initiator
   who triggers the signaling protocol. In some scenarios the initiator
   may not be willing to reveal location information to the responder as
   part the signaling procedure.
   The

5.7.7 Denial-of-service attacks

   A signaling protocol should SHOULD provide means to protect the identity
   confidentiality and as far as possible location privacy.

5.8.7 Denial-of-service attacks prevention of DoS attacks.
   To effectively prevent denial-of-service attacks it is necessary that
   the used security and protocol mechanisms should not require the
   execution of heavy MUST have low computation
   complexity to verify a resource request prior authenticating the
   requesting entity. Additionally the signaling protocol and the used
   security mechanisms should not SHOULD NOT require large resource consumption
   (for example main memory or other additional message exchanges)
   before a successful authentication was done. A
   signaling protocol should provide prevention of DoS attacks.

5.8.8

5.7.8 Confidentiality of signaling messages

   Based on the signaling information exchanged between nodes
   participating in the signaling protocol an adversary may learn both
   the identities and the content of the signaling messages. To prevent
   this from happening, confidentiality of the signaling message in a
   hop-by-hop manner may MAY be provided. Note that the 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 signaling
   protocol must be able to read and eventually modify the content of
   the signaling messages.

5.8.9

5.7.9 Ownership of a reservation

   When existing reservations have to be modified then there is a need
   to use a reservation identifier to uniquely identify the established
   state. A signaling protocol must MUST provide the appropriate security
   protection to prevent other entities to modify state without having
   the proper ownership.

5.8.10

5.7.10 Hooks with Authentication and Key Agreement protocols

   This requirement covers two subsequent steps before a signaling
   protocol is executed and the required hooks. First there is a need to
   agree on a specific authentication protocol. Later this protocol is
   executed and provides authentication and establishes the desired
   security associations. Using these security associations it is then
   possible to exchange secured signaling messages.

   The signaling protocol should implementation SHOULD provide hooks to
   interact with protocols that allow the negotiation of authentication
   and key agreement protocols. Although the negotiation of an
   authentication and key management protocol within the signaling
   protocol may be outside the scope it is still required to trigger
   this exchange in case that no such security association is available.

               Requirements for QoS Signaling Protocols      July 2002
   This requirement originates from the fact that more than one key
   management protocol may be used to provide a security association for
   the signaling protocol. Hence the communicating entities must be
   capable to agree on a specific authentication. The selected
   authentication and 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 to be transmitted to allow a session key and the
   corresponding security association to be derived. To avoid the
   complex issue of embedding individual authentication and 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 although the key management protocol may be
   independent there must be a way for the signaling protocol to access
   and use available (i.e. already established) security associations to
   avoid executing a separate key management protocol (or instance of
   the same protocol) for protocols that closely operate together. If no
   such security association exists then there should SHOULD be means for the
   signaling protocol to dynamically trigger such a protocol.

5.9

5.8 Mobility

5.9.1

5.8.1 Allow efficient QoS re-establishment after handover

   Handover is an essential function in wireless networks. After
   handover, QoS the reservation may need to be completely or partially re-established 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
   signaling should MUST allow efficient QoS re-establishment after handover.  Re-
   establishment of QoS after handover should MUST be as quick as possible so that
   the mobile node does not experience service interruption or
   QoS service
   degradation. The re-establishment should SHOULD be localized, and not
   require end-to-end signaling, if possible.

5.10 signaling.

5.9 Interworking with other protocols and techniques

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

5.10.1 Interworking

5.9.1 MUST interwork with IP tunneling

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

5.10.2
   due to encryption.

5.9.2 The solution should not MUST NOT constrain either to IPv4 or IPv6
               Requirements for QoS Signaling Protocols      July 2002

5.10.3 Independence

5.9.3 MUST be independent from charging model

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

5.10.4 Hooks

5.9.4 SHOULD provide hooks for AAA protocols

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

5.10.5 Interworking

5.9.5 SHOULD interwork with seamless handoff protocols

   An NSIS protocol should 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

5.9.6 MAY interwork with non-traditional routing

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

5.11

5.10 Operational

5.11.1

5.10.1 Ability to assign transport quality to signaling messages.

   The NSIS architecture should SHOULD allow the network operator to assign
   the NSIS protocol messages a certain transport quality. As signaling
   opens up for possible denial-of-service attacks, this requirement
   gives the network operator a mean, but also the obligation, to
   trade-off between signaling latency and the impact (from the
   signaling messages) on devices within his/her network. From protocol
   design this requirement states that the protocol messages should 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 MUST be defined how an
   NSIS signaling
   systems system behaves if some kind of request it sent stays
   without answer. The basic transport protocol to be used between
   adjacent NSIS units must MAY ensure message integrity and reliable
   transport.

5.11.2

5.10.2 Graceful fail over

   Any unit participating in NSIS signaling must not 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

5.10.3 Graceful handling of NSIS entity problems

   NSIS peers SHOULD be able to detect the network'. In malfunctioning peer. It may
   notify the different parts of NSIS Initiator or another NSIS entity involved in the network a particular requirement might have a different
   priority.
   signaling process. The parts of NSIS peer may handle the networks we differentiate are problem itself e.g.
   switching to a backup NSIS entity. In the host-to-first
   router, latter case note that
   synchronization of state between the access network, primary 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 backup entity
   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 needed.

6  Security Considerations

   Section 5.8 of a complete layer 2 networks as
   well. The core network characteristics include high-speed forwarding
   capacities and interdomain QoS issues. All this draft provides security related requirements of them are not strictly
   defined and should not be regarded as that, but should give
   a
   feeling about where signaling protocol. Another document describes security threads
   for NSIS [3].

7  Reference

   [1] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S.,
   "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
   Specification", RFC 2205, September 1997.

   [2] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow,
   "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December
   2001.

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

8  Acknowledgments

   Quite a number of people have been involved in the network we have different requirements
   concerning QoS signaling.

   Note that discussion of 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.

   [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.

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
   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
   for other users. In the worst-case scenario, a delay in handover may
   cause the connection to be dropped if the handover occurred due to
   bad air link quality. Therefore, it is critical that QoS 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.

10.2    Scenario: Cellular Networks

   In this scenario, the 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
   cellular system.

   2) The placement of QoS initiators and QoS controllers (terminology
   in the framework given here). The QoS initiator could be located at
   the End Host (triggered by applications), the GGSN/PDSN, or at a
   node not directly on the data path, such as a bandwidth broker. In
   the second case, the GGSN/PDSN could either be acting as a proxy on
   behalf of an End Host with little capabilities, and/or managing
   aggregate resources within its QoS domain (the UMTS core network).
   The IP signaling messages are interpreted by the QoS controllers,
   which may be located at the GGSN/PDSN, and in any QoS sub-domains
   within the cellular system.

   3) Initiation of IP-level QoS negotiation. IP-level QoS re-
   negotiation may be initiated by either the End Host, or by the
   network, based on current network loads, which might change
   depending on the location of the end host.

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

   Note that in comparison to the former scenario, the emphasis is much
   less on the mobility aspects, because mobility is mainly handled on
   the lower layer.

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

   The 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 of the visited domain, i.e. the domain where the
   mobile user wants to set-up a call. The Gateway GPRS Support Node
   (GGSN) is the egress router of the UMTS domain and connects the UMTS
   access network to the Edge Router (ER) of the core IP network. The
   P-CSCF/PCF communicates with the GGSN via the COPS protocol [4]. The
   User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal
   Equipment (TE), e.g. a laptop.

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

                      Figure 1: UMTS access scenario

   In this scenario the GGSN has the role of Access Gate. According to
   3GPP standardization, the PCF is responsible for the policy-based
   control of the end-user service in the UMTS access network (i.e.
   from UE to GGSN). In the current UMTS release R.5, the PCF is part
   of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF
   may evolve to an open standardized interface. In any case the PCF
   has all required QoS information for per-flow admission control in
   the UMTS access network (which it gets from the P-CSCF and/or GGSN).
   Thus the PCF would be the appropriate entity to host the
   functionality of QI, initiating the "NSIS" QoS signaling towards the
   core IP network. The PCF/P-CSCF has to do the mapping from codec
   type (derived from SIP/SDP signaling) to IP traffic descriptor. SDP
   extensions to explicitly signal QoS information [7] are useful to
   avoid the need to store codec information in the PCF and to allow
   for more flexibility and accurate description of the QoS traffic
   parameters. The PCF also controls the GGSN to open and close the
   gates and to configure per-flow policers, i.e. to authorize or
   forbid user traffic.

   The QC is (of course) not part of the standard UMTS architecture.
   However, to achieve end-to-end QoS a QC is needed such that the PCF
   can request a QoS connection to the IP network. As in the previous
   example, the QC could manage a set of pre-provisioned resources in
   the IP network, i.e. bandwidth pipes, and the QC performs per-flow
   admission control into these pipes. In this way, a connection can be
   made between two UMTS access networks, and hence, end-to-end QoS can
               Requirements for QoS Signaling Protocols      July 2002

   be achieved. In this case the QI and QC are clearly two separate
   entities.
   This use case clearly illustrates the need for an "NSIS" QoS
   signaling protocol between QI and QC. An important application of
   such a protocol may be its use in the inter-connection of UMTS
   networks over an IP backbone.

10.4    Scenario: Wired part of wireless network

   A wireless network, seen from a QoS domain perspective, usually
   consists of three parts: a wireless interface part (the "radio
   interface"), a wired part of the wireless network (i.e., Radio
   Access Network) and the backbone of the wireless network, as shown
   in Figure 2. Note that this figure should not be seen as an
   architectural overview of wireless networks but rather as showing
   the conceptual QoS domains in a wireless network.

   In this scenario, a mobile host can roam and perform a handover
   procedure between base stations/access routers. In this scenario the
   NSIS QoS protocol can be applied between a base station and the
   gateway (GW).  In this case a GW can also be considered as a local
   handover anchor point. Furthermore, in this scenario the NSIS QoS
   protocol can also be applied either between two GWs, or between two
   edge routers (ER).

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

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

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

      Figure 2. QoS architecture of wired part of wireless network
               Requirements for QoS Signaling Protocols      July 2002

   Each of these parts of the wireless network impose different issues
   to be solved on the QoS signaling solution being used:

   * Wireless interface: The solution for the air interface link
     has to ensure flexibility and spectrum efficient transmission
     of IP packets.  However, this link layer QoS can be solved in
     the same way as any other last hop problem by allowing a
     host to request the proper QoS profile.

   * Wired part of the wireless network:  This is the part of
     the network that is closest to the base stations/access
     routers.  It is an IP network although some parts logically
     perform tunneling of the end user data. In cellular networks,
     the wired part of the wireless network is denoted as a
     radio access network.

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

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

         2. The network must support mobility.  Many wireless
            networks are able to provide a combination of soft
            and hard handover procedures.  When handover occurs,
            reservations need to be established on new paths.
            The establishment time has to be as short as possible
            since long establishment times for reservations degrade
            the performance of the wireless network.  Moreover,
            for maximal utilization of the radio spectrum, frequent
            handover operations are required.

         3. These links are typically rather bandwidth-limited.

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

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

   * Backbone of the wireless network: the requirements imposed
     by this network are similar to the requirements imposed by
     other types of backbone networks.

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

               Requirements for QoS Signaling Protocols      July 2002

10.5    Scenario: Session Mobility

   In this scenario, a session is moved from one end-system to another.
   Ongoing sessions are kept and QoS parameters need to be adapted,
   since it is very likely that the new device provides different
   capabilities. Note that it is open which entity initiates the move,
   which implies that the QoS initiator might be triggered by different
   entities.

   User mobility (i.e., a user changing the device and therefore moving
   the sessions to the new device) is considered to be a special case
   within the session mobility scenario.

   Note that this scenario is different from terminal mobility. Not the
   terminal (end-system) has moved to a different access point. Both
   terminals are still connected to an IP network at their original
   points.

   The issues include:

   1) Keeping the QoS guarantees negotiated implies that the end-
   point(s) of communication are changed without changing the
   reservations.

   2) The trigger of the session move might be the user or any other
   party involved in the session.

10.6    Scenario: QoS reservations/negotiation from access to core
    network

   The scenario includes the signaling between access networks and core
   networks in order to setup and change reservations together with
   potential negotiation.

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

   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 traffic (amount of traffic), a
   particular QoS is guaranteed for, needs to be changed. E.g., in case
   additional flows are added to the aggregate, the traffic
   specification of the flow needs to be added if it is not already
   included in the aggregates specification.

   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      July 2002

10.7    Scenario: QoS 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 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
   internals (e.g., topology, technology, etc.) should not be
   exchanged. Some information exchange about the "access points" of
   the core networks (which is topology information as well) may need
   to be exchanged, because it is needed for proper signaling.

   2) Additionally, as in scenario 4, signaling most likely is based on
   aggregates, with all the issues raise there.

   3) Authorization: It is critical that the QoS initiator is
   authorized to perform 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.

10.8    Scenario: QoS signaling between PSTN gateways and backbone
    routers

   A PSTN gateway (i.e., host) requires information from the network
   regarding its ability to transport voice traffic across the network.
   The voice quality will suffer due to packet loss, latency and
   jitter. Signaling is used to identify and admit a flow for which
   these impairments are minimized.  In addition, the disposition of
   the signaling request is used to allow the PSTN GW to make a call
   routing decision before the call is actually accepted and delivered
   to the final destination.

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

   There are several ways that a PSTN gateway can acquire assurances
   that a network can carry its traffic across the network. These
   include:

     1. Over-provisioning a high availability network.

               Requirements for QoS Signaling Protocols      July 2002

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

   Item 1 requires no signaling at all and is therefore outside the
   scope of this working group.

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

   Item 3 is initially attractive as it appears to have reasonable
   scaling properties, however, its scaling properties only are
   effective in cases where there are relatively few PSTN GWs. In the
   more general case were a PSTN GW reduces to a single IP phone
   sitting behind some access network, the opportunities for
   aggregation are reduced and the problem reduces to item 4.

   Item 4 is the most general case. However, it has the most difficult
   scaling problems. The objective here is to place the requirements on
   Item 4 such that a 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 inclusion of IP phones on cable, DSL, wireless or
   other access networks in this scenario.

   Call Scenario

   A PSTN GW signals end-to-end for some 5 tuple defined flow a
   bandwidth and QoS requirement. Note that the 5 tuple might include
   masking/wildcarding. The access network admits this flow according
   to its local policy and the specific details of the 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 the relationship between the PSTN
   GW and the policy server and the routers and the policy server is
   outside the scope of NSIS. The edge router then admits the flow into
   the core of the network, possibly using some aggregation technique.

   At the interior nodes, the NSIS host-to-host signaling should either
   be ignored or invisible as the Edge router performed the admission
   control decision to some aggregate.

   At the inter-provider router (i.e., border node), again the NSIS
   host-to-host signaling should either be ignored or invisible as the
   Edge router has performed an 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 use cases for the NSIS signaling protocol is the scenario
   of interconnecting PSTN gateways with an IP network that supports
   QoS.
   Four different scenarios are considered here.
     1. In-band QoS signaling is used. In this case the Media Gateway
        (MG) will be acting as the QoS Initiator and the Edge Router
        (ER) will be the QoS Controller. Hence, the ER should do
        admission control (into pre-provisioned traffic trunks) for the
        individual traffic flows. This scenario is not further
        considered here.
     2. Out-of-band signaling in a single domain, the QoS Controller is
        integrated in the MGC. In this case no NSIS protocol is
        required.
     3. Out-of-band signaling in a single domain, the QoS Controller is
        a separate box. In this case NSIS signaling is used between the
        MGC and the QoS Controller.
     4. Out-of-band signaling between multiple domains, the QoS
        Controller (which may be integrated 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 as the QoS Initiator.

   In the second scenario the 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 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     /
                                    +-------------------+

                 Figure 1: PSTN trunking gateway scenario

   In the third scenario, the voice provider does not lease traffic
   trunks in the network. Another entity may lease traffic trunks and
   may use a QoS Controller to do per-flow admission control. In this
   case the NSIS signaling is used between the MGC and the QoS
               Requirements for QoS Signaling Protocols      July 2002

   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 scenario

   In the fourth scenario multiple transport domains are involved. In
   the originating network either the MGC may have an overview on the
   resources of the overlay network or a separate QoS Controller will
   have the overview. Hence, depending on this either the MGC or the
   QoS Controller of the originating domain will contact the QoS
   Controller of the next domain. The MGC always acts as a QoS
   Initiator and may also be acting as a QoS Controller in the 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 guaranteed service from an IP network.
   draft, adding some ideas, requirements, etc. We assume here that the
   application is somehow able to specify the network service. The
   characteristics here are that many hosts might do it, but that the
   requested service is low capacity (bounded by the 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 significant issues in VPNs is
   related to how a flow is identified and what quality list them without a flow gets. A
   flow identification might consist among others of the transport
               Requirements for QoS Signaling Protocols      July 2002

   protocol port numbers. In an IP-Sec tunnel this will be problematic
   since the transport protocol information is encrypted.

   There are two types
   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 of L3 VPNs, distinguished Ulm), Ilya
   Freytsis.

   Some text and/or ideas for text, requirements, scenarios have been
   taken from a draft written by where the endpoints following authors: David Partain
   (Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia),
   Georgios Karagiannis (Ericsson), Jukka Manner (University of the tunnels exist. The endpoints
   Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars
   Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have
   actively contributed new text to the tunnels may either be on
   the customer (CPE) or 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 provider equipment or provider edge (PE).

   Virtual Private networks following we describe scenarios, which are also likely important to request bandwidth or
   other type of service in addition
   cover, and which allow us to the premium services the PSTN
   GW are likely discuss various requirements. Some
   regard this as use cases to use.

   Tunnel end points at the Customer premises

   When be covered defining the endpoints use of a QoS
   signaling protocol.

10.1 Terminal Mobility

   The scenario we are looking at is the CPE, the CPE may want 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 signal across handle mobility on the public IP network for a particular amount of bandwidth layer in this scenario and QoS
   for
   consider the tunnel aggregate. Such signaling may be useful when a
   customer wants various extensions (i.e., IETF proposals) to vary their network cost with demand, rather than
   paying a flat rate. Such signaling exists between the two CPE
   routers. Intermediate access Mobile IP,
   in order to provide 'fast handover' for roaming Mobile Terminals.
   The goal to be achieved lies in providing, keeping, and edge routers perform adapting the same exact
   call admission control, authentication and aggregation functions
   performed by
   requested QoS for the corresponding routers ongoing IP sessions in case of handover.
   Furthermore, the PSTN GW scenario negotiation of QoS parameters with the exception that the endpoints are the CPE tunnel endpoints rather
   than PSTN GWs and new domain
   via the 5-tuple used old connection might be needed, in order to describe support the RTP flow is
   replaced with
   different 'fast handover' proposals within the corresponding flow spec to uniquely identify IETF.

   The entities involved in this scenario include a mobile terminal,
   access points, an access network manager, communication partners of
   the
   tunnels. Tunnels may be MT (the other end(s) of any variety (e.g. IP-Sec, GRE, IP-IP).

   In such the communication association).
   From a scenario, NSIS would actually allow partly for customer
   managed VPNs, which technical point of view, terminal mobility means changing the
   access point of a customer can setup VPNs by subsequent
   NSIS signaling to mobile terminal (MT). However, technologies might
   change in various end-point. Plus directions (access technology, QoS technology,
   administrative domain). If the tunnel end-points access points are
   not necessarily bound 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 application. The customer administrator
   might be IntServ domain,
   however still using the one triggering NSIS signaling.

   Tunnel end same access technology. Finally, if the
   access points at 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 provider premises

   In access point, since the case were traffic conditions of the tunnel end-points exist on new
   access point are better supporting the provider edge,
   requests for bandwidth QoS requirements. The metric
   may be signaled either per flow, where a flow
   is defined from different (optimized towards a customers address space, single or between customer
   sites.

   In the case a group/class of per flow signaling, the PE router must map
   users). Note that the
   bandwidth request to MT or the tunnel carrying traffic to network (see below) might trigger
   the destination
   specified in handoff.

   - The mobility management forces handoff. This can have several
   reasons. The operator optimizes his network, admission is no longer
   granted (e.g. emptied prepaid condition). Or another example is when
   the flow spec. Such a tunnel MT is a member of an
   aggregate to which reaching the flow must be admitted. In focus of another base station. However, this case, the
   operation
   might be detected via measurements of admission control is very similar to QoS on the case physical layer and
   is therefore out of scope of QoS signaling in IP. Note again that
   the
   PSTN GW with MT or the additional level of indirection imposed by network (see below) might trigger the VPN
   tunnel. Therefore, authentication, accounting and policing may handoff.

   - This scenario shows that local decisions might not be
   required on enough. The
   rest of the PE router.

   In path to the case other end of per site signaling, a site would need the communication needs to be
   identified. This may be accomplished by specifying the network
   serviced at that site through an IP prefix. In this case, the
   admission control function is performed
   considered as well. Hand-off decisions in a QoS domain, does not
   only depend on the aggregate to local resource availability, e.g., the PE
   router connected to wireless
   part, but involves the site in question.

               Requirements for QoS Signaling Protocols      July 2002

Full Copyright Statement

  Copyright (C) The Internet Society (2000). All Rights Reserved.
  This document and translations rest 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 the path as well. Additionally,
   decomposition of an end-to-end reservation might be prepared, copied, published
  and distributed, in whole or needed, in part, without restriction order
   to change only parts of any
  kind, provided that it.

   2) Trigger sources
   - Mobile terminal: If the above copyright notice and this paragraph are
  included on all such copies and derivative works. However, this
  document itself may not end-system QoS management identifies
   another (better-suited) access point, it will request the handoff
   from the terminal itself. This will be modified especially likely in any way, such as by removing the copyright notice or references to case
   that two different provider networks are involved. Another important
   example is when the Internet Society or other
  Internet organizations, except as needed for current access point bearer disappears (e.g.
   removing the purpose of
  developing Internet standards in which case Ethernet cable). In this case, the procedures for
  copyrights defined in NSIS Initiator is
   basically located on the Internet Standards process must be
  followed, or as required to translate it into languages other than
  English.
  The limited permissions granted above are perpetual and mobile terminal.

   - Network (access network manager): Sometimes, the handoff trigger
   will not be
  revoked by issued from the Internet Society or its successors or assigns.
  This document and network management to optimize the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 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 overall
   load situation. Most likely this will result in changing the requirement concerning data sender or data receiver or
   both to initiate base-
   station of a QoS request.

   Terminology text added

   open issue, what single providers network. Most likely the NSIS
   Initiator is located on a potential req (currently we say "both must be
   possible")

   Proposals:
   1)should be optimized for sender initiated
   2) remove system within 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: network.

   3) Integration with other protocols

   - does Interworking with other protocol must be considered in one or the
   other form. E.g., it matter who pays?

   - for sender initiated, can we support implicit might be worth combining QoS signaling
   (bundling the between
   different QoS requests domains with other mobility signaling - registration,
   etc.)?

   - 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 reciever initiated, do we need protection against spamming -
   how do we protect against unwanted changes?
               Requirements example, in the GSM (Global System for QoS Signaling Protocols      July 2002

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

   28) (OPEN) new requirement on "asynchronous events from 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 network"

   The content handover rate is significantly higher.

   5) Fast reservations

   Handover can also cause packet losses. This happens when the
   processing of an admission request causes a delayed handover to the message
   new base station. In this situation, some packets might be very service specific, but the
   protocol support for asynchronous events from
   discarded, and the network overall speech quality might be degraded
   significantly. Moreover, a
   valuable requirement. We have something about notification delay in case
   of errors/failures.

   Asynchronous notification of handover may cause degradation
   for other users. In the worst-case scenario, a delay in handover may
   cause the connection to be dropped if the handover occurred due to
   bad air link quality. Therefore, it is critical that QoS Initiator, Controller, Receiver,
   there are security issues related. Basically, an ownership issue.
   Nevertheless, an asynch notifcation signaling
   in connection with handover be carried out very quickly.

   6) Call blocking in case of an error, overload

   Furthermore, when the network
   failure etc. is specifically in areas, where longer lived sessions
   are setup, essential in order overloaded, it is preferable to notify upper layers.

   44) (OPEN) req
   keep reservations for previously established flows while blocking
   new requests. Therefore, the resource availability info on request come back to it
   as soon as we have a more clear idea about service description issue

   53) (OPEN) Error handling

   Comments:
   1) notification of user reservation requests in case of unrecoverable errors (has been
   done by notification requirement, or will
   connection with handover should be done by asynch
   notification, issue 43)
   A description of both types given higher priority than new
   requests for resource reservation.

10.2 Cellular Networks

   In this scenario, the user is using the packet service of errors (recoverable, unrecoverable)
   are listed in Section 5.3.4.

   2) hop-by-hop? OR right 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 end?

   3) What GGSN in UMTS or the PDSN in 3GPP2) is potential value
   considered to notify about recoverable errors?
   Proposal: not hop by hop, but be a single QoS controller to domain.

   The issues in such an environment regarding QoS initiator

   59) (OPEN) add req: ability to deal include:

   1) Cellular systems provide their own QoS technology with severe congestion (req
   5.3.4 of draft-partain-..-00

   issues are:
   - occurs
   specialized parameters to co-ordinate the QoS provided by both the
   radio access and wired access network. For example, in a highly utilised network and  if it UMTS
   network, one aspect of GPRS is not solved very
   fast then the network performance will  quickly collapse
   - deos that it belong 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 failure recovery (I would assume from
   be invoked with suitable parameters when higher layers trigger a service
   point of view
   request for QoS, and this is failure
   - hop by hop problem (issue from Jorge)
   - What difference does it make (from therefore involves mapping the requested
   IP QoS perspective) if onto these UMTS bearer classes. This request for resources
   might be triggered by IP signaling messages that pass across the
   provided
   cellular system, and possibly other QoS degraded due to hardware failure on a device or due domains, to
   congestion caused by failures on some other devices? What is
   required from negotiate for
   network resources. Typically, cellular system specific messages
   invoke the protocol is to signal this failure to other
   participants (QCs or QI) underlying cellular system QoS technology in parallel
   with the hope that they can do something
   meaningful (e.g. re-routing) IP QoS negotiation, to correct allocate the problem or tear down resources within the
   flow.

   65) (OPEN) Request to add req: Unexpected situations and error
   restistance
   An NSIS protocol must define behaviour
   cellular system.

   2) The placement of NSIS signaling units
   during unexpected situations. Unexpected situtions are unknown
               Requirements for QoS Signaling Protocols      July 2002

   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) Initiators and requirement 5.3.4.
   This requirement is emphasizing to many details that might not be
   necessary

   Req 5.3.4 refers to behaviour NSIS Forwarders (terminology
   in the case of problems in framework given here). The NSIS Initiator could be located at
   the data
   plane. My suggestion here is about unexpected events/errors in End Host (triggered by applications), the
   control plane. If you think that this point carries to many details,
   let's split it up in several individual requirements.

   72) (OPEN) request to add "Error notification and error location"

   "An NSIS signaling node rejecting GGSN/PDSN, or releasing a reservation must
   indicate its identity. NSIS signalling should indicate why at a
   requested resource is
   node not or no longer available. "

   Compared to 5.3.4 this is about problems directly on the control plane

Closed Issues

   1) (CLOSED) add Scenarios
   Do we need to add, remove, or change data path, such as a bandwidth broker. In
   the second case, the scenarios?
   - added scenario GGSN/PDSN could either be acting as a proxy on
   behalf of an End Host with little capabilities, and/or managing
   aggregate resources within its QoS signalling between PSTN gateways domain (the UMTS core network).
   The IP signaling messages are interpreted by the NSIS Forwarders,
   which may be located at the GGSN/PDSN, and
   backbone routers
   - added: Application request end-to-end in any QoS path from sub-domains
   within the network
   - added VPN scenario
   We can add what ever scenario we want. The more cellular system.

   3) Initiation of IP-level QoS negotiation. IP-level QoS re-
   negotiation may be initiated by either the better to
   understand End Host, or by the issues. Nevertheless, we have to take care that we
   are future prove as well.

   3) (CLOSED) Draft organization

   The proposed changes include
   - put all
   network, based on current network loads, which might change
   depending on the scenarios into an appendix
   - In Section 6 add text describing 3 different "parts location of the
   network"
        -Host to first hop
        -access network
        -core end host.

   4) The networks
     better names are welcome, but I don't want to be religious about
   it

   - Prioritize the requirements according designed and mainly used for speech
   communication (at least so far).

   Note that in comparison to the "parts of former scenario, the
   network" (This means emphasis is much
   less on the mobility aspects, because mobility is mainly handled on
   the tables lower layer.

10.3 UMTS access

   The UMTS access scenario is shown in Section 6 of the current
   draft will get three colums with the MUST, SHOULDs, and MAYs for
   each requirement

   5) (CLOSED) Framework text. figure 3. The figures have been removed, because they seamed to be misleading. Proxy-Call State
   Control Function/Policy Control Function (P-CSCF/PCF) is the
   outbound SIP proxy of the text has been revisited. I regard visited domain, i.e. the issue closed until we have
   a clear picture about what domain where the NSIS framework draft is about.

               Requirements for QoS Signaling Protocols      July 2002

   6) (CLOSED)
   mobile user wants to set-up a call. The requirement organization
   I heard some voices on Gateway GPRS Support Node
   (GGSN) is the list that egress router of the grouping should be more
   along UMTS domain and connects the lines of host-to-edge, edge UMTS
   access network to edge etc.
   So far I have not changed it, because I though that the requirements
   heavily depend on Edge Router (ER) of the scenario we are looking at.

   closed, by core IP network. The
   P-CSCF/PCF communicates with the change in GGSN via the draft organisation (issue 3)

   7) (CLOSED) Hemant Chaskar: Section 3.1, items 1) Handoff decision
   and 2) Trigger sources: COPS protocol. The handoff decision and trigger sources
   should be out of scope
   User Equipment (UE) consists of NSIS. a Mobile Terminal (MT) and Terminal
   Equipment (TE), e.g. a laptop.

                           +--------+
                +----------| P-CSCF |-------> SIP signaling
               /           +--------+
              / SIP            :
             :             +--------+   NSIS should rather focus only on
   "establishing" QoS along  +----------------+
             :             |  PCF   |---------| NSIS Forwarder |
             :             +--------+         +----------------+
             :                 :
             :                 : COPS
             :                 :
           +----+          +--------+      +----+
           | UE |----------|  GGSN  |------| ER |
           +----+          +--------+      +----+

                      Figure 1: UMTS access scenario

   In this scenario the packet path after handoff.

   added exclusion

   8) (CLOSED) bi-directional data path setup with one QoS request
   I have not seen consensus on whether to require bi-directional data
   path setup with QoS.

   Q: How can we actually perform bi-directional reservations when GGSN has the
   forward and reverse paths are not reciprocal, with respect to
   routing topology and routing policy role of network domains between
   sender and receiver?

   A: bi-directional data path setup does not need Access Gate. According to use
   3GPP standardization, the same
   return path as PCF is responsible for the forwarding path. The only requirement policy-based
   control of the end-user service in the UMTS access network (i.e.
   from UE to achieve
   a bi-directional reservation is that GGSN). In the sender for current UMTS release R.5, the forwarding
   path PCF is also part
   of the receiver for P-CSCF, but in UMTS R.6 the return path interface between P-CSCF and that PCF
   may evolve to an open standardized interface. In any case the receiver PCF
   has all required QoS information for per-flow admission control in
   the  forwarding path is also UMTS access network (which it gets from the sender for P-CSCF and/or GGSN).
   Thus the return path.

   - The need PCF would be the appropriate entity to ensure that host the return path is
   functionality of NSIS Initiator, initiating the same as "NSIS" QoS signaling
   towards the
   forwarding path is one of core IP network. The PCF/P-CSCF has to do the problems with RSVP, particularly mapping
   from codec type (derived from SIP/SDP signaling) to IP traffic
   descriptor. SDP extensions to explicitly signal QoS information are
   useful to avoid the need to store codec information in a
   mobile environment.

   added some explanations that we do not require the same path, PCF and
   that the goal is an optimization
   to allow for more flexibility and accurate description of the setup delay

   9) (CLOSED) Potential requirement: must be implementable in user
   space (on end hosts)

   has not been included in QoS
   traffic parameters. The PCF also controls the req list because it seams GGSN 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 open and 18, closed

   11) (CLOSED) Potential requirement: Flexibility in close
   the granularity
   of reservation (I don't remember who brought it up, but I assume it
   refers gates and to configure per-flow policers, i.e. to the flexibility in terms authorize or
   forbid user traffic.

   The NSIS Forwarder is (of course) not part of what size the flow has. Where
   size can be bandwidth etc.)
               Requirements for standard UMTS
   architecture. However, to achieve end-to-end QoS Signaling Protocols      July 2002

   The assumption a NSIS Forwarder is
   needed such that the PCF can request a QoS classes as well as service definitions are
   out of scope for this draft, also connection to the flexibility is.

   12) (CLOSED) text replacing scalability reqs

   "The nsis architecture should give IP
   network. As in the ability to constrain previous example, the load
   (CPU load, memory space, signaling NSIS Forwarder could manage
   a set of pre-provisioned resources in the IP network, i.e. bandwidth consumption
   pipes, and
   signaling intensity) on devices where it is needed. This the NSIS Forwarder performs per-flow admission control
   into these pipes. In this way, a connection can be
   achieved by many different methods, made between two
   UMTS access networks, and hence, end-to-end QoS can be achieved. In
   this case the NSIS Initiator and NSIS Forwarder are clearly two
   separate entities.
   This use case clearly illustrates the need for example message aggregation,
   by ignoring an "NSIS" QoS
   signaling message, header compression or minimizing
   functionality. The architecture may choose any protocol between NSIS Initiator and NSIS Forwarder. An
   important application of these methods as
   long as the requirement is met."

   Editor: added such a protocol may be its use in 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
   inter-connection of UMTS networks over an IP backbone.

10.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 the wireless network operator to assign (i.e., Radio
   Access Network) and the nsis protocol messages a certain transport quality. As signaling
   opens up for possible denial-of-service attacks, backbone of the wireless network, as shown
   in Figure 2. Note that this requirement
   gives figure should not be seen as an
   architectural overview of wireless networks but rather as showing
   the network operator conceptual QoS domains in a mean, but also wireless network.

   In this scenario, a mobile host can roam and perform a handover
   procedure between base stations/access routers. In this scenario the obligation, to
   trade-off
   NSIS QoS protocol can be applied between signaling latency a base station and the impact (from the
   signaling messages) on devices within his/her network. From protocol
   design
   gateway (GW).  In this requirement states that case a GW can also be considered as a local
   handover anchor point. Furthermore, in this scenario the NSIS QoS
   protocol messages should can also be
   detectable, at least where the control and assignment 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
                                            ... = interior nodes
            <------------------->
       Wired part of the
   messages priority is done."

   text has been added

   14) (CLOSED) proposal to add "support grouping wireless network

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

      Figure 2. QoS architecture of microflows
   (possibly only for feedback)"
   "As a consequence wired part of wireless network

   Each of these parts of the optimization for the interactive multimedia
   services, wireless network impose different issues
   to be solved on the QoS signaling should allow one unique request for several
   micro flows having the same origination and destination IP
   addresses. This is usually the case solution being used:

   - Wireless interface: The solution for multimedia SIP calls where the voice air interface link
     has to ensure flexibility and video micro flows follow the same path. This grouping
   of requests allows optimization spectrum efficient transmission
     of the QoS processing. Note that IP packets.  However, this may link layer QoS can be detrimental for solved in
     the call setup time. The use of grouping
   for microflows may be restricted to teardown and/or notification
   messages when call setup time is same way as any other last hop problem by allowing a concern."

   Should not be restrict
     host to teardown and/or notification, it might be
   useful also for request the procedure that refreshes reservation states

   added that requirement.

   15) (CLOSED) Support for preemption proper QoS profile.

   - Wired part of sessions
   -might play into the fault/ error handling case
   -is regarded as service-specific, whether existing sessions can be
   pre-empted
   Conclusion: it wireless network:  This is network policy to determine how to do pre-emption,
   not a protocol issue.

               Requirements for QoS Signaling Protocols      July 2002

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

   we did not find a better word

   17) (CLOSED) add assumption that QoS classes/service definitions are
   already known to all the parties involved in signaling before hand
   (before a signalling session even starts

    added text in Section 4.1

   18) (CLOSED) add exclusion part of methods, protocols, and ways to
   express QoS
   Even so, this might be covered by saying
     the network that we are independent of
   QoS classes and service description etc. (see issue 17), I added two
   points is closest to the exclusion Section 4.2.

   Implications: issue 20, 23,

   19) (CLOSED) remove req 5.2.5 base stations/access
     routers.  It is an IP fragmentation

   20) (CLOSED) remove req 5.3.2 Ability to signal life-time network although some parts logically
     perform tunneling of a
   reservation

   is regarded service-specific therefore the end user data. In cellular networks,
     the wired part of the service
   description

   added some reservation life time text service description assumption
   text and removed wireless network is denoted as a
     radio access network.

     This part of the req

   21) (CLOSED) remove req 5.5.4 Aggregation method specification

   Concerns
   -QI not able wireless network has different
     characteristics when compared to know the impact traditional IP networks:

         1. The network supports a high proportion of real-time
            traffic.  The majority of aggregation
   -to far down the implementation/ service definition road
   -leave it to traffic transported in the provider how a service
            wired part of the wireless network is realized

   removed

   22) (CLOSED) remove 5.3.7 Automatic notification on available
   resources not been granted before

   regarded speech, which is
            very sensitive to complex delays and is heavily dependend on the service
   description

   removed

   23) (CLOSED) remove 5.5.3 Simple mapping delay variation (jitter).

         2. The network must support mobility.  Many wireless
            networks are able to lower-layer QoS
   provisioning parameters

   this heavily depends provide a combination of soft
            and hard handover procedures.  When handover occurs,
            reservations need to be established on service definition new paths.
            The establishment time has to be as short as possible
            since long establishment times for reservations degrade
            the performance of the wireless network.  Moreover,
            for maximal utilization of the radio spectrum, frequent
            handover operations are required.

         3. These links are typically rather bandwidth-limited.

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

         5. The radio base stations are spread over a wide
            geographical area and 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 are in general situated a large
            distance from the actually
   received level backbone.

   - Backbone of QoS guarantees" with two requirements: 1) the
   feedback wireless network: the requirements imposed
     by this network are similar to the requirements imposed by
     other types of a request MUST include yes backbone networks.

   Due to these very different characteristics and no (MUST respond yes or
   no) 2) requirements, often
   contradictory, different QoS signaling solutions might be needed in case
   each 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 three network parts.

10.5 Session Mobility management

   However the integration should not be

   In this scenario, a priori excluded, there is
   explicitly no statemant about independence of mobility management.

   There session is more discussion for the mobility case needed anyway.

   26) (CLOSED) interaction of NSIS with seamoby (context transfer moved from one end-system to another.
   Ongoing sessions are kept and
   CAR discovery)

   added requirement, that NSIS should interwork with seamoby protocols

   27) (CLOSED) remove req 5.5.10 QoS conformance specification
   Motivation: this heavily depends on parameters need to be adapted,
   since it is very likely that the service definition and new device provides different
   capabilities. Note that it is
   therefore out of scope

   removed

   29) (CLOSED) NSIS in case of handovers
   issue 26, mentions open which entity initiates the move,
   which implies that the NSIS should interwork with handoffs

   30) (CLOSED) remove 5.1.7 Avoid modularity with large overhead (in
   various dimensions)

   removed because it seams to Initiator might be obvious

   31) (CLOSED) remove 5.1.8 Possibility to use triggered by
   different entities.

   User mobility (i.e., a user changing the signaling protocol
   for existing local technologies

   It is contradictory to 5.1.9 device and therefore moving
   the intention behind sessions to the
   requirement new device) is covered by considered to be a special case
   within the requierement session mobility scenario.

   Note that this scenario is different from terminal mobility. Not the QoS controller
   can be placed wherever needed.

   32) (CLOSED) add assumption: there are means for discovery of nsis
   entities in order
   terminal (end-system) has moved to know the signaling peers (solutions include
   static configuration, or automatically discovered etc.)

   33) (CLOSED) add req " highest possible network utilization"
   "There a different access point. Both
   terminals are networking environments that require high still connected to an IP network
   utilization for various reasons, and at their original
   points.

   The issues include:

   1) Keeping 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 guarantees negotiated implies that the end-
   point(s) of communication are very expensive (as is changed without changing the case for
   many wireless networks), efficient network utilization is
   reservations.

   2) The trigger of
   critical financial importance.  On the session move might be the user or any other hand there are other
   parts of
   party involved in the session.

10.6 QoS reservations/negotiation from access to core network where high utilization is not required.
   "

   req added

   34) (CLOSED)_difference

   The scenario includes the signaling between "UMTS access scenario" "cellular
   network scenario", networks and "Wired part of wireless network" (Section
   8.2, 8.3, core
   networks in order to setup and 8.4)

   all three change reservations together with
   potential negotiation.

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

   1) The only common point between 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 three scenarios traffic (amount of traffic), a
   particular QoS is that they guaranteed for, needs to be changed. E.g., in case
   additional flows are
   related added to cellular networks. Section 8.4 is introducing the
   scenario used aggregate, the traffic
   specification of the flow needs to be added if it is not already
   included in the radio access aggregates specification.

   4) The flow specification is more complex including network of cellular networks.
   Sections 8.2
   addresses and Section 8.3 are discussing other parts sets of different address for the
   cellular network.

   35) (CLOSED) difference between source as well as
   for the destination of the flow.

10.7 QoS reservation/negotiation over administrative boundaries

   Signaling between two PSTN gateway scenarios
   (Section 8.8 and 8.9)

   currently both are included, they might be merged, sionce one seams
   to be or more general than the other

   36) (CLOSED) req "Independence of reservation identifier"
   issue here core networks to provide QoS is that
   handled in this scenario. This might only be valuable in mobile
   environments, and complicate also include access to core
   signaling over administrative boundaries. Compared to the protocol for other environments.

   there previous
   one it adds the case, where the two networks are related issues (37,38,

   37) (CLOSED) ownership of a reservation

   The issue here is that a known party owns reservations done not in the
   network. (which might include that same
   administrative domain. Basically, it is the party also pays). inter-domain/inter
   provider signaling which is handled in here.

   The
   question arose who domain boundary is allowed the critical issue to tear-down, receive asynchronous
   notifications in case be resolved. Which as
   various flavors of network initiated tear-down, etc.

   This also relates issues a QoS signaling protocol has to how certain service granted is
   named/identified.

   req 5.8.9 added (renamed)

   38) (CLOSED) definition of security threats
   handled in draft-tschofenig-nsis-threats-00.txt

   39) (CLOSED) simplify security requirements section
   done

   40) (CLOSED) add mobility related requirements
   we have some mobility related requirements, but do 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
   internals (e.g., topology, technology, etc.) should not be
   exchanged. Some information exchange about the "access points" of
   the core networks (which is topology information as well) may need
   to add
   more
               Requirements for QoS Signaling Protocols      July 2002

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

   42) (CLOSED) add an assumption that QoS monitoring needed for proper signaling.

   2) Additionally, as in scenario 4, signaling most likely is application-
   specific and based on
   aggregates, with it out of scope of all the WG (done)

   43) (CLOSED) asynchronous notification of QoS Initiator, Controller,
   Receiver, there are security issues related. Basically, an ownership
   issue. Nevertheless, an asynch notifcation in case of an error,
   network failure etc. raise there.

   3) Authorization: It is specifically in areas, where longer lived
   sessions are setup, essential in order critical that the NSIS Initiator is
   authorized to notify upper layers,
   applications etc. perform a QoS path setup.

   4) Accountability: It is important to notice that signaling might be
   used as well.

   45) (CLOSED) 5.3.4 Possibility for automatic re-setup of resources
   after recovery
   - more thoughts in failure conditions potentially
   - better text
   - operation under overload
   plays into issue 46) an entity to charge money for, therefore the interoperation
   with accounting needs to be available.

10.8 QoS signaling between PSTN gateways and backbone routers

   A PSTN gateway (i.e., host) requires information from the network
   regarding its ability to transport voice traffic across the network.
   The requirement has been removed:

   "Possibility voice quality will suffer due to packet loss, latency and
   jitter. Signaling is used to identify and admit a flow for automatic re-setup of resources after recovery which
   these impairments are minimized.  In case of a failure, addition, the reservation can get setup again
   automatically. It enables sort disposition of a persistent reservation, if
   the
   QoS Initiator requests it. In scenarios where signaling request is used to allow the reservations are
   on a longer time scale, this could make sense PSTN GW to reduce make a call
   routing decision before the
   signaling load in case of failure and recovery."

   46) (CLOSED) we might need multiple scenarios for failure call is actually accepted and
   recovery cases delivered
   to derive requirements. Or a list the final destination.

   PSTN gateways may handle thousands of failure cases
   might be a start as well.

   47) (CLOSED) traffic engineering calls simultaneously and route pinning
   added Assumption: NSIS should work with networks using standard L3
   routing.

   added requirement: NSIS should not there
   may 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 hundreds of detail PSTN gateways in description.
   (Motivation: someone interpreting a single provider network. These
   numbers are likely to increase as the request size of the network increases.
   The point being that scalability is a major issue.

   There are several ways that a PSTN gateway can acquire assurances
   that a network can tune carry its own level
   of complexity by going down to more or less levels of detail. A
   lightweight implementation within traffic across the core could consider only network. These
   include:

     1. Over-provisioning a high availability network.
     2. Handling admission control through some policy server
        that has a global view of the
   coarsest level.)"

   removed, because it is service-specific

   49) (CLOSED) remove req 5.5.9 Signaling must support quantitative,
   qualitative, network 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, 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 minimize negotiation latency carry a single RTP flow).

   Item 1 requires no signaling at all 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 therefore outside the requirement text somewhere else:

   Heading: Avoid duplication
   scope of [sub]domain signaling functions

   The specification this working group.

   Item 2 is really a better informed version of 1, but it is also
   outside the NSIS signaling protocol should be optimized
   to avoid duplication scope 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 this working group as it has
   to be end-to-end, universal to all network types
   ('simple/lightweight'), or if relies on a particular
   telephony signaling protocol rather than a packet admission control
   protocol.

   Item 3 is initially attractive, as it has appears 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, reasonable
   scaling properties, however, its scaling properties only are
   effective in many cases where there are relatively few PSTN GWs. In the local QoS technology will contain equivalent functions to
   the NSIS-required ones, just in
   more general case were a technology specific form. Examples
   of these functions would be error/QoS violation notifications,
   ability PSTN GW reduces to query a single IP phone
   sitting behind some access network, the opportunities for resources
   aggregation are reduced and so on. So, there the problem reduces to item 4.

   Item 4 is the most general case. However, it has the most difficult
   scaling problems. The objective here is a danger to place the requirements on
   Item 4 such that
   our 'lightweight' a scalable per-flow admission control protocol or
   protocol suite may be developed.

   The case where per-flow signaling ends up trying extends to carry all individual IP end-
   points allows the inclusion of IP phones on cable, DSL, wireless or
   other access networks in this
   information all over again, scenario.

   Call Scenario

   A PSTN GW signals end-to-end for some 5 tuple defined flow a
   bandwidth and (even worse) QoS requirement. Note that the
   initiator/controller functions have 5 tuple might include
   masking/wildcarding. The access network admits this flow according
   to weigh up nearly equivalent
   information coming from two directions. However, its local policy and the basic problem
   here specific details of the 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 the boundary relationship between new and re-used stuff is pretty
   shaky. The requirement is trying to scope our problem (a) to
   eliminate the potential overlap, PSTN
   GW and (b) to keep the new NSIS stuff
   simple.

   However, we are aware that it is very difficult to judge what is
   duplicated, if we want to run the protocol in various environments.

   52) (CLOSED) New requirement: interaction with policy
   Is part of server and the AAA solution or service definition, routers 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 policy server is out-of-scope of
   outside 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 scope of succesful or erroneous processing NSIS. The edge router then admits the flow into
   the core of QoS signalling
   messages at one border node.

   In the network, possibly using some domains, aggregation technique.

   At the interior nodes, the NSIS QoS signalling protocol MAY carry
   identification of host-to-host signaling should either
   be ignored or invisible as the ingress and egress edge between Edge router performed the ingress-
   egress edges.  However, admission
   control decision to some aggregate.

   At the identification of edges inter-provider router (i.e., border node), again the NSIS
   host-to-host signaling should not either be
   visible to ignored or invisible as the end host and only applies within one QoS
   administrative domain.
   "

   Comments:
   - service mapping
   Edge router has performed an admission control decision about an
   aggregate across a carrier network.

10.9 PSTN trunking gateway

   One of the use cases for the NSIS signaling protocol is more service-specific (layering,tunneling)
   - the scenario to look at is a complicated service description -> in
   part
   of the interconnecting PSTN gateways with an IP network you want to change that supports
   QoS.
   Four different scenarios are considered here.
     1. In-band QoS signaling is used. In this case the message to something more
   easy, and at Media Gateway
        (MG) will be acting as the other end go back to NSIS Initiator and the more complicated part.
   -QI being everywhere might be enough
   -and we have already a requirement saying that intermediate node
   MUST Edge Router
        (ER) will be able to add/remove domain-specific information to/from the NSIS Forwarder. Hence, the ER should do
        admission control (into pre-provisioned traffic trunks) for the
        individual traffic flows. This scenario is not further
        considered here.

     2. Out-of-band signaling messages

   56) (CLOSED) add req 5.3.1.3 of draft-partain-..-00
   -already added in a req to single domain, the scalability section (issue ???), which
   has been provided by Anders

   57) (CLOSED) potentially better title for text from issue 56) e.g.
   (śśminimal impact on core∆∆)

   58) (CLOSED) add req 5.3.2 from draft-partain-...-00

   - NSIS Forwarder is
        integrated in the fast establishment req MGC. In this case no NSIS protocol is handled by
        required.
     3. Out-of-band signaling in a single domain, the low setup latency
   req, NSIS Forwarder is
        a separate box. In this case NSIS signaling is used between the
        MGC and the scalability NSIS Forwarder.
     4. Out-of-band signaling between multiple domains, the NSIS
        Forwarder (which may be integrated in handover req

   - added the text to MGC) triggers the teminal mobility scenario

   - added text " time scale (e.g., handover in mobile environments),"
   to req

   60) (CLOSED) add req 5.4.3. from draft-partain-...-00 "Allow
   efficient
        NSIS Forwarder of the next domain.

   When the out-of-band QoS re-establishment after handover"

   "Handover signaling 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 used the Media Gateway
   Controller (MGC) will be requested by acting as the
               Requirements for QoS Signaling Protocols      July 2002

   mobile node itself or triggered by NSIS Initiator.

   In the access point second scenario the voice provider manages a set of traffic
   trunks that are leased from a network provider. The MGC does the mobile
   node
   admission control in this case. Since the NSIS Forwarder acts both
   as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is attached to.
   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     /
                                    +-------------------+

                 Figure 1: PSTN trunking gateway scenario

   In the first case, the QoS signalling should
   allow efficient QoS re-establishment after handover.  Re-
   establishment of QoS after handover should be as quick as possible
   so that third scenario, the mobile node voice provider does not experience service interruption or
   QoS degradation. The re-establishment should be localized, lease traffic
   trunks in the network. Another entity may lease traffic trunks and not
   require end-to-end signalling, if possible."

   - most likely it is already cover, please check again, whether there
   may use a NSIS Forwarder to do per-flow admission control. In this
   case the NSIS signaling is something missing
   - added it again under used between the mobility requiremments

   61) (CLOSED) add req: 6.1.8 from draft-bucheli-...-00 on multicast
   "Multicast consideration should not impact MGC and the protocol complexity
   for unicast flows. Multicast support NSIS
   Forwarder, which is not considered a separate box here. Hence, the MGC acts only as
   a
   priority, because NSIS Initiator. This scenario is depicted in figure 2.

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

                 Figure 2: PSTN trunking gateway scenario

   In the targeted interactive multimedia services fourth scenario multiple transport domains are
   mainly unicast. For this reason, if considered in involved. In
   the solution,
   multicast should not bring complexity in originating network either the unicast scenario."

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

   62) (CLOSED) Request to add VPN scenario
   - Related to issue 1)
   - Difference of VPN scenario compared to what we already MGC may have is
   missing

   added the scenario

   63) (CLOSED) added Sven Van den Bosch, Maarten Buchli, and Danny
   Goderis to acknowledgement section.

   64) (CLOSED) Request to add req: Backwards compatibility
   A later version of an NSIS protocol must be backwards compatible
   with earlier versions overview on the
   resources of an the overlay network or a separate NSIS protocol.

   we can take of this if we Forwarder will
   have NSIS.

   66) (CLOSED) Request to add req: Default behaviour
   An NSIS protocol must define default behaviours and parameter
   settings wherever applicable.
   Is assumed to be normal practice.

   67) (CLOSED) Request to add req: Extendability
   An NSIS protocol must provide means to enhance a protocol with
   future procedures, messages, parameters and parameter settings.

   This was refering mostly to the service specific part of overview. Hence, depending on this either the
   protocol.
   could be a part of MGC or the modularity requirement 5.1.3

   68) (CLOSED) Request to add req: Preventation
   NSIS Forwarder of stale state
               Requirements for QoS Signaling Protocols      July 2002

   An the originating domain will contact the NSIS signalling protocol must provide means for an
   Forwarder of the next domain. The MGC always acts as a NSIS signaling
   unit to discover
   Initiator and remove local stale state. This may for example also be done by means like soft state and periodic flooding or by acting as a
   polling mechanism and hard state signaling.

   Might already be covered NSIS Forwarder in other requirements, could also the first
   domain.

10.10  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 guaranteed service from an IP network. We assume here that the solutions known are solutions for different problems. I think
   distributed garbage collection could also be a solution.

   merged this text into requirement 5.3.2

   69) (CLOSED) Request
   application is somehow able to add req: Reliable Communication
   NSIS signaling procedures, connectivity between units involved in
   NSIS signaling as well as specify the basic transport protocol used network service. The
   characteristics here are that many hosts might do it, but that the
   requested service is low capacity (bounded by NSIS
   must provide the access line).
   Additionally, we assume no mobility and standard devices.

    QOS for Virtual Private Networks

   In a maximum of communication reliability. Procedures must
   define how an NSIS signaling systems behaves if some kind Virtual Private Network (VPN) a variety of request
   it sent stays without answer (this tunnels might be
   used between its edges. These tunnels could require e.g. be timers,
   number of message retransmits for example, IP-Sec,
   GRE, 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 IP-IP. One of the most significant issues in VPNs is
   related to how a DoS attack tool - the frequency of these
   checks must be limited, flow is identified and what quality a flow control may be useful).
   The basic gets. A
   flow identification might consist among others of the transport
   protocol to port numbers. In an IP-Sec tunnel this will be used between adjacent NSIS units
   must ensure message integrity and reliable transport.

   MUST/SHOULD ensure error- and loss free transmission problematic
   since the transport protocol information is encrypted.

   There are two types of signaling
   information.

   Added some L3 VPNs, distinguished by where the endpoints
   of the tunnels exist. The endpoints of the text to req 5.11.1

   70) (CLOSED) Request to add req: Smooth breakdown
   A unit participating in NSIS signaling must no cause further damage tunnels may either be on
   the customer (CPE) or the provider equipment or provider edge (PE).

   Virtual Private networks are also likely to request bandwidth or
   other systems involved in NSIS signaling when it has to go out type of
   service.

   added as requirement 5.11.2

   71) (CLOSED) Changed text "5.6.8: Ability to constrain load on
   devices" service in addition to

   The NSIS architecture should give the ability premium services the PSTN
   GW are likely to constrain use.

   Tunnel end points at 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 Customer premises
   When the endpoints are only
   examples, include message aggregation, by ignoring signaling
   message, header compression, or minimizing functionality. The
   framework the CPE, the CPE may choose any method as long as want to signal across
   the requirement is met.

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

   73) (CLOSED) add table of contents
               Requirements public IP network for a particular amount of bandwidth and QoS Signaling Protocols      July 2002

   ------------------------------------------------------
   Change Log Version 01 -> 02
   - added issues 62-72

   - added some discussion text
   for the tunnel aggregate. Such signaling may be useful when a
   customer wants to open issues

   - req " highest possible vary their network utilization" added (issue 33,
   closed)

   - issues closed: 34 (UMTS scenarios), 35 (PSTN gatway scenarios),

   - removed req "Avoid duplication of [sub]domain cost with demand, rather than
   paying a flat rate. Such signaling
   functions", issue 51

   - Section 5.3.4: added explanation of recoverable exists between the two CPE
   routers. Intermediate access and edge routers perform the same exact
   call admission control, authentication and aggregation functions
   performed by the corresponding routers in the PSTN GW scenario with
   the exception that the endpoints are the CPE tunnel endpoints rather
   than PSTN GWs and unrecoverable
   errors (issue 53)

   - added the following requirement: (closed issue 55) Allow local QoS
   information exchange between nodes of 5-tuple used to describe the saeme administrative
   domain

   The QoS signaling protocol must be able RTP flow is
   replaced with the corresponding flow spec to exchange local QoS
   information between QoS controllers located within one single
   domain. Local QoS information might, for example, uniquely identify the
   tunnels. Tunnels may be IP addresses,
   severe congestion notification, notification of successful or
   erroneous processing of QoS signaling messages. any variety (e.g. IP-Sec, GRE, IP-IP).

   In some cases, the such a scenario, NSIS QoS signalling protocol may carry
   identification of the QoS controllers located at the boundaries of would actually allow partly for customer
   managed VPNs, which means a
   domain. However, customer can setup VPNs by subsequent
   NSIS signaling to various end-point. Plus the identification of edge should tunnel end-points are
   not be visible necessarily bound to an application. The customer administrator
   might be 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 triggering NSIS signaling.

   Tunnel end points at the provider premises

   In the case were the tunnel end-points exist 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 provider edge,
   requests for QoS Signaling Protocols      July 2002

   [8] NSIS should allow bidirectional reservations as an optimisation bandwidth may be signaled either per flow, where a flow
   is defined from a customers address space, or between customer
   sites.

   In the network topology allows it. (done)

   [14] Grouping case of microflows. Added (as a MAY, probably). Network
   does not need per flow signaling, the PE router must map the
   bandwidth request to know relationship exists. Add justification the tunnel carrying traffic to the destination
   specified in the flow spec. Such a tunnel is a member of why an
   aggregate to which the flow must be admitted. In this case, the
   operation of admission control is an optimization. (done)

   [16] Closed. (done)

   [26] Interaction with seamoby. Add requirement very similar to say that we are
   interworking in the area case of mobility protocols (e.g. CT and CAR
   discovery). (done)

   [28] Asynchronous events from the network. REH & Sven to propose
   wording including some motivation as examples. Issues to do
   PSTN GW with
   locality and scenarios. (resilience draft from Sven)

   [29] NSIS in case the additional level of handovers. No change needed concerning
   handovers. (closed indirection imposed by the issue: done)

   [37] Ownership VPN
   tunnel. Therefore, authentication, accounting and policing may be
   required on the PE router.

   In the case of per site signaling, a reservation. Close issue and handle it within
   security section. (done, changed security req text)

   [39] Simplify security section. (done)

   [40] Mobility requirements - don't add. Closed. (done)

   [42] Add assumption site would need to be
   identified. This may be accomplished by specifying the network
   serviced at that QoS monitoring site through an IP prefix. In this case, the
   admission control function is application/service
   specific performed on the aggregate to the PE
   router connected to the site in question.

Full Copyright Statement

  Copyright (C) The Internet Society (2002). All Rights Reserved.

  This document and out of scope. (done)

   [43] Notification of QI/QC/QR. Closed earlier. (done, put together
   with issue 28)

   [44] Resource availability query.  Query not as 'real' reservation
   is part translations of service definition. May need new requirement about
   endpoint controlling locality 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 signalling.

   [45] Automatic re-installation. Removed, leave open option to supply
   text for new requirement. (done)

   [46] Scenarios for failure any
  kind, provided that the above copyright notice and recovery cases. Remove, invite
   individual contributions. (done)

   [47] Traffic engineering this paragraph are
  included on all such copies and route pinning issues. Assumption: NSIS
   should work with networks using standard L3 routing. NSIS should derivative works. However, this
  document itself may not be broken modified in any way, such as by networks which do non-traditional L3 routing. (done)

   [52] Closed. Aspect of AAA (authentication --> authorisation)
   solution removing
  the copyright notice or service definition. (done)
   [53] Sven et al. references to write submissions.
   [59] Covered under [53].
   [61] Closed. (done)
   [64] Closed (no new text the Internet Society or other
  Internet organizations, except maybe motherhood statements). (done)
               Requirements as needed 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 the purpose of
  developing Internet standards in transport service quality
   requirement). Protocol design which case the procedures for
  copyrights defined in the Internet Standards process must take into account reliability
   concerns. (done)
   [70] Add something about graceful failover to general protocol
   requirements section. (done)
   [72] Closed. Should be possible for NSIS
  followed, or as required to transport useful error
   messages.

   - changed security text
   - rearranged open issues (open ones translate it into languages other than
  English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on top) 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.