NSIS Working Group Maarten Buchli Internet Draft Danny Goderis draft-buchli-nsis-req-00.txt Sven Van den Bosch Expires: August 2002 Juan-Carlos Rojas Stefan Custers Alcatel February 2002 QoS signaling requirements, interfaces and architecture 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. Abstract This draft gives evidence for the existence of different QoS signaling interfaces based on a reference architecture that is derived from two use cases. The main purpose is to refine the requirements for the signaling interface that is being considered in scope of NSIS. The two use cases are the interconnection of PSTN trunking gateways over an IP core network and the connection of an UMTS access network to an IP core network. From these use cases a QoS reference architecture is derived containing QoS Initiator (QI) and QoS Controller (QC) entities, as defined in draft-brunner-nsis-req- 00.txt. The architecture encompasses the inter-connection of any type of access networks over an IP DiffServ core network and does not require any upgrade of the existing (and deployed) DiffServ routers. The proposed architecture identifies four relevant signaling interfaces between functional entities. We believe the interface between QI and QC to be of particular interest in the context of Buchli et al. Informational - Expires August 2002 1 QoS signaling architecture, interfaces February 2002 and requirements NSIS. Based on our architecture, the signaling protocol over this interface can be kept simple. 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 [1]. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................2 1. Introduction....................................................3 2. Terminology.....................................................4 3. Overview of signaling requirements..............................5 4. Use cases.......................................................6 4.1 PSTN trunking gateway scenario.................................7 4.2 UMTS access scenario...........................................8 5. General architecture............................................9 5.1 Signaling architecture........................................10 5.2 Protocol interfaces...........................................13 5.2.1 Host to QoS Initiator.......................................13 5.2.2 QoS Initiator to Access Gate................................13 5.2.3 QoS Initiator to QoS Controller (NSIS)......................14 5.2.4 QoS Controller to Network Management System (NMS)...........14 5.3 Evolution scenario............................................15 6. Requirements on the QoS Initiatorûto-QoS Controller interface..15 6.1 Signaling requirements........................................15 6.2 Requirements on protocol content..............................17 6.3 Open issues...................................................18 7. Security Considerations........................................18 8. Conclusions....................................................19 9. Acknowledgment.................................................20 References........................................................20 Author's Addresses................................................21 Buchli et al. Informational - Expires August 2002 2 QoS signaling architecture, interfaces February 2002 and requirements 1. Introduction The task of the NSIS working group is to specify general QoS signaling requirements and possibly propose a new protocol or modifications to existing ones. Two use cases are presented in this draft to explore such QoS signaling requirements. The first case is a PSTN trunking gateway interconnection scenario. The second case is the interconnection between a UMTS access network and an IP core network. In addition to the NSIS requirements draft [8], and based on the two use cases, we introduce a QoS signaling reference architecture and identify the different protocol interfaces that are in place. An important observation is that several QoS signaling interfaces may exist and that their requirements are of a different nature. We identify four relevant signaling interfaces, which may be involved in QoS provisioning. The most important being the interface between the QoS Initiator (QI) and the QoS Controller (QC) as also described in [8]. The basic requirements of the QI-to-QC interface are described and compared with the requirements as expressed in [8]. In particular it must be possible to gradually deploy the NSIS QoS solution on top of existing networks. This high-level requirement yields concrete consequences for the QoS signaling in as well access as core networks. First it is noted that access networks (UMTS, Packet cable, ADSL access, etc) may use their own specific QoS signaling protocols for quite some time. Moreover, in current networks, QoS signaling in access may be very technology dependent, while for IP core networks we need definitely a technology independent protocol. This may involve mapping requirements and the draft discusses particular features of this mapping and the actual place in the network where this mapping can take place. Thus, in a first phase, access networks may still use their own QoS signaling, which is mapped onto a generic NSIS protocol by an entity at the edge of the network. However, in a second phase the NSIS protocol may also be supported by the end-host and used in the access networks to setup QoS reservations. Hence, this provides an evolution scenario for gradual deployment of the NSIS protocol in access networks. Second the QoS technology used by most operators in IP core networks is Differentiated Services (DiffServ). It should be possible to deploy the QoS solution onto these networks without upgrading the routers. This may require the compatibility of in-band and out-of- band signaling because, for pure DiffServ networks, the QoS signaling can not be done on the data-path. This draft presents one way of doing this for scenarios involving one IP core and several access networks. It presents a two-step approach in order to support Buchli et al. Informational - Expires August 2002 3 QoS signaling architecture, interfaces February 2002 and requirements end-user Quality of Service (QoS). First step is to pre-provision bandwidth pipes in the transport network defined by means of e.g. DiffServ Service Level Specifications (SLS). These are e.g. IP VLLs with statistical QoS guarantees, such as edge-to-edge delay and packet loss bounds, for traffic aggregates. The second step is then to admit (micro)-flows in the bandwidth pipes based on the user QoS request. As a consequence of this two-step approach, the dynamic per-flow QoS signaling can be simplified and kept out of the (DiffServ) routers. The outline of the draft is as follows. The terminology is defined in section 2. Section 3 summarizes the main signaling requirements for the QI-to-QC interface and makes the comparison with [8]. Section 4 presents the two use cases while section 5 draws conclusions and proposes a more general signaling architecture. The requirements on the signaling protocol and the parameter groups are discussed in section 6. The conclusions are presented in the final section. 2. Terminology The terminology used in this draft is in line with the DiffServ terminology [10] and the NSIS requirements draft from Brunner et al. [8]. The relevant terminology is repeated here and some new terms are introduced. See e.g. figure 3 for a position of the relevant functional entities in the network. Host: end-user entity where the application is running that requires QoS to another host or server. The end-user service, which should be supported end-to-end by the network, is supposed to be a dynamic QoS demanding service such as voice, video, etc. Access Gate (AG): functional entity that enforces QoS policy by policing and traffic conditioning per microflow. In this context, a microflow is understood as the IP packet flow carrying the payload of the actual service to be supported in the network (e.g. voice) and may be formally defined as e.g. the IntServ 5-tuple. A microflow is always understood to be end-to-end, i.e. host-to-host. Edge router (ER): router at the edge of a Differentiated Services (DiffServ) capable network. It is a common DiffServ edge router enforcing QoS policy by policing and traffic conditioning traffic aggregates and DiffServ Service Level Specifications SLS, see e.g. [8][9]. According to DiffServ an SLS is "a set of technical parameters and their values, which together define the service, offered to a traffic stream by a (DiffServ) transport network". In this context, an SLS is the technical specification of a long-lived QoS service such as an IP VLL or an assured rate bandwidth pipe. The geographical scope of an SLS is single domain, i.e. edge-to-edge. The edge-to-edge statistical QoS guarantees, such as maximum delay, Buchli et al. Informational - Expires August 2002 4 QoS signaling architecture, interfaces February 2002 and requirements are provided to the in-profile packets of the traffic aggregate stream defined by the SLS. For a detailed description of SLSs, see [9]. For its support and implementation in a DiffServ network by means of Per Hop Behaviors (PHB) and Per Domain Behaviors (PDB), see [8]. Network Management System (NMS): common network and element management platform, configuring the edge and core routers of a single IP network by e.g. the SNMP or COPS protocol. In this context the NMS is the functional entity responsible for the configuration and provisioning of long-lived QoS services, which are technically described by SLSs. QoS Controller (QC): the functional entity that is ôresponsible for interpreting the signaling carrying the end-user service QoS parameters, optionally inserting/modifying the parameters according to local network QoS management policy, and invoking local QoS provisioning mechanismsö [8]. More specifically in this context the QC performs per-microflow admission control for a single IP domain. The QC manages or "owns" (part of) the pre-provisioned network resources, which are described by a set of Service Level Specifications. These SLSs provide statistical edge-to-edge QoS guarantees. QoS Initiator (QI): the functional entity ôgenerating the QoS request for traffic flow(s) based on user or application requirements and signaling them to the network as well as invoking local QoS provisioning mechanisms. This can be located in the end system, but may reside elsewhere in networkö [8]. This draft takes the same viewpoint and discusses use cases for different locations of the QI. The QI is in any case an ôNSIS-speakerö, i.e. it implements the (to-be-defined) NSIS protocol and signals a QoS request to the QC. In case the QI is situated at the network edge (access-core), the QI should perform a mapping from the (access technology dependent) user QoS request to the QoS request towards the QC. 3. Overview of signaling requirements The main purpose of this document is to derive requirements for NSIS protocol interfaces that are identified from use cases. In this section, we give an overview of the requirement list. The requirements are primarily derived for the QI-QC interface but it seems advantageous that they be reused (partly) for the QC-QC interface. Each requirement will be put into context and clarified in subsequent sections. Apart from the generic requirements that the protocol should be fast and lightweight, it - must support both in-band and out-of-band signaling - must support priority - must allow notification of (QoS) failure Buchli et al. Informational - Expires August 2002 5 QoS signaling architecture, interfaces February 2002 and requirements - must decouple the messaging mechanism from the information being signaled - should be independent of core transport technology - should avoid extra complexity due to (optional) multicast support - should be optimized for interactive multimedia services - should support different service levels for a service class - the mobility aspects should have no impact on the NSIS protocol Two considerations are left as open issues: - the protocol may be stateful or stateless - it should consider allowing grouping of microflows Related work in the NSIS group [8] states that: "Specific mechanisms for QoS provisioning within a domain/subdomain are not considered. It should be possible to exploit these mechanisms optimally within the end to end context. Consideration of how to do this might generate new requirements for NSIS however." The two-step approach for which requirements are documented in this draft achieves this goal of exploiting the QoS intra-domain provisioning solution. In this way, it inherently addresses some of the requirements in [8]: - it avoids duplication of sub-domain signaling - it provides independence of the underlying technology - it reuses existing QoS technologies and does not impact existing infrastructure during deployment - it decomposes the path which is essential to provide mobility It also emphasizes some other requirements in [8]: - QoS signaling and QoS Controllers must not be constrained to be in the data path - the network is expected to handle 2 QoS granularities: per-flow and per-trunk or per-class Note, however, that an important difference is that per-flow signaling can be considered in the core because the required amount of signaling information is strongly reduced by the two-step approach. Finally, it allows to relax some of the signaling requirements in [8]: - the info that is passed as signaling content does not have to be universal. It suffices that it can be translated by each domain in the appropriate local QoS. - communication between QoS administration functionality (e.g. traffic engineering) and QI is not needed. - it is not necessary to map opaque application-dependent information in the message. The QI provides a mapping function and the end-host to end-host alignment can be obtained at the application layer. 4. Use cases Buchli et al. Informational - Expires August 2002 6 QoS signaling architecture, interfaces February 2002 and requirements In [8] the concepts of QoS Initiator (QI) and QoS Controller (QC) were introduced. Here we analyze these functions for two concrete use cases. In 3.1 a scenario of interconnecting PSTN trunking gateways is discussed. In this case the QI and QC are integrated in one entity. In 3.2 a possible scenario is shown for providing end- to-end QoS with UMTS access networks. In this case the QI and QC are two separate entities. In both cases the QI function is not part of the end-host. 4.1 PSTN trunking gateway scenario This section discusses an example scenario where a number of PSTN trunking gateways are interconnected by a QoS enabled IP transport network. The PSTN consists of a network carrying 64 kb/s circuits. It is connected to the Edge Router (ER) of the IP network by a Media GateWay (MG). The PSTN call signaling is transported over a separate SS7 signaling network. This signaling network is connected to a Media GateWay Controller (MGC). In the IP network the SS7 signaling is carried with the ISUP/SIGTRAN protocol [11]. The MGC controls the MG with the Megaco protocol [5]. In figure 1 the example scenario is shown for two media gateways, i.e. trunking gateways. The Network Management System (NMS) is the entity that is able to provision bandwidth pipes in the transport network. +-------------+ ISUP/SIGTRAN +-----+ +-----+ | SS7 network |---------------------| MGC |--------------| SS7 | +-------------+ +-------+-----+---------+ +-----+ : / : \ : / : \ : / +--------:----------+ \ : MEGACO / / : \ \ : / / +-----+ \ \ : / / | NMS | \ \ : / | +-----+ | \ : : | | : +--------------+ +-----+ | bandwidth pipe (SLS) | +-----+ | PSTN network |--| MG |--|ER|=====================|ER|-| MG |-- +--------------+ +-----+ \ / +-----+ \ QoS network / +-------------------+ Figure 1: PSTN trunking gateway scenario Resources should be pre-provisioned between the media gateways. This is done by establishing a mesh of bandwidth pipes, with strict delay guarantees, between the trunking gateways. The capacity of the pipes should be determined by means of traffic prediction and use of e.g. Erlang calculations in order to provision for a small call blocking probability. Buchli et al. Informational - Expires August 2002 7 QoS signaling architecture, interfaces February 2002 and requirements The MGC receives the call setup signaling and should perform per- microflow admission control onto the pre-provisioned resources. The MGC determines the rate of the microflow from the type of codec that is used in the MG. The resource request is a number of 64kb channels and hence, a simple counter to keep track of the used capacity of the bandwidth pipe could be sufficient to perform admission control. The MGC should have the information about the capacity of all bandwidth pipes and should block call setups when the capacity is completely used. The capacity of the bandwidth pipe may be negotiated by an off-line process via paper contracts or by an automated process with an SLS negotiation protocol. In this scenario the MG has the role of Access Gate and the MGC acts as the QoS Controller, performing admission control in the pre- provisioned bandwidth pipes. The QoS Initiator functionality may reside in as well the MG as in the MGC, exchanging information by the MEGACO protocol. This depends on the concrete implementation of MG and MGC. In any case the codec type must be mapped onto a traffic descriptor, which is then used for the admission control of the micro-flow into the bandwidth pipe. In this scenario there may be a separate network provider (owning the transport network and NMS) and voice service provider (owning the MGs and the MGC). Both legal entities have a service level agreement (SLA) and the technical part, i.e. the SLS, describes the mesh of bandwidth pipes between the MGs. The existence of such a SLA is shown as a line between MGC and NMS in figure 1. For more details, see section 5.2 ôQC-to-NMS interfaceö. Remark also that multiple service providers may be active on the same physical network through SLAs with the network provider. 4.2 UMTS access scenario The UMTS access scenario is shown in figure 2. The Proxy-Call State Control Function/Policy Control Function (P-CSCF/PCF) is the outbound SIP proxy of the visited domain, i.e. the domain where the mobile user wants to set-up a call. The Gateway GPRS Support Node (GGSN) is the egress router of the UMTS domain and connects the UMTS access network to the Edge Router (ER) of the core IP network. The P-CSCF/PCF communicates with the GGSN via the COPS protocol [4]. The User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal Equipment (TE), e.g. a laptop. +--------+ +----------| P-CSCF |-------> SIP signaling / +--------+ / SIP : : +--------+ NSIS +----------------+ : | PCF |---------| QoS Controller | : +--------+ +----------------+ Buchli et al. Informational - Expires August 2002 8 QoS signaling architecture, interfaces February 2002 and requirements : : : : COPS : : +----+ +--------+ +----+ | UE |----------| GGSN |------| ER | +----+ +--------+ +----+ Figure 2: UMTS access scenario In this scenario the GGSN has the role of Access Gate. According to 3GPP standardization, the PCF is responsible for the policy-based control of the end-user service in the UMTS access network (i.e. from UE to GGSN). In the current UMTS release R.5, the PCF is part of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF may evolve to an open standardized interface. In any case the PCF has all required QoS information for per-flow admission control in the UMTS access network (which it gets from the P-CSCF and/or GGSN). Thus the PCF would be the appropriate entity to host the functionality of QI, initiating the "NSIS" QoS signaling towards the core IP network. The PCF/P-CSCF has to do the mapping from codec type (derived from SIP/SDP signaling) to IP traffic descriptor. SDP extensions to explicitly signal QoS information [7] are useful to avoid the need to store codec information in the PCF and to allow for more flexibility and accurate description of the QoS traffic parameters. The PCF also controls the GGSN to open and close the gates and to configure per-flow policers, i.e. to authorize or forbid user traffic. The QC is (of course) not part of the standard UMTS architecture. However, to achieve end-to-end QoS a QC is needed such that the PCF can request a QoS connection to the IP network. As in the previous example, the QC could manage a set of pre-provisioned resources in the IP network, i.e. bandwidth pipes, and the QC performs per-flow admission control into these pipes. In this way, a connection can be made between two UMTS access networks, and hence, end-to-end QoS can be achieved. In this case the QI and QC are clearly two separate entities. This use case clearly illustrates the need for an "NSIS" QoS signaling protocol between QI and QC. An important application of such a protocol may be its use in the inter-connection of UMTS networks over an IP backbone. 5. General architecture This section proposes a QoS reference architecture generalizing the examples discussed above. The architecture encompasses the inter- connection of any type of (layer two) access networks with an IP backbone and provides QoS to any type of (uni-cast) end-user services (i.e. not only telephony services). The extension of the architecture to multiple IP backbones, with multiple QCs on the end- to-end signaling path, is for further study. Buchli et al. Informational - Expires August 2002 9 QoS signaling architecture, interfaces February 2002 and requirements In 4.1 the architecture is presented. The different signaling interfaces are identified and discussed in 4.2. In 4.3 an NSIS evolution scenario is discussed with regard to access networks. 5.1 Signaling architecture The reference architecture is shown in figure 3. In this architecture the host requests QoS to the QoS Initiator, which in turn contacts the QoS Controller. The functional entities are shown separately but they may be located in the same physical box. For the sake of simplicity the access networks are presented as single lines between host and Access Gates. +----+ 3 NSIS +----+ NSIS +----+ +-| QI |-------------| QC |-------------| QI |-+ / +----+ +----+ +----+ \ / : : : \ 1 / : 4 : SLS IF : \ / : +-----:-----+ : \ / : 2 / +-----+ \ : \ / : / | NMS | \ : \ : : / +-----+ \ : : : : | | : : +------+ +----+ | | +----+ +------+ | Host |----| AG |===|ER|===================|ER|==| AG |---| Host | +------+ +----+ | SLS | +----+ +------+ \ / +---------------+ IP network Figure 3: QoS signaling interfaces and functional entities The architecture identifies at least three roles, i.e. the end-user, the service provider (SP) and the network provider (NP). The NP is the owner of the IP transport equipment. The SP naturally provides end-user services and may or may not be the same entity as the NP. For example the SP could be an UMTS mobile operator, leasing transport capacity from an IP Network Provider. The leased capacity inter-connects the Access Gates of the SP and is formalized by a SLSs, which are part of a Service Level Agreement between NP and SP (see section 5.2 ôQC-to-NMS interfaceö for more details). The IP network is DiffServ enabled and therefore capable of providing e.g. IP virtual leased line services. These IP VLLs are specified by DiffServ Service Level Specifications (SLSs), which are the technical part of the SLA. QoS provisioning for individual flows is done by a two-step approach. First step is to provision the capacity in the network by provisioning bandwidth pipes between the ingress and egress points of the IP network by means of SLSs. The second step is to perform Buchli et al. Informational - Expires August 2002 10 QoS signaling architecture, interfaces February 2002 and requirements admission control for microflows, i.e. checking whether they still fit in the bandwidth pipe. This admission control function is done by the QoS Controller. The end-user QoS provisioning is described in detail below. Steps 1) and 2) are the pre-provisioning steps for aggregate bandwidth pipes (SLS). Steps 3) and 4) are the per-microflow signaling and admission control steps. 1) The QoS Controller requests one or more bandwidth pipes (i.e. virtual leased lines) to the NMS. These bandwidth pipe IP services are specified as SLSs and are requested over an SLS interface or they are negotiated off-line, resulting in a paper contract SLA (in case NP and SP are distinct legal entities). The capacity of the bandwidth pipes is based on some kind of traffic prediction process. The SLSs are stored in databases in the QoS Controller and the NMS. 2) The NMS triggers a traffic management process in order to provision the required resources (SLSs) in the network. This may involve reconfiguring one or more network elements. The traffic conditioning block in the edge routers are configured to police the bandwidth pipes. Thus, the traffic is policed on an aggregate base. 3) The application (e.g. VoIP) at the end-host, requiring a connection with QoS guarantees to another host or server, signals the QoS request to the QoS Initiator. This signaling may be access technology dependent. The QoS initiator performs the mapping to a technology independent format and signals the QoS request to the QoS Controller by the NSIS protocol. 4) The QoS Controller performs admission control for the QoS request. It determines whether sufficient capacity is available in the bandwidth pipes that are defined by the SLSs. The QC will return an admit or reject message. Note, that this step does not involve any configuration of network elements. If the flow has been admitted the QoS Initiator will configure the Access Gate in order to police the microflow. This end-user QoS provisioning approach provides a clear distinction between the provisioning of resources in the transport network and the admission of per-microflow QoS requests. The per-flow QoS signaling can therefore be kept simple since the complexity resides mainly in the resource provisioning in the network and specification of the bandwidth pipes (i.e. SLSs). The provisioning may be static or semi-dynamic. The provisioning is anyhow already in place when the per-flow QoS request arrive. This two-step approach is also visible in the way the traffic is policed. The edge router polices per SLS (bandwidth pipe), and hence, on aggregated traffic. The Access Gate polices per-microflow. The main point here is that the DiffServ network is not (required to be) per micro-flow aware. The DiffServ network operator only Buchli et al. Informational - Expires August 2002 11 QoS signaling architecture, interfaces February 2002 and requirements provides QoS guarantees to the (SLA/SLS contracted) long-term aggregate IP services such as IP virtual leased lines. Above we made abstraction of the QoS class and QoS parameters to be signaled. This is discussed in more detail below, but it is instructive to make the following key observation at this point. The main objective is to keep the NSIS signaling protocol between QI and QC as simple as possible, certainly if it should be extended to QC-to-QC inter-domain scenarios. Basically, the information to be signaled is an indication of the QoS class plus a required throughput R (peak rate, token rate, etc) for this particular QoS class. Indeed, provided the QoS class is determined by other means, the required throughput is the main parameter needed by the QC to be able to perform per-flow admission control (i.e. answering the question whether there is still enough capacity in the QoS pipe SLS for admitting e.g. R bandwidth units). We argue that there is no need to signal delay values in the NSIS protocol (interface 3), because the statistical delay bounds are already known and provided by the SLSs. If the QC admits the request for R bandwidth units, then the service will enjoy the delay bounds guaranteed by the SLS. The remaining question is whether this approach can deal with several service (QoS) classes. Suppose for example that there are two QoS classes ôGoldö and ôSilverö. This could e.g. be used for the offering of voice services with different quality. Another example is to use the Gold QoS class for real-time, delay-sensitive services and the Silver QoS class for elastic, non-delay sensitive services. The latter only require a throughput guarantee. How is this handled in the two-step approach described above? First step: the pre-provisioning. The SLSs describing the bandwidth pipes between the AGs may or may not contain edge-to-edge delay- bound guarantees, corresponding respectively with gold and silver type of services. The Gold and Silver SLSs are realized by respectively the DiffServ Virtual Wire PDB and Assured Rate PDB. Second step: per-flow signaling. Clearly the signaling between host and QI (interface 1) must indicate whether the requested service is gold or silver. The QoS class could also be implicitly derived from the type of service (e.g. voice). Besides the QoS class the user must at minimum also signal the required throughput. In any case, the QI knows the appropriate QoS class and the required throughput. What remains to be decided is what information is signaled between QI and QC. If the same QC is allowed to manage as well Gold as Silver SLSs, then the QI needs to signal the required QoS Class. If a QC only manages one type of SLSs, corresponding with one QoS class, then the QI decides (based on QoS class information) which QC Buchli et al. Informational - Expires August 2002 12 QoS signaling architecture, interfaces February 2002 and requirements he has to request resources and signals (only) the required throughput. It is for further study to decide whether both approaches should be possible and able to inter work. 5.2 Protocol interfaces 5.2.1 Host to QoS Initiator The host to QoS Initiator protocol interface will in most cases depend on the access technology that is used. Due to the variety of access QoS technologies it is to be expected that there will not be one single protocol used over this protocol interface. The QoS Initiator is the entity that triggers the actual QoS setup in the core network. There are several possibilities how the host can trigger the QoS Initiator. 1) The QoS Initiator may be integrated in a web-host or an outbound SIP proxy. In the first case the end-user may e.g. use a webpage in order to specify the service he/she would like to use. The web host may then initiate a QoS connection. In the latter case, the host may piggyback the QoS information on the session setup signaling. More precisely, QoS information may be carried in SDP [7] and may be interpreted by the SIP proxy, which will trigger the QoS setup in the network. 2) The host uses an access specific layer 2 or 3 protocol. This is e.g. an RSVP-derived protocol for PacketCable networks and the Packet Data Protocol (PDP) for UMTS networks. For xDSL broadband access a mechanism based on ATM Virtual Connections (VC) maybe used. The AG intercepts this QoS signaling and forwards it to the QoS Initiator. In this way the access specific QoS signaling is coupled to the generic QoS setup in the core. This protocol interface is within the scope of NSIS in the sense that existing access signaling protocols should be assessed whether they contain the minimum set of parameters that are required at the QoS Initiator in order to map them to the generic signaling protocol between the QoS Initiator and the QoS Controller. Of course, the first step should be to specify this minimum set of parameters required for the generic signaling protocol. 5.2.2 QoS Initiator to Access Gate The protocol interface between the QI and the AG is used to configure the AG such that it correctly installs per-flow policers. In order to configure the policer a flow identifier is required (e.g. five-tuple) and a traffic descriptor (e.g. token bucket parameters). Optionally an indication for DiffServ packet marking may be signaled (i.e. the DiffServ Code Point value). Buchli et al. Informational - Expires August 2002 13 QoS signaling architecture, interfaces February 2002 and requirements This protocol interface may be e.g. COPS [4] or a future MIDCOM [13] protocol. Hence, this protocol interface is outside the scope of NSIS. 5.2.3 QoS Initiator to QoS Controller (NSIS) The protocol interface between the QoS Initiator and the QoS Controller is discussed in section 6. This protocol is generic in the sense that is technology independent. The QI is responsible for mapping the access technology dependent user QoS request on this protocol. This protocol interface is certainly within the scope of NSIS. 5.2.4 QoS Controller to Network Management System (NMS) A Service Level Agreement (SLA) is a legal agreement between a customer and a provider. The technical part of the SLA is called a Service Level Specification (SLS). The SLS specifies capacity and QoS guarantees between one or more ingress and egress points of a network. The SLS also specifies the availability and reliability of the bandwidth service. The services specified in an SLS usually stay in place for a long duration (e.g. days or months) and their setup (time between the request of the service from the customer and the availability) will not be real-time. The resources needed to fulfill the SLS may be provisioned by means of traffic engineering. In case the IP network is a DiffServ domain, the SLS may be implemented with a PDB [6], e.g. a virtual wire or assured rate PDB. Remark that it is not required for the architecture to automate this interface. Indeed the SLA may be negotiated off-line yielding full static SLS pipes between the Access Gates. It may however evolve to an automated, (to-be-standardized) interface. It is argued that automation and standardization of this SLS interface may yield two key advantages for QoS provisioning. First, it may be used to semi-dynamically negotiate SLSs. For example, if the QoS Controller has to block too many calls between two AGs, the QC may trigger the NMS for more resources on a dynamic basis. Second, the interface may be used to exchange monitoring information. In other words, the NMS may send information about e.g. the current traffic load in the bandwidth pipe that is specified by the SLS. The monitoring information applies to the traffic aggregate SLSs. The QC may use this monitoring information to cross check whether the currently admitted flows (and their throughput) corresponds with the actual traffic load in the bandwidth pipe SLSs. An SLS template has been specified by the European IST-project Tequila [9] in order to facilitate for both functions. Finally note that in figure 3 the SLS interface is shown as a line between the QC and NMS. This is a somewhat simplified view because Buchli et al. Informational - Expires August 2002 14 QoS signaling architecture, interfaces February 2002 and requirements in practice, the service provider owning the QC will also dispose of an NMS for managing his equipment (e.g. Access Gates). Thus an SLS interface will rather be implemented between two NMSÆs of providers. These NMSÆs each have their SLS-database and the QC has access to the NMS of the service provider for executing the policy-based admission control decision. This protocol interface may be in scope of NSIS. 5.3 Evolution scenario In the previous section it was assumed that the end-host and QI were two separate entities. This is because each type of access network has its own QoS signaling protocol. The QI couples the access dependent QoS signaling with the generic NSIS signaling in the core (i.e. between QI and QC). Hence, in the short/medium-term the NSIS protocol will be used between the QI and QC and an access technology dependent protocol will be used between the host and the QI. However, once an NSIS protocol has been specified and deployed between QI and QC the access networks may gradually start to adopt NSIS signaling. This implies that the QoS Initiator becomes integrated in the end-host and that the NSIS protocol is also used to setup QoS in the access. Of course, this is an evolution scenario since there is a large installed base of cable, UMTS, xDSL access networks only supporting their own QoS signaling methods. Hence, in the long-term the NSIS signaling protocol may be supported by the end-host (acting as QoS Initiator) and may also be used for QoS signaling in the access network, realizing effectively end-to- end (NSIS) QoS signaling. 6. Requirements on the QoS Initiatorûto-QoS Controller interface Per-flow QoS requests are mapped onto an SLS. Hence, most of the complexity resides in the specification and provisioning of SLSs. This results in a small set of requirements for the end-user QoS signaling. The QoS Initiator must map the parameters from the host-to-QI interface on the QoS Initiator-to-QoS Controller (NSIS) protocol. This section discusses the signaling requirements and parameter groups that need to be signaled. 6.1 Signaling requirements 1) The protocol should be lightweight. The required processing power and memory consumption per QoS request should be very small at the QoS Controller such that large amounts of reservation requests can be processed per time unit. The protocol Buchli et al. Informational - Expires August 2002 15 QoS signaling architecture, interfaces February 2002 and requirements can be lightweight since the complexity resides in the pre- provisioning of resources by means of SLSs. 2) The time to setup a QoS connection should be constrained to one or a few round trip times. This may be necessary for a telephony application because this requires a small call setup delay. Short set up times can be achieved by the two-step approach discussed earlier in this draft, i.e. pre-provision bandwidth pipes by means of SLSs and map flow in these bandwidth pipes. 3) Support of priority A minimal support of priority and preemption in case of congestion may be needed in the signaling or in the class description. 4) Immediate notification of QoS failure The signaling must allow the users to be notified in case of QoS failure or violation. This notification must be immediate if no local recovery action is taken. The notification should occur when local recovery actions are taken. This requirement is due to the high reliability of the service that needs at least to make the user know in case the QoS is no more guaranteed. 5) Both in-band and out-of-band signaling should be supported. This implies that the QoS Initiator and QoS Controller may not be located on the data path of the media flow. See e.g. the UMTS use case. The main advantage of out-of-band signaling is that it avoids the need to upgrade (edge) routers with e.g. the NSIS protocol. Indeed the QCs can be deployed on existing (DiffServ) IP networks. In other words, the network needs only to provision bandwidth pipes (e.g. by means of DiffServ PDBs) while the QoS Controller performs per-flow admission control into these pipes and processes the per-flow (NSIS) signaling. Therefore, the NSIS protocol MUST allow for interworking between both in-band and out-of-band signaling approaches for (gradual) deployment reasons. 6) The protocol should be independent of core transport technology as opposed to the access part where the transport and QoS are technology specific. Because of this there is a need for interworking between the QoS in the access network with the QoS in the core network in order to offer end-to-end QoS (i.e. from host to host). 7) The signaling information should be independent from the protocol that carries it. Different protocols may be used but the semantics should be the same. The information semantics of the host-to-QI protocol must be mapped on a QI-to-QC protocol. This mapping should take place in the QoS Initiator. This couples the technology dependent signaling protocols in the access with a generic protocol in the core. In order to do this a minimal set of protocol parameters that need to be mapped should be specified. Buchli et al. Informational - Expires August 2002 16 QoS signaling architecture, interfaces February 2002 and requirements 8) Multicast consideration should not impact the protocol complexity for unicast flows. Multicast support is not considered as a priority, because the targeted interactive multimedia services are mainly unicast. For this reason, if considered in the solution, multicast should not bring complexity in the unicast scenario. 9) Effective support of unidirectional reservations Bidirectional reservations are considered as almost impossible in a multidomain configuration due to the unidirectional nature of IP. So bidirectionnal reservations are considered as exceptional if not out of the scope of the protocol. 10) the mobility aspects should have no impact on the NSIS protocol A QoS controller should not be affected by mobility issues. In UMTS networks, the users has an anchor point in the GGSN, and thus does not require mobility support. 11) Optimization for interactive multimedia services The SIP/H.323 applications are foreseen as the main drivers for end to end QoS solutions. NSIS protocols should be designed in order to be optimised for such traffics. 12) Support for different service levels The protocol should be able to support different service levels for a service class. This may, for instance, be used in relation to olympic service classes ("gold", "silver" and "bronze") 6.2 Requirements on protocol content The per-flow QoS requests are mapped onto the bandwidth pipe, which is specified by an SLS. These pipes may provide statistical guarantees such as delay and packet loss bounds (depending on the QoS class). In order to invoke per-flow QoS services the only parameter needed is a required rate, a means to identify the data path (mapping on SLS) and eventually a reservation identifier. 1) Microflow/reservation description The signaling should allow the request to describe the microflow whose QoS would be guaranteed by giving at least the source and destination IP addresses of the media flow. In case the QC is stateful (per microflow) there may be a need to include a unique reservation identifier (e.g. QI identifier+counter) such that in case of e.g. a tear down message the reservation can be easily identified in the QC. 2) Traffic descriptor The required peak rate must be signaled. Optionally the traffic parameters may be expressed in terms of token bucket parameters (similar to the TSpec in RSVP). Buchli et al. Informational - Expires August 2002 17 QoS signaling architecture, interfaces February 2002 and requirements 6.3 Open issues Two points are left as open issues: 1) The protocol may be stateful or stateless. Because of the two-level approach, statefulness needs to be considered both for the pre-provisioned pipes and for the microflows. Clearly, per QoS-class state will need to be maintained by the NMS and the QC; so the (long-term) bandwidth pipe reservations always should be stateful. It is not clear yet whether per microflow state should be maintained by the QC. A stateful approach allows simple implementation of per-flow notification of QoS violation and priority/preemption. This may be feasible in some parts of the network because the two-step approach strongly reduces the state information that needs to be kept. Still, in core networks the number of reservations may be too large to use a stateful approach. A stateful approach can keep hard-state or soft-state. Regardless of the fact whether hard-state or soft-state is used, we see a possible need for explicit refresh/feedback messages that may be used for teardown and/or performance notification (performance level and/or violation). Note that these messages may be per-flow or per-class. A stateless approach may simply decrement/increment capacity on pre- provisioned bandwidth pipes without keeping per-flow state. In this case, the information required for priority support and/or QoS failure notification may be implemented on a per-class basis. Note that in this case, only one setup message should be sent in order to avoid duplicate reservation. Notification messages should be clearly distinguishable as such in order to avoid unnecessary or unwanted allocation or deallocation of resources. 2) Grouping of microflows As a consequence of the optimization for the interactive multimedia services, the signaling should allow one unique request for several micro flows having the same origination and destination IP addresses. This is usually the case for multimedia SIP calls where the voice and video micro flows follow the same path. This grouping of requests allows optimization of the QoS processing. Note that this may be detrimental for the call setup time. The use of grouping for microflows may be restricted to teardown and/or notification messages when call setup time is a concern. 7. Security Considerations This draft does not identify other security aspects than those described in [8]. Buchli et al. Informational - Expires August 2002 18 QoS signaling architecture, interfaces February 2002 and requirements 8. Conclusions Based on the use cases of an interconnection scenario of PSTN trunking gateways and an interconnection scenario between a UMTS access network and an IP core network, a general architecture is proposed and the different protocol interfaces where identified. These are between the: 1) host and the QoS Initiator, 2) QoS Initiator and the Access Gate, 3) QoS Initiator and the QoS Controller, 4) QoS Controller and the Network Management System. The QoS signaling in the access is usually technology dependent. However, the QoS signaling in the core should be technology independent. The signaling protocol requirements and the parameter groups to be signaled between the QoS Initiator and the QoS Controller where discussed in this draft. The proposed architecture involves two steps in QoS provisioning: 1) Provisioning of bandwidth pipes between the ingress and egress points of the IP core network by means of SLSs. This involves configuration of network elements by a Network Management System. 2) Admission control of per-flow QoS request in the pre-provisioned bandwidth pipes. In other words, a functional entity in the network checks if the usage of the bandwidth pipe between the ingress and egress points of the network does not exceed the capacity specified in the SLS. Hence, this step does not involve any configuration of network elements. The following recommendations are made towards the NSIS working group: 1) A first priority for NSIS should be the signaling interface between the QoS Initiator and the QoS Controller. This is completely in line with the recommendation in [8]. 2) The protocol between the host and the QoS Initiator is access technology dependent. Therefore, NSIS should study the different access signaling protocol and assess whether they contain the minimal set of protocol parameter groups (that have to be defined in step 1). If not, changes may be proposed for these access signaling protocols. 3) The SLS interface between the QoS Controller and the NMS is used for SLS negotiation and for the exchange of SLS monitoring information. The SLS negotiation may be off-line by means of a paper contract or may be semi-dynamically signaled. The monitoring aspect of SLSs is very important and requires that the protocol between the NMS and the QC is able to exchange such information. Therefore, NSIS may consider adding this signaling interface to their scope. Buchli et al. Informational - Expires August 2002 19 QoS signaling architecture, interfaces February 2002 and requirements 9. Acknowledgment The authors would like to acknowledge Alban Couturier for his contributions to the QoS signaling requirement section. The authors would also like to acknowledge Christian Jacquenet, George Pavlou, Richard Egan, David Griffin, Panos Georgatsos, Pim Van Heuven, Eleni Mykoniati and other participants in the TEQUILA project for their input and reflection on this work. References 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 2 RFC 2205 Braden, R. et al., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997. 3 RFC 2223 Postel, J. and Reynolds, J., "Instructions to RFC Authors", RFC 2223, October 1997. 4 RFC 2748 Boyle, J. et al., "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. 5 RFC 3015 Cuervo, F. et al., "Megaco Protocol Version 1.0", RFC 3015, November 2000. 6 RFC 3086 Nichols, K. and Carpenter, B., "Definition of Differentiated Services Per Domain Behaviors and Rules for their specification", RFC 3086, April 2001. 7 Bos, L. et al., "A Framework for End-to-End User Perceived Quality of Service Negotiation", draft-bos-mmusic-sdpqos- framework-00.txt, Work in Progress, November 2001. 8 Brunner, M. et al., "Requirements for QoS Signaling Protocols", draft-brunner-nsis-req-00.txt, Work in Progress, November 2001. 9 Goderis, D. et al., "Service Level Specification Semantics, Parameters and negotiation requirements", draft-tequila-sls- 02.txt, Work in Progress, February 2002. 10 Grossman, D., "New terminology for diffserv", , draft-ietf- diffserv-new-terms-08.txt, work in progress, January 2002. 11 Sidebottom, G. et al., "SS7 MTP3-User Adaptation Layer (M3UA)", draft-ietf-sigtran-m3ua-12.txt, Work in Progress, Febuary 2002. Buchli et al. Informational - Expires August 2002 20 QoS signaling architecture, interfaces February 2002 and requirements 12 Westberg, L. et al., "Resource Management in Diffserv (RMD) Framework", draft-westberg-rmd-framework-01.txt, Work in Progress, February 2002. 13 IETF Middlebox Communication (MIDCOM) working group, http://www.ietf.org/html.charters/midcom-charter.html/ 14 IST-Tequila project http://www.ist-tequila.org/ Author's Addresses Maarten Buchli Alcatel Network Strategy Group Francis Wellesplein 1 B-2018 Antwerpen Phone: +32 3 2407081 BELGIUM Email: maarten.buchli@alcatel.be Danny Goderis Alcatel Network Strategy Group Francis Wellesplein 1 B-2018 Antwerpen Phone: +32 3 2407853 BELGIUM Email: danny.goderis@alcatel.be Sven Van den Bosch Alcatel Network Strategy Group Francis Wellesplein 1 B-2018 Antwerpen Phone: +32 3 2408103 BELGIUM Email: sven.van_den_bosch@alcatel.be Juan-Carlos Rojas Alcatel Next Generation Networks Division Le Mail F-44708 Orvault Cedex Phone: +33 2 51781282 FRANCE Email: juan-carlos.rojas@alcatel.fr Stefan Custers Alcatel Next Generation Networks Division Francis Wellesplein 1 B-2018 Antwerpen Phone: +32 3 2409071 BELGIUM Email: stefan.custers@alcatel.be Buchli et al. Informational - Expires August 2002 21