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]