Robert Hancock
   Internet Draft                                       Eleanor Hepworth
   Document: draft-hancock-nsis-framework-00.txt      Siemens/Roke Manor
   Expires: August 2002
                                                        Cornelia Kappler
                                                       Hannes Tschofenig
                                                             Jochen Eisl
                                                           Jorge Cuellar
                                                            Mehmet Ersue
                                                              Siemens AG

                                                             Xiaoming Fu
                                                             Holger Karl
                                                               TU Berlin

                                                          Marcus Brunner

                                                         Andreas Kassler
                                                       University of Ulm

                                                       February 22, 2002

           Towards a Framework for QoS Signaling in the Internet

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-

   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
   The list of Internet-Draft Shadow Directories can be accessed at

   Hancock et al.    Informational - Expires August 2002             1                 Towards a Framework for QoS Signaling    February 2002


   This Internet Draft presents a framework for further development of
   QoS signaling in the Internet. We give a basic model for the
   entities involved in QoS signaling, which is intended to be
   applicable to a very wide range of networking environments, while
   still retaining the flexibility to allow lightweight implementations
   in particular environments and incremental deployment in the
   Internet as a whole.

   As well as the details of the framework itself, we also relate it to
   the NSIS requirements work by mapping the framework to the
   requirements themselves. We also present an initial assessment of
   the applicability of existing QoS mechanisms to be used within the
   framework. Security, scalability, and resilience are considered as
   special issues. The framework leaves open a number of questions
   relating to tradeoffs between simplicity and flexibility, and these
   are summarized in the conclusions.

