Robert Hancock
   Internet Draft                                       Eleanor Hepworth
   Document: draft-hancock-nsis-framework-00.txt      Siemens/Roke Manor
                                                                Research
   Expires: August 2002 
                                                        Cornelia Kappler
                                                       Hannes Tschofenig
                                                             Jochen Eisl
                                                           Jorge Cuellar
                                                            Mehmet Ersue
                                                              Siemens AG
    
                                                             Xiaoming Fu
                                                             Holger Karl
                                                               TU Berlin
    
                                                          Marcus Brunner
                                                                     NEC
    
                                                         Andreas Kassler
                                                       University of Ulm
    
                                                       February 22, 2002
 
 
           Towards a Framework for QoS Signaling in the Internet 
                   <draft-hancock-nsis-framework-00.txt> 
 
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance 
   with all provisions of Section 10 of RFC2026. 
    
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
     
   Hancock et al.    Informational - Expires August 2002             1                 Towards a Framework for QoS Signaling    February 2002 
    
    
Abstract 
 
   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 
   Signaling.........................................................35 
   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 
   nodes. 
    
   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-
   fold: 
   *) 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 
   operation. 
    
   '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 
   draft. 
   - 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 
   included. 
   - 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 
   highlighted. 
   - Section 5 discusses various generic scenarios to illustrate the 
   use of the functions and definitions described in the previous 
   sections.  
   - 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 
   protocol. 
   - 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 
     aggregate. 
                           
   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 .                                 
                             Provisioning                               
                               (local or                                
                                remote)                                 
                                .     .                                 
                                +     +                                 
                                 \   /                                  
                                  \ /                                   
                                   v                                    
                        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 
     timeouts. 
   -     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 
   follows: 
   -     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 
   signaling. 
    
                           
   Hancock et al.    Informational - Expires August 2002            16                 Towards a Framework for QoS Signaling    February 2002 
    
    
    
                            +--------------------------+ 
                            |   Administrative Domain  | 
   +----+    flow path     +-+                        +-+ 
   |Host|==================|R|========================|R|==========++ 
   +----+            /     +-+                        +-+          || 
         \          /       | \                      / |           || 
          \ +----+ /        |  \+----+        +----+/  |           || 
           \|QoS |/         |   |QoS |        |QoS |   |           || 
            |init|          |   |cont|        |cont|   |           || 
            +----+          |   +----+        +----+   |           || 
                            |      ^            ^      |           || 
                            |      |            |      |           || 
                            |      V            V      |           || 
   +-+                      |   +------------------+   |           || 
   |R| = Edge router        |   |QoS administration|   |           || 
   +-+                      |   |    functions     |   |           || 
                            |   +------------------+   |           || 
                            +--------------------------+           || 
                                                                   || 
                   +-----------------------------------------+     || 
                   |           +--------------------+        |     || 
                   |     +-----|   QoS controller   |--+     |     || 
                   |    /      +--------------------+   \    |     || 
                   |   /                                 \   |     || 
                   |  /     +--------------------------+  \  |     || 
                   | /      |      QoS Subdomain       |   \ |     || 
    +----+        +-+      +-+                        +-+   +-+    || 
    |Host|========|R|======|R|************************|R|===|R|====++ 
    +----+        +-+      +-+     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 
   changes. 
   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 
   5.1. 
    
   Therefore, again, a choice between the two methods requires further 
   analysis of the critical scenarios and the tradeoffs between the two 
   methods. 
 
 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 
   procedure. 
    
   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 
   setup.  
    
                           
   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 
   5.1. 
    
 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 
   RSVP. 
    
   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 
   system.  
    
   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 
   parameters. 
    
   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 
   resources. 
    
 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 
   mechanisms. 
    
   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 
   approach: 
    
   1. 'Registration' phase - discovery, authentication, overall policy 
      aspects and so on. 
   2. 'Reservation' phase - any signaling associated with a single 
      flow. 
    
   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 
     domain.  
    
   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' 
   scope. 
    
   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 
          domain. 
    
        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 | 
   |Controller| 
   +----------+ 
        |   +------------+                 +------------+ 
        |   |+----------+|   +----------+  |+----------+|  +----------+ 
        +--->|   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 
   messages. 
    
   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 
      Signaling 
    
   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 
   controller.   
 
 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 
   4.4) 
    
 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       | | 
   |Initiator|-->|Controller|--|---------------------->|Controller|--> 
   +---------+  |+----------+  |   |                  |+----------+ | 
                |              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-
   fold. 
    
   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 
   case. 
    
   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 
   maintained. 
    
 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 
   Initiator. 
    
   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 
     Agents. 
    
   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 
   assumed. 
        
   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 
   customers.   
        
 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 
   balancing. 
    
   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 
   framework. 
    
   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 
   results. 
    
   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 
   handoff). 
                           
   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 
   discussion. 
    
   - 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 
   SENDER_TEMPLATE, FILTER_SPEC, STYLE and SCOPE objects can be 
   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 
     place. 
    
   - 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 
   general.  
    
   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 
   associations.  
    
   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 
   Agents 
   -    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 
   regarding: 
   -    Peer NSIS Agents and authentication state and policy associated 
   with them 
   -    The next hop NSIS Agent associated with a particular flow or 
   aggregate 
   -    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 
   protocol. 
                           
   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 
   follows: 
   -    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 
      matter. 
   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 
   networks. 
    
   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 
      2000 
   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 
      2002 
   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 
      2002 
   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 
      2000 
   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, http://www.comet.columbia.edu/insignia/ 
   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 
      2002 
   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]@roke.co.uk 
    
   Cornelia Kappler 
   Siemens AG 
   Berlin  13623 
   Germany 
   E-Mail: cornelia.kappler@icn.siemens.de 
                           
   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 
   Germany 
   E-mail: Hannes.Tschofenig@mchp.siemens.de 
    
   Jorge R Cuellar 
   Siemens AG 
   Otto-Hahn Ring 6                             
   81730 Munich                    
   Germany 
   E-mail:  jorge.cuellar@mchp.siemens.de 
    
   Jochen Eisl 
   Siemens AG 
   Hofmannstr. 51 
   81359 Muenchen 
   Germany 
   E-Mail: jochen.eisl@icn.siemens.de 
    
   Mehmet Ersue  
   Siemens AG  
   Hofmannstr. 51                               
   81359 Munich                      
   Email:  Mehmet.Ersue@icn.siemens.de  
    
   Xiaoming Fu, Holger Karl 
   Technical University Berlin 
   Sekr. FT 5-2, Einsteinufer 25 
   Berlin  10587 
   Germany 
   E-Mail: [fu|karl]@ee.tu-berlin.de 
    
   Marcus Brunner 
   NEC Europe Ltd. 
   Network Laboratories 
   Adenauerplatz 6 
   D-69115 Heidelberg 
   Germany 
   E-Mail: brunner@ccrle.nec.de 
 
   Andreas Kassler 
   Dept. Distributed Systems 
   University of Ulm 
   Oberer Eselsberg 
   89069 Ulm 
   Germany 
   E-Mail: kassler@informatik.uni-ulm.de 
 
                           
   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 
   recovery 
   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 
   reservation 
   5.6.4  Scalability in the number of state per entity (QoS initiators 
   and QoS controllers) 
   5.6.5  Scalability in CPU use (end terminal and intermediate nodes) 
   5.6.6  Low latency 
   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 
   requests) 
   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 
   requests 
   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 
   security. 
   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 
   messages. 
   5.8.9  The QoS protocol should provide hooks to interact with 
   protocols that allow the negotiation of authentication and key 
   management protocols. 
   5.8.10  The QoS protocol should provide means to interact with key 
   management protocols 
    
   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