Internet DRAFT - draft-hancock-nsis-fw-outline

draft-hancock-nsis-fw-outline




    
   Internet Draft                                        Robert Hancock
                                                       Eleanor Hepworth
   Document: draft-hancock-nsis-fw-outline-00.txt          Siemens/Roke
                                                         Manor Research
   Expires: November 2002                                      May 2002
    
    
             An Outline Framework for QoS Signalling Protocols 
    
    
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].  
    
   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. 
 
Abstract 
    
   The Next-Steps-in-Signalling (NSIS) working group of the IETF is 
   considering the requirements for QoS signalling protocols [2]. One 
   element of this, and follow up work, is to develop a framework within 
   which existing and proposed protocols can be analysed, and which 
   captures how QoS signalling protocols should interact, both with each 
   other and with other components of the Internet, such as routing 
   protocols or AAA mechanisms. Because of this aspect of interactions, 
   the scope of an NSIS framework is necessarily broader than the scope 
   of any new NSIS protocol. 
    
   Previous work suggests that a complete QoS signalling framework is a 
   major undertaking. This Internet Draft outlines the principal 
   components of such a framework and their interrelationships. It could 
   be used as a starting point for more detailed investigation of 
   individual components. It could also be used to refine the scope of 
   NSIS more precisely, both in terms of what functions are to be 
   considered and how many variant approaches are relevant. 
 
 
                 Outline Framework for QoS Signalling         May 2002  
 
    
    
Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC-2119 [3]. 
    
Table of Contents 
    
   1. Introduction...................................................3 
      1.1 Purpose....................................................3 
      1.2 Scope......................................................3 
      1.3 Structure..................................................4 
   2. Overall Framework Structure....................................4 
      2.1 Signalling Entities........................................4 
      2.2 Protocol Locality..........................................5 
      2.3 Protocol Function Split....................................5 
   3. Basic Protocol Components......................................6 
      3.1 QoS (Service) Descriptors..................................6 
      3.2 Flow Description...........................................7 
      3.3 NSIS Control Information...................................7 
      3.4 Protocol Transport.........................................7 
   4. Non Local Aspects..............................................8 
      4.1 Application Layer Interactions.............................8 
      4.2 End-to-End Paths...........................................8 
      4.3 Extensions.................................................9 
   5. Inter-Layer and Inter-Protocol Interactions....................9 
      5.1 Resource Management........................................9 
      5.2 AAA Interactions..........................................10 
      5.3 Routing...................................................11 
      5.3.1 Signalling and Data Paths ..............................11 
      5.3.2 Route Change and Mobility (Handover) Support ...........11 
      5.3.3 Access Router Selection and Handover ...................12 
   6. Additional Analysis Areas.....................................12 
      6.1 State Information Storage.................................12 
      6.2 Scalability...............................................13 
      6.3 Resilience................................................13 
      6.4 Interworking..............................................13 
      6.5 Security Considerations...................................13 
   References.......................................................14 
   Acknowledgments..................................................14 
   Author's Addresses...............................................14 
    
    



 
 
Hancock et al.         Expires - November 2002                [Page 2] 
                 Outline Framework for QoS Signalling         May 2002  
 
1. Introduction 
    
   This document provides an outline framework for the discussion, 
   analysis and design of QoS signalling protocols for the Internet. 
    
   Previous work [4] indicates that a framework document that covers all 
   the issues of QoS signalling in all network scenarios can rapidly 
   become large and hard to manage. On the other hand, if parts of the 
   QoS problem are considered only in isolation  there is a danger that 
   interactions and implications are missed. This i-d provides an 
   overview of what an NSIS framework could (or should) consider. Any of 
   the sections (or subsections) of this document could be dramatically 
   expanded. 
    