Table of Contents

   1  Introduction ...................................................3
   1.1  Fundamental Approach .........................................4
   1.2  Scope and Design Principles ..................................5
   1.3  Document Structure ...........................................6
   2  Terminology ....................................................7
   3  Framework Overview .............................................7
   3.1  Fundamental Building Blocks ..................................7
   3.2  Fundamental Network Structures ..............................10
   3.3  Abstract Entities in QoS Signaling paths ....................14
   3.4  Basic Signaling Paths .......................................17
   3.4.1 Sender Initiated ...........................................18
   3.4.2 Receiver Initiated Reservations ............................18
   3.4.3 Bi-Directional Reservations ................................20
   3.5  Impact of Accounting Considerations .........................22
   3.6  Security Overview ...........................................23
   3.7  Refinements and Extensions ..................................24
   3.7.1 Proxy NSIS Agents ..........................................24
   3.7.2 Multicast ..................................................25
   4  Fundamental Framework Components ..............................26
   4.1  Interactions with Application Layers ........................26
   4.2  Interactions with QoS Provisioning ..........................27
   4.3  NSIS Signaling Protocols ....................................28
   4.4  NSIS Signaling Data .........................................30
   4.5  Routing Aspects .............................................32
   4.5.1 Implicit Routing of Signaling Packets ......................32
   4.5.2 Impact of Multi-Field Routing ..............................34
   5  Application to Generic Signaling Scenarios ....................35

   Hancock et al.    Informational - Expires August 2002             2                 Towards a Framework for QoS Signaling    February 2002

   5.1  Network / Proxy / Edge / End Signaling Scenarios ............35
   5.2  End-to-Network Signaling and Interworking with Higher-Layer QoS
   5.3  Transparent path traversal ..................................36
   5.4  Use of NSIS Signaling in QoS Provisioning ...................36
   5.5  Aggregation and Hierarchical Reservations ...................38
   5.5.1 NSIS Aggregation Techniques ................................38
   5.5.2 Aggregation Context ........................................40
   5.6  Operation over Addressing and Other Boundaries ..............40
   5.7  Support for Adaptive Applications ...........................42
   6  Applicability of Other QoS Frameworks and Protocols ...........43
   6.1  Incremental Deployment in an NSIS-Unaware Internet ..........43
   6.1.1 Step 1: NSIS compliant Islands .............................44
   6.1.2 Step 2: Heterogeneous Infrastructure .......................44
   6.1.3 Step 3: Widespread deployment of NSIS ......................45
   6.2  Basic Diffserv ..............................................45
   6.3  Basic Intserv ...............................................45
   6.4  RMD .........................................................45
   6.5  MPLS ........................................................47
   6.6  Bandwidth Broker ............................................47
   7  Possible NSIS Signaling Protocols .............................48
   7.1  RSVP and its Extensions .....................................48
   7.2  RSVP ultra-lite .............................................50
   7.3  In-band QoS Signaling .......................................51
   8  Possible NSIS QoS Class Descriptors ...........................52
   9  Security Considerations .......................................53
   9.1  End-Node to Network Signaling ...............................53
   9.2  Network to Network ..........................................57
   9.3  End-to-End ..................................................59
   10 Resilience and Scalability Considerations .....................60
   10.1 Resilience ..................................................60
   10.2 Scalability .................................................61
   11 Conclusion ....................................................63
   12 References ....................................................66
   13 Acknowledgments ...............................................67
   14 Author's Addresses ............................................67
   Appendix A. Mapping to Requirements ..............................69

 1  Introduction

   This Internet Draft presents a framework for further development of
   QoS signaling in the Internet. We give a basic model for the
   entities involved in QoS signaling, which is intended to be
   applicable to a very wide range of networking environments, while
   still retaining the flexibility to allow lightweight implementations

   Hancock et al.    Informational - Expires August 2002             3                 Towards a Framework for QoS Signaling    February 2002

   in particular environments and incremental deployment in the
   Internet as a whole.

   As well as the details of the framework itself, we also relate it to
   the NSIS requirements work [1], by comparing the framework to the
   requirements themselves. We present an initial assessment of the
   applicability of existing QoS mechanisms to be used within the
   framework. Security, scalability, and resilience are considered as
   special issues.

 1.1  Fundamental Approach

   Our basic approach is to define a set of entities which represent
   the QOS signaling and associated functions within and 'around' a
   single node. With a minor generalization, they can also represent a
   group of nodes which act as a unit for NSIS QoS signaling purposes
   (the 'virtual router'.)

   This approach is similar to that taken in the Policy area, where the
   abstract definition of Policy Enforcement and Policy Decision
   concepts allows their use in a wide variety of network scenarios.
   The same motivation applies in this case: the full variety of ways
   in which QoS signaling might get implemented in real networks is
   still unclear, and the more abstract the component definitions, the
   more deployment possibilities are enabled. In particular, we have
   avoided building the framework on concrete assumptions about
   possible network topologies and hierarchies, instead building these
   up from the basic components as a validation exercise.

   A second analogy can be drawn with the way routing is now handled in
   the Internet. The full routing problem is probably comparable in
   complexity to the full QoS signaling problem, and a modular routing
   framework has evolved which allows this problem to be solved
   piecemeal. For example, the host and network parts are quite
   decoupled, and the inter- and intra-domain areas are handled
   separately. Also, multicast is nowadays considered as a function to
   be built alongside or on top of unicast routing rather than as an
   integrated part of it. We believe that the same level of
   decomposition is both necessary and appropriate in considering QoS
   signaling solutions, which need to be both widely applicable without
   imposing the burden of a single full solution on all participating

   It is our intention that the framework is used to derive more
   concrete requirements for QoS signaling protocols and data, and
   possibly QoS extensions to existing protocols. This could be done by
   a more formal analysis of NSIS requirements in the context of the
   framework, and development of additional implementation requirements
   on the protocols themselves. The framework can also serve as a
   context for evaluating existing QoS and other mechanisms, either to
   be parts of the NSIS solution, or for interactions with it in areas
   such as accounting or application layer interactions.

   Hancock et al.    Informational - Expires August 2002             4                 Towards a Framework for QoS Signaling    February 2002

   Security is considered an integral problem within the framework
   itself. The reason for this is that when any differential QoS
   mechanism is available in a network, it may immediately become a
   target for abuses such as theft and denial of service; the
   assumption is commonly made that this is controlled by requiring
   some kind of authentication and accounting relationship between
   entities in the network. However, this only works if the
   corresponding security relationships are consistent with the way
   that the threats of QoS abuse propagate from peer to peer within the
   network. In other words, the QoS framework must be underpinned with
   a compatible security framework.

 1.2  Scope and Design Principles

   The fundamental goals of the framework presented here are three-
   *) Applicability
   *) Adaptability
   *) Re-use

   'Applicability' means that minimal assumptions are made about the
   environment within which the framework can be used. It is supposed
   to be applicable in both access and core contexts, for fixed and
   wireless and mobile networks; also, it can operate over various
   boundary types, as administrative domain boundaries and also address
   space boundaries (including IPv4-IPv6 boundaries), and does not
   assume any single style of QoS provisioning paradigm. (A consequence
   of this wide applicability is that the core framework itself must be
   rather minimal, which is also a desirable characteristic.)

   Because we believe that network structures will continue to evolve
   into progressively more complex and nested relationships, we have
   avoided assuming any particular type of network hierarchy or
   classification of node types. The fundamental framework contains a
   single type of node that processes QoS signaling, which can be
   decorated with particular selections of signaling protocols and
   upper/lower layer interactions without modifying the overall

   'Adaptability' means that the way the framework is instantiated in
   any particular node or network type must be adaptable to the special
   needs of that environment. For example, it must be possible to make
   it lightweight for hosts at the edge of the network while making it
   scalable in the core; security requirements are also likely to be
   network scenario dependent. In particular, the framework must be
   able to adapt to the fact that large parts of the Internet will at
   least initially be NSIS-unaware, so incremental, minimal-pain
   deployment must provide benefits even in this case.

   The main method for achieving this is to make the framework modular,
   so different parts can be adapted relatively independently: in

   Hancock et al.    Informational - Expires August 2002             5                 Towards a Framework for QoS Signaling    February 2002

   particular, the protocols used to carry QoS reservation information
   are considered independent of the that information itself, and QoS
   provisioning is treated strictly as a local matter, independent of
   these (allowing any QoS provisioning paradigm).

   'Re-use' means that the framework must be able to incorporate
   existing QoS solutions in a natural way, otherwise networks could be
   forced to deploy multiple QoS technologies in parallel. In this
   draft, we have considered the applicability of both existing
   architectural approaches to QoS such as DiffServ, RMD, and Bandwidth
   Brokering (section 6) and made an initial assessment of possible
   signaling protocols such as RSVP (section 7).

   A second aspect of re-use is that we have attempted to minimize the
   problem space of NSIS by having the framework hook into other
   functions - such as user administration, accounting and especially
   upper layer applications - in a well defined way, with a clear
   function split between these functions and NSIS. A secondary benefit
   of this is that these functions can be implemented with consistent
   interactions with QoS elements of the network layer, without having
   to be adapted to multiple QoS technology choices.

 1.3  Document Structure

   The document is structured as follows:
   - Section 2 introduces the additional terminology used within the
   - Section 3 describes the framework, providing an overview of the
   entities and signaling concepts.  The different signaling options
   that should be considered for support by the framework are discussed
   and a brief overview of accounting and security considerations is
   - Section 4 explores in more detail the framework components, and
   discusses interactions with higher layer functions.  The interaction
   with local QoS provisioning mechanisms and routing are also
   - Section 5 discusses various generic scenarios to illustrate the
   use of the functions and definitions described in the previous
   - Section 6 describes other QoS frameworks and protocols and
   analyses how aspects of these solutions could be re-used within the
   scope of the NSIS framework.
   - Section 7 considers existing and potential future QoS signaling
   proposals and evaluates their suitability as an NSIS signaling
   - Section 8 provides on overview of existing QoS parameter
   descriptors, and analyses their applicability to the framework
   - Section 9 details the security aspects related to the framework.
   - Section 10 analyses the framework with regard to resilience and
   scalability concerns.
   - Section 11 describes the conclusions that can be drawn from the
   framework and highlights open issues that need to be addressed.

   Hancock et al.    Informational - Expires August 2002             6                 Towards a Framework for QoS Signaling    February 2002

   - Appendix A analyses the framework against the relevant
   requirements provided in [1].

 2  Terminology

   Where possible, this draft uses the terminology defined in [1].
   Exceptions and additions are stated here.

   Administrative Domain: a region of the network whose boundaries are
   defined by the point where common administrative control ends. Also
   called a QoS Domain or simply Domain in [1].

   Edge router: router at the boundary of a domain or QoS subdomain
   boundary; may be responsible for aggregation, shaping/policing, or
   similar QoS functions.

   NSIS Agent: any entity that takes part in NSIS QoS signaling. QoS
   Controllers and QoS Initiators (as defined in [1]) are particular
   types of NSIS Agents.

   Proxy NSIS Agent: an NSIS agent that acts on behalf of an end host
   (which might or might not be NSIS aware).

   QoS Provisioning Signaling: the signaling messages that are used to
   communicate provisioning commands from a QoS controller to its
   routers; part of the overall QoS provisioning mechanism. QoS
   provisioning signaling only exists where the QoS controller is
   physically separate from the routers it controls.

   Virtual Router: all routers provisioned under the control of a
   single QoS controller, and seen as a unit by the NSIS signaling.

 3  Framework Overview

 3.1  Fundamental Building Blocks

   This section introduces the building blocks used within the
   framework and the motivation for their definition.

   The QoS Initiator and QoS Controller concepts introduced in [1] can
   be placed at many different locations within a network, and made to
   interact with many other entities.  However, their QoS signaling
   attributes are not altered by differences in location, so it is
   possible to simplify the QoS initiator and QoS controller concepts
   to a single case and define how it supports QoS signaling.

   This single entity can then be taken and used to build more
   complicated scenarios by:
   -     linking entities together in various different ways, such as
     allowing two entities in neighboring domains to exchange
     information or allowing an entity to initiate QoS signaling for an

   Hancock et al.    Informational - Expires August 2002             7                 Towards a Framework for QoS Signaling    February 2002

   -     giving the entities additional non-NSIS functions such as the
     ability to interact with applications, the ability to know about
     routing in the local network, or the ability to know about domain
     wide resource utilization etc.

   Figure 1 illustrates the framework entity identified above.

                           ^       ^        ^
                           .       .        .
                      Accounting   .   User Admin
                     Interaction   .  Interaction
                           .       .        .
                           .  Application   .
                           .  Interaction   .
                           .       .        .
                           V       V        V
                          |    NSIS Agent    |
                          |                  |
                          | +-------------+  |
                          | |             +=======================+\
                          | |             | Outgoing QoS requests   \
                          | |             | "I want QoS X2 for       >
                          | |     QoS     | packets described by Y" /
   +======================+ |     Flow    +=======================+/
   |Incoming QoS requests  \| Interworking|  |
   |"He wants QoS X for     >             | /+.....................+\
   |packets described by Y"/|             |/    Interaction with     \
   +======================+ |             <     routing, traffic      >
                          | |             |\    engineering etc.     /
                          | |             | \+.....................+/
                          | |             |  |
                          | |             |  |
                          | |             +=======================+\
                          | |             | Outgoing QoS requests   \
                          | |             |"I want modified QoS Z for>
                          | |             | packets described by Y" /
                          | |             +=======================+/
                          | +-------------+  |
                          |                  |
                                .     .
                                . QoS .
                               (local or
                                .     .
                                +     +
                                 \   /
                                  \ /
                        Figure 1: Basic NSIS Agent

   Hancock et al.    Informational - Expires August 2002             8                 Towards a Framework for QoS Signaling    February 2002

   This framework entity is referred to as an NSIS agent.  NSIS agents
   communicate with each other using peer-to-peer QoS protocols, which
   carry the QoS information between NSIS Agents to provision resources
   for a traffic flow.

   Therefore, the NSIS Agent peer-to-peer protocol can be sub-divided
   into two parts:
   -     the NSIS signaling protocol that carries data including the QoS
     parameters, and which has to carry out operations such as peer
     discovery, and that should support features such as reservation
   -     the NSIS signaling data that represents the flow and associated
     QoS requirements.
   These aspects are discussed further in sections 4.3 and 4.4.

   Different configurations of NSIS Agent can be identified based on
   their interactions with surrounding functions and optional
   capabilities in processing of QoS signaling messages.  These are as
   -     If the NSIS Agent does not receive input signals from peer agents
     concerning QoS requirements, it probably receives QoS request
     information from the higher layers (applications).
   -     NSIS Agents can support N inputs and M outputs corresponding to a
     given flow, but 1:1 and n:1/1:n (to reflect the aggregation/
     deaggregation case) are the only common ones.
   -     QoS provisioning can be treated as a black box (invoked in an
     implementation dependent way for example via a technology-specific
     convergence layer) if the QoS provisioning signaling used when
     carrying it out cannot be fitted into the framework. In this
     sense, there may be QoS signaling protocols that do not come under
     the NSIS 'umbrella'; our general intention is to fit existing
     protocols into the framework if this can be done simply, but there
     is no aim to generalize the framework to cover all possible QoS-
     related protocols.
   -     Conversely, if the NSIS signaling is being propagated along the
     traffic path within the network, it might be used directly to
     control the local QoS provisioning, and no additional provisioning
     actions are needed from the QoS controller.
   -     Some NSIS agents might simply do protocol or address boundary
     interworking, or gather and forward accounting/authorization
     information. In this case, they wouldn't perform any QoS
     provisioning or modify the flow signaling at all.
   -     Specialised NSIS Agents may interact with routing protocols or
     traffic engineering protocols etc. to support features such as
     sophisticated path capability discovery. See Section 4.5
   -     NSIS Agents can assume the role of proxy, and in this capacity can
     initiate and terminate signaling on behalf of a QoS initiator.
     Further details of this are provided in Section 3.7.1.

   Hancock et al.    Informational - Expires August 2002             9                 Towards a Framework for QoS Signaling    February 2002

 3.2  Fundamental Network Structures

   In this section, we introduce some representative network structures
   which can be used to describe the range of actual allowable
   deployments of the fundamental NSIS agent building blocks of section
   3.1. At the highest level, we can picture the networks across which
   QoS is signaled with the following structure. The complete end to
   end path covers a number administrative domains, each carrying a
   single path segment. (Within each domain there may be further
   subdomains corresponding to QoS technology boundaries.)

   [+]------------------------- Path -------------------------------[+]

             [+]------- Path Segment ---------[+]

   +------+  +-------+////        \\\\+--------+
   | End  +--| Edge  | Administrative |  Edge  |
   | Host |  | Router|    Domain      | Router |
   +------+  +-------+\\\\        ////+--------+
                          --------        .
                             .         --------
                         +--------+////        \\\\+--------+  +------+
                         | Edge   | Administrative | Edge   +--+ End  |
                         | Router |    Domain      | Router |  | Host |
                         +--------+ \\                                   \  \        ////+--------+  +------+

                         [+]------- Path Segment ---------[+]

                   Figure 2: Top Level Network Structure

   We believe that it is crucial to consider the complete end to end
   path and then work down in detail to individual hops: this is partly
   because QoS is meaningful primarily as an end to end concept, and
   also because several critical technicalities (such as asymmetric
   routing) are emphasized by this 'macro' view.

   At this level, we see the network foremost at the level of
   administrative domains and QoS subdomains rather than individual
   routers (except in the special case that the domain contains one
   link). Because administrative domains are defined as administrative
   entities, we can expect that special 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. Another example might be that a subdomain uses some
   special routing mechanisms, e.g. to support mobile hosts, and that

   Hancock et al.    Informational - Expires August 2002            10                 Towards a Framework for QoS Signaling    February 2002

   this may indirectly force the use of special QoS provisioning
   methods. End hosts may be connected through one or more domains;
   this is indicated by the dotted line in Figure 2.

   Note that although the simple idea of a sequence of domains with one
   level of subdomain covers many basic scenarios, it is certainly not
   rich enough to encompass the possible configurations that could
   arise in the real-world. For example:
   *) Administrations could be nested (reflecting internal
   organizational boundaries, where some subset of typical accounting
   or security requirements might be applicable).
   *) An end-user (as seen by the network) might support multiple end-
   hosts (as seen by the user). Examples might be a dial-up user
   supporting a home network, or a mobile cellular user supporting a
   PAN; in each case, the full weight of a single 'network-network'
   interface would be inappropriate.
   *) There may be address space or technology boundaries within or
   between networks, whose problems need to be addressed specially.

   For these reasons, we have not tried to identify a specific
   hierarchy of protocols; the framework is supposed to be more
   generally applicable. Once consistency of the framework at the
   overall level is understood, detailed requirements for protocols can
   be considered in terms of particular scenarios.

   Aggregation typically takes place at both domain and subdomain
   boundaries, where edge routers are located. Edge routers may have
   more responsibility than other routers, for example to carry out
   this aggregation, or perform admission control. Where these
   functions involve interactions with QoS signaling, there will be an
   NSIS agent performing this signaling role.

   The next figure shows the general structure of a domain or
   subdomain, which is simply a network of connected routers.

   Hancock et al.    Informational - Expires August 2002            11                 Towards a Framework for QoS Signaling    February 2002

      |                QoS (sub)domain using any                   |
      |                     QoS technology                         |
      |                                            +------+        |
      |                  +------+                  |Router|        |
      |                  |Router|    +------+      |      |        |
   +------+              |      |    |Router|------|      |----+------+
   | Edge |--------------|      |----|      |      +------+    | Edge |
   |router|              +------+    |      |        /         |router|
   |      |\               /   \     +------+       /         /|      |
   +------+ \             /     \          \       /         / +------+
      |      \           /       \          \     /        /       |
      |       \         /      +------+      \   /       /         |
      |        \   +------+    |Router|    +------+     /          |
      |         \  |Router|    |      |    |Router|   /            |
      |          \ |      +----|      |----+      | /              |
      |           \|      |    +------+    |      |/               |
      |            +------+                +------+                |

               Figure 3: General Domain/Subdomain Structure

   One particular scenario is that the resources of these routers may
   be governed by the decisions of a bandwidth broker, as shown in
   Figure 4.

      |                   Domain/Subdomain                        |
      |                                                           |
      |                     +-----------+                         |
      |.....................| Bandwidth |.........................|
      |.            ........|  Broker   |............            .|
      |.            .       +-----------+           .            .|
      |.            .        .    .   .           +------+       .|
      |.            .   +------+  .   .           |Router|       .|
      |.            .   |Router|  . +------+      |      |       .|
   +------+         .   |      |  . |Router|------|      |----+------+
   | Edge |-------------|      |----|      |      +------+    | Edge |
   |router|         .   +------+  . |      |        /         |router|
   |      |         .     /   \   . +------+       /         /|      |
   +------+\        .    /     \  .       \       /         / +------+
      |     \       .   /       \ .        \     /        /       |
      |      \      .  /      +------+      \   /       /         |
      |       \   +------+    |Router|    +------+     /          |
      |        \  |Router|    |      |    |Router|   /            |
      |         \ |      +----|      |----+      | /              |
      |          \|      |    +------+    |      |/               |
      |           +------+                +------+                |

            Figure 4: Bandwidth Broker in a Domain or Subdomain

   Hancock et al.    Informational - Expires August 2002            12                 Towards a Framework for QoS Signaling    February 2002

   Bandwidth broker or similar solutions can be expected to be common
   mechanisms where large or complex domains need to be QoS aware, and
   it is therefore important to consider how to fit them into the
   overall NSIS framework. At a minimum, we need to be able to
   propagate NSIS signaling between end hosts transparently through
   such a domain; ideally, there should be some interaction with the
   bandwidth broker itself to ensure that the provisioning it carries
   out reflects the QoS requirements of the underlying flows. The NSIS
   framework needs to define what mediates this interaction and where.

   Note that we don't consider the BB-router signaling as a fundamental
   part of NSIS, since it is essentially a local mechanism. However,
   there is an option to exploit work done in defining NSIS for use to
   carry out this type of remote provisioning. This possibility is
   discussed in section 5.4.

   A particularly crucial point to note about the macro-scale network
   structure is that end to end packet flows are likely to be
   asymmetric, and this applies to both signaling and data packets. A
   characteristic situation is shown in Figure 5. This simple fact has
   significant impact on the signaling possibilities even within a
   single edge domain, since only in special cases can the entry point
   for incoming traffic be predicted or controlled, in which case QoS
   signaling for this traffic has to be carefully routed. More
   implications of this situation are considered in section 3.4.

   >> = traffic flow H1->H2
   << = traffic flow H2->H1        +-------+
   H = Host                        |  QoS  |
   R = Router      +-----+         | domain|
                   |     |        +-+      |
                   |    +-+>>>>>>>|R|>     |
                   |   >|R|       +-+ >    |
                   |  > +-+        |   >  +-+
                   | >   |         |    >>|R|
                   |>    |         |      +-+
                   >     |         +------ >
   +--+    +-+    +-+    |                 >
   |H1|><><|R|<><>|R|    |                 >
   +--+    +-+    +-+<    \               +-+
                   |  <   |            +--|R|>----+
                   |   <  |            |  +-+ >   |
                   |    <+-+           |       > +-+
                   |     |R|<<<<<<<<   |        >|R|>>>>>+--+
                   |     +-+        < +-+        +-+     |H2|
                   | QoS  |          <|R|<<<<<<<<<<<<<<<<+--+
                   |domain|           +-+         |
                   +------+            |QoS domain|

             Figure 5: Asymmetric Routing at the Domain Level

   Hancock et al.    Informational - Expires August 2002            13                 Towards a Framework for QoS Signaling    February 2002

 3.3  Abstract Entities in QoS Signaling paths

   The NSIS requirements are phrased in terms of two abstract entities,
   the QoS Initiator, and the QoS Controller.

   The QoS initiator starts the request for QoS for a user flow.  It
   might be located in the end system or within some part of the
   network, such as the edge router for an access network, or even an
   application layer proxy. The distinguishing feature of the QoS
   initiator is that it acts on triggers coming (directly or
   indirectly) from the higher layers in the end systems, mapping the
   QoS requested by them. It also provides feedback information to the
   higher layers which might be used by transport layer rate management
   or adaptive applications.

   In our model, the QoS initiator is a particular instance of the
   generic NSIS agent shown in Figure 1, which will have
   *) Triggers from and feedback to upper layer applications
   *) Typically, no incoming QoS requests
   *) Typically, one outgoing QoS request per application data flow
   *) Local QoS provisioning functions for the first hop (for both the
   IP and link layers)

   Likewise, the QoS controller manages and enforces QoS further along
   the path. It might be located in some or all routers, or in a
   separate network element, e.g. in a bandwidth broker (note therefore
   that QoS controllers are not constrained to lie on the traffic
   path). If QoS is to be provisioned on a path segment, there must be
   at least one QoS controller to do this (but this would not be needed
   for example in overprovisioned QoS subdomains). The QoS controller
   does not interact with higher layers, but interacts with the QoS
   initiator and possibly more QoS controllers further along the path.

   In our model, the QoS controller is another particular instance of
   the generic NSIS agent, which will have:
   *) Incoming and outgoing QoS requests. Incoming QoS requests are
   interworked to outgoing requests. The interworking might consist of
   managing additional flows (e.g. aggregation or disaggregation), or
   interpreting the QoS requested by the user in terms of the QoS
   allowed by some SLA (e.g. on inter-domain links).
   *) If the local QoS cannot be provisioned by sending the appropriate
   outgoing QoS request, subdomain-specific QoS provisioning signaling
   can be invoked. In this case, the provisioning mechanism is opaque
   to NSIS and can be locally implementation specific.
   *) Accounting and authentication information may be exchanged with
   local AAA nodes. The precise protocol used to do this is again
   outside the scope of NSIS signaling.

   The QoS initiator and controller(s) interact with each other. This
   interaction involves the exchange of data (QoS control information)
   over some signaling protocol. In terms of our framework, this is
   simply considered as a peer-peer protocol exchange between NSIS

   Hancock et al.    Informational - Expires August 2002            14                 Towards a Framework for QoS Signaling    February 2002

   agents (i.e. there is no client-server concept, or differences
   between initiator-controller and controller-controller protocols
   built into the framework, although the protocol selected may still
   depend on the local environment).

   A simple layer model covering a single path segment with a single
   QoS controller is shown in Figure 6. The scope of NSIS within the
   context of this diagram is therefore the protocol between the NSIS
   agents (initiator and controller), including selection of signaling
   protocols to carry the QoS information, and the syntax/semantics of
   the information  that is exchanged. The provisioning is being
   carried out using non-NSIS mechanisms.

   ..............   ................
   .  request/  .   .  response/   .
   .trigger from.   . feedback to  .
   .higher layer.   .higher layers .
   ..............   ................
            |         ^
            |         |
            |         |        ...............
            |         |        . QoS Control .
            V         |        . Information .
       +----------------+      ...............     +----------------+
   --->|                |------------------------->|                |->
       |                |      QoS signaling       |                |
       | QoS Initiator  |     (request/query,      | QoS Controller |
       |                |   response/error etc.)   |                |
   <---|                |<-------------------------|                |<-
       +----------------+                          +----------------+
        ^              |                            ^              |
        | ............ |                            | ............ |
        |     QoS      |                            |     QoS      |
        | provisioning |                            | provisioning |
        |  commands &  |                            |  commands &  |
        |  responses   |                            |  responses   |
        | ............ |                            | ............ |
        |              |                            |              |
        |              V                            |              V
      |        Administrative domain or QoS domain using any         |
      |                        Qos technology                        |
      |                                                              |
      |     +------+       +------+                     +------+     |
      |     | Edge |       |Router|                     | Edge |     |
   =========|Router|=======|      |=====================|Router|=======
      |     |      |       |      |       flow path     |      |     |
      |     +------+       +------+                     +------+     |

                   Figure 6: Generic scope of signaling

   Hancock et al.    Informational - Expires August 2002            15                 Towards a Framework for QoS Signaling    February 2002

   A second diagram, Figure 7, concentrates more on the overall end to
   end (multiple QoS domains) aspects, in particular:

   1. The QoS initiator need not be located at the end system (for
   example, it might be an application signaling server), and the QoS
   controllers are not assumed to be located on the flow path. However,
   they must be able to identify the next hop QoS controller, to do
   which might require knowledge about the path's egress point; more
   detailed path information might be required to carry out the QoS
   provisioning correctly.

   2. Only a unicast flow is shown, with the QoS initiator at or near
   one end. However, we do not exclude bi-directional flows with the
   QoS requested by either end. Multicast or anycast flows or flows
   with variable paths within a subdomain (e.g. to a mobile end system)
   are also logically possible.

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

   Although the figures show QoS controllers 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 to become more 'dense'
   towards the edges of the network, but this is not a requirement. An
   overprovisioned domain might contain no QoS controllers at all (and
   be NSIS transparent); at the other extreme, QoS controllers might be
   placed at every router. In the latter case, QoS provisioning can be
   carried out in a local implementation-dependent way without further

   Hancock et al.    Informational - Expires August 2002            16                 Towards a Framework for QoS Signaling    February 2002

                            |   Administrative Domain  |
   +----+    flow path     +-+                        +-+
   +----+            /     +-+                        +-+          ||
         \          /       | \                      / |           ||
          \ +----+ /        |  \+----+        +----+/  |           ||
           \|QoS |/         |   |QoS |        |QoS |   |           ||
            |init|          |   |cont|        |cont|   |           ||
            +----+          |   +----+        +----+   |           ||
                            |      ^            ^      |           ||
                            |      |            |      |           ||
                            |      V            V      |           ||
   +-+                      |   +------------------+   |           ||
   |R| = Edge router        |   |QoS administration|   |           ||
   +-+                      |   |    functions     |   |           ||
                            |   +------------------+   |           ||
                            +--------------------------+           ||
                   +-----------------------------------------+     ||
                   |           +--------------------+        |     ||
                   |     +-----|   QoS controller   |--+     |     ||
                   |    /      +--------------------+   \    |     ||
                   |   /                                 \   |     ||
                   |  /     +--------------------------+  \  |     ||
                   | /      |      QoS Subdomain       |   \ |     ||
    +----+        +-+      +-+                        +-+   +-+    ||
    +----+        +-+      +-+     aggregate path     +-+   +-+
                   |        | \                      / |     |
                   |        |  \+----+        +----+/  |     |
                   |        |   |QoS |        |QoS |   |     |
                   |        |   |cont|        |cont|   |     |
                   |Admin.  |   +----+        +----+   |     |
                   |Domain  +--------------------------+     |

               Figure 7: Signaling in Multiple (QoS) Domains

 3.4  Basic Signaling Paths

   It has been a long term question in NSIS whether and how to support
   different reservation models, sender initiated, receiver initiated,
   or bi-directional. (Here, 'sender/receiver' refers to the direction
   of user traffic flow, while 'initiated' refers to the role of the
   QoS initiator. A bi-directional reservation is logically a
   combination of a sender and receiver initiated reservation carried
   out by a single QoS initiator.)

   There are several models for how this might take place at the macro-
   level (i.e. at the level of whole domains). Which model is used must

   Hancock et al.    Informational - Expires August 2002            17                 Towards a Framework for QoS Signaling    February 2002

   be fixed at this level level, since this cannot be decided locally
   without harming interoperability, especially taking into account
   that asymmetric routing is possible even at the domain level as
   discussed earlier.

 3.4.1  Sender Initiated

   Considering a sender initiated reservation for a single
   unidirectional flow, the eventual setup must converge to the
   situation shown in Figure 8. In the figure, each 'QC' represents a
   single 'virtual router' which could be a complete domain.

                    +---+     +---+             +---+
                    |QC1|-----|QC2|             |QC4|
                   /+---+     +---+\           /+---+\
                  /                 \         /       \
                 /                   \       /         \
            +--+/                     \+---+/           \+---+
            |QI|                       |QC3|             |QC5|
            +--+                       +---+    \        +---+
                     +--------------------------+ \
                     |       Traffic Flow          >
                     +--------------------------+ /

               Figure 8: Basic Sender Initiated Reservation

   Here, it is natural to assume that the actual reservation message is
   generated at the QoS initiator QI, and then propagated sequentially
   through the QoS controllers QC1...QC5 to the endpoint. Since this
   runs in the same direction as the traffic flow, the underlying IP
   routing of the signaling packet towards the flow destination can
   usually be exploited to find the next hop QoS controller, although
   other mechanisms might also be allowed for particular inter-domain
   NSIS protocols. The use of the underlying routing protocol to reach
   the next QoS controller (shorthand: the 'routing method') is
   discussed in more detail in section 4.5.

   We therefore make the assumption that basic signaling message flows
   follow this pattern in the sender initiated case. Note that no
   special forwarding state is needed in the QoS controllers to route
   the signaling messages.

 3.4.2  Receiver Initiated Reservations

   In this case, the basic picture is very similar, except that the
   traffic flow is in the opposite direction. Because of asymmetric
   routing, QC2/3/4 have been replaced by QCa/b/c for the reverse
   direction. However, we cannot assume that propagation of the
   signaling messages from the QoS initiator is possible in the same

   Hancock et al.    Informational - Expires August 2002            18                 Towards a Framework for QoS Signaling    February 2002

   way as in the sender initiated case, because the underlying IP
   routing cannot be used to route the signaling packets backwards.

   Even if some QoS controllers can be configured to know their
   upstream neighbor for a particular flow, if even a single one (e.g.
   at an inter-domain boundary) needs the routing method to discover
   its neighbor, the whole signaling procedure will fail.

                    +---+             +---+
                    |QC1|             |QCb|
                   /+---+\           /+---+\
                  /       \         /       \
                 /         \       /         \
            +--+/            +                            \ ---+/           \+---+     +---+
            |QI|             |QCa|             |QCc|-----|QC5|
            +--+        /    +---+             +---+     +---+
                      / +--------------------------+
                     <          Traffic Flow       |
                      \ +--------------------------+

              Figure 9: Basic Receiver Initiated Reservation

   There appear to be two basic solutions to this problem:

   *) "RSVP style": Here, a message must be sent from the far end
   (QC5), which can use the routing method to work along QCc/b/a/1 back
   to QI. At each stage, per-flow forwarding state must be installed in
   the QoS controllers and QI so that each knows its upstream neighbor.
   (This message can also be used to probe for resources.) Then, the
   actual reservation can be initiated from QI in the same way as the
   sender initiated case. (We can regard the first message, analogous
   to an RSVP PATH, as part of a registration phase, see section 4.3.)
   Note that there must be some message to stimulate QC5, which might
   be application layer or part of the QoS signaling.

   *) "Reflection style": Here, the reservation message is generated by
   QI and sent directly to Q5 using normal routing. Q5 then sends the
   reservation request on behalf of QI, and the routing method can be
   used to discover the 'previous' hop QoS controllers along the path.
   This does not require reverse path forwarding state to be installed
   along the path and can save one end to end transmission time, but
   requires more careful consideration of security and accounting
   issues, since the reservation is now being set up in the reverse
   direction. Also, resource probing and exception handling may be more
   complex in such a approach.

   The tradeoffs between these two techniques essentially relate to

   Hancock et al.    Informational - Expires August 2002            19                 Towards a Framework for QoS Signaling    February 2002

   1. The amount of state stored at intermediate QoS controllers, and
   the necessity to maintain this state in the event of routing
   2. The number of end to end transmissions required.
   3. The complexity of handling admission control and accounting
   policy information securely when the reservation starts from the
   'wrong' end.
   4. Resource query requirements.
   5. The necessity to retain backwards compatibility with end to end
   RSVP signaling (harder with reflection).

   Selection between these options requires further analysis of the
   scenarios and requirements. Fortunately, it seems that the
   implications of this decision for the other parts of the framework
   are limited (there is a potential impact on QoS violation reporting,
   section 5.7).

 3.4.3  Bi-Directional Reservations

   In this case, QI wants to initiate the reservation for both
   directions of the flow.

   It is important first to consider exactly what benefit a special bi-
   directional reservation might provide over independent sender and
   receiver reservations made by QI in parallel. If the routing is
   totally asymmetric, the resulting configurations will be identical;
   therefore, bi-directional reservations are at most an optimization
   to exploit regions of symmetric routing, typically towards the edges
   of the network, e.g. starting at QI. In this symmetric region, it
   may be possible to provision the QoS for the two flows more
   efficiently when they are considered together (see also section
   4.2). We assume that once the bi-directional reservation splits it
   will be very hard to correlate the two parts at the other end, and
   to enable the two reservations to be treated together near QI
   without requiring complex correlation in the network, they should be
   signaled in a single message.

   Hancock et al.    Informational - Expires August 2002            20                 Towards a Framework for QoS Signaling    February 2002

                    +---+    +---+    +---+    +---+
                    |QC1|----|QC2|    |QCb|    |QC4|
                   /+---+\   +---+\  /+---+\  /+---+\
                  /       \        \/       \/       \
                 /         \       /\       /\        \
            +--+/           \+---+/  \+---+/  \+---+   \+---+
            |QI|             |QCa|    |QC3|    |QCc|----|QC5|
            +--+             +---+    +---+    +---+    +---+

                      /                          \
                     /|                          |\
                    / +--------------------------+ \
                   <          Traffic Flow          >
                    \ +--------------------------+ /
                     \|                          |/
                      \                          /

                Figure 10: Basic Bi-directional Reservation

   In the case shown in Figure 10, a bi-directional reservation could
   be set up between QI and QC1, but would then have to be split out
   into independent sender and receiver reservations for the remainder
   of the path. There appear to be two possibilities for how this could
   be done.

   1. The "RSVP style" is used to discover the upstream chain of QCs
   from QI. When QI notices that the first and last hop QoS controller
   are the same, it can send the combined reservation message to QC1,
   which then splits them for the uplink and downlink directions. The
   message flow then looks like a direct combination of a sender
   initiated reservation and RSVP style receiver initiated reservation,
   optimized over the first hops until the paths split.

   2. QI knows somehow (out of band) that it has a symmetric route to
   the first QoS controller (for example, as a consequence of the
   access technology it is using), and sends the bi-directional
   reservation directly to QC1. QC1 can then initiate a standard sender
   initiated reservation for the uplink direction, and use either style
   for the downlink direction.

   In neither case does the rest of the network (between QC1 and QC5)
   know that a bi-directional reservation has taken place.

   The first technique is clearly more general, but enforces the use of
   the RSVP style for the receive path everywhere. The second technique
   introduces a distinct third reservation type and can only apply
   where the QI knows about the uplink neighbor in this way. However,
   it is potentially more suited to operation in an environment where
   QC1 acts as a proxy initiator for QI (see section 3.7.1), and makes
   the signaling task for QI very simple indeed. It may cover the bulk
   of scenarios where bi-directional reservations are actually

   Hancock et al.    Informational - Expires August 2002            21                 Towards a Framework for QoS Signaling    February 2002

   valuable. Such a scenario is considered in more detail in section

   Therefore, again, a choice between the two methods requires further
   analysis of the critical scenarios and the tradeoffs between the two

 3.5  Impact of Accounting Considerations

   The traditional way of collecting accounting information is the
   following: after the successful authentication and authorization of
   the user, appropriate filters and meters are installed at the edge
   devices to collect information about resource consumption. Those
   data are merged together and sent to the home domain of the user. In
   our case, also, the edge devices monitor also the QoS treatment and
   generate corresponding accounting data, and, moreover, each edge
   router of each administrative domain collects resource consumption
   information, including again the different QoS treatment.

   This distributed accounting data may be linked or merged into a
   single record, and periodically transmitted to the entity that takes
   care of the billing of the end entities. The charging entity could
   be for instance the home domain of the user. But also other business
   and payment models are possible, without changing the metering
   procedures sketched. Perhaps the domains pay to each other using
   their own measurements at their edge routers, based on service level
   agreements, and the user has to pay only what he is accounted for at
   his own access device. This also allows that QoS traffic of
   different users be aggregated. Obviously there is a need for
   different domains to be able to understand the collection of
   accounting data and the charging of them.

   Note that there is in general no need to collect and report the
   accounting data in real-time to the home network. Accounting data
   may be collected as a batch-job and transmitted via the existing
   infrastructure, for example COPS or DIAMETER. However within a
   single service provide it may still be necessary to collect all
   accounting data relatively quickly to determine whether a user has
   reached a particular limit or not.

   The above described mechanism should not only work with a
   subscription with a network provider or some form of network-based
   pre-payment, but also for a larger variety of forms of payment based
   on e.g. local cash payments, pre-paid cards, credit cards,
   electronic purses or micropayments. The form of payment may have
   some influence on the security architecture and on the accounting

   It is currently an open issue how the price for a QoS service
   reservation should be determined. Some work has be done in the
   academic community but it is still an issue whether the user should
   pay to the first service provider only (for the entire end-to-end

   Hancock et al.    Informational - Expires August 2002            22                 Towards a Framework for QoS Signaling    February 2002

   reservation) or whether it is necessary to somehow involve all other
   providers to determine the final price of the reservation.
   Those billing aspects (as opposed to accounting) are left out of the
   scope of this draft.

 3.6  Security Overview

   This section gives an overview of the security issues related to the
   described framework. The security architecture is divided into three
   categories: The first category raises security issues for the user
   to network communication. The second category discusses intra-domain
   and network-to-network issues. Finally the last category deals with
   end-to-end security issues.

   The main concern of security for the user-to-network communication
   deals with the separation of the initial authentication and key
   agreement step and the security protection of the QoS signaling
   messages originated from the user's host. Issues like the discovery
   of the entity to which the user has to authenticate, user identity
   confidentiality and different authentication and key agreement
   mechanisms are critical, and are discussed in detail in section 9.1.
   Signaling initiated by the user usually receives the highest
   attention since authorization and accounting procedures strongly
   depend on a successful authentication procedure.

   To secure the messages that travel within an administrative domain
   hop-by-hop security is applied. It is obvious that such a hop-by-hop
   security protection of signaling messages aims to be fast and is
   based on the assumption that the main threat originates from
   adversaries not residing on the path of the QoS signaling messages.
   However there is still a need to establish the security associations
   required to secure this communication. Because of the static network
   structure and the user-independence there is more flexibility for
   security association establishment. The communication between
   different networks is the next issue that needs investigation.
   Authentication, authorization and accounting that are also executed
   between different networks is assumed to be secure to guarantee that
   the traffic conforms to service level agreements.

   Finally there is the notion of end-to-end security. Two fields of
   further investigation have been identified which are usually not
   addressed within the context of QoS signaling protocols. A QoS
   signaling protocol may exploit existing security association
   (possibly established by preceding protocols and already available
   to the application) to protect parts of the QoS signaling message
   that are not modified in transit. Furthermore the QoS protocol may
   be used to carry key management protocol messages, which are likely
   to be opaque to the signaling protocol itself. If no end-to-end
   security association is available then message exchange of the
   signaling protocol may help reduce the latency for an application

   Hancock et al.    Informational - Expires August 2002            23                 Towards a Framework for QoS Signaling    February 2002

   The mutual implications QoS and security have for each other have
   received relatively little consideration at system level up to now,
   so there is a large set of potential open issues about the correct
   way(s) to secure QoS signaling. These open issues are gathered
   together in the conclusions section 11.

 3.7  Refinements and Extensions

   This section discusses various ways in which the framework can be
   extended, or deployed to achieve additional functions compared to
   the core set introduced so far.

 3.7.1  Proxy NSIS Agents

   A Proxy NSIS Agent acts as a NSIS agent in lieu of an end host. It
   has a mandate from the end host to handle all NSIS-related signaling
   and processing in its place. In particular, it initiates (as QoS
   initiator) and terminates (as QoS controller) NSIS signaling on
   behalf of the end host. It is the proxy's responsibility to relay
   all relevant NSIS signaling information to the end host, possibly in
   a condensed or otherwise optimised form. Normally, the signaling
   between the proxy and end host should be considered a form of NSIS
   signaling and within the scope of the framework; however, a proxy
   with special functionality might also be used to isolate NSIS-aware
   and NSIS-unaware networks. This use of the term 'proxy' is analogous
   to the use in RSVP [22].

   The proxy is located upstream from the end host. For all other NSIS
   agents further upstream, the proxying can be considered transparent,
   that is, they do not need to be aware that they are talking to the
   proxy rather than to the end host directly (unless they happen to
   know the true IP address of the end host). The proxy inserts its own
   identification into the NSIS signaling to take the place of that of
   the end host (see also section 4.4). Note that this requires the
   flexibility that the network allows the QoS signaling to be managed
   from a point which is not the end point of the traffic flow, which
   is a fundamental assumption in our framework.

   The reasons for employing a proxy can be manifold. The end host
   might not have the processing capability necessary for acting as a
   NSIS agent and therefore uses a proxy to carry out this function for
   him. From the network operator's perspective, using a proxy is
   desirable when the connection between end host and network is either
   of low bandwidth (expensive) or error prone, or shouldn't be
   burdened with signaling for some other reason. A good example of
   such a connection is the air interface in UTMS. In this case, the
   network operator might even prescribe the use of this type of NSIS
   proxy agent. A proxy may also be useful for hiding micro-mobility
   from the network, and thus simplifying QoS reservation re-setup
   after handoff, it might be deployed at an addressing boundary where
   deep translation of signaling message content was required.

   Hancock et al.    Informational - Expires August 2002            24                 Towards a Framework for QoS Signaling    February 2002

   For scenarios illustrating the use of signaling proxies see Section

 3.7.2  Multicast

   It is currently an open question within NSIS whether support for
   signaling QoS for multicast applications is actually required. There
   are several reasons why it might be preferable to consider a
   unicast-only NSIS framework as the initial step: firstly, that
   multicast support is a source of considerable complexity in any
   network layer signaling and that one of the goals of NSIS is to
   allow lightweight signaling solutions; and secondly, that we already
   have a solution for the protocol for multicast signaling, namely

   We must therefore ask how much commonality there is between
   signaling for unicast and multicast applications, and how much
   benefit there is to gain in having a single signaling solution.

   In terms of the framework presented so far, which has been developed
   mainly with the unicast case in mind, it is clear that several
   components could be re-used in a multicast scenario. For example,
   the NSIS signaling data (including QoS classes) should be mainly
   common, and likewise the basic concepts of NSIS agents inside QoS
   controllers and initiators (including issues like their peer-peer
   relationships, and authentication protocols and so on).

   On the other hand, some parts of the framework would be totally
   different. In particular, for multicast, it probably only makes
   sense to consider receiver initiated reservations, whereas for
   unicast a particularly simple sender-only case is possible (one
   solution, based on RSVP with the multicast capabilities removed, is
   outlined in section 7.2). Also, the accounting implications for
   multicast are not well understood which will have an impact on
   security analysis also. Finally, any QoS implementation that is
   routing aware (e.g. bandwidth brokers) would have to be multicast
   routing aware, not unicast routing aware.

   Because of these concerns, it makes sense to ask what benefit there
   is to integrate unicast and multicast QoS signaling, and at what
   level. The basic consideration is that both sets of signaling are
   for traffic that share the same physical resources. Therefore, it
   would be possible to have unicast and multicast QoS signaling that
   interacted only indirectly, via the QoS provisioning mechanisms,
   therefore having no effect on the NSIS parts of the framework. (This
   could be considered close to a 'ships in the night' approach,
   comparable to what is often done in multiprotocol routing).

   The main limitation of this approach is that there is no scope for
   joint negotiation of unicast and multicast flows. Without more
   detailed scenario analysis, it is hard to tell if this is a major
   concern or not. Therefore, at the current time, we have continued to

   Hancock et al.    Informational - Expires August 2002            25                 Towards a Framework for QoS Signaling    February 2002

   consider multicast as a second stage issue. If it becomes a concern
   for NSIS (for example, if RSVP is judged insufficient for this
   purpose), consideration should be given to what components of the
   unicast framework could be re-used to build a complete multicast QoS
   signaling solution.

 4  Fundamental Framework Components

 4.1  Interactions with Application Layers

   The application or higher layers can be seen as a service consumer
   for the services provided by the NSIS agent on behalf of the NSIS
   framework (the service provider). The task of the NSIS agent is to
   provide QoS to higher layers/application. The task of an application
   is to provide a QoS specification to describe the Quality of Service
   that the applications wants for its network traffic. Adaptive
   applications may want to adapt to changes in QoS delivery which may
   be the result of network failure or hand-over. Therefore, they need
   feedback information from the NSIS agent in form of monitoring or
   adapt requests.

   A typical interaction sequence is described below. The interaction
   with applications/higher layer is bi-directional as the consumer may
   (re-)negotiate for QoS and the NSIS agent may issue adapt requests.

   A consumer requests a certain QoS with a QoS specification that
   specifies the amount of network resources or the treatment of the
   application's data flow. Together with the desired QoS the consumer
   provides an identifier (e.g. one possibility would be port numbers,
   IP addresses, protocol IDs) for the data flow and a direction (e.g.
   send, receive, send/receive).

   The NSIS agent may in some cases invoke an admission control test to
   check if the QoS is available. In that phase, typically signaling is
   invoked. If the request is granted, the NSIS agent notifies the
   consumer about the success. If the request cannot be granted, the
   consumer is notified via an error message.

   Once the QoS is established, the consumer may re-negotiate
   dynamically with the NSIS agent for better or lower QoS at any time.
   This is necessary since the traffic characteristics may change over
   time (e.g. a scene break in the video may lead to a higher network
   resource consumption). The NSIS agent can again invoke an admission
   control test and notify the consumer about success or failure. If
   QoS delivery is not within the acceptable range, the consumer may
   request better QoS or adapt to the situation.

   Finally, the consumer releases the established QoS and the service
   provider releases the allocated resources, if any.

   At any time, network resource availability may change due to
   admission of new consumers, departure or re-negotiation of existing

   Hancock et al.    Informational - Expires August 2002            26                 Towards a Framework for QoS Signaling    February 2002

   consumers. This may lead to overload/underload situations detected
   by the NSIS agent (either directly, or notified to it by upstream
   peer agents - see section 5.7 for a discussion of the implications
   of this for the signaling protocols). In that case, the NSIS agent
   may force some or all consumers to adapt, i.e. downgrade the QoS
   requirements. The consumer can then restructure its internal
   operation and adapt to the new situation by sending an optional
   adapt response.

   There may be situations where an initial request could not be
   granted by the agent, e.g. if the requested QoS is not available.
   Then, the application/higher layer may at any time restart the
   process of requesting QoS (possibly at a lower level). This may lead
   to trial and error situations and can be avoided by introducing
   notifications. In that case the application would request to be
   notified by the NSIS agent, when the desired QoS is available. In
   addition, the application can first start to request QoS at a low
   level and ask the NSIS agent to provide notification when the full
   QoS is available.

   The discussion here has focused on the interaction between the NSIS
   agent and application layers in the case of the QoS initiator. The
   only other place in the network where the application layers are
   active is in the correspondent host at the other end of the traffic
   flow. Here, the interaction is much simpler: it appears that all
   that is needed is a notification capability that a QoS reservation
   has taken place, and this can be managed using the session
   identification information that must be carried in the signaling
   data anyway.

   It is also mentioned in the NSIS requirements that it may be helpful
   to be able to carry additional application layer messaging opaquely
   within the NSIS signaling messages. This has no other impact on the
   framework other than to require the existence of such a container,
   which is noted in section 4.4.

 4.2  Interactions with QoS Provisioning

   From the IP layer perspective, QoS provisioning techniques can
   implement virtual circuit style provisioning schemes like IntServ
   architecture or MPLS trunks etc. Alternative solutions are based on
   a hop by hop concept like the Diffserv architecture. Each
   provisioning scheme relies on router specific resource allocation
   mechanisms. Also, link layer specific characteristics may have major
   impacts on the performance of a QoS provisioning system. For
   example, in some link layers, there may be very efficient ways to
   allocate physical resources for a bidirectional flow, or more
   generally multiplex flows together. On the other hand wireless link
   layers may suffer from channel fading etc. These effects have to be
   taken into account for allowing efficient operation of the QoS
   provisioning system.

   Hancock et al.    Informational - Expires August 2002            27                 Towards a Framework for QoS Signaling    February 2002

   For flexible integration with various link layer technologies and
   router platforms it is suggested that NSIS agents interact with the
   QoS provisioning system on an abstract basis. Hence NSIS agents
   should not be involved in interpretation of signaling parameters to
   control a QoS provisioning system. Instead a generic interface is
   required to exchange parameters for various purposes between NSIS
   agents and the QoS provisioning system. As stated earlier in the
   document the QoS provisioning system may be co-located with NSIS
   agents or realized on one or more separate platforms. Following the
   principle of an open internet architecture a resource allocation
   protocol is required between NSIS agents and the QoS provisioning

   Adaptation to specific link layer characteristics is achieved by
   introduction of a link layer specific convergence sublayer for the
   QoS provisioning system. Support for a variety of NSIS compliant
   provisioning systems with specific link layer convergence mechanisms
   is a prerequisite for successful introduction of NSIS solutions.
   Accordingly routing and switching hardware need to come along with
   support for an NSIS based resource allocation protocol. This way
   signaling parameters together with ISP policies rules define a
   specified packet treatment behavior in a routing fabric. Finally,
   packet treatment is defined by architectural components like packet
   classifiers, queue buffers, schedulers and traffic conditioners.
   Some of these components may be directly controlled by signaling

   The QoS provisioning system should map status indications, hardware
   alarms and notifications into NSIS compliant reporting, which can be
   passed to NSIS agents for subsequent processing. Furthermore it is
   assumed that resource monitoring  is performed by the QoS
   provisioning system independently. Status information that is
   generated by the QoS provisioning hardware and requires mapping to
   be compliant with NSIS status reporting includes resource violation
   events, results of reservation requests and records about available

 4.3  NSIS Signaling Protocols

   The NSIS Signaling Protocol supports the actual communication of QoS
   requirement information for a traffic flow/aggregate between NSIS
   agents.  In order to support this, a number of network related
   actions must be carried out, namely:

   - Peer Agent Discovery: the NSIS Agents should be able to discover
   peer NSIS Agents, and optionally establish a trust relationship with
   them.  One NSIS Agent may discover one or more peer NSIS Agents in a
   number of different domains.  NSIS Agents can also exchange SLA and
   the many types of policy information required for intra/inter-domain
   management. This refers both to the QoS initiator discovering its
   first hop QoS controller, and also to have QoS controllers discover
   each other.

   Hancock et al.    Informational - Expires August 2002            28                 Towards a Framework for QoS Signaling    February 2002

   - Agent Selection: the NSIS Agents that will be provisioning
   resources for the traffic flow or aggregate are identified, i.e.
   each NSIS Agent selects the next hop NSIS Agent from the peers with
   which it has established a relationship with during peer agent
   discovery. Policy information associated with the user, such as
   whether realtime accounting must be supported, can be exchanged if
   necessary. Agent selection will not be as dynamic in the core of the
   network than at the edges, and user policy will probably not
   propagate too far from the edges of the network.

   - Path Capability Discovery: the capabilities and resource
   availability of the nodes along the data path are determined.  There
   are open issues associated with whether this occurs locally or
   cumulatively and on a hop-by-hop or end-to-end basis.

   - Reservation Request: the actual request for resources that
   triggers the QoS provisioning, also carrying QoS parameters and
   possibly per flow/aggregate policy information.

   The potential transfer of authentication, authorisation and user
   information places additional confidentiality and integrity security
   requirements on the protocol (see section 3.6).  Also, the
   information transferred within and between domains is variable,
   implying a need for an easily extensible set of parameters that can
   be carried, possibly opaquely, by the protocol (see section 4.4). It
   is the responsibility of the NSIS signaling protocol to detect
   failure conditions along the data path, and to initiate recovery

   A single NSIS signaling protocol solution could address the aspects
   outlined above, however, since a goal of NSIS is to make the actual
   reservation signaling as lightweight as possible, it may be
   desirable to address the first two actions using a separate family
   of protocols, which do not necessarily need to be used on a per flow
   basis, that are initiated at some stage before the generation of the
   reservation request. We therefore potentially have a two-phase

   1. 'Registration' phase - discovery, authentication, overall policy
      aspects and so on.
   2. 'Reservation' phase - any signaling associated with a single

   The registration phase may depend strongly on other protocols that
   already exist, and may be entirely optional in some environments.
   The protocol for the reservation phase should be of minimal
   complexity. Indeed, note that in several significant environments,
   the registration phase could be omitted altogether. For example, in
   a cellular network, the host could know (on the basis of what link
   type it was using) that the first hop QoS controller was always to
   be reached via its default router, and that authentication and

   Hancock et al.    Informational - Expires August 2002            29                 Towards a Framework for QoS Signaling    February 2002

   policy aspects were managed by the network on the basis of access
   control rather than an explicit message exchange.

 4.4  NSIS Signaling Data

   The NSIS signaling protocol should be able to carry a variety of
   signaling data. The majority of the information is related to QoS,
   but some other parameters are required to support protocol
   operation, accounting, etc.

   Different parameters may have relevance in different parts of the
   network. End-to-end parameters carry application QoS requirements,
   and may additionally carry extra information such as
   - user policy information
   - session ID to identify the traffic flow
   - reservation ID to identify the reservation independently from the
     flow identifier
   - initiator ID to identify the requestor of the reservation. This
     necessity for this parameter is dependent on the decision made
     about some aspects of the framework.  The initiator id can be
     over-ridden be a proxy so that the proxy receives feedback
     messages etc. on behalf of the real initiator.
   - opaque transport of application layer signaling

   Other parameters may be exchanged between peer NSIS Agents to
   support, for example, inter-domain QoS and accounting. This could
   include parameters such as:
   - charging policy: indicating how the domain expects to be charged
     for the traffic flow
   - security parameters
   - aggregation parameters: may include preferred mapping of the
     aggregate exiting one domain onto an aggregate in the neighboring

   Finally, some parameters may only have significance within a QoS
   domain, and should not propagate outside that domain. Such
   parameters may be:
   - wireless parameters: such as those outlined in [2]
   - optional router technology specific parameters: to support the use
     of NSIS as a QoS provisioning mechanism.

   Note: the scoping of the requirements above is intended mainly for
   demonstration purposes, there will be scenarios for which the scope
   of the parameters will not be the same as listed above. Framework
   level decisions may also effect the data that is carried.

   As mentioned previously, the information carried by the NSIS
   Signaling protocol may have different scoping characteristics
   depending on its type. The concept of scope of parameters plays an
   important part in the framework.  At a minimum, the NSIS signaling
   must carry the QoS parameters concerning the QoS requested by the

   Hancock et al.    Informational - Expires August 2002            30                 Towards a Framework for QoS Signaling    February 2002

   application end-to-end.  This could be considered as a 'global'

   The end-to-end per-flow parameters may not be interpreted by every
   QoS controller along the data path and may pass transparently
   through domains or NSIS agents that do not maintain per-flow state.
   If per-flow information is interpreted by a QoS controller, these
   parameters may need to be translated into a local format to support
   legacy QoS mechanisms.

   End-to-end parameters may not only consist of unidirectional, per-
   flow information. In some cases, additional information could be
   added to support bi-directional flows or to communicate QoS
   requirements for multiple flows.  In the former case, information
   about both directions of the traffic flow would be included to
   optimize reservation establishment in segments of the network where
   bi-directional flows could be supported.  Further details are
   available in Section 3.4.3.  In the latter case, multiple QoS
   parameters sets could be provided for different flows from the same
   sender to the same receiver to try and optimize the installation
   time of multiple reservations.  The various merits of doing this
   compared to simply initiating multiple reservation requests
   simultaneously still need to be investigated.

   In addition to transporting the end-to-end QoS parameters, NSIS
   Agents have the ability to signal new parameters either across their
   administrative domain with a 'local' scope, or to peer NSIS Agents
   in other administrative domains with a 'one-hop inter-domain' scope.
   These parameters will be derived from parameters with greater scope,
   e.g. the end-to-end parameters. These parameters can also be
   modified or deleted from the signaling messages, but only if the
   NSIS Agent has the right to do so by either belonging to the same
   administrative domain as, or by having a peering relationship with,
   the NSIS Agent who inserted the parameter. The indication that an
   NSIS Agent has the right to modify or delete a parameter could be
   indicated by a scope ID.  The QoS Initiator is at liberty to include
   local scope parameters in the reservation request, for example, to
   provide information regarding how it wishes its sessions to be
   handled during handover if it is attached to a mobile network.

   Two options for the transport of 'local' scope and 'one-hop inter-
   domain' scope parameters can be identified:

        1.           A separate signaling message could be initiated to carry the
          parameters, which would also share the same scope as the
          parameters.  The end-to-end parameters could be signaled
          directly to the next NSIS Agent either at the egress point of
          the current domain, or to a peer NSIS Agent in a neighboring

        2.           Parameters can be 'stacked' within the single NSIS signaling
          message travelling end-to-end.  NSIS Agents are allowed to

   Hancock et al.    Informational - Expires August 2002            31                 Towards a Framework for QoS Signaling    February 2002

          append parameters only to the top of the stack.  When an NSIS
          Agent determines that the scope ID is not valid beyond this
          point, it should remove all parameters with that scope ID.
          This is illustrated in Figure 11.

   | Peer QoS |
        |   +------------+                 +------------+
        |   |+----------+|   +----------+  |+----------+|  +----------+
        +--->|   QoS    ||-->|   QoS    |-->|   QoS    ||->| Peer QoS |
   +------+ ||Controller||   |Controller|  ||controller||  |Controller|
   | user | |+----------+|   +----------+  |+----------+|  +----------+
   |params| |            |                 |            |
   +------+ |Ingress     | +------+------+ |      Egress|
            |router      | | user |domain| |      router|
            +------------+ |params|params| +------------+
           +------+------+                 +------+------+   +------+
           | user |domain|     Signaled    | user |domain|   | user |
           |params|params|    Parameters   |params|params|   |params|
           +------+------+                 +------+------+   +------+

            +-----------------QoS Domain----------------+
               Figure 11: Domain Local Signaling Parameters
   There are advantages and disadvantages associated with each
   approach.  The first approach minimizes the complexity of the end-
   to-end signaling protocol and allows an independence of message rate
   for the sets of signaling.  However, some synchronization between
   the signaling is required that could be quite complex to support.

   The second approach increases the complexity and size of the data
   carried by the signaling, but simplifies protocol interactions
   within the network.

 4.5  Routing Aspects

 4.5.1  Implicit Routing of Signaling Packets

   As described in sections 3.4 and 4.3, an NSIS agent needs to find
   out about its nearest neighbors, and which of them is responsible to
   handle signaling packets for which destinations. Additionally, it
   needs to know whether it is able to initiate provisioning of the
   path segment that is adjoining to the path segment provisioned by
   the last-hop NSIS agent. (In other words it needs to know whether it
   is the right QoS controller for this signaling packet.) When the
   next-hop QoS controller is known, signaling packets can be addressed
   directly to it.

   Hancock et al.    Informational - Expires August 2002            32                 Towards a Framework for QoS Signaling    February 2002

   However, there might be situations when a QoS controller doesn't
   know an appropriate next-hop QoS controller. This might be either
   because the adjacent domain is NSIS-unaware, or it is
   overprovisioned, or even because of some failure or other, or simply
   that the next hop has not yet been discovered. Along the same line,
   an end host initiating NSIS signaling might not now the appropriate
   QoS controller to address. Hence, there should be some simple
   'boostrap' ways for finding the next NSIS agent when its address is
   not yet known. We consider two basic approaches here, both relying
   on the underlying routing layer to forward some signaling packet
   towards the other end of the flow and have it intercepted. We call
   this type of approach generically 'implicit routing' of signaling

   The first possibility is to forward the signaling packet with the
   signaling destination as the destination address (this requires that
   the signaling destination is coded somewhere in the signaling
   packet), so it can be intercepted by a router 'closer' to the next
   hop QoS controller and handled by it. The natural way to implement
   this with least impact on router efficiency is to use the IP Router
   Alert Option [3]. The signaling message will be read and forwarded
   by all routers on the path until it arrives at one which knows the
   next QoS controller. This provides the discovery mechanism
   (subsequent messages may turn off the IP Router Alert Option and be
   addressed directly). Note that even this case still requires some
   router to implement some special processing of the router alert
   option, although it may be possible to re-use the processing already
   defined for RSVP for this purpose.

   Obviously, for this default scenario to work, at least some NSIS
   agents need to be located in the data path. An end host (QoS
   initiator) might just send the NSIS signaling packet with the IP
   Router Alert Option set, addressed to the signaling end point. Then
   it would be sensible for the end host's Access Router to be able to
   forward this packet to the right QoS controller. Note that this
   method is sometimes referred to as 'proxying', although it is
   conceptually quite different from the proxying described in section
   3.7.1. In this case here the router is acting as a proxy, forwarding
   signaling packets to the 'real' QoS controller, but is doing no QoS
   signaling on its own behalf.

   A second possibility considers the case where QoS is required for
   inbound traffic to some end host, and the far end doesn't support
   any QoS (NSIS) signaling, but local bi-directional reservations are
   not possible (e.g. because of asymmetric routing). This can be
   achieved with a single inbound message from the remote end which is
   intercepted by a specialized router at the local domain boundary.
   The requirement here is that the message should use a lightweight
   protocol (preferably one which did not trigger exception processing
   in the rest of the network), and was 'firewall friendly' in using
   well known protocols and carrying minimal data to minimize security
   concerns. Some type of ICMP request/response exchange might be

   Hancock et al.    Informational - Expires August 2002            33                 Towards a Framework for QoS Signaling    February 2002

   appropriate here. Note that the response does not have to be
   returned from the ultimate endpoint, just any router which knew it
   was on the return path - so a site border firewall could
   legitimately do this.

   These techniques can be considered complementary. The adoption of
   either of them requires a consideration of deployment considerations
   for them. The first is naturally a generalisation of RSVP, while the
   second provides part of the solution to the problem of QoS in multi-
   homed networks having minimal impact on the rest of the network.

 4.5.2  Impact of Multi-Field Routing

   Classically, routing is destination based, that is, all packets from
   one source with the same destination IP address usually travel along
   the same route. Therefore, a flow usually will follow the same route
   as the signaling packet that signaled QoS for that flow if they are
   addressed to the same destination. This allows the signaling packet
   to distribute QoS information locally (i.e. to the routers actually
   on the flow path), where it will be needed. This is the set of
   circumstances where implicit routing functions correctly.

   However, routing may also be more complicated, and it is
   increasingly deployed that way. It might be constraint based, or it
   may be based on other fields in addition to the destination
   (multifield routing), e.g. the TOS/DS field or higher layer
   information. In such a case, some effort specific to the routing
   applied in a particular area may be necessary for making the
   signaling packet travel along the same route as the flow it is
   signaling for - e.g. the signaling and flow need the identical TOS
   Byte (and hence, as a possibly unwanted side effect, this signaling
   packet would receive the same QoS as the signaled flow). Since the
   fields or constraints on which routing is based might change in each
   QoS subdomain, this might be difficult to achieve.

   The problem is somewhat different when QoS controllers are not
   located on every hop. They might for example be located on edge
   routers only. In this case each QoS controller obviously controls
   (or at least is aware of) the resources of a number of routers.
   Depending on how finely-grained it controls these resources, it
   needs to know the routing table, including the path taken by the
   flow a particular signaling packet is signaling for. Additionally it
   needs to know the boundary of its control over this path, and the
   identity of the QoS controller for the next segment.

   It is interesting that by incorporating the functionality that
   supports interworking with multi-field and constraint-based routing,
   we automatically must consider signaling traveling off the data
   path. In that case, integrating QoS Controllers off the data path,
   such as bandwidth brokers, does not require any extra effort.

   Hancock et al.    Informational - Expires August 2002            34                 Towards a Framework for QoS Signaling    February 2002

 5  Application to Generic Signaling Scenarios

 5.1  Network / Proxy / Edge / End Signaling Scenarios

   One important requirement for QoS signaling [1] is that the NSIS
   protocol work in various scenarios end-to-end, edge-to-edge, end-to-
   network etc. i.e. the location of QoS initiator and signaling end
   point can be chosen freely.

   The QoS initiator usually can be assumed to know the termination
   point, e.g. when a reservation for aggregates is to be established
   within a domain, the QoS initiator could be the ingress router, and
   signaling is to be terminated at the egress router. In this case,
   the signaling packet carries as its termination address (as opposed
   to destination address, which typically is the address of the next-
   hop QoS controller, see 4.5) the egress router. A slightly special
   case is when the signaling end point is a signaling proxy. In this
   case, the signaling end point addressed is thought to be a
   particular end host, whereas in reality it is a signaling proxy
   impersonating the end host.

   It is clear that most combinations of QoS initiator and signaling
   end point that can be composed of the section heading are addressed
   straight forwardly by the framework. The only combinations which are
   less evident are those involving the "network". This is discussed in
   the next section, including defining more precisely what in this
   context is meant by "network", see subsequent section.

 5.2  End-to-Network Signaling and Interworking with Higher-Layer QoS

   In some cases when NSIS signaling is to be used for reserving QoS
   along a particular path, all relevant QoS parameters might already
   have been exchanged by, or can be derived from, another form of
   signaling, e.g. SIP /SDP [4]. If, additionally, the backbone is
   overprovisioned, it is desirable to confine NSIS signaling to those
   areas where it is needed, i.e. the (access) network up to the
   backbone. Particularly, it would be desirable to not NSIS signal
   end-to-end, but just (from both sides) end-to-network.

   The problem with the above optimisation is that the use of upper-
   layer end-to-end QoS exchange should in principle be transparent to
   NSIS agents and the NSIS protocol. It is of course possible to build
   hooks into the protocol to carry this information. However, this is
   a clear case of layer-violation, would complicate the NSIS protocol
   and is not recommended. Alternatively, one could use the fact that
   the end host might know end-to-end QoS information has already been
   exchanged. But on the other hand it wouldn't know whether the
   network is overprovisioned or not.

   A possible scenario for solving the problem is the employment of
   Proxy NSIS agents at the edge to the overprovisioned domain, acting

   Hancock et al.    Informational - Expires August 2002            35                 Towards a Framework for QoS Signaling    February 2002

   as proxies for the end host on the other side. These proxies would
   be configured such that they _always_ block NSIS signaling from
   going any further into the network. Obviously, analogous proxies are
   needed on the other side of the network. Such an approach can only
   work however, when all operators involved agree (via SLAs) that
   typically end-to-end exchange of QoS information has taken place
   before NSIS signaling is invoked, and that in all other cases, end-
   to-end QoS exchange is unnecessary. Further complication arises when
   asymmetric paths through the overprovisioned domain are considered,
   such that the ingress for upstream data is not the same as the
   egress for downstream data.

   A solution as described above is conceivable for relatively isolated
   networks with a well-defined service structure, such as e.g.
   commercial mobile networks.

 5.3  Transparent path traversal

   One of the requirements in [1](5.2.4) states that it should be
   possible for NSIS signaling to traverse path segments transparently,
   i.e. without interpretation by some QoS controllers. This ability
   can e.g. be useful when a local QoS provisioning protocol, or
   DiffServ, is employed in a subdomain. There is no need for NSIS
   signaling to be interpreted in this region (However, in this case
   there simply might not be any QoS controllers in this region). It is
   also useful for tunnelling per-flow or per-sub-aggregate NSIS
   signaling through aggregation regions.

   Within the NSIS framework, such scenarios can easily be realised. As
   described in 4.5, it is possible to directly address a particular
   QoS controller. Thus, when the signaling is to enter the transparent
   region, the adjacent controller (typically the ingress router to the
   subdomain) would choose the next QoS controller beyond the
   transparent region (typically the egress router) as a next-hop QoS

 5.4  Use of NSIS Signaling in QoS Provisioning

   The following scenario describes how QoS provisioning can be fitted
   within the NSIS framework. The framework has the flexibility to
   allow NSIS signaling to be used as part of the intra-domain QoS
   provisioning mechanism with no additional complexity.

   When NSIS is used in this way, it carries additional domain specific
   parameters indicating the configuration requirements for the packet
   engine, e.g. the schedulers. This sort of specific information is
   not envisaged as being carried by 'normal' NSIS signaling. In
   addition, the NSIS Agents in the routers pass configuration
   parameters direct to the packet engine.

   (Note that this is not the only type of QoS provisioning option
   supported by the framework. Section 4.2 considers the implications

   Hancock et al.    Informational - Expires August 2002            36                 Towards a Framework for QoS Signaling    February 2002

   of using a 'black box' QoS provisioning mechanism, whose details are
   opaque to the framework, which may be the more usual case.)  If
   desired, NSIS for QoS provisioning can be supported by the framework
   in any of the following ways:

   1. The NSIS protocol can be interpreted hop-by-hop along the data
   path by placing an NSIS agent in every router. This would use NSIS
   signaling to trigger the QoS provisioning mechanism locally; some
   form of RSVP would be an appropriate protocol for this purpose,
   provided RSVP can be fitted into the framework.

   2. A central NSIS agent can initiate NSIS signaling to agents on
   each router to configure resources directly.  Used in this way,
   protocols such as COPS-PR can be fitted within the framework.

               -------------->||            ||-------------->
       'Normal'<--------------|| NSIS Agent ||<--------------
     NSIS Signaling           |+------------+|
                             /| centralised  |\
                            / | controller   | \
                           /  +--------------+  \
                          /          |           \
                         /           |            \
                        /     NSIS Signaling       \
                       /   for QoS Provisioning     \
                       |             |              |
                       V             V              V
        +-----router-----+   +-----router-----+   +-----router-----+
        |+--------------+|   |+--------------+|   |+--------------+|
        ||              ||   ||              ||   ||              ||
   =====||  NSIS Agent  ||===||  NSIS Agent  ||===||  NSIS Agent  ||===
   flow |+--------------+|   |+--------------+|   |+--------------+|
   path | |              |   | |              |   | |              |
        | |configuration |   | |configuration |   | |configuration |
        | | parameters   |   | | parameters   |   | | parameters   |
        | |              |   | |              |   | |              |
        | | +----------+ |   | | +----------+ |   | | +----------+ |
        | +>|pkt engine| |   | +>|pkt engine| |   | +>|pkt engine| |
        |   +----------+ |   |   +----------+ |   |   +----------+ |
        +----------------+   +----------------+   +----------------+

        Figure 12: Domain-Local NSIS Signaling for QoS Provisioning

   In either case, domain specific information concerning the
   configuration of routers etc. would need to be included in the
   parameters carried by the NSIS protocol, but would be limited in
   scope to the area of the network where NSIS was being used as part
   of a provisioning mechanism. For some protocols, such as COPS-PR,
   the signaling has local scope and will not propagate outside the

   Hancock et al.    Informational - Expires August 2002            37                 Towards a Framework for QoS Signaling    February 2002

   domain.  For others, such as RSVP, indication must be provided to
   edge routers to indicate that the message must be terminated.  This
   could be done using, for example, a scope identifier (see section

 5.5  Aggregation and Hierarchical Reservations

   Aggregation of per-flow signaling (or - recursively - per-
   subaggregate signaling) is a technique contributing to scalability
   of both QoS signaling and QoS provisioning. It results in
   hierarchical reservation set-up.

   Aggregation / deaggregation of flow state information can be
   described by a functional component which may be located in NSIS
   agents. However, this task needs to be carried out by dedicated NSIS
   agents - not all NSIS agents need to implement aggregation and
   deaggregation functions. Aggregation is expected to be in deployment
   at all ingress routers of a particularly administrative domain or
   subdomain. Therefore deaggregation would happen at an egress router,
   but not necessarily within the same network domain.

   An aggregation region as defined by [5] may stretch along several
   domains with some level of nesting in aggregated domains. Therefore
   we assume that these tasks may represent an interdomain problem.
   Proper operation of aggregation mechanisms among several (sub-)
   domains need to make sure that all entities are provided with
   sufficient aggregation context. Correct interpretation of
   aggregation context may be handled by establishment of service level
   specifications (SLS's) among adjacent network domains.

   Prominent existing solutions for aggregating flow state information
   in a QoS signaling enabled network are namely the framework for
   IntServ operation over Diffserv networks [6] and the RSVP
   aggregation approach [5]. For the IntServ over Diffserv concept,
   aggregation usually is performed with coarse granularity, since RSVP
   style flow state information is mapped to a Diffserv transport
   service class, which defines a specific per hop behaviour (PHB).
   Aggregated RSVP represents a flexible solution to define the
   granularity of aggregation. Flow aggregation can however also be
   performed based on the NSIS signaling. In the following, all these
   possibilities are considered for the NSIS framework.

 5.5.1  NSIS Aggregation Techniques

   An NSIS agent should be able to either initiate aggregate signaling
   itself, or to interwork with network domains supporting their own
   flow aggregation techniques. These two approaches are considered in
   the following.

   In any event, in order to realise aggregation, usually two things
   are necessary:

   Hancock et al.    Informational - Expires August 2002            38                 Towards a Framework for QoS Signaling    February 2002

   (i)  per-flow or per-subaggregate NSIS signaling must pass the
   aggregation region  between ingress and egress (or aggregator and
   deaggregator) transparently. How this is done was handled in the
   previous section on Transparent Path Traversal.

   (ii) Per-aggregate signaling (NSIS-based or other QoS provisioning
   signaling) must be initiated by the aggregator and terminated at the
   deaggregator. The QoS information in the aggregate signaling message
   is somehow derived from the total of per-flow or per-subaggregate
   QoS information. However, the relation between them may be described
   by a rather complicated algorithm. Furthermore, they may work on
   very differently time scales. This corresponds to edge-to-edge
   signaling described in 5.1.

   NSIS-based Aggregation

   The following figure describes a possibility of mapping this
   scenario to the framework:

                +------------------+                  +-------------+
                |   +-------------+|                  |             |
                |   |Aggregation  ||                  |             |
                |   |algorithm    ||                  |             |
                |   |(application)||                  |             |
                |   +-------------+|                  |             |
                |      ^       |   |                  |             |
                |      |       |   |   Per-flow or    |             |
   +---------+  |+----------+  |   | per-subaggregate |+----------+ |
   |QoS      |  ||QoS       |  |   |    signaling     ||QoS       | |
   +---------+  |+----------+  |   |                  |+----------+ |
                |              V   |                  |   ^         |
                |       +---------+|   +----------+   |   |         |
                |       |QoS      ||   |QoS       |   |   |         |
                |       |Initiator|--->|Controller|-------+         |
                |       +---------+|   +----------+   |             |
                |                  |                  |             |
                |   Aggregator     |                  |De-aggregator|
                +------------------+                  +-------------+

                      Figure 13: Aggregate Signaling

   In Figure 13, the QoS controller on the Aggregator communicates the
   per-flow or per-subaggregate QoS information to some kind of
   aggregation algorithm. The output of this algorithm are instructions
   to the QoS Initiator function on this same aggregator on how
   existing aggregates are to be modified, or what new aggregates are
   to be initiated. Sticking to the definition of QoS Initiator, the
   aggregation algorithm it communicates with resides in the
   application layer.

   Hancock et al.    Informational - Expires August 2002            39                 Towards a Framework for QoS Signaling    February 2002

   In an alternative scenario, the aggregation algorithm resides in a
   separate administrative entity. In this case, this administrative
   entity would trigger aggregate signaling in the Aggregator.
   Interpreting the framework definition strictly, in this case the
   administrative entity is the QoS initiator.

   Non-NSIS based Aggregation

   In this approach NSIS signaling data is forwarded to an adjacent
   domain which supports non-NSIS compliant aggregation techniques
   only, i.e. the considered domain is not capable of aggregating NSIS
   signaling state information, but supplies its own QoS provisioning
   signaling. In that situation the gateway NSIS agent must provide
   specific mechanisms for allowing the aggregation. A function is
   required to provide filter rules for classifying NSIS signaling
   state information and apply aggregation mechanisms to support
   interworking with the adjacent domain. This function may be co-
   located with an NSIS agent as an aggregation algorithm as described
   for NSIS-based Aggregation above.
   Aggregation of NSIS data into Diffserv classes for example requires
   an aggregation function to provide filter rules for mapping NSIS
   flow state information into predefined PHB transportation classes
   and coordinate DSCP codepoint marking to comply with service level
   specifications (SLS) for domain interworking.

 5.5.2  Aggregation Context

   An administritative entity is required to decide about NSIS agent
   responsibility to perform aggregation / deaggregation and to
   determine the appropriate rules for performing the tasks.
   Furthermore, participating entities should be identified and
   entitled to carry out aggregation and deaggregation tasks. In case
   of traffic trunks for example, tunneling endpoints might be
   responsible for performing aggregation and deaggregation. It is
   assumed that the administrative entity controls the distribution of
   required information, identifies potential aggregation entities
   (e.g. NSIS agents) and entitles them to execute the tasks. The term
   aggregation context represents the structured information that is
   required to enforce consistent execution of aggregation and
   deaggregation tasks. It is distributed by the administrative entity
   to entitled aggregation entities. Policy decision points (PDP's)and
   network administration servers represent such administrative
   entities. With appropriate extensions COPS and SNMP are envisioned
   candidate protocols to carry aggregation context information and
   related status and context messages.

   As described above, the actual algorithm for determining whether
   changes to aggregates or new aggregates are necessary might reside
   either in the administrative entity, or in the aggregator.

 5.6  Operation over Addressing and Other Boundaries

   Hancock et al.    Informational - Expires August 2002            40                 Towards a Framework for QoS Signaling    February 2002

   The ideal operational paradigm for the Internet is that end to end
   addressing transparency is preserved; in other words, the IP
   addresses in packets are unchanged between the sending and receiving
   end hosts. This is recognised as an optimal situation from the point
   of view of network simplicity and resilience [7].

   Unfortunately, this paradigm is broken in today's Internet for
   several reasons. The major current reason is NAT [8], although
   address translation techniques are also one method considered for
   IPv4-IPv6 transition [9]. In addition, some recent network layer
   protocol developments change or add to the addressing capabilities
   of the network layer header, including the HAO of Mobile IPv6 [10]
   and HIP [11]. Finally, tunneling mechanisms or application layer
   gateways can also be considered as falling into this category, but
   are less of a concern here: tunnels can be modeled (and are often
   implemented) relatively transparently as virtual links, while NSIS
   would see an application layer gateway as a signaling endpoint in
   its own right, not needing special consideration.

   The implications of addressing non-transparency for NSIS are two-

   Firstly, the signaling messages themselves must be capable of
   passing through addressing boundaries and might have to use (or be
   able to exploit) these more recent addressing approaches. This
   requires consideration of the way in which possible NSIS signaling
   protocols can be treated in this way. This is particularly
   important, since it is likely that the NSIS signaling data will
   contain addressing information about signaling endpoints which will
   also need to be translated consistently.

   Secondly, the NSIS signaling data will contain packet classification
   information that is used to identify the user packets for which QoS
   is being requested. On the assumption that both the user packets and
   signaling packets have to be treated or interpreted consistently,
   the treatment (e.g. translation) applied to the user packets must be
   matched by updates to the signaling data carried in the NSIS
   packets. This may have implications for the security treatment
   applied to these packets.

   In our framework, it seems that the various boundary cases should be
   treated individually. Classic NAT is stateful and typically has to
   run over a single physical device. In this case, it is natural to
   locate a Proxy NSIS agent at the NAT device. In order to do
   consistent message processing on the user and signaling data, this
   will have to be closely integrated with the NAT functionality,
   probably according to a proprietary behavior specification; however,
   the rest of the network should continue to be unaware of its
   presence. On the other hand, SIIT being stateless, it should ideally
   also be possible to translate NSIS messages statelessly, which would
   require extensions to the current definition, comparable to those
   needed to handle IP options or extension headers. This requires

   Hancock et al.    Informational - Expires August 2002            41                 Towards a Framework for QoS Signaling    February 2002

   defining a NSIS data format which could have semantically identical
   v4 and v6 forms, but NSIS proxies should not be enforced for this

   The situation of modified network layer identifiers may require
   extended address format capabilities for NSIS signaling data to
   include the new formats, and also a precise definition of the
   semantics of addressing information elements (e.g. whether or not an
   address in a classifier refers to the HAO if present).

   It is certain that these addressing considerations will need to be
   re-evaluated when a more concrete NSIS solution is ready to be
   considered. At that stage, it might even be questioned whether
   support for all possible network scenarios (e.g. NAT) needs to be

 5.7  Support for Adaptive Applications

   Adaptive applications require feedback about the ongoing resource
   availability in the network, or the occurrence of QoS violations.
   The actual frequency and detail required in the feedback messages
   any vary depending on the scenario, e.g. mobile vs. fixed network.

   In the following discussion, it is assumed that the feedback
   information should be passed back to the initiator of the session,
   and then on to the application to whom the session belongs.  The
   application can choose to take adaptive action if required, which
   may result in a re-negotiation of resources along the data path.

   There are a number of ways that QoS feedback information to the

   1.      Information can be sent direct to the QoS initiator: the NSIS
     Agents maintain the address of the initiator to allow the QoS
     violation notification to be signaled directly. When a proxy is
     present in the path and has modified the initiator identifier to
     identify itself, the message will be sent direct to the proxy
     instead of the real initiator. There may be trust issues
     associated with this approach concerning the fact that the
     initiator will be receiving information on which it is basing re-
     negotiation decisions from an untrusted node.  However, the
     signaling does not have to be processed by all intermediate NSIS

   2.      Information can be sent hop-by-hop back towards the initiator: the
     feedback information is signaled backwards between NSIS Agents on
     the data path until it reaches the QoS Initiator. Each NSIS Agent
     must maintain previous hop information and process the messages in
     part to forward the messages to the correct agent.  However, the
     Initiator will receive information from a peer NSIS Agent with
     whom it has established a trust relationship.

   Hancock et al.    Informational - Expires August 2002            42                 Towards a Framework for QoS Signaling    February 2002

   3.      Information can be sent downstream in the data path to destination
     domain and reflected back to the Initiator: the violation
     information is simply sent along the signaling path to the
     destination node that then reflects this information back to the
     receiver.  No state information is required within the NSIS
     Agents, but the propagation time for the signaling to reach the
     Initiator is increased

   Only the entities that know about violations need to support
   violation reporting.  When the QoS for a flow that is being
   transported as an aggregate is violated, it is a local matter as to
   whether this information is propagated, and implies some per-flow
   knowledge about the flows in the aggregate.  This is to allow the
   information to be propagated to the correct Initiator and is may be
   undesirable for scalability reasons.

   The decision about how feedback to applications is supported by the
   framework will impact the QoS signaling data that has to be carried
   by the protocol, and also the state information maintained by NSIS
   Agents depending on the chosen option.

 6  Applicability of Other QoS Frameworks and Protocols

 6.1  Incremental Deployment in an NSIS-Unaware Internet

   Introduction of NSIS compliant network components most likely will
   follow a step-by-step process where deployment in few networks has
   to be considered at the beginning. A three stage introduction
   process is described assuming few NSIS compliant domains at the
   beginning. If NSIS technology could gain more acceptance after the
   introductory phase a heterogeneous infrastructure with NSIS capable
   domains and non NSIS capable domains intermixed arbitrarily is

   For the non NSIS compliant domains in operation two cases can be
   thought of.

   a. Heterogeneous QoS Signaling Solutions

   A domain offers QoS provision mechanisms but QoS signaling is not
   compliant with NSIS protocols, e.g. an ISP's proprietary solution is
   in operation. Application of appropriate interworking mechanisms
   have to be considered then. NSIS signaling data traversing a non
   NSIS compliant domain should not be subject to loss or delay caused
   by low priority handling. To avoid loss, NSIS signaling information
   either may be encapsulated or may be forwarded transparently in non
   NSIS aware regions. Additionally non NSIS compliant domains have to
   provide mechanisms to forward NSIS signaling information with the
   required reliability and priority, which has to be defined by
   service level specifications (SLS's).

   b. Best Effort Forwarding Paradigm

   Hancock et al.    Informational - Expires August 2002            43                 Towards a Framework for QoS Signaling    February 2002

   In this case end to end signaling and QoS provision is broken by non
   QoS aware domain(s). Consequently delivery of end to end services is
   not possible with satisfactory service level guarantees.

 6.1.1  Step 1: NSIS compliant Islands

   In this situation deployment of NSIS technology is in its initial
   phase. The technology can be used for usage of intradomain QoS
   sensitive services. Then NSIS signaling can be applied e.g. for
   accessing services from a local host. This approach can be
   associated with the walled garden model [12]. A more complex
   scenario deals with application flows that may extend along non NSIS
   aware domains. A potential option for signaling between remote NSIS
   agents can be accomplished by using a leased line service for
   bridging the NSIS islands. Transport characteristics of  the leased
   line service have to be taken into account when deciding about
   admission of an NSIS resource reservation request. Therefore gateway
   node interfacing with the leased line service are responsible to
   perform AAA functions on single flows and flow aggregates, that
   require resources for bridging to a remote NSIS domain.

 6.1.2  Step 2: Heterogeneous Infrastructure

   With the incremental deployment of further NSIS technology a mixed
   infrastructure is assumed comprising NSIS compliant and non NSIS
   compliant domains. Some end to end NSIS signaling may be
   accomplished without break in between even if several domains have
   to be crossed. Still there remains some potential for unreliable
   transport and signaling especially when the QoS enabled path extends
   along several domains. This problem can be reduced by introducing
   "trusted" NSIS regions. This concept assumes 'strong' SLA's between
   several ISP's, extending a trusted NSIS region among several
   domains. Further enhancement can be achieved by an approach, which
   relies on an extended record route mechanism. Detection of next hop
   NSIS agent requires the tracking of all NSIS agents along and end to
   end path. The NSIS agent record can be used by all NSIS agent to
   check whether the next hop agent is available in a network domain
   with established SLA's for proper interworking. With the proposed
   concepts an ISP may be aware with reasonable high reliability which
   destination network will be reachable through NSIS signaling without
   signaling and service break in between.

   Destination networks may not be reachable without leaving an NSIS
   compliant region. Reliable transport of NSIS signaling with
   appropriate QoS provision could be enforced if there is no more than
   one non-compliant NSIS domain between NSIS compliant domains with
   appropriate SLA's in place.

   In the context of heterogeneous infrastructure we consider a
   scenario where a host or network node wants to act as QoS initiator
   for NSIS signaling without actually being capable of doing so. Proxy

   Hancock et al.    Informational - Expires August 2002            44                 Towards a Framework for QoS Signaling    February 2002

   NSIS agents described in this document may take over the QoS
   initiating part in this situation. ISP's could benefit from this
   scenario by offering QoS enabled services to a larger number of

 6.1.3  Step 3: Widespread deployment of NSIS

   A widespread deployment of NSIS compliant domains represents an
   optimistic case though it may be considered for specific countries
   or federal states. Compared to step 2 of deployment there are no
   further technical issues to consider here.

 6.2  Basic Diffserv

   DiffServ domains can be deployed in a variety of ways. Particularly,
   they may work with or without admission control. If admission
   control is included, it may work based on a variety of data. In this
   context, DiffServ networks with the admission control based on the
   flow characteristics and the flow's QoS requirement are interesting.
   This information would be transferred by NSIS signaling. The
   admission control typically is handled by edge routers or by
   bandwidth brokers. Consequently, QoS controllers would be located on
   the corresponding entity(entities), as applicable for a particular
   network. The next QoS controller would be either the egress router,
   or the bandwidth broker of the next domain. Inside the DiffServ
   domain, usually no QoS controller is necessary.

   The responsibility of the QoS controller also includes providing for
   proper (re-)marking of data packets at the ingress router to the
   DiffServ domain. RODA [16]defines a signaling and resource
   reservation protocol for DiffServ domains. It can be regarded as a
   QoS provisioning signaling protocol, outside but compatible with the
   NSIS framework.

 6.3  Basic Intserv

   In an IntServ domain, each router is in charge of its own resources
   and needs QoS signaling information. Hence, each router in fact is a
   QoS controller.

   If RSVP will be used as the / one NSIS signaling protocol, this
   scenario fits in seamlessly. If on the other hand, NSIS decides on
   using another signaling protocol, we need interworking of the NSIS
   protocol and RSVP at the edge router of the IntServ domain. In this
   case, the edge routers are QoS Controllers only, and RSVP is QoS
   provisioning signaling.

 6.4  RMD

   Resource Management in Diffserv (RMD) is designed for edge-to-edge
   resource reservation in a Differentiated Services domain [13]. The
   RMD framework defines two architectural concepts:

   Hancock et al.    Informational - Expires August 2002            45                 Towards a Framework for QoS Signaling    February 2002

     - the Per Hop Reservation (PHR)
     - the Per Domain Reservation (PDR)

   Individual candidate resource reservation protocols are envisioned
   for both concepts. A PHR protocol is used within a Diffserv domain
   on a per-hop basis to augment the Diffserv Per Hop Behavior (PHB)
   with resource reservation. It is implemented in all nodes in a
   Diffserv domain. On the other hand, a PDR protocol manages the
   resource reservation per Diffserv domain, relying on installed PHR
   resource status in all nodes. The PDR is only implemented at the
   boundary of the domain(at the edge nodes).

   The RMD framework uses the Diffserv classes Expedited Forwarding(EF)
   [14] and Assured Forwarding (AF) [15] as QoS classes. It is implies
   that any network supporting the RMD framework is able to classify,
   mark, police and schedule the traffic accordingly. A signaling
   protocol is proposed as well for allocating resources hop by hop in
   a DiffServ capable domain. An instantiation of a PHR protocol is
   named RODA [16] (Resource Management in Diffserv On DemAnd), which
   has been proposed recently. In contrast, the PDR can be supported
   either by a new protocol or (one or more) existing protocols.
   Examples of such existing protocols can be the Resource Reservation
   Protocol(RSVP) [17], RSVP aggregation [5] etc.

   For PHR the RMD Framework currently specifies two different groups:

   The Reservation-Based PHR group

   In this PHR group, each node in the communication path from ingress
   node to egress node keeps only one reservation state per PHB. The
   reservation is done in terms of resource units, which may be based
   on a single parameter, such as bandwidth, or on more sophisticated
   parameters. These resources are requested dynamically per PHB (i.e.,
   per DSCP) and reserved on demand on all nodes in the communication
   path from an ingress node to an egress node. Furthermore, this PHR
   group has to maintain a threshold for each PHB that specifies the
   maximum number of reservable resource units.

   The Measurement-based Admission Control (MBAC) PHR group

   This PHR group is used to check the availability of resources before
   flows are admitted.  That is, measurements are done on the real
   average traffic (user) data load. However, the measurement based PHR
   uses two states. One state per PHB that stores the measured user
   traffic load associated to the PHB and another state per PHB that
   stores the maximum allowable traffic load per PHB.

   The RMD framework supports signaling to achieve load sharing among
   several paths. Interior nodes are able to observe when a load
   sharing situation occurs and know the number of multiple equal cost
   paths that a routing protocol will use to provide the load sharing

   Hancock et al.    Informational - Expires August 2002            46                 Towards a Framework for QoS Signaling    February 2002

   principle. Subsequently, for each arrived PHR message which is
   affected by the load sharing principle, the interior node will be
   able to create the appropriate number of PHR messages of identical
   type as the original one. "Appropriate" here means the number of
   paths participating in the load split.

   In the following an assessment is done on fitting the RMD framework
   proposal with NSIS requirements [1]. The goal is to apply and reuse
   RMD concepts for NSIS based solutions where possible.

   The RMD framework proposes a scalable solution and fits with the
   ideas of lightweight signaling. In particular, little state
   information is required for hop by hop signaling in the Diffserv
   domain. A major benefit is the possible reuse of existing signaling
   protocols (RSVP etc.) and QoS provisioning mechanisms (Diffserv).
   Independence of signaling and provisioning paradigm is achieved by
   the RMD framework. PDR allows hiding the internal structure of a QoS
   domain from end-nodes and from other networks. A useful feature not
   explicitly part of the NSIS requirements is support for load

   RMD focus is on intradomain but does provide hooks for domain
   interworking, and requirements that typically come from the end to
   end or host to edge signaling cases are emphasised less. Resilience
   aspects are not explicitly mentioned. RMD doesn't consider
   interworking with QoS provisioning mechanisms other than Diffserv.
   Processed state information for each PHB is restricted to a maximum
   of two states, which are measured traffic load and maximum allowable
   traffic load by name. Mobility support is not considered in the RMD

   Though the RMD framework does not cover some crucial requirements to
   be met by an NSIS solution it seems to fit into our overall NSIS
   framework. RMD can be considered to provide a sub-solution for our
   NSIS framework with beneficial extensions to an Diffserv network.

 6.5  MPLS

   In MPLS, the ingress router to a domain sets up LSPs e.g. edge-to-
   edge. Particular LSPs may be set up for a particular QoS class. For
   the ingress router it is necessary to know the QoS requirements of
   an incoming flow in order to map it to the appropriate LSP. Hence,
   in MPLS domains, ingress routers are QoS controllers. The next QoS
   controller is on the egress of the LSP of the signaled flow. Note
   that signaling inside the MPLS domain, e.g. for setting up LSPs, is
   not in any way changed by NSIS signaling but can regarded as a form
   of QoS signaling provisioning.

 6.6  Bandwidth Broker

   Bandwidth brokers are QoS controllers outside the data path. As
   illustrated in section 4.5 on Routing Aspects, such QoS controllers

   Hancock et al.    Informational - Expires August 2002            47                 Towards a Framework for QoS Signaling    February 2002

   naturally integrate into the NSIS framework, as signalling cannot be
   assumed to follow the data path anyways as soon as other than
   destination-based routing is employed. Examples of bandwidth brokers
   integration in NSIS signalling are given in the following.

   The basic scenario is a bandwidth broker being the only QoS
   controller in a domain. It makes its existence known to QoS
   controllers in neighbouring domains, and directly receives NSIS
   signalling from them. For provisioning QoS, the bandwidth broker may
   signal to all routers in the domain, as illustrated in section 5.4.
   Alternatively, the bandwidth broker may just monitor router loads in
   the domain, and base admission control decisions on monitoring

   In a more involved scenario, additional QoS controllers are located
   on edge routers. These edge routers are responsible for interworking
   with outside domains. NSIS signaling in this case arrives at edge
   routes first, which relay it (without any QoS provisioning action)
   to the bandwidth broker(s). The bandwidth broker addresses the  NSIS
   signaling to the next-hop QoS controller, the egress router. It
   needs to be investigated whether such a scenario is more robust,
   since edge routers are in the data path and can always be discovered
   by the default routing of NSIS signaling packets with Router Alert
   Option on (cf. section 4.5). Additionally, it facilitates topology
   hiding (at least the existence of the bandwidth broker is hidden)
   required by some operators.

   Of course, a bandwidth broker can also act as a QoS Initiator, for
   example for setting up inter-domain aggregate reservations.

 7  Possible NSIS Signaling Protocols

 7.1  RSVP and its Extensions

   RSVP has been extended in a number of directions, e.g., aggregation,
   DiffServ, tunnel, policy, proxy, and mobility support. Together with
   these extensions, RSVP serves for broader applicability of signaling
   beyond the IntServ model only.

   RSVPv1 provides an ability to communicate the application's
   requirements to network elements along the path and to convey QoS
   management information between network elements and the application.

   RFC 2746 [18] extends RSVP to provide signaling support in IP
   tunnels. The tunnel RSVP session views the two tunnel endpoints as
   two end hosts with a unicast FF style reservation in between; the
   e2e RSVP session views the tunnel as a single link on the path
   between the source(s) and destination(s). Inside the tunnel, the
   endpoint uses a new SESSION_ASSOC object in the Path message to map
   between an e2e session and a tunnel session, and uses a tunnel Resv
   to reserve resources.

   Hancock et al.    Informational - Expires August 2002            48                 Towards a Framework for QoS Signaling    February 2002

   RFC 2749 [19] supports COPS policy services in RSVP environments.
   All objects carried in RSVP messages received  by the PEP (if not
   matching its cache) are encapsulated in a Client Specific
   Information (CSI) object and sent to the PDP. COPS provides the PDP
   with flexible policy controls upon receipt of the CSI, making
   decision per reservation flow.

   With RFC 3175 [5], individual flows can be aggregated in an
   aggregated region. Aggregated Path/Resv messages are used in the
   region to setup and maintain aggregation sessions. According to
   DiffServ, DSCPs are used to identify the traffic belong to the
   correspondent aggregation. The DSCP can be specified by a DCLASS
   object per [20]. One or more Diff-Serv PHBs are used to offer the
   required forwarding treatment to this traffic.  The corresponding
   PHB is determined by the Intserv to Diffserv mapping rules
   recommended by [6].

   With the addition of [22], RSVP is also used to proxy the RSVP
   messages intended for one of the communication ends in  an
   intermediate node. The node running the rsvp-proxy takes the
   responsibility of the other communication end. A RSVP receiver
   proxy may generate a Resv message upon receipt of a Path  message. A
   RSVP sender proxy can initiates a proxy Path message upon some
   policy-based triggers.

   With various proposed mobility extensions, RSVP is used for
   signaling application's requirements when hosts are mobile. For
   examle, Shen  et al [21] suggest a way to use the mobile node's home
   address to identify the source or destination of a RSVP flow. In
   [23] a "mobile-proxy" is put at the edge of the access domain  on
   behalf of RSVP messages: inside and outside the access domain,  LCoA
   (local CoA) and RCoA (RCoA) of the mobile node will be used to
   identify the same RSVP session. The mobile-proxy will either change
   the session information in Path/Resv message accordingly and forward
   it (when it is an inter-domain handoff), or generate a Path toward
   the  mobile node / respond with a Resv message upon receipt of a
   Path  message from the mobile node (when it's an intra-domain

   Hancock et al.    Informational - Expires August 2002            49                 Towards a Framework for QoS Signaling    February 2002

 7.2  RSVP ultra-lite

   Per RSVPv1 [17], a unicast session is defined as session which has
   one or multiple senders, one receiver. Multicast as well as multiple
   senders unicast brings much difficulty e.g., in state merging and
   maintenance. However there are many cases when a session has one
   sender, one receiver. In this section a possible functionality set
   of the simplified RSVP for one sender, one receiver unicast is
   discussed.  We use the abbreviation "RSVPvs" in the following

   - The session identification in RSVPvs. In RSVPv1, a SCOPE object
   carries an explicit list of sender hosts, and (DestAddress,
   ProtocolID[, DstPort]) is used to identify a session. A fileterspec,
   together with the session information, defines the set of data
   packets to receive the QoS specified in a flowspec and is used to
   set parameters in the packet classifier function. In RSVPvs, there
   will be only one FF style for reservation, hence the sender address
   with a port number may be added in the session information; the
   omitted. Alternatively it is also possible to keep the same session
   identification and use the (FILTER_SPEC, session) pair to classify
   the packets belongs to a session.

   - Message processing. The simplification as above may apply to all
   messages in RSVPvs. As a result of the one-to-one feature of
   sessions, in RSVPvs there will be no necessity for FLOWSPEC merging
   (or change) - and later, complexity in the state maintenance - when
   a session is reserved (or torn down). Path messages are reduced to
   transmit SENDER_TSPEC (and optional ADSPEC to find the predicted e2e
   QoS) and Resv messages are still used to reserve resources but no
   FLOWSPEC merging is required. It is possible for RSVPvs to simplify
   the sender-initiated reservation: senders are usually not able to
   predict the end-to-end service, thus it is possible to use only a
   Resv message in the direction which he/she wish to send. In this
   case, a SENDER_TSPEC will be required to be carried in the Resv
   message. An even simpler possibility is, a Resv message initiated by
   either the sender or the receiver, carrying a SENDER_TSPEC, a
   FLOWSPEC, and optionally an ADSPEC, may be sufficient for the NSIS
   signaling, and reduces to a pure "one-pass" approach.

   - Application for RSVP aggregation and other extensions. In RFC
   3175, it is suggested that reservation state is per multicast
   session inside the aggregation region, and multicast flows
   heterogeneous reservations increase the difficulty in RSVP
   aggregation. For RSVP proxy [22] and various proposed mobility
   extensions [23], it is extremely difficult to manage multicast
   sessions which are not supported for many applications. In contrast,
   RSVPvs allows a uniform method for flow aggregation in the aggregate
   region as well as in processing in proxy scenarios; thus largely
   decreases the overhead for multicast sessions.

   Hancock et al.    Informational - Expires August 2002            50                 Towards a Framework for QoS Signaling    February 2002

 7.3  In-band QoS Signaling

   In some scenarios, it may be advantageous to include QoS related
   data within existing, non-QoS specific signaling messages such as
   routing signaling or mobility related signaling, or even within
   ordinary IP data packets.

   As an example, if we consider a situation where a mobile node is
   attached to an access network, when the mobile changes its point of
   attachment i.e. handsover, the routing in the network must be
   updated so that traffic is sent to the mobile's new location. At the
   same time, any QoS state stored along the old path must also be
   moved to the new path.  This process can be optimized by including
   QoS information about a mobile's traffic flows in the routing update
   messages, so that re-routing and resource allocation occur
   simultaneously. INSIGNIA [24] proposes such an in-band signaling
   approach that explicitly carries control information in the IP
   packet header (so-called INSIGNIA IP option). This approach allows
   one-pass check for the required resources along the path toward the
   destination node.

   A similar concept has been suggested for QoS support in Mobile Ipv6
   [25]. The basic idea is to define a new hop-by-hop header containing
   a so-called QoS object. The QoS object codes the QoS desired by a
   flow and is attached to the mobile IP Binding Update. Each node
   along the path reads the QoS object (acts as a QoS controller) and
   provides QoS accordingly, if it has the resources to do so. This
   way, QoS along the new path after handover is provided by one-pass
   signaling simultaneously with the Binding Update. The QoS Initiator
   may be either the end host, or the Access Router who received the
   information on QoS desired by the end host e.g. by a SEAMOBY
   mechanism, or the Correspondent Node who received a Binding
   Update. The drawback of this one-pass signaling is of course that
   the QoS Initiator doesn't receive any feedback on whether the QoS
   desired is at all available along the new path.

   This problem is solved in [26]. Here, the Binding Update is
   conditionalized upon receiving the QoS desired along the new path.
   If a router cannot provide adequate QoS it returns the Binding
   Update as invalid. Furthermore, the QoS object does not need to be
   read by every host, but could be obtained by the new access router
   from the old access router e.g., by way of Context-Transfer [27].

   Lightweight QoS signaling via QoS object has so far only been
   investigated for providing QoS after hand-off. Whether it is a
   viable option for QoS signaling in general needs further study, but
   the mechanism is flexible enough to operate in many different
   situations, not only those related to mobility scenarios.

   Hancock et al.    Informational - Expires August 2002            51                 Towards a Framework for QoS Signaling    February 2002

 8  Possible NSIS QoS Class Descriptors

   It may be possible to re-use existing QoS class descriptors for use
   as QoS signaling data options. Re-use of parameters provides
   simplified interworking with existing QoS mechanisms such as IntServ
   or COPS based networks, and also stops 're-invention of the wheel'
   with existing work taken as a starting point for any extensions.

   The following section provides a brief introduction to the possible
   descriptors that could be re-used in the framework, and a brief
   overview of where they might be useful. However, an in-depth
   analysis will need to be performed at a later stage.

   - DiffServ PHBs/PDBs: the per-hop behavior (PHB) is a description of
     the externally observable forwarding behavior of a DiffServ node
     applied to a particular DiffServ behavior aggregate [28].  The Per
     Domain Behavior (PDB) describes the behavior that should be
     experienced by a particular set of packets as they cross the
     DiffServ domain by specifying how the forwarding path components
     work together [29].  These cannot be used to accurately describe
     the application requirements end-to-end, but may prove useful for
     aggregation purposes both within a domain, and potentially between
     domains if the appropriate administrative relationship is in

   - UMTS bearer classes [30]: provides four distinct classes of
     parameter for different types of application traffic,
     conversational, streaming, interactive, and background.  These
     parameters are fairly abstract and could be re-used to provide
     end-to-end application requirement descriptions.

   - IntServ Tspec/Rspec [31, 32]: describes a traffic flow in terms of
     token bucket and other parameters such as the maximum datagram
     size and an indication of the desired service (controlled load or
     guaranteed service).  The parameters exchanged in the Tspec and
     Rspec have been the result of intensive analysis work. These
     parameters are used to configure the schedulers within the
     routers. The IntServ Tspec/Rspec is appropriate for QoS
     provisioning since it indicates parameters for router
     configuration, but may also be suitable for end-to-end if it is
     flexible enough to meet all requirements.

     Additions to IntServ parameters have been proposed in [2] to
     improve the operation of Integrated Services in environments with
     wireless links.

   Translation between domains using different QoS parameters can be
   provided by local 'stacking' of parameters, but these must be
   derived from a well defined and understood set of parameters that
   are transferred end-to-end. Since the QoS class descriptors are

   Hancock et al.    Informational - Expires August 2002            52                 Towards a Framework for QoS Signaling    February 2002

   primarily for end-to-end use, excessive flexibility and support for
   multiple options may lead to inter-operability problems.

 9  Security Considerations

   This section tries to identify and describe possible security issues
   related to a QoS framework. We would like to focus on the security
   issues of the QoS signaling protocol and not to concentrate too much
   on the protocols supporting the QoS signaling and provisioning for
   example COPS, AAA, LDAP etc. For a security architecture it is
   useful to distinguish between user-related security and network
   domain security. The first part of this section concentrates on the
   user-related security, whereby an end-node (i.e. a user) issues a
   quality of service request that first reaches the network at the
   first hop router. That is, this section deals with the first stage
   of the QoS signaling. The next section discusses network-to-network
   and intra-domain signaling security. This addresses the network
   domain security part of the security architecture. Finally, the last
   section addresses end-to-end signaling issues which are also user-
   security related but usually not addressed in the context of QoS
   signaling. We, however, think that it is worth investigating issues
   concerning end-to-end security within a QoS framework.

 9.1  End-Node to Network Signaling

   In order to authenticate to the network the user has to know (at
   least for the case of symmetric cryptography) to which entity he has
   to authenticate since he has to select the appropriate security
   association and the corresponding key. To support the generic
   roaming case there must be a way for the mobile node to learn the
   identity of this node. This can be the first hop router or another
   node in the network. If these two entities already share a security
   association, then an initial key management protocol was executed
   because manual key distribution is practically not feasible in a
   mobile environment. This established security association can be
   created using protocols like PANA or could be the result of a AAA
   protocol exchange that took place at the time the mobile node had to
   authenticate to the network. Since the mobile node is likely to be
   attached to a network different to his home network cross-realm
   authentication may very likely be required. However there is no need
   to solely create the QoS required security association with the help
   of a separate run of a key management protocol supporting cross-
   realm authentication. It is sufficient to derive the QoS required
   security association based on some available session key distributed
   by some other protocol. Hence the actual authentication and key
   distribution procedure executed with the visited network may already
   be finished at the time the QoS signaling is started. However, from
   this there is still the need to derive QoS related security
   association. Furthermore, it may be required to transfer the key to
   the appropriate entity in the network with which the security
   association is required. For the discovery of this entity several
   mechanisms could be used that are already used in other protocols.

   Hancock et al.    Informational - Expires August 2002            53                 Towards a Framework for QoS Signaling    February 2002

   The mobile node could learn this information via Router
   Advertisements, address the entity with an anycast address, the
   mobile node could retrieve information from a DNS server or query a
   DHCP server. Additionally service location protocols could be used.
   Note however that there is a strong need to execute this task
   securely and as fast as possible since a real-time service would
   suffer from performance degradation. The mechanism which results in
   the lowest latency is probably to pre-configure a particular entity
   within the network whose identity is already constructed in a
   deterministic way. The first-hop router would be an example for such
   a node since its IP address is supposed to be known to the mobile
   node. The Kerberos principal name could be derived from the IP
   address with a specific service prefix and the realm name would then
   be taken from the Router Advertisement. Instead of having a pre-
   shared security association of some kind it would be possible to
   make use of Kerberos to dynamically derive one. Kerberos has the
   main advantage that it obsoletes a separate, independent, previously
   executed key management protocol since the purpose of the ticket
   inside the AP_REQ request is to provide the session key to the other
   party and to provide authentication. Note that the authentication
   and the guarantee of freshness provided with the Kerberos
   Authenticator can also be replaced by some other mechanisms similar
   to those provided by the Integrity Object in RSVP. Usually the
   Kerberos message exchange required to request the session ticket for
   a particular principal is outside the scope of a QoS signaling
   protocol but may require several roundtrips because of a cross-realm
   authentication procedure. The total number of messages that need to
   be transmitted depend on the type of inter-realm navigation that is
   required to navigate from the home domain possibly via several
   intermediate domains to the visited domain. This "navigation"
   involves the request for cross-realm ticket granting tickets and the
   corresponding response. Note that PKCROSS allows reducing the number
   of round-trips for a cross-realm navigation and PKINIT allows a user
   to use public key based mechanisms to request the initial ticket
   granting ticket. PKINIT therefore also allows problems related to
   dictionary attacks to be defended. The usage of passwords and
   Kerberos has often caused concerns and some papers have been
   published to address these issues and how to prevent them.

   If we speak about authentication then we also have to answer the
   question of what identities to use for identification. For the QoS
   Initiator possible identification entities are the user, the host on
   which the user resides and an entire network as described in more
   detail in the next section. The type of identity used heavily
   depends on the authentication protocol. Different identifiers are
   used in Kerberos, AAA or as subject names inside certificates.
   Additionally to the identity used by the user a host identity (i.e.
   IP address) must be transmitted to the network and updated in case
   of a movement since the accounting rules and firewall filters at the
   edge of the network must reflect the fact that a particular user is
   allowed to transmit data traffic that receives the desired QoS
   treatment. Kerberos additionally complicates the authentication by

   Hancock et al.    Informational - Expires August 2002            54                 Towards a Framework for QoS Signaling    February 2002

   the fact that the mobile node needs to learn the principal name of a
   node for which he has to request the session ticket.

   There may also be a concern about the user identity confidentiality.
   Hence it might be favorable to use a temporal identity for
   subsequent sessions after a successful authentication. Note that the
   question of user identity confidentiality might raise other
   difficult questions that need to be answered. The initial
   authentication protocol must provide some means of identity
   protection which is not the case for current protocols like
   Kerberos, Radius, Diameter etc. If the underlying authentication
   protocol reveals the user identity then it might be difficult to
   provide some useful protection at the QoS signaling level.
   Furthermore it must be clear against whom these user identities need
   to be protected i.e. what threat scenarios are applicable. For a
   service provided at the visited network it might not be necessary to
   know the real name of the user issuing the QoS request - a pseudonym
   might be sufficient. The name must however provide enough
   information to find and associate the corresponding home realm with
   the user if traditional accounting with AAA protocols is used. Hence
   there is a strong relationship with accounting and payment at this
   point. Furthermore it might be necessary to protect the transmitted
   identity against eavesdropper on the link between the mobile node
   and for example the first hop router. These issues require a careful
   investigation since there are strong interdependencies with other
   protocols and hence this issue might be difficult to solve in

   To provide mutual authentication a second step has to be executed
   after the user is authenticated to the network. In most cases it is
   assumed that the initial key management protocol already provided
   enough evidence to authenticate both parties mutually against each
   other to prevent false base station like attacks. However note that
   care must be taken if such an assumption does not hold. The fact
   that most QoS signaling protocols use a message from the imitator to
   the network and vice versa allows the initiator to be assured that
   the other party knows the session key.

   The authorization step executed after a successful authentication of
   a QoS request may result in a token to be transmitted along the QoS
   signaling path within the same administrative domain to provide
   subsequent nodes with enough information to do admission control.
   The authorization step usually requires a router that receives a
   properly secured resource request to trigger other protocols to
   retrieve the desired information. Such a token may have already been
   handed over to the QoS initiator as part of a protocol executed
   preceding the QoS signaling (e.g. a SIP signaling protocol run) and
   used to provide a pointer to an already executed authorization step.

   The issue of public key based authentication of the mobile node to
   the visited network is somewhat more complex than the symmetric
   case. If we assume that accounting (and the payment of the consumed

   Hancock et al.    Informational - Expires August 2002            55                 Towards a Framework for QoS Signaling    February 2002

   resources) is the main goal of the authentication of the mobile node
   (i.e. of the user) then there must be a strong interrelationship
   between a payment protocol and the public key based authentication
   protocol. Otherwise it would be quite difficult to accomplish the
   accounting task. This requires some investigations for alternative
   means of access authentication and payment. The combination between
   a public key based authentication and the traditional AAA
   infrastructure may lead to the conclusion that two different
   authentication mechanisms are used together although a single one
   might be sufficient. Furthermore it should not be underestimated
   that public key based authentication involves substantially more
   computational operations than symmetric cryptography and then there
   are issues related to certificate path validation, certificate
   revocation, etc. This may imply that a digital signature used to
   protect every QoS signaling message might not be an advantage in the
   context of "lightweight" QoS signaling. If a digital signature is
   used with every QoS signaling message then denial of service attacks
   are more easy to launch since the verification of the signature
   requires more performance demanding cryptographic computations than
   the verification of keyed message digest.

   Public key based mechanisms may therefore be more interesting for
   initial key distribution (key transport or key agreement) where
   several roundtrips are more likely to be accepted. The resulting
   session key could then be used to protect subsequent QoS signaling
   messages. User identity confidentiality however can be solved more
   efficient using public key based techniques compared to symmetric
   alternatives. The question of discovering the identity to which the
   user or the user's host has to authenticate is also less difficult.

   The main threats that must be prevented in this context are the
   following. A malicious user must not be able to request resources on
   behalf of another user. We can prevent this threat by requiring
   every user to authenticate and to issue only authenticated,
   integrity and replay protected QoS signaling messages. A subsequent
   step of authorization ensures that each user can only request the
   amount of resource he is entitled to. This step is executed as part
   of the policy based admission control procedure. If every user
   requesting resources is authenticated and the request is properly
   integrity and replay protected then there is no danger of denial of
   service attacks against the access network whereby an
   (unauthenticated) adversary massively requests resources. Special
   cases during the reservation setup like the RSVP Killer Reservation
   are no security issue by itself. A different threat, which was
   previously mentioned, is related to user identity confidentiality
   whereby an adversary learns the user identity and the corresponding
   QoS request issued. It is an open point of discussion whether this
   threat should be addressed or not.

   If we assume a preceding authentication and key agreement phase
   before the QoS signaling is started then we have the following
   advantages. First, the user can easily authenticate himself using

   Hancock et al.    Informational - Expires August 2002            56                 Towards a Framework for QoS Signaling    February 2002

   various types of protocols including public key based protocols. It
   may therefore be possible to run any "administrative tasks" which
   may be more time-consuming in advance to the actual QoS signaling.
   Second, such an initial phase allows the network and the user to
   establish the required QoS security association. Furthermore the
   identities used within the initial authentication step may be
   different to those used during the QoS signaling. For the benefit of
   user identity confidentiality and shorter messages it would be
   beneficial to use a short identifier with local meaning (independent
   of the IP address of the user's host) to select security
   associations and to identity the registered user. These messages
   have typically lower time constraints and the message exchange may
   involve several roundtrips. Please note that such an initial
   authentication and key agreement phase does not necessarily need to
   be part of the QoS protocol and may also be optional.

 9.2  Network to Network

   As soon as the QoS signaling message is authenticated and the
   request is authorized a token may be added to allow subsequent
   routers participating in the QoS signaling to immediately have a
   possibility to point to the already established authorization state
   maintained at some nodes in the network. Note that this
   authorization token may already be obtained from a different
   protocol executed before the QoS signaling took place. This issue
   was already mentioned in the previous section.

   The QoS signaling messages then travel within the same
   administrative domain and experience hop-by-hop protection. Note
   that hop-by-hop protection does not necessarily mean that each node
   along the path needs to participate in the QoS signaling. Hop-by-hop
   security could also mean that the ingress router adds a security
   object and the egress router verifies this object and removes it and
   the nodes within the network may be transparent from the signaling
   point of view. There may also be the case that a different QoS
   mechanism is in place within the network and that a different
   security mechanism may be used to protect these signaling messages.
   Hop-by-hop security assumes a certain trust relationship between the
   entities within the core network whereby protection against outsider
   attacks and against nodes that do not participate in the QoS
   signaling itself is guaranteed.

   To provide fast processing of the messages within the core network
   the common security mechanism deployed for this purpose is a keyed
   message digest of the entire signaling message including a replay
   protection indicator (for example a sequence number). To provide
   protection against resynchronization failures countermeasures must
   be in place. Additionally it is required to consider the case of
   sequence number rollovers to provide rekeying in those cases.

   The key used to provide this hop-by-hop protection is often
   distributed with protocols different from the QoS protocol. Because

   Hancock et al.    Informational - Expires August 2002            57                 Towards a Framework for QoS Signaling    February 2002

   of the static nature of the network structure various means of
   distributing these security associations are possible. The
   possibilities range from manual distribution (for small networks) to
   network management protocols that allow automatic distribution to
   standard key management protocols. Note that a manually established
   QoS security association does obviously not allow rekeying. In
   larger networks public key based key management protocols may be
   used to allow more flexibility for the network provider. One
   important issue that has to be mentioned is that the key management
   protocols used must be able to create security associations that can
   be used with the QoS protocol. One possibility to secure a QoS
   protocol independent of the protocol itself is to provide protection
   with IPSec in a hop-by-hop manner. It must be noted that in such a
   case it is obvious that the processing for policy aware and policy
   ignorant nodes cannot be distinguished. Such a differentiation
   between nodes that are QoS aware but policy ignorant and other nodes
   that are QoS and policy aware cannot be accomplished at the network
   layer.  Furthermore there is little possibility for the application
   to recognize the existence of the underlying (for the application
   transparent) IPSec protection. Missing protection because of a
   misconfiguration can therefore not be recognized by the QoS
   signaling daemon.

   In order to select the correct security association it is necessary
   for the individual QoS aware network element (i.e. the network
   element actively participating in the QoS signaling) to know the
   next hop. Such information should also be available to the key
   management protocol and to the entities distributing the security

   From a threat scenario perspective it is obvious that the choice for
   a hop-by-hop security nature also implies that insider attacks
   cannot be prevented. Hence if an adversary is able to break the
   security of a router participating in the QoS signaling then there
   is no possibility to prevent this adversary from modifying the QoS
   signaling messages or from mounting denial of service attack against
   the network. But, anyway, if an adversary is able to break into a
   router, he has the possibility of mounting all types of DoS attacks,
   not only for QoS. He can just throw away some packets or change some
   headers or whatever. Such a threat can only be reduced by end-to-end
   security means whereby the end-to-end protection of QoS signaling
   message parts is limited to those objects that do not change in
   transit. Message parts that need to be modified hop-by-hop obviously
   cannot be protected end-to-end. From this point-of-view it would be
   appropriate to separate the message parts of the QoS signaling
   message into those that change during transit and others that remain
   unchanged (mutable and non-mutable message parts). More problematic
   is the case where the QoS signaling messages traverse networks where
   no security protection (hop-by-hop protection within the network) is
   applied at all and the hop-by-hop security principle is violated.
   Obviously, in such a case it is not possible to ensure appropriate
   protection. We assume that every network requires that QoS signaling

   Hancock et al.    Informational - Expires August 2002            58                 Towards a Framework for QoS Signaling    February 2002

   messages transmitted by users always receive the necessary security
   protection. The exact threat caused to the network depends on the
   QoS signaling protocol used and on the scenario in which such a
   signaling is used. QoS protocols with one roundtrip may have the
   advantage that the first message establishes some state information
   before the actual reservation takes place. It is therefore assumed
   that a reservation message that is transmitted without a preceding
   path message cannot result in fully successful end-to-end
   reservation. A more detailed threat analysis may however be required
   for a particular QoS signaling protocol.

   If the QoS message leaves one administrative domain and enters
   another then network-to-network authentication has to be executed.
   Note that the above description assumes that the QoS Initiator is
   the user and the subsequent QoS signaling messages traverse through
   the network. However QoS signaling can also be initiated by the
   network which has basically the same consequences for network-to-
   network and intra-domain signaling. Usually it is assumed that two
   domains already have service level agreements and have a trust
   relationship established. This initial trust relationship then
   allows a security association to be dynamically derived based on
   some pre-shared secret or an existing public key infrastructure.
   Since scalability issues are important and other QoS technologies
   may be used that do not provide fine-grained reservations on a flow
   level there is no notion of the user initially triggering the QoS
   request at this point of the signaling that issued the resource
   request. Hence admission control is executed based on policies
   shared between the different network service providers.

   Finally the QoS signaling message terminates at the destination and
   the last hop must also be secured. If we assume a previous initial
   authentication and key agreement step of the quality of service
   supporting end-device then this existing QoS security association
   can be used to protect the message at the last hop. If such a
   security association is not available then the corresponding key
   management protocol must be triggered to dynamically derive one. In
   case of Kerberos the reversed authentication from the network to the
   user - the so-called user-to-user authentication could be used. The
   Kerberos case however is especially difficult since the network (or
   some node within the network to be more precise) does not know the
   identity of the end-node and hence it is difficult to request a
   session ticket if the realm and the principal name is unknown. A DNS
   lookup to determine the Kerberos realm and principal name may be
   possible based on the mobile node's or the server's (home) IP
   address. Furthermore the network does not know which protocols are
   supported by the end-node (which may also be a mobile node) and
   hence such a task can be difficult.

 9.3  End-to-End

   Traditionally there is little support for end-to-end security at the
   QoS signaling level. However there are two reasons that might argue

   Hancock et al.    Informational - Expires August 2002            59                 Towards a Framework for QoS Signaling    February 2002

   for incorporating end-to-end security mechanisms into a QoS
   protocol. First QoS signaling messages contain parts that do not
   change during transit and are therefore subject to a possible end-
   to-end protection. This circumstance is already described in the
   previous section. Hence if a previous protocol already established
   an end-to-end security association then such a security association
   may be reused for protecting the QoS signaling messages end-to-end.
   The second issue tries to address the case where other protocols are
   not executed before the QoS signaling took place. In this case the
   QoS signaling could be reused to transport authentication and key
   agreement messages that are later used to provide protection of the
   end-to-end data communication subsequent to the QoS signaling. Some
   key management protocols have been proposed that try to establish a
   session key with a single roundtrip. These protocols use timestamps
   for replay protection. To provide independence against the
   underlying transport protocol the data of the key management
   protocol are embedded into SDP.

   Finally, there is the issue of the subsequent protection of data
   traffic between the two end-nodes along the pinned path. TLS and
   other higher layer security protocols are independent and unaffected
   of the underlying QoS established data path. But in case of network
   layer protection as achieved with IPSec the relevant filters need to
   be adjusted to be able to identify the encrypted data traffic
   accordingly. Whatever QoS protocols are used care must be taken to
   ensure to allow IPSec protected data traffic to be transmitted over
   the QoS established path.

 10 Resilience and Scalability Considerations

   Resilience and scalability considerations may influence the NSIS
   framework. Resilience usually implies that a network designer
   strives hard to avoid single points of failure. At the same time
   information needs to be replicated without impacts on performance.

 10.1 Resilience

   Resilience as considered in this draft deals with NSIS agent failure
   and the consequences for the QoS architecture. If QoS control
   components are located within the data path, when a node fails or
   the data path changes due to re-routing both the signaling and data
   paths are affected. Resilience can be achieved by redirection around
   the point of failure, using for example, constrained based routing
   schemes. However, any state information maintained by the failed
   node must be transferred to another node, or re-discovered. If the
   QoS enabled path, including the state information can be re-
   established in a considerably short time an application would
   experience service degradation only for a short time period.

   Resilience has also to be considered when NSIS agent resides off the
   data path. When there is a node failure or re-routing along the data
   path, there is no need to move state information since it still

   Hancock et al.    Informational - Expires August 2002            60                 Towards a Framework for QoS Signaling    February 2002

   resides in the same NSIS Agent.  However, if the NSIS Agent fails,
   then the signaling path and state information must be recovered.
   Redundancy is achieved if a substitute NSIS Agent can take over on
   demand. Usually in case of failure a smooth change over with
   traversal of all current state information is not possible. To
   minimize the loss of signaled state information NSIS Agents within
   the same network domain may periodically update each other with
   context information. A substitute NSIS Agent in action needs to be
   properly addressed to process upcoming resource requests. For this
   purpose the new NSIS Agent should advertise its presence to
   counterpart NSIS agents located in end terminals, adjacent network
   domains or any other locations in the Internet.

   Resilience issues are closely related to the location of state
   information within the network.  The locations where state
   information is required must be determined, and the more globally
   useful the state information is, the more state information will
   have to be maintained.

 10.2 Scalability

   In the NSIS framework critical criteria for scalability can be
   described by the amount of state information processing and by the
   signaling overhead that is fed into the network.

   The first issue deals with the signaling state information that has
   to be processed by the NSIS agent. This will rely strongly on a
   number of framework level decisions.  The following discussion aims
   to highlight the amount of state information that must be maintained
   for the different options highlighted for a number of open issues in
   the framework.

   *)Basic Signaling Paths

   The two options and their implications are as follows:
   -    Sender Initiated: no state information is maintained in NSIS
   -    Receiver Initiated: the 'previous' hop NSIS Agent address must
   be maintained to support correct routing of the message if the 'RSVP
   style' option is used.

   *)NSIS Signaling Protocols

   Identified the need for NSIS Agents to maintain information
   -    Peer NSIS Agents and authentication state and policy associated
   with them
   -    The next hop NSIS Agent associated with a particular flow or
   -    Timeout periods for reservations

   Hancock et al.    Informational - Expires August 2002            61                 Towards a Framework for QoS Signaling    February 2002

   *)NSIS Signaling Data

   Identified the need for NSIS agents to maintain state about:
   -    Identifying the flow or aggregate
   -    Scope identification for scoping parameters

   *)NSIS Aggregation Techniques

   Aggregation techniques can have a large impact on the amount of per-
   flow state information maintained within the NSIS Agents.

   An open issue here concerns whether a domain that is performing
   aggregation still needs to maintain per-flow state information.

   *)Support for Adaptive Applications
   Two options for providing feedback to applications were identified:
   -    Send feedback directly to the initiator:  this required the
   initiator ID to be maintained in the NSIS Agents
   -    Send feedback hop-by-hop back towards the initiator: the
   previous hop NSIS Agent address must be maintained.
   -    If admission control failed, and the application has indicated
   that it would like to be informed when resources become available,
   per-flow information and the initiator identity must be maintained.
   -    Threshold values for when the level of service provided
   requires that the application be informed via feedback messages

   Signaling overhead is less critical but influences the throughput of
   the network to some degree. The amount of signaling information is
   influenced by the scale of flow aggregation, the amount of signaled
   information per flow and the frequency of state information update.
   The NSIS framework provides a flexible approach for transporting
   signaling parameters. Though an NSIS protocol should allow the
   transportation of a variety of signaling parameters it should at the
   same time provide a flexible structure for carrying only signaling
   information that is actually required for a specific purpose. For
   example an NSIS signaling message chould carry MAC layer specific
   parameters like bit error ratio (BER) etc. only if the considered
   link layer is able to provide and process this information suitably.
   Defining a flexible protocol avoids the transportation of "empty"
   information fields significantly.

   Another issue is the frequency of information state update by
   refresh messages. High accuracy of resource allocation requires the
   frequent exchange of refresh messages, which on the other hand
   increases the amount of signaling overhead. While host to network
   refresh frequency are controlled by the terminals, domain internal
   frequency may be determined by ISP policies, e.g. terminal to
   network refreshing could be delayed by an NSIS agent at the network
   ingress before initiating a separate refresh message at a later
   time. Generally an NSIS agent could consider policies for variable
   definition of timer refreshing, but this is a matter for the

   Hancock et al.    Informational - Expires August 2002            62                 Towards a Framework for QoS Signaling    February 2002

   Two outstanding decisions concerning the framework also impact on
   signaling overhead:

   *)Basic Signaling Paths

   The two options and their implications on signaling overhead are as
   -    Sender Initiated: only one end-to-end transmission is required
   -    Receiver Initiated: additional round-trips may be required to
   determine the correct routing path.

   *)NSIS Signaling Data

   Identified two different approaches to exchanging parameters that do
   not have local scope:
   -    Parameter 'stacking': more information is carried by the
   signaling protocol, larger messages
   -    Separate signaling message: the signaling is lighter-weight,
   but more messages are required.

   There will be a trade-off between the information carried in the
   message as a parameter, and the amount of state information that is
   maintained at the NSIS Agent.

 11 Conclusion

   This document has presented a framework for further discussion of
   the requirements and possible implementation architectures of NSIS.
   We believe that this framework can be developed into the skeleton of
   a more concrete solution, that meets most if not all of the
   requirements that were identified in [1].

   It has been a major goal of the framework to be modular, so that it
   can support a wide range of features without forcing their use
   everywhere - lightweight but widely applicable. We believe that this
   approach is important for the success of NSIS, since a QoS solution
   that is optimised for only a single subset of the Internet will
   never gain the wide acceptance it needs to acquire the 'critical
   mass' necessary for pervasive deployment of QoS. Some of these
   modular capabilities are listed here:
   1. Use of bi-directional reservations is a local issue (section
      3.4.3). Outside the path segments subject to the bidirectional
      reservation, the rest of the network does not need to know that
      bidirectional reservations are being used.
   2. Multipart reservations could likewise be handled as a local
   3. Proxy use (3.7.1 and 5.1) is similarly a local issue. The proxy
      simply hides the QoS initiator identification with its own; other
      parts of the network can ignore the fact that the proxy is not
      the real initiator.

   Hancock et al.    Informational - Expires August 2002            63                 Towards a Framework for QoS Signaling    February 2002

   4. Registration details are optional and can depend on the local
      environment, and the actual QoS reservation signaling can be made
      lightweight as a result.
   5. The framework emphasises the use of different signaling protocols
      and QoS provisioning techniques.
   6. Parameters can be scoped to allow local and inter-domain
      parameters to be transported, and the signaling protocol is not
      affected by their inclusion. QoS controllers are allowed to
      ignore all parameters that are out of their scope, and it should
      be trivial to organise packet formats to make this filtering a
      simple process.
   Many other aspects of the modularity requirement would be refined
   given a more detailed analysis of the QoS signaling data formats
   themselves. This would be a second stage of refinement of the

   In developing the framework, we have discovered a number of open
   issues about the right way to proceed in more detail. Several of
   these are related to the detailed interpretation of particular
   requirements, while others are related to design tradeoffs between
   flexibility, complexity, and applicability. To resolve these issues,
   and to further validate the framework as it stands, a mapping of the
   scenarios of [1] onto the framework would be very beneficial in
   enabling a detailed comparison to be done.

    1.   Should we have a defined set of hierarchical levels in the
         framework, or allow arbitrary nesting? (For example, is there
         a well defined level of 'edges' in the Internet, or can there
         be edges within edges?)
    2.   Should receiver initiated reservations be propagated from the
         receiver against the traffic flow direction (requires reverse
         path forwarding state at all intermediate agents) or reflected
         via the sender (requires the QoS request to indicate 'I am
         sending you packets which you wanted'.)
    3.   As a related point, should bi-directional reservations be
         treated as a special case mainly to support proxy NSIS agents,
         or as an add on to standard reservations but requiring RSVP
         style receiver oriented reservations?
    4.   At what level does any multicast QoS framework need to be
         integrated with a unicast framework? Are common signaling
         protocols useful or necessary? Is a common set of traffic
         classes useful or necessary?
    5.   Is there any value in integrating QoS provisioning protocols
         (router remote control) into the NSIS framework, as discussed
         in section 5.4? Do they interact with each other?
    6.   Does the NSIS signaling security between the endpoints
         interact with any assumptions about how the application layers
         have associated with each other? Is security between the end
         hosts required at the NSIS level at all, or can all the
         necessary protection be propagated downwards from the higher
         (application) layers.

   Hancock et al.    Informational - Expires August 2002            64                 Towards a Framework for QoS Signaling    February 2002

    7.   Is it appropriate to assume that security associations to
         protect the signaling protocol itself are already available?
         If so, how are they hooked into the signaling protocol itself
         (since each end has to agree to use the same security
         association). If not, what is the overhead of developing an
         NSIS security protocol?
    8.   Is there a need to protect non-mutable message parts end-to-
         end in addition to the hop-by-hop security protection? Is
         there anyone that argues against the assumptions raised with
         hop-by-hop security?
    9.   Are public key based mechanisms appropriate for the protection
         of a lightweight signaling protocol? Please note that the
         answers might be different between the initial authentication
         and key agreement phase and the subsequent protection of
         signaling messages.
    10.  Are there further interrelationships between the signaling
         protocol and the process of accounting?
    11.  Which identity should be used for the purpose of
         authentication? Is it enough to have the user authenticate to
         the network or should also the host identity be involved?
    12.  Should end-to-end security mechanisms receive further
         investigation with a QoS signaling protocol?
    13.  Is user identity confidentiality a concern that needs to be
         addressed? In the scenarios where it is, can the proxy
         concepts of section 3.7.1 always be applied?
    14.  How does Path Capability Discovery operate? Are capabilities
         discovered locally or cumulatively, and on a hop-by-hop or
         end-to├Żend basis.
    15.  Do we need to support aggregate policy information, e.g.
         indicating between domains how one domain would like it's
         aggregate traffic to be treated, and if so, what does the
         policy information consist of?
    16.  How is the feedback of QoS violations and resource
         availability supported, and how does it interact with
         aggregate flows?
    17.  How do we address the issue of end-to-end QoS class
         descriptors to maintain flexibility but also avoid inter-
         operability problems?
    18.  Should the agent maintain total resource usage and request
         information, or should this be maintained by the local
         provisioning function? (May have implications for NSIS
         management, e.g. MIB design.)

   Hancock et al.    Informational - Expires August 2002            65                 Towards a Framework for QoS Signaling    February 2002

 12 References

   1 Brunner, M. (ed.), "Requirements for QoS Signaling Protocols",
      draft-ietf-nsis-req-00.txt, Work in Progress, February 2002
   2 Fodor G., Persson F., Williams B., "Proposal on new service
      parameters (wireless hints) on the controlled load integrated
      service", draft-fodor-intserv-wireless-params-01, January 2002
   3 Katz, D, " IP Router Alert Option", RFC 2113, February 1997
   4 W. Marshall, K. Ramakrishnan , E. Miller, G. Russell, B. Beser, M.
      Mannette, K. Steinbrenner, D. Oran, F. Andreasen, M. Ramalho, J.
      Pickens, P. Lalwaney, J. Fellows, D. Evans, K. Kelly, A. Roach, J.
      Rosenberg, D. Willis, S. Donovan and H. Schulzrinne, "Integration
      of Resource Management and SIP", draft-ietf-sip-manyfolks-
      resource-03.txt, work in progress, November 2001
   5 Baker F., Iturralde C., Le Faucheur F., Davie B., " Aggregation of
      RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001
   6 Bernet, Y. et al, "A Framework for Integrated Services Operation
      over Diffserv Networks", RFC 2998, November 2000
   7 Hain, T. "Architectural Implications of NAT", RFC 2993, November
   8 Egevang, K, Francis, P, "The IP Network Address Translator (NAT)",
      RFC 1631, May 1994
   9 Nordmark, E. "Stateless IP/ICMP Translation Algorithm (SIIT)",
      RFC2765, February 2000
   10 Johnson, D. B, Perkins, C, "Mobility Support in IPv6", draft-
      ietf-mobileip-ipv6-15.txt, Work in Progress, July 2001
   11 Moskowitz, R. "Host Identity Payload And Protocol", draft-
      moskowitz-hip-05.txt, Work in Progress, November 2001
   12 D. Mitzel "Overview of 2000 IAB Wireless Internetworking
      Workshop" RFC 3002, December 2000
   13 L. Westberg "Resource Management in Diffserv (RMD) Framework",
      draft-westberg-rmd-framework-01.txt, Work in Progress, February
   14 V. Jacobson, "An Expedited Forwarding PHB", RFC 2598, June 1999
   15 J. Heinanen, "Assured Forwarding PHB Group", RFC 2597, June 1999
   16 L. Westberg "Resource Management in Diffserv On DemAnd (RODA)
      PHR", draft-westberg-rmd-od-phr-01.txt, Work in Progress, February
   17 Braden, B., Ed., et. al., "Resource Reservation Protocol (RSVP) -
      Version 1 Functional Specification", RFC 2205, September 1997
   18 Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP
      Operation Over IP Tunnels", RFC 2746, January 2000
   19 S. Herzog (ed), et al, "COPS usage for RSVP", RFC 2749, January
   20 Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
      November 2000
   21 C. Q. Shen et al. "An Interoperation Framework for Using RSVP in
      Mobile IPv6 Neworks", draft-shen-rsvp-mobileipv6-inerop-00.txt,
      Work in Progress, July 2001

   Hancock et al.    Informational - Expires August 2002            66                 Towards a Framework for QoS Signaling    February 2002

   22 Silvano Gai, Dinesh G Dutt, Nitsan Elfassy, Yoram Bernet, "RSVP
      Proxy", draft-ietf-rsvp-proxy-02.txt, Work in Progress, July 2001
   23 S. Paskalis et al., "RSVP Mobility Proxy", draft-paskalis-rsvpmp-
      00.txt, Work in Progress, December 2001
   24 The INSIGNIA Project,
   25 Hemant Chaskar, Rajeev Koodli, "A Framework for QoS Support in
      Mobile IPv6", draft-chaskar-mobileip-qos-01.txt, work in progress,
      March 2001
   26 X. Fu, H. Karl, et al, "QoS-Conditionalized Binding Update in
      Mobile IPv6", draft-tkn-nsis-qosbinding-mipv6-00.txt, work in
      progress, January 2002
   27 Hamid Syed, et al, "General Requirements for Context Transfer",
      draft-ietf-seamoby-ct-reqs-03.txt, work in progress, January 2002
   28 Blake S., Black D., Carlson M., Davies E., Wang Z., Weiss W., "An
      Architecture for Differentiated Services", RFC 2475, December 1998
   29 Nichols K., Carpenter B., "Definition of Differentiated Services
      for Per Domain Behaviors and Rules for their Specification", RFC
      3086, April 2001
   30 3GPP, "QoS Concept and Architecture", TS23.107 v5.3.0, January
   31 Shenker S., Partridge C., Guerin R., "Specification of Guaranteed
      Quality of Service", RFC 2212, September 1997
   32 Wroclawski J., "Specification of the Controlled-Load Network
      Element Service", RFC 2211, September 1997

 13 Acknowledgments

   During the writing of this draft, we have benefited from insightful
   and detailed discussions with many of our colleagues and co-workers
   in the challenging areas of Internet QoS. In no particular order, we
   should mention Dirk Kroeselberg, Wolfgang Buecker, Mark West,
   Richard Price, Changpeng Fan, Jukka Manner, Louise Burness, Alberto
   Lopez. We also specially acknowledge Georgios Karigiannis for his
   stimulating contributions on hierarchical reservation set-up on the
   NSIS mailing list.

 14 Author's Addresses

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

   Cornelia Kappler
   Siemens AG
   Berlin  13623

   Hancock et al.    Informational - Expires August 2002            67                 Towards a Framework for QoS Signaling    February 2002

   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munchen

   Jorge R Cuellar
   Siemens AG
   Otto-Hahn Ring 6
   81730 Munich

   Jochen Eisl
   Siemens AG
   Hofmannstr. 51
   81359 Muenchen

   Mehmet Ersue
   Siemens AG
   Hofmannstr. 51
   81359 Munich

   Xiaoming Fu, Holger Karl
   Technical University Berlin
   Sekr. FT 5-2, Einsteinufer 25
   Berlin  10587
   E-Mail: [fu|karl]

   Marcus Brunner
   NEC Europe Ltd.
   Network Laboratories
   Adenauerplatz 6
   D-69115 Heidelberg

   Andreas Kassler
   Dept. Distributed Systems
   University of Ulm
   Oberer Eselsberg
   89069 Ulm

   Hancock et al.    Informational - Expires August 2002            68                 Towards a Framework for QoS Signaling    February 2002

Appendix A. Mapping to Requirements

   The following section examines the requirements outlined in [1] and
   verifies that the framework can support the requirement and explains
   how it does so. The numbering of the requirements is taken directly
   from [1].

   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 Avoid duplication of [sub]domain signaling functions
   5.1.7 Avoid modularity with large overhead (in various dimensions)
   5.1.8 Option to use the protocol for existing local technologies
   5.1.9 Independence of signaling and provisioning paradigm
   Requirement | Supported by Framework
   5.1.1       | General feature of framework, examples of how
               | QoS technologies can be used within the framework are
               | provided in sections 5.4 and 6.
   5.1.2       | Supported by the Path Capability Discovery aspects of
               | the QoS Signaling Protocol (section 4.3)
   5.1.2       | General feature of the framework, examples of this are
               | provided in sections 1 and 11
   5.1.4       | The NSIS Signaling Data (section 4.4) is independent
               | of the NSIS Signaling Protocol used in any particular
               | domain
   5.1.5       | Many types of different QoS provisioning techniques
               | can be fitted within the framework as illustrated in
               | sections 4.2 and 5.4
   5.1.6       | This must be considered in context of a more detailed
               | description of the QoS provisioning mechanisms and how
               | link layer aspects are managed here
   5.1.7       | Framework tries to achieve this in a number of ways,
               | see section 11
   5.1.8       | This is supported by the framework, see section 5.4
   5.1.9       | Fundamental characteristic of the framework to
               | separate signaling from actual QoS provisioning

   Hancock et al.    Informational - Expires August 2002            69                 Towards a Framework for QoS Signaling    February 2002

   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
   5.2.5  Deal with IP fragmentation gracefully
   Requirement | Supported by Framework
   5.2.1       | The framework makes no assumptions about the location
               | of the NSIS Agents
   5.2.2       | NSIS Agents can be on or off the signaling path
   5.2.3       | Can be achieved using NSIS proxy agents and is also a
               | side effect of aggregation
   5.2.4       | The QoS signaling protocol supports the transparent
               | transport of parameters either by parameter 'stacking'
               | or by initiating multiple signaling flows (section
               | 4.4)
   5.2.4       | This is an open issue related to possible packet
               | classification rules. It cannot be solved purely
               | as a signaling issue

   5.3  Additional information beyond signaling of QoS information

   5.3.1  Explicit release of resources
   5.3.2  Ability to signal life-time of a reservation
   5.3.3  Possibility for automatic release of resources after failure
   5.3.4  Possibility for automatic re-setup of resources after
   5.3.5  Prompt notification of QoS violation in case of error /
   failure to QoS Initiator and QoS Controllers
   5.3.6  Feedback about the actually received level of QoS guarantees
   5.3.7  Automatic notification on available resources not been
   granted before

   Hancock et al.    Informational - Expires August 2002            70                 Towards a Framework for QoS Signaling    February 2002

   Requirement | Supported by Framework
   5.3.1       | This is an attribute of the NSIS Signaling Protocol
   5.3.2       | This can be included in the NSIS Signaling Data
   5.3.3       | Something can be implemented by the NSIS agent to
               | support this provided the signaling protocol enables
               | failure detection
   5.3.4       | see 5.3.3
   5.3.5       | Supported by NSIS signaling feedback mechanism (
               | section 5.7)
   5.3.6       | Supported as part of the NSIS Signaling reservation
               | mechanism
   5.3.7       | This could be implemented given an asynchronous
               | signaling protocol and the appropriate monitoring
               | functionality within the QoS controller with support
               | from the provisioning mechanism

   5.4  Layering

   5.4.1  The signaling protocol and QoS control information should be
   application independent.
   Requirement | Supported by Framework
   5.4.1       | The framework makes no assumptions regarding
               | applications, and includes support for the opaque
               | transport of application information (section 4.4).

   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  Simple mapping to lower-layer QoS provisioning parameters
   5.5.4  Aggregation method specification
   5.5.5  Multiple levels of detail
   5.5.6  Ranges in specification
   5.5.7  Independence of reservation identifier
   5.5.8  Seamless modification of already reserved QoS
   5.5.9  Signaling must support quantitative, qualitative, and
   relative QoS specifications
   5.5.10  QoS conformance specification

   Hancock et al.    Informational - Expires August 2002            71                 Towards a Framework for QoS Signaling    February 2002

   Requirement | Supported by Framework
   5.5.1       | End-to-end parameters are transported unchanged end-to
               | -end, but domain specific parameters can also be
               | signaled (section 4.4)
   5.5.2       | Supported by either parameter 'stacking' or by
               | initiating separate signaling message (section 4.4)
   5.5.3       | Assumed to be a function of technology specific
               | convergence sublayer (inter provisioning) and is
               | dependent on the complexity of the QoS parameters (see
               | section 8)
   5.5.4       | Any NSIS Agent is capable of inserting aggregation
               | parameters into the NSIS Signaling messages (section
               | 4.4)
   5.5.5       | see 5.5.2
   5.5.5       | Will be supported as part of the QoS descriptor
               | activities, transport of which is supported by the
               | framework.
   5.5.7       | see 5.5.5
   5.5.8       | NSIS signaling messages can be generated at any time
               | to support service re-negotiation
   5.5.9       | see 5.5.5
   5.5.10      | see 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
   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
   5.6.7  Low bandwidth consumption

   Hancock et al.    Informational - Expires August 2002            72                 Towards a Framework for QoS Signaling    February 2002

   Requirement | Supported by Framework
   5.6.1       | Number of messages depends on some high level
               | framework decisions (section X)
   5.6.2       | This depends on the detailed protocol design. The
               | protocol design can be optimized for the environment
               | for which this type of scalability is needed.
   5.6.3       | see 5.6.2
   5.6.4       | Amount of state maintained depends on some high level
               | framework decisions (section X)
   5.6.5       | see 5.6.2
   5.6.6       | see 5.6.2
   5.6.7       | see 5.6.2

   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
   5.7.4  Uni / bi-directional reservation
   Requirement | Supported by Framework
   5.7.1       | Supported by aggregation parameters carried by
               | NSIS Signaling Protocol
   5.7.2       | Framework makes no assumption about the location of
               | NSIS Agents
   5.7.3       | Framework supports the asynchronous generation of
               | signaling messages to support re-negotiation
   5.7.4       | Both can be supported by the framework (section 3.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
   5.8.3  The QoS signaling messages must provide integrity protection.
   5.8.4  The QoS signaling messages must be replay protected.

   Hancock et al.    Informational - Expires August 2002            73                 Towards a Framework for QoS Signaling    February 2002

   5.8.5  The QoS signaling protocol must allow for hop-by-hop
   5.8.6  The QoS protocol should allow identity confidentiality and
   location privacy.
   5.8.7  The QoS protocol must prevent denial-of-service attacks
   against signaling entities.
   5.8.8  The QoS protocol may support confidentiality of signaling
   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

   All of these requirements are already allocation to either the
   protocol or signaling data components of the framework.  More
   detailed analysis of these requirements should therefore be carried
   out in the context of particular selected signaling protocols or
   concrete definitions of the signaling data format.

   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  Combination with Mobility management
   5.10.4  Independence from charging model
   5.10.5  The QoS protocol should provide hooks for AAA protocols
   Requirement | Supported by Framework
   5.10.1      | This is an issue concerning the NSIS Signaling
               | protocol choice
   5.10.2      | No assumption concerning the IP version is made.
               | Addressing issues of highlighted in section 5.6
   5.10.3      | Framework does not preclude in-band signaling or
               | other such optimizations (section 7.3)
   5.10.4      | NSIS supports charging and accounting functions by
               | allowing the exchange of pertinent information, but
               | does not assume any charging models (section 3.5)
   5.10.5      | This is an issue concerning the NSIS Signaling
               | protocol choice

   Hancock et al.    Informational - Expires August 2002            74