1.1 Purpose 
    
   We think an overall NSIS framework would have a 5-fold purpose: 
     1. Enable refinement of requirements where this has to be done by 
        consideration of some concrete proposal (e.g. a security threat 
        analysis is easier in the context of some sort of framework). 
     2. Enable refinement of the scope of the NSIS itself. 
     3. Enable analysis of existing solutions ("does protocol X fit to 
        the function which is required to do Y?"). 
     4. Enable more detailed analysis of particular parts of the problem 
        in (relative) isolation, while capturing interactions with other 
        protocols (and indeed working groups). 
     5. Capture some basic assumptions about how NSIS protocol(s) should 
        be structured. 
    
   Obviously these goals are not all comparable, and relate to different 
   stages of the overall process. The tension between modelling existing 
   protocols and designing new ones may pull the framework activity in 
   different directions. 
    
1.2 Scope 
 
   Some things are assumed excluded from the NSIS framework activity. 
   Firstly, we are not considering an overall QoS framework: we only 
   consider that NSIS interacts with other functions at the protocol 
   endpoints, we don't consider in detail how these other functions 
   should be implemented in the network (unless this has some impact 
   back on the QoS signalling itself). Also, support for multicast is 
   not considered, nor are specifics of particular network scenarios. 
    
   However, because the NSIS problem includes these interactions and 
   also interworking with existing QoS signalling protocols, the scope 
   of consideration is necessarily broader than given by the NSIS 

 
 
Hancock et al.         Expires - November 2002                [Page 3] 
                 Outline Framework for QoS Signalling         May 2002  
 
   requirements themselves. This i-d does not modify those requirements; 
   it should eventually be validated against them. 
    
   Ideally the framework should define common terminology (eventually). 
    
1.3 Structure 
    
   Section 2 proposes a set of basic assumptions for the framework, 
   including the assumption that most interactions are hop-by-hop. 
   Section 3 considers a decomposition of the components that would make 
   up an NSIS protocol exchange. 
   Section 4 considers aspects of the framework that relate to a longer 
   range than pure hop-by-hop interactions. 
   Section 5 considers lower layer and inter-protocol interactions. 
   Section 6 considers overall analysis themes, such as security, 
   resilience, and scalability, which do not relate specifically to a 
   single part of the framework. 
    
2. Overall Framework Structure 
    
2.1 Signalling Entities 
    
   We assume that an NSIS signalling protocol runs between two 
   neighbouring entities which are a single 'NSIS hop' apart. In [4] 
   these were called 'NSIS agents'. An NSIS agent is responsible for 
   interpreting the resource requests in NSIS messages and applying them 
   ('QoS provisioning') over its segment of the flow path; the complete 
   flow path is made up of a concatenation of NSIS hops. 
    
   We make no assumptions about the relationship between NSIS agents and 
   the flow path, except that the former must know enough about the 
   latter to carry out the provisioning action. In particular, NSIS 
   agents do not need to be at each router, or even located at routers 
   at all. They can be placed around networks in various different 
   configurations, covering the spectrum from centralised management all 
   the way to pure hop-by-hop RSVP. But we don't want to relate this 
   overview to any particular example configurations. 
    
   In [4] and subsequent discussions we considered 3 subtypes of NSIS 
   agent: the QoS Initiator (QI), which starts the reservation process 
   based on upper layer requests (e.g. an application); the QoS 
   Controller (QC), which processes and forwards the reservation; and 
   the QoS Responder (QR), which terminates it at the remote flow 
   endpoint. Note that there may be QI-QC-QR chains in the core of the 
   network as well as end to end (e.g. in the case of network management 
   dynamically provisioning an aggregate). The basic situation is shown 
   in Figure 1. 

 
 
Hancock et al.         Expires - November 2002                [Page 4] 
                 Outline Framework for QoS Signalling         May 2002  
 
      +----+                                                   +----+ 
      | UL |                                                   | UL | 
      +----+                                                   +----+ 
        ^                                                        ^ 
        |                                                        | 
        |                                                        | 
        V                                                        V 
      +----+        +----+        +----+        +----+        +----+ 
      |    |  NSIS  |    |  NSIS  |    |  NSIS  |    |  NSIS  |    | 
      | QI |------->| QC |------->| QC |------->| QC |------->| QR | 
      |    |        |    |        |    |        |    |        |    | 
      +----+        +----+        +----+        +----+        +----+ 
    
          /----------------------------------------------------\ 
         /                                                      \ 
        <                 Flow (unidirectional)                  > 
         \                                                      / 
          \----------------------------------------------------/ 
                                      
                          Figure 1: QI, QC and QR 
    
   There is a minor ambiguity as to whether we consider a QC as really 
   terminating one NSIS protocol instance and initiating another (i.e. 
   QC=QI+QR). This seems to be purely an issue of semantics. 
    
2.2 Protocol Locality 
    
   A goal of this framework is to allow maximum freedom for local 
   (operator or technology influenced) selection of QoS mechanisms 
   within particular networks. One consequence of this is that it should 
   be possible to select different NSIS protocols (or use existing 
   protocols) at different points in the end to end path. A minimum set 
   of attributes needs to be common to all protocols to make 
   interoperability possible (see section 4). Also, we don't assume any 
   particular overall QoS architecture, at least in part because we 
   don't say anything about how QoS is actually enforced by the NSIS 
   agents. 
    
2.3 Protocol Function Split 
    
   We know the basic goal of an NSIS protocol is to establish state 
   related to resource reservations. There seems to be a split into the 
   most basic messages needed to support this function, and supporting 
   protocols which set up associated information beforehand.  
    
   The basic capability would include: request to create/modify a 
   reservation; acknowledge a reservation (maybe modified); and 

 
 
Hancock et al.         Expires - November 2002                [Page 5] 
                 Outline Framework for QoS Signalling         May 2002  
 
   asynchronously notify a change in the reservation state. It is 
   assumed that an NSIS protocol would support these functions directly.  
   Conversely, a preparatory phase could include elements such as 
   discovering the next hop NSIS agent, setting up a security 
   association, and agreeing QoS service descriptions or defaults. It is 
   not clear which of these functions NSIS protocols should support (it 
   might provide a container or activate triggers for other protocols). 
    
   This preparatory/basic split is almost analogous to the two phase 
   approach (main/quick) which seems to have been found useful in IKE. 
   Also, appropriate protocols for parts of the preparatory exchanges 
   may be highly scenario dependent (cf. the current discussion on 
   mechanisms for DNS server discovery) but not NSIS-specific. 
 
3. Basic Protocol Components 
    
   Although we could consider an NSIS 'basic' protocol as a single 
   layer, it makes sense to subdivide the message content into 
   components, as in Figure 2. 
    
   +-------------------------------------------------------------------+ 
   |                  |              |                 | / / / / / / / | 
   |                  |              |                 |/ / / / / / / /| 
   |                  |              |                 | / / / / / / / | 
   |     Protocol     |     NSIS     |      Flow       |/ / / QoS / / /| 
   |     Transport    |    Control   |   Description   | / Descriptor/ | 
   |                  |  Information |                 |/ / / / / / / /| 
   |                  |              |                 | / / / / / / / | 
   |                  |              |                 |/ / / / / / / /| 
   +-------------------------------------------------------------------+ 
    
                   Figure 2: Abstract Message Structure 
 
   The division into these components seems arbitrary, and could lead to 
   inefficiences in terms of duplication of functions. However, it 
   reflects requirements-related decisions about NSIS scope and can help 
   describe how NSIS protocols can be terminated or interworked at 
   different boundary types. It therefore needs to be analysed according 
   to some engineering principles. 
 
3.1 QoS (Service) Descriptors 
    
   It is a working assumption that the NSIS signalling protocol does not 
   care how QoS for a flow is actually described. In particular, we 
   don't argue about service classes, or parametrised approaches, or 
   opaque references to pre-negotiated service level specifications. The 
   expectation is that these descriptors will be very different at 

 
 
Hancock et al.         Expires - November 2002                [Page 6] 
                 Outline Framework for QoS Signalling         May 2002  
 
   different network interface types. Also, the service description can 
   encompass many of the more sophisticated QoS features (pre-emption, 
   resource availability notification, time-limited sessions) without 
   polluting the structure of the basic protocol. This information is 
   therefore carried opaquely by the protocol, and only used during QoS 
   provisioning. 
    
   However, QoS service descriptions need to be analysed at least to 
   some extent to determine their impact on the protocol (e.g. how many 
   message exchanges are needed to negotiate them, whether a particular 
   service requires additional per-flow state storage). Also, at least 
   the top-level syntax (IANA aspects etc.) need to be defined. 
    
   The abandonment of universal QoS descriptions has interoperability 
   implications especially for host-network interfaces especially in 
   terminal roaming environments. It probably makes less likely the wide 
   adoption of rich descriptive parameters (e.g. as proposed in [5]). 
   One way round this would be to consider associating scope information 
   with the QoS description, as described in [4]. 
 
3.2 Flow Description 
    
   The flow description defines the traffic that is the subject of the 
   reservation. This description could potentially be very simple, or 
   use very sophisticated multi-field classification (even including 
   field re-writing rules). It is also technology dependent (v4, v6...) 
    
   One reason for separating the flow description from the rest of the 
   information is to allow it to be managed correctly by devices which 
   are otherwise QoS-unaware (e.g. address translators, tunnel 
   entry/exit points). The way such transformations affect protocol 
   overhead (and hence flow QoS requirements) needs to be accounted for. 
 
3.3 NSIS Control Information 
    
   This represents the remaining NSIS-specific information carried by 
   the signalling protocol. It includes information about message type, 
   status information, reservation identification and so on. Although 
   conceptually different from the transport of section 3.4 the two 
   could in fact end up being inextricably intermingled. 
    
3.4 Protocol Transport 
    
   NSIS basic signalling protocols have many attributes in common with 
   standard signalling protocols, such as the need for secure and timely 
   delivery, recovery from error conditions, prevention against denial 
   of service attacks, and so on. Ability to be proxied or relayed in a 
   controlled way could also be important. None of these attributes is 
 
 
Hancock et al.         Expires - November 2002                [Page 7] 
                 Outline Framework for QoS Signalling         May 2002  
 
   specific to QoS signalling, and so it is likely that existing 
   protocols (such as SCTP or even Diameter) could be used to transport 
   NSIS messages. The choice of protocol might still be local (cf. the 
   way PPP and Diameter are used eat different stages to carry 
   Extensible Authentication Protocol [EAP] message exchanges). Suitable 
   protocols need to be selected. 
 
4. Non Local Aspects 
    
   It is clear that the NSIS signalling problem is simpler if as many 
   problems as possible are considered purely locally (i.e. hop by hop). 
   For some functions this is not possible, and for others it imposes 
   certain restrictions, which are considered here. 
    
4.1 Application Layer Interactions 
    
   Considering unicast (1:1) application flows (or triggered 
   aggregates), the NSIS entities responsible for the signalling are the 
   QI and QR of section 2.1. We note that the QI and QR might not be 
   colocated with the application or the user; however, this decoupling 
   should not be relevant to the protocol (except that the signalling 
   and traffic endpoints need not be the same). In particular, we would 
   like to consider that the security implications of a remote QI/QR are 
   handled elsewhere. 
    
   In that case, as in [4], we assume that the main interaction with the 
   application is that it requests negotiation of the QoS at the QI 
   (where it might also receive notifications), and is notified about it 
   at the QR. We assume that the decision about which application end 
   plays which role (for which flow direction) is made above NSIS (a 
   direct end-to-end NSIS protocol could do this but the application 
   seems better placed). 
 
4.2 End-to-End Paths 
    
   Even where NSIS basic protocols are selected locally, some aspects 
   must be common to allow end-to-end interoperation. Constraints 
   related to the basic signalling paths for sender/receiver-initiated 
   and bidirectional reservations are considered extensively in [4]. Two 
   further related open issues are mentioned here. 
    
   It is not clear if 'initiation' of a reservation is related to 
   willingness to accept accounting responsibility. (Current accounting 
   practices tend to assume that flow originators are responsible.) In 
   any case, it seems unlikely that a domain will make a cost-incurring 
   request of a peer domain without already having received a matching 
   request from the peer at the other end of the flow path - in other 
   words, requests must propagate between domains in the same direction 
 
 
Hancock et al.         Expires - November 2002                [Page 8] 
                 Outline Framework for QoS Signalling         May 2002  
 
   as money. If this argument is correct, and if NSIS initiation and 
   accounting responsibility are decoupled, it must be possible for the 
   NSIS exchange to run both in the direction initiator->responder and 
   vice versa. Also, if both [flow] sender and receiver initiation are 
   possible, service descriptions must include information about the 
   accounting policy to be applied, which must be imposed consistently 
   along the whole path. These issues should be analysed to determine if 
   1, 2 or 4 alternative scenarios are possible. 
    
   A second issue relates to the semantics of acknowledgement messages 
   in the basic protocol. An acknowledgement could mean either "I have 
   accepted this request for my domain [or hop]" or "this request has 
   been accepted for the remainder of the path". The first approach is 
   simpler (except in error cases), while the second requires more state 
   storage but could enable reporting of overall path characteristics. 
   (It replicates aspects of end-to-end RSVP behaviour.) The choice 
   between the two must be made consistently by all NSIS basic 
   protocols. 
    
4.3 Extensions 
    
   Various extensions to the pure hop-by-hop model could be considered 
   to build more sophisticated operational scenarios. Otherwise, with 
   the basic protocol features being considered, it is not clear that 
   NSIS could be used to build more complex services such as collect 
   calls, advice of charge, sensible charging of calls to a roaming 
   mobile, where the path crosses more than one administrative domain.  
    
   It is not clear whether these service capabilities are necessary 
   within the Internet, and if so whether their implications need to be 
   considered in the first stages of NSIS development. 
    
5. Inter-Layer and Inter-Protocol Interactions 
    
   This section considers the interactions between an NSIS basic 
   protocol and other protocols. While inter-layer interactions are 
   usually easy to model ("protocol X uses the service provided by 
   protocol Y"), intra-layer interactions (especially those relevant to 
   QoS signalling) are more subtle since they involve internal protocol 
   components such as state transitions or security parameters. This 
   area may require the development of abstract APIs to these other 
   protocols, although the interactions would in the end still be 
   implementation issues. 
 
5.1 Resource Management 
    
   The term "resource management" covers the various actions which are 
   taken to apply the QoS requested in the NSIS signalling message (QoS 
 
 
Hancock et al.         Expires - November 2002                [Page 9] 
                 Outline Framework for QoS Signalling         May 2002  
 
   descriptor) to the flow defined in the signalling message. It also 
   includes preparatory interactions to decide whether the request is 
   feasible and maybe negotiate its content. 
    
   This NSIS framework assumes the following come under the remit of 
   resource management: 
     1. Determination based on some local or network view whether the 
        request can be granted. 
     2. Configuration of layer 3 resources (filters and queues) at 
        routers along the path. 
     3. Configuration of layer 2 resources (link characteristics) at 
        routers and other devices along the path. 
   The framework makes no assumptions about how these are done, merely 
   that they can be done based on the information contained in the NSIS 
   messages. All QoS provisioning architectures with these capabilities 
   will 'look' the same to the signalling protocol. 
    
   As well as invoking QoS provisioning, the NSIS protocol must also 
   interact with resource management for notification of changes to the 
   available resources for a flow violation notifications can be sent. 
   The same applies to availability notifications and pre-emption, if 
   these services are supported. 
 
5.2 AAA Interactions 
    
   NSIS implementations within the network will have interactions with 
   authentication, authorisation and accounting functions. Although 
   protocol support for these is often integrated, it seems we can make 
   very different assumptions about the interactions with QoS signalling 
   for each. 
    
   The authentication interaction relates to peer entity authentication 
   (e.g. user/host-network) rather than authentication backhaul (e.g. 
   using RADIUS). This authentication is needed to establish the 
   identity of the user for later authorisation of QoS requests. The 
   authentication can also be used to set up security parameters for 
   later use. 
    
   Note here that we are assuming that the authentication function is 
   provided by an external protocol rather than by an NSIS function 
   (e.g. within the preliminary phase). The interaction might be 
   mediated through some abstract API, such as the EAP API that crops up 
   in roaming PPP discussions [6]. Other authentication protocols could 
   be integrated similarly. 
    
   Subsequent to authentication, authorisation information can be 
   provided to the QC. However, it appears that this information is used 
   only by the resource management function in admission control 
 
 
Hancock et al.         Expires - November 2002               [Page 10] 
                 Outline Framework for QoS Signalling         May 2002  
 
   decisions and has no direct interaction with NSIS signalling, except 
   via the message sequence constraints discussed in section 4.2. The 
   same reasoning applies to accounting information flows. 
    
5.3 Routing 
    
   This section considers interactions with routing and routing 
   protocols. Except to note that routes might be QoS dependent, we 
   don't consider QoS-aware routing or traffic engineering, since 
   controlling this would be a function of resource management, with no 
   implication back on the QoS signalling protocol. 
 
5.3.1  Signalling and Data Paths 
    
   The relationships between the routing of user data and the signalling 
   messages that request QoS for it have been extensively discussed in 
   [4] and elsewhere. Here, we just note that implicit routing of 
   signalling messages on flow destination address does not guarantee 
   that signalling follows the data path (because of QoS routing), and 
   explicit addressing of QoS messages might be used in any case for 
   security or other reasons (as is necessary for RSVP messages in some 
   cases). 
    
   It seems that the only impact on the signalling protocol is to allow 
   explicit addressing of messages. Discovering the explicit address is 
   therefore required, but we have regarded this discovery as an aspect 
   of the preliminary phase rather than part of the basic protocol. 
 
5.3.2  Route Change and Mobility (Handover) Support 
    
   When the path taken by a traffic flow changes, the reservation must 
   be changed to match it. Such a change could take place either because 
   of a topology change or end host mobility. There are two areas where 
   interaction with NSIS signalling might take place: in detecting the 
   route change, and sending update signalling messages. 
    
   Route changes can be detected by a trigger from the routing protocol 
   (which is natural if signalling messages are explicitly routed). If 
   signalling is implicitly routed and the NSIS agents are routing 
   unaware, it appears that there is no alternative to soft-state 
   refresh, in which case the updating process is automatic. Beyond 
   this, there seem no additional mandatory implications for routing-
   NSIS interactions. 
    
   Substantial research work has been done in considering the detailed 
   interactions of QoS signalling and mobility routing protocols. This 
   has considered both independent protocols interacting via triggers as 
   in the previous paragraph, as well as a tighter coupling mode where 
 
 
Hancock et al.         Expires - November 2002               [Page 11] 
                 Outline Framework for QoS Signalling         May 2002  
 
   the QoS messages are carried within routing protocol messages. This 
   case can be considered as a local NSIS protocol, with the mobility 
   routing protocol playing the role of NSIS transport in the sense of 
   section 3.4. The relative merits of these approaches can be analysed, 
   but both fit naturally into the framework outlined here. 
 
5.3.3  Access Router Selection and Handover 
    
   Also in the mobility area, work is going on to consider protocols for 
   selecting access router handover targets. One selection criterion 
   would be QoS available at the candidate access router, over both the 
   access link and into the rest of the network. There is a clear 
   interaction with NSIS signalling here, partly because NSIS may also 
   support a query capability, and also that NSIS agent implementations 
   will have the necessary interfaces to resource management to do parts 
   of this. It seems very unclear how to manage this protocol 
   interaction, although the ability to reuse components of NSIS 
   messages for the QoS-related aspects of the signalling could be 
   useful. 
 
6. Additional Analysis Areas 
    
   The following sections consider areas which cut across all aspects of 
   the framework. They therefore need to be analysed for each aspect, as 
   well as looking at the way these aspects work together to support the 
   function overall. 
    
6.1 State Information Storage 
    
   The NSIS framework may be assessed in terms of what state information 
   is required at which points in the network and for which 
   interactions. Some state information must be maintained at NSIS 
   agents, minimally in order to support protocol operation, such as: 
    
     1. Flow Information: to allow identification of a flow/aggregates 
        for re-negotiation and allow notifications to be propagated to 
        right node. The resource allocated is also part of this state. 
     2. Aggregation information: to allow disaggregation and the 
        regeneration of reservation information. 
     3. NSIS Agent associations: including authentication state and
        accounting policy associated with NSIS peers. 
    
   Since NSIS also carries QoS descriptions, there may be additional 
   information associated with these (to do with more complex services 
   such as time limited reservations) which is otherwise unknown to 
   NSIS. Likewise, resource management will need state information about 
   what resources are in use by whom. Whether to integrate this with 
   protocol state handling might be left as an implementation issue. 
 
 
Hancock et al.         Expires - November 2002               [Page 12] 
                 Outline Framework for QoS Signalling         May 2002  
 
6.2 Scalability 
    
   Scalability analysis of the different aspects of the framework can 
   provide indications regarding protocol performance and efficiency.  
   The analysis can be carried out independently for different framework 
   aspects, for example, the impacts of a particular security approach 
   in terms of signaling vs. state information. 
    
6.3 Resilience 
    
   Analysis of resilience requires identification of what failure 
   conditions need to be handled by NSIS, followed by an assessment of 
   how recovery takes place for different aspects of the framework.  The 
   impacts of the failure of one part of the framework on another also 
   need to be considered, for example, should state information 
   availability be dependent on ("fate share with") node or signaling 
   path failure, or should at least some parts of the state information 
   (e.g. authentication state) be decoupled. 
    
6.4 Interworking 
    
   Solutions developed within NSIS should support interworking with 
   existing QoS solutions, such as RSVP, or MPLS.  This supports 
   incremental deployment of NSIS solutions in existing QoS-enabled 
   networks. This requirement seems to impact on all aspects of NSIS. 
    
6.5 Security Considerations 
    
   This internet draft has security considerations in almost every 
   aspect. However, no explicit security requirements or proposals are 
   made in it (except that some options are given about potential 
   interactions with existing security protocols). Instead, this 
   internet draft is aimed at progressing security analysis. 
    
   Security requirements are given in [2], and a more detailed threat 
   analysis is on-going. This analysis can initially only be done at the 
   user/system level; however, it is possible to do a more specific 
   threat analysis against a more concrete protocol framework. 
    
   A particular issue for the security considerations is the fact that 
   NSIS is a container protocol for QoS descriptions which are otherwise 
   not considered. Some security requirements (e.g. theft of service) 
   apply mainly to these QoS descriptors and associated authorisation 
   aspects, while others (e.g. denial of service/flooding) apply more to 
   the NSIS parts. We then have three possible basic approaches: 
     1. Assume that the authenticated and secure QoS descriptors will 
        always be required, and build on this to secure other aspects of 
        the protocol, such as denial of service attack prevention. 
 
 
Hancock et al.         Expires - November 2002               [Page 13] 
                 Outline Framework for QoS Signalling         May 2002  
 
     2. Have the NSIS parts include a security service which can be used 
        also to secure the QoS description. 
     3. Consider the two parts independently. 
   One open question is whether the assumption (1) is valid, or whether 
   secure anonymous access should also be considered (e.g. as provided 
   by HIP [7]). 
 
References 
                     
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
      9, RFC 2026, October 1996. 
    
   2  Brunner, M., "Requirements for QoS Signaling Protocols", draft-
      ietf-nsis-req-02.txt (work in progress), May 2002 
    
   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997 
    
   4  Hancock, R.E. et al., "Towards ...", draft-hancock-nsis-framework-
      00.txt (work in progress), February 2002 
    
   5  Fodor, G., "Application of Integrated Services on Wireless 
      Accesses", draft-fodor-intserv-wireless-params-01.txt (work in 
      progress), January 2002 
    
   6  Aboba, B., "The EAP Keying Problem", draft-aboba-pppext-key-
      problem-01.txt (work in progress), February 2002 
    
   7  Moskowitz, R., "Host Identity Payload And Protocol", draft-
      moskowitz-hip-05.txt (work in progress), November 2001 
    
Acknowledgments 
    
   The authors would like to acknowledge Cornelia Kappler and Hannes 
   Tschofenig for input and comments, as well as all the other co-
   workers, colleagues from collaborative projects, and active players 
   in the NSIS working group who have broadened our horizons on the 
   subject of QoS signalling architectures over the past months.  
    
Author's Addresses 
    
   Robert Hancock 
   Eleanor Hepworth 
   Siemens/Roke Manor Research 
   Old Salisbury Lane, Romsey, U.K. 
   Email: {robert.hancock|eleanor.hepworth}@roke.co.uk 
     

 
 
Hancock et al.         Expires - November 2002               [Page 14]