Internet Draft NSIS QoS Signalling Requirements February 2002 Internet Engineering Task Force D. Partain (ed.), Ericsson INTERNET-DRAFT A. Bergsten, Telia Expires August 2002 M. Greis, Nokia G. Karagiannis, Ericsson J. Manner, U. of Helsinki J. Murphy, Juniper P. Pan, Juniper V. Rexhepi, Ericsson L. Westberg, Ericsson H. Zheng, Nokia NSIS QoS Signalling Requirements draft-partain-nsis-requirements-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Partain, et al. Expires August 2002 [Page 1] Internet Draft NSIS QoS Signalling Requirements February 2002 Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo identifies a set of requirements that must be applied to the development of the NSIS quality of service (QoS) signalling protocol. These requirements are based upon the needs of various kinds of applications that will utilize IP networks and need to be able to signal their QoS needs. 1. Introduction Some applications, such as real-time applications, impose strict QoS requirements on the underlying transmission network. This level of QoS can only be achieved with QoS management on an end-to-end basis (i.e., end user to end user), from application to application. This will potentially be across many domains since the Internet is a concatenation of many domains, usually managed by different QoS administrators (operators). End-to-end QoS management does not necessarily mean that a single one-size-fits-all QoS signalling protocol must be applied end-to-end. In fact, it is most likely that the end-to-end QoS management architecture will consist of many interoperable and concatenated QoS management architectures rather than one global end-to-end QoS infrastructure. While the NSIS QoS signalling protocol may indeed be used end to end, it will also be necessary to interoperate with other mechanisms which provide for end-to-end signalling (e.g., RSVP). This memo begins by describing different IP scenarios and application areas which support a large volume of real-time traffic (mixed with best effort traffic). These applications need a simple, scalable and very fast QoS signalling protocol. Given this set of applications, we list a set of requirements to be fulfilled by the NSIS QoS signalling protocol. The requirements are built upon these various scenarios as "use cases". Each of these scenarios has a set of requirements that needs to be fulfilled in order for a QoS signalling protocol to be useful within that context. Some of these requirements may be common to other scenarios, while some may indeed be unique to that environment. Partain, et al. Expires August 2002 [Page 2] Internet Draft NSIS QoS Signalling Requirements February 2002 In any requirements discussion, there is always a risk that everyone's favorite set of requirements will be pulled in to create a union of all possible requirements. By using these scenarios as the basis of requirements, we are trying to limit the requirements to a reasonable subset that is applicable to the most acute QoS signalling needs today. This in no way negates the validity of other requirements but rather is an attempt to prioritize the work. Typically an end-to-end QoS management architecture consists of many interoperable and concatenated QoS management architectures. Each QoS domain is responsible for taking its own decisions in its own domain- specific ways. An example is shown in Figure 1, where the end-to-end QoS management architecture consists of two concatenated QoS domains. This QoS architecture uses different types of interfaces: * interior <-> interior interface: provides basic QoS functionality, such as scalable, simple and fast QoS provisioning. Due to the fact that different networks have different characteristics, such as cost of bandwidth and performance, this basic QoS functionality may differ from one QoS domain to another. * BN <-> BN interface: provides the QoS functionality for a complete QoS domain by interacting with the interior <-> interior interfaces. * Host <-> BN interface: in addition to the basic QoS functionality, this interface has to provide a user with secure access to the network. Therefore, this interface will have to provide security functions, such as authentication and authorization. QoS domain QoS domain |------------------| |------------------| | | | | |-----| |-----| |----| |-----| |-----| |----| |-----| |-----| | |<->| |<->| |<->| |<->| |<->| |<->| |<->| | |-----| |-----| |----| |-----| |-----| |----| |-----| |-----| | | | | |------------------| |------------------| host BN interior BN BN interior BN host (access w/in domain (edge) (edge) w/in domain (access router) router) Partain, et al. Expires August 2002 [Page 3] Internet Draft NSIS QoS Signalling Requirements February 2002 Figure 1: The end-to-end QoS architecture Different types of QoS requirements are imposed on these interfaces due to the different characteristics of the interfaces used in the QoS architecture. In addition, the different parts of the network often have different service and billing structures, with different trust models, all of which translate into signalling needs with varying degrees of complexity. These are the reasons for separating the generic QoS requirements into QoS requirements specific to a particular interface. 2. Terminology Editor: There is certainly going to be work that needs to be done on this section. - End-to-End QoS QoS management applied in all the domains from end-host to end-host. In some scenarios this can be the NSIS QoS protocol and in other scenarios it might be an existing QoS protocol. - QoS administrative domain A network wherein the QoS provisioning is managed by one administrator (or operator). - Edge Node Router on the boundary of a QoS administrative domain. - Interior Node Routers inside a single domain that are not edge nodes. - Border node A "box" that represents entities such as edge node (or edge router), access router, border router, proxy, gateway, inter-provider-router, CPE (customer provider equipment edge), PE (provider equipment edge), but it does not represent a host or an interior node. It provides interior node functionality, as well as additional functions, such as: Partain, et al. Expires August 2002 [Page 4] Internet Draft NSIS QoS Signalling Requirements February 2002 * QoS functionality on a complete QoS domain, such as an edge node. Note that the minimum functionality that a border node can provide is the functionality that an edge node (or edge router) provides. * supports authentication, accounting, such as an access router or a border router * supports initiation and termination of the NSIS protocol, and/or interworking with other QoS protocols, such as proxies, BTSs, BSC/RNCs, and media gateways - Single-domain QoS domain administrated by a single administrator (operator). - Multi-domain Multiple QoS domains managed by different administrators (operators), but seen by the NSIS QoS protocol as a single-domain. 3. IP scenarios and application areas A number of different QoS solutions have been developed by the IETF. However, there are IP scenarios and application areas that require a different or at least modified QoS signalling protocol. Given the framework above, this memo outlines a set of requirements for different applications that will use these networks. In all the scenarios (end-to-end, edge-to-edge or end-to-edge) where the NSIS protocol is used for signalling and where it is processed by the nodes along the communication path, the data MUST follow the same path as the signalling messages. 3.1. Mobile IP In this scenario, as shown in Figure 2, a mobile host can roam and perform a handover procedure between Access Routers (i.e., border Partain, et al. Expires August 2002 [Page 5] Internet Draft NSIS QoS Signalling Requirements February 2002 nodes). In this scenario, the NSIS QoS protocol can be applied between an Access Router and a proxy (i.e., border node) which we denote as "Joint point of reservation"." The "Joint point of reservation" router is located in the QoS aware segment that maintains an end-to-end reservation, but due to handover it should change/modify this reservation. Moreover, this router provides the bridging function between a local NSIS QoS protocol and the end-to- end QoS protocol (which could be the NSIS QoS protocol). In many handover situations (e.g., when reverse tunneling and no route optimization is used) an example of such a router would be the Home Agent. As can be seen, the border nodes used in this QoS architecture are the Access Routers and the "Joint point of reservation". There are cases were the Access Router and the left most Edge Router shown in the Figure 2 can be included in one entity (i.e., AR). |--| |MH|---/ |--| / |--------| /--| Access | |--| | Router |-|ER|.... |-------------| |--------| |--| . |--| | Proxy | |----| ...|ER|..|(Joint point |...."Internet"..|host| -- |--------| |--| . |--| |reservation: | |----| |--| \ | |-|ER|.... | PROXY) | |MH| \ | Access | |--| |-------------| |--|--- | Router | MH = mobile host |--------| ER = edge router BN = border node ... = interior nodes Figure 2: Mobile IP QoS Architecture 3.2. Wired part of wireless network A wireless network, seen from a QoS domain perspective, usually consists of three parts: a wireless interface part (the "radio interface"), a wired part of the wireless network (i.e., Radio Access Network) and the backbone of the wireless network, as shown in Figure 3. Note that this figure should not be seen as an architectural overview of wireless networks but rather as showing the conceptual QoS domains in a wireless network. In this scenario, a mobile host can roam and perform a handover Partain, et al. Expires August 2002 [Page 6] Internet Draft NSIS QoS Signalling Requirements February 2002 procedure between base stations/access routers (i.e., border nodes). In this scenario the NSIS QoS protocol can be applied between a base station and the gateway (GW) (i.e., border node). In this case a GW can also be considered as a local handover anchor point. Furthermore, in this scenario the NSIS QoS protocol can also be applied either between two GWs, or between two edge routers (ER) (i.e, border nodes). |--| |GW| |--| |--| |MH|--- . |--| / |-------| . /--|base | |--| . |station|-|ER|.... |-------| |--| . |--| back- |--| |---| |----| ...|ER|.......|ER|..|BGW|.."Internet"..|host| -- |-------| |--| . |--| bone |--| |---| |----| |--| \ |base |-|ER|... . |MH| \ |station| |--| . |--|--- |-------| . MH = mobile host |--| ER = edge router <----> |GW| GW = gateway Wireless link |--| BGW = border gateway ... = interior nodes <-------------------> Wired part of wireless network <----------------------------------------> Wireless Network Figure 3. QoS architecture of wired part of wireless network Each of these parts of the wireless network impose different requirements on the QoS signalling solution being used: * Wireless interface: The solution for the air interface link has to ensure flexibility and spectrum efficient transmission of IP packets. However, this link layer QoS can be solved in the same way as any other last hop problem by allowing a host to request the proper QoS profile. * Wired part of the wireless network: This is the part of the network that is closest to the base stations/access Partain, et al. Expires August 2002 [Page 7] Internet Draft NSIS QoS Signalling Requirements February 2002 routers. It is an IP network although some parts logically perform tunneling of the end user data. In cellular networks, the wired part of the wireless network is denoted as a radio access network. This part of the wireless network has different characteristics when compared to traditional IP networks: 1. The network supports a high proportion of real-time traffic. The majority of the traffic transported in the wired part of the wireless network is speech, which is very sensitive to delays and delay variation (jitter). 2. The network must support mobility. Many wireless networks are able to provide a combination of soft and hard handover procedures. When handover occurs, reservations need to be established on new paths. The establishment time has to be as short as possible since long establishment times for reservations degrade the performance of the wireless network. Moreover, for maximal utilization of the radio spectrum, frequent handover operations are required. 3. These links are typically rather bandwidth-limited. 4. The wired transmission in such a network contains a relatively high volume of expensive leased lines. Overprovisioning might therefore be prohibitively expensive. 5. The radio base stations are spread over a wide geographical area and are in general situated a large distance from the backbone. * Backbone of the wireless network: the requirements imposed by this network are similar to the requirements imposed by other types of backbone networks. Due to these very different characteristics and requirements, often contradictory, different QoS signalling solutions might be needed in each of the three network parts. Partain, et al. Expires August 2002 [Page 8] Internet Draft NSIS QoS Signalling Requirements February 2002 3.3. QoS signalling between PSTN gateways and backbone routers A PSTN gateway (i.e., host) requires information from the network regarding its ability to transport voice traffic across the network. The voice quality will suffer due to packet loss, latency and jitter. Signalling is used to identify and admit a flow for which these impairments are minimized. In addition, the disposition of the signalling request is used to allow the PSTN GW to make a call routing decision before the call is actually accepted and delivered to the final destination. PSTN gateways may handle thousands of calls simultaneously and there may be hundreds of PSTN gateways in a single provider network. These numbers are likely to increase as the size of the network increases. The point being that scalability is a major issue. There are several ways that a PSTN gateway can acquire assurances that a network can carry its traffic across the network. These include: 1. Over-provisioning a high availability network. 2. Handling admission control through some policy server that has a global view of the network and its resources. 3. Per PSTN GW pair admission control. 4. Per call admission control (where a call is defined as the 5 tuple used to carry a single RTP flow). Item 1 requires no signalling at all and is therefore outside the scope of this working group. Item 2 is really a better informed version of 1, but it is also outside the scope of this working group as it relies on a particular telephony signalling protocol rather than a packet admission control protocol. Item 3 is initially attractive as it appears to have reasonable scaling properties, however, its scaling properties only are effective in cases where there are relatively few PSTN GWs. In the more general case were a PSTN GW reduces to a single IP phone sitting behind some access network, the opportunities for aggregation are reduced and the problem reduces to item 4. Item 4 is the most general case. However, it has the most difficult scaling problems. The objective here is to place the requirements on Partain, et al. Expires August 2002 [Page 9] Internet Draft NSIS QoS Signalling Requirements February 2002 Item 4 such that a scalable per-flow admission control protocol or protocol suite may be developed. The case where per-flow signalling extends to individual IP end- points allows the inclusion of IP phones on cable, DSL, wireless or other access networks in this scenario. Call Scenario - A PSTN GW signals end-to-end for some 5 tuple defined flow a bandwidth and QoS requirement. The access network admits this flow according to its local policy and the specific details of the access technology. Flow request may be authenticated - access routers (i.e., border nodes) may need to interwork with a policy server to admit the flow. At the edge router (i.e., border node), the flow is admitted, again with an optional authentication process, possibly involving an external policy server. Note that the relationship between the PSTN GW and the policy server and the routers and the policy server is outside the scope of NSIS, the point is that the signalling protocol should support any hooks required to make this authentication possible. The edge router then admits the flow into the core of the network, possibly using some aggregation technique. The job of policing the actual packet flow may be performed by either the access or edge router depending on where the trust border lies. It is likely that whomever authenticates the request would also police the flow. For the purposes of accounting, the policing router should also provide accounting data to some external server. Again the access or edge router could perform this function, depending on the trust border, etc. At the interior nodes, the NSIS host-to-host signalling should either be ignored or invisible as the Edge router performed the admission control decision to some aggregate. At the inter-provider router (i.e., border node), again the NSIS host-to-host signalling should either be ignored or invisible as the Edge router has performed an admission control decision about an aggregate across a carriers network. The only requirement of the inter-provider routers is to police the aggregate and to know what to Partain, et al. Expires August 2002 [Page 10] Internet Draft NSIS QoS Signalling Requirements February 2002 police it to. How inter-providers know the size of the aggregate is outside the scope of NSIS, but suffice it to say that we can assume that the Edge router can perform the admission control function into some aggregate. 3.4. QoS for Virtual Private Networks There are two types of L3 VPNs, distinguished by where the endpoints of the tunnels exist. The endpoints of the tunnels may either be on the customer (CPE) (i.e., Border Node), or the provider equipment or provider edge (PE) (i.e., Border Node). Virtual Private networks are also likely to request bandwidth for Assured Forwarding style services in addition to the Expedited Forwarding services the PSTN GW are likely to use. 3.4.1. Tunnel end points at the CPE When the endpoints are the CPE, the CPE may want to signal across the public IP network for a particular amount of bandwidth and QoS for the tunnel aggregate. Such signalling may be useful when a customer wants to vary their network cost with demand, rather than paying a flat rate. Such signalling exists between the two CPE routers. Intermediate access and edge routers perform the same exact call admission control, authentication and aggregation functions performed by the corresponding routers in the PSTN GW scenario with the exception that the endpoints are the CPE tunnel endpoints rather than PSTN GWs and the 5-tuple used to describe the RTP flow is replaced with the corresponding flow spec to uniquely identify the tunnels. Tunnels may be of any variety (eg. IP-Sec, GRE, IP-IP). 3.4.2. Tunnel end points at the PE In the case were the tunnel end-points exist on the provider edge, requests for bandwidth may be signaled either per flow, where a flow is defined from a customers address space, or between customer sites. In the case of per flow signalling, the PE router must map the bandwidth request to the tunnel carrying traffic to the destination specified in the flow spec. Such a tunnel is a member of an aggregate to which the flow must be admitted. In this case, the operation of admission control is very similar to the case of the PSTN GW with the Partain, et al. Expires August 2002 [Page 11] Internet Draft NSIS QoS Signalling Requirements February 2002 additional level of indirection imposed by the VPN tunnel. Therefore, authentication, accounting and policing may be required on the PE router. In the case of per site signalling, a site would need to be identified. This may be accomplished by specifying the network serviced at that site through an IP prefix. In this case, the admission control function is performed on the aggregate to the PE router connected to the site in question. 4. Assumptions and non-goals of the QoS Signalling Protocol In determining the requirements to be placed upon a QoS signalling protocol, it is important that the assumptions of the work are clearly stated. This section identifies a set of problems which are specifically not targeted by the NSIS QoS signalling protocol. - Multicast support introduces a significant level of complexity to QoS signalling and should consequently be left for future work. - The user networks and IP backbone know how to manage their own network resources and must satisfy QoS requirements once packets are inside their network. More importantly, it is not required to have a unified signal and resource management technique in all networks. - Though, in theory, the only applications that require QoS guarantees are interactive real-time applications, the signalling protocol MUST be independent of the application type. - Several groups have been and are working on the protocols used by bandwidth brokers to manage resources within a QoS domain and between domains. While it is possible that the NSIS QoS signalling protocol may be useful in this scenario, bandwidth brokering protocols is not the target of this work. Specifically, NSIS signalling may be used by a border node to admit a flow into its domain. This border node may interwork with a bandwidth broker. However, the details of this interworking are outside the scope of these requirements. Partain, et al. Expires August 2002 [Page 12] Internet Draft NSIS QoS Signalling Requirements February 2002 - Application-specific QoS signalling above layer 3. For example, no attempt is made to infringe upon the applicability of SIP. Application signalling protocols may be used to set up authentication servers, etc. But there is no assumption from NSIS signalling that such application signalling exists or is required. - Layer 2 specific QoS work, such as the specific parameters necessary for setting up the air interface in the most efficient manner. Indeed, the layer 3 information should be sufficient to drive the layer 2 setup. How layer 3 information is mapped to a specific layer 2 network is outside the scope of these requirements. There should, though, be enough layer 3 information available to the layer 2 entity. - Receiver-initiated QoS signalling. While there are possible scenarios where the receiver initiates the signalling, such as a web QoS scenario, this should be solved at the application layer for unicast flows. The host signalling into the network should be sender-initiated. 5. QoS requirements This section presents the QoS requirements imposed by the IP scenarios described in the previous sections. In particular, the following subsections present the QoS requirements that affect the "host to border node", "border node to border node" and "interior - interior" interfaces, respectively. Furthermore, additional QoS requirements that affect these interfaces are described in Section 5.4, where the border node can initiate and terminate the NSIS QoS signalling protocol. 5.1. QoS requirements on Host - BN interface These QoS requirements affect only the Host to border node interface, and therefore should be only processed by mobile hosts and/or border nodes. Note that the only case considered in this section is when the border node is not capable of initiating and terminating the NSIS protocol. Partain, et al. Expires August 2002 [Page 13] Internet Draft NSIS QoS Signalling Requirements February 2002 5.1.1. Low overhead and allow for efficient bandwidth usage The QoS signalling protocol should allow the processing of the QoS signalling messages to be as simple as possible, and it should take as few messages as possible to set up a reservation. This is especially important on mobile hosts with limited resources and power. This simplicity requirement may also help to reduce the delay of the QoS signalling procedure. Furthermore, the QoS parameters must be understandable, simple, but also intuitive to the "user" (e.g. end user or API developer) or communicating partners. 5.1.2. Flexible and extensible It must be possible to include special parameters for different access technologies in the QoS signalling protocol. Also, it must be possible to extend the QoS signalling protocol to adapt to future access technologies. This implies that the signalling protocol and the information it carries must be de-coupled from each other. 5.1.3. Enable QoS negotiation between host and network in efficient manner "QoS negotiation" in this context describes the process of an actual negotiation which may take place between a host and the network. That is, the QoS request from the host would be seen as a proposal, which can be either accepted, rejected or downgraded by the network. This final option leaves it up to the host, whether it wants to establish the communication based on the modified QoS. The QoS signalling protocol should allow QoS negotiation between the end node and the network or the remote endpoint in an efficient way. The efficiency can be measured by delay, bandwidth required, etc. Delay can in this context result from the number of round trip times, the processing time, and the size of the signalling messages. Partain, et al. Expires August 2002 [Page 14] Internet Draft NSIS QoS Signalling Requirements February 2002 5.1.4. Allow the combination of soft state and explicit QoS release principles In designing the QoS signalling protocol that can be used for signalling QoS needs, there needs to be a balance between how often a request is refreshed and efficiency of utilization. If the refresh timer is too long, this will result in poor utilization of the network resources. If it is instead too short, this will result in a potential signalling burden on the network. In order to achieve good balance, the QoS signalling prototol SHOULD use both soft state and an explicit release. After call termination, unneeded states related to the QoS signalling in the network should be released as soon as possible. Therefore, in addition to the soft state release principle, the QoS signalling protocol must allow a host to send a QoS release request explicitly. Furthermore, if the host is a mobile node, it may be the responsibility of the network to remove old reservations at the old access point after handovers. It must be possible to implement such mechanisms in the network. 5.1.5. Allow QoS authorization and policy control QoS authorization and policy control provide operators with service control. QoS signalling must include necessary information to be used for the network to authorize the QoS request and perform policy control. 5.1.6. Support common security features This includes privacy and anonymity support as well as the integrity of signalling packets. 5.1.7. Allow authentication of the QoS request QoS requests need to be authenticated before QoS authorization is performed. QoS signalling must be able to carry necessary information used by the network to authenticate the QoS request. Partain, et al. Expires August 2002 [Page 15] Internet Draft NSIS QoS Signalling Requirements February 2002 5.1.8. Provide hooks for accounting QoS signalling protocol should include necessary information for the network to collect charging data for a specific user. 5.1.9. Independent of different mobility protocols Although QoS signalling may be able to take advantage of specific mobility protocols for optimized operation, it should be designed independent of mobility protocols in the sense that it can still perform the same functionality when one or more of these mobility protocols are not used. 5.1.10. Network structure must be invisible to end hosts End hosts MUST NOT be required to be aware of network topology in order to be able to get the QoS that they desire. The implementation of QoS in the network, including its topology, need not be visible to the end hosts. The QoS interface shall only reflect the "bearer requirements" that a host can request. Any mechanism or combination of mechanisms can be used together to provide the overall QoS. 5.1.11. Interwork with IP tunneling The QoS signalling and provisioning mechanisms must operate in networks that make use of IP tunneling, but also IPSec. The signalling messages need to be visible to the network QoS nodes, but also the data packets that would need a specific QoS need to be identified. 5.1.12. Support different types of QoS requests It must be possible to signal different QoS service types, both flow- based (per-single-flow or per-aggregated-flow) as well class-based (e.g. priority based traffic classes, drop precedences traffic Partain, et al. Expires August 2002 [Page 16] Internet Draft NSIS QoS Signalling Requirements February 2002 classes). 5.1.13. Work with changing IP addresses of (mobile) hosts Mobile hosts may need to change their CoA while QoS is provisioned for them. The signalling mechanism must make it possible to change the identification information related to provisioned QoS to keep the QoS allocated to a mobile host's flows, either upstream or downstream. 5.1.14. Deal with IP fragmentation gracefully Signalling messages might be fragmented in transit from sender to receiver. This has the potential of rendering that signalling message useless. As such, care should be taken in designing the protocol to minimize the possibility of fragmentation. Fragmentation of signalling packet SHOULD be managed by the end host, as is done in IPv6. This means that the sender SHOULD set the "Don't Fragment" bit and react to possible ICMP messages. 5.1.15. Sender initiated A sender-initiated QoS signalling protocol is a protocol where the sender of the data is also the initiator of the QoS reservations. This is unlike receiver-initiated procols, such as RSVP [RFC2205], where the QoS reservations are initiated by the receiver of the user data. What this means is that the admission control and the resource allocation on all the nodes that process the signalling protocol in the communication path from the sender to the receiver will be initiated by the sender of the data. However, the triggering of the sender-initiated QoS signalling protocol can be done by either the sender or the receiver of the user data. The triggering can be part of NSIS protocol or it may be another protocol. The scenarios described above require a QoS signalling protocol that Partain, et al. Expires August 2002 [Page 17] Internet Draft NSIS QoS Signalling Requirements February 2002 is initiated very quickly by either a fixed or a mobile host. A sender-initiated QoS signalling protocol applied in these kinds of scenarios operates more efficiently than a receiver initiated QoS signalling protocol for the following reasons: * Using a sender-initiated approach, the sender can be informed faster when the reservation request is rejected, than when using a receiver initiated approach. In other words, when using a sender initiated approach, in the case of an unsuccessful reservation, the reservation request response time can be shorter than with a receiver initiated approach. * When using a a sender-initiated approach, backward routing is not necessary. * In a sender initiated approach, a mobile node can initiate a reservation as soon as it has moved to another roaming subnetwork. In a receiver-initiated approach, a mobile node has to inform the receiver about its handover procedure, thus allowing the receiver to initiate a reservation. Therefore, a sender initiated QoS signalling protocol is required. See [YESSIR] for further information. 5.1.16. Error handling and redundancy considerations Border nodes should be able to notify the users if there is an error inside the network. There are two types of network errors: - Recoverable errors: this type error can be locally repaired by the network nodes. The network nodes do not have to notify the users of the error immediately. - Unrecoverable errors: the network nodes cannot handle this type of error, and have to notify the users as soon as possible. For example, when there is a network failure inside the backbone, if the backbone routers can utilize redundancy functionality to protect effected user flows, the routers have the option to notify or not notify the users about the failure. On the other hand, if the Partain, et al. Expires August 2002 [Page 18] Internet Draft NSIS QoS Signalling Requirements February 2002 network failure is so severe that backbone routers have to terminate some of the user flows, the routers must notify the users immediately on the network failure. Upon receiving the error messages, the users may have to rely on their own redundancy function to redirect user flows. Thus, the distinction of recoverable and unrecoverable errors is fairly important in signalling protocol design. This can impact the overall signalling process overhead. 5.1.17. Identification requirement The host MUST be able to identify the first hop router (default router). However, the identification of the first hop router may be provided by various mechanisms, including DHCP and Router Advertisements. 5.2. QoS requirements on BN - BN interface These QoS requirements affect only the border node to border node interface, and therefore should be only processed border nodes. Note that the only case considered in this section is when the border node is not capable of initiating and terminating the NSIS protocol. 5.2.1. Ability to traverse a border node transparently In some networks the QoS signalling protocol should transparently be forwarded through a border node, without taking any action. 5.2.2. Allow local QoS information exchange between two border nodes The QoS signalling protocol must be able to exchange local QoS information between edge nodes. Local QoS information might, for example, be IP addresses, severe congestion notification, notification of succesful or erroneous processing of QoS signalling messages at one border node. Partain, et al. Expires August 2002 [Page 19] Internet Draft NSIS QoS Signalling Requirements February 2002 In some domains, the NSIS QoS signalling protocol MAY carry identification of the ingress and egress edge between the ingress- egress edges. However, the identification of edges should not be visible to the end host and only applies within one QoS administrative domain. 5.2.3. Allow generation of local QoS signalling messages Any border node must be allowed to generate QoS signalling messages that can be used locally within a QoS domain. 5.3. QoS requirements on Interior - Interior interface The QoS requirements described in this section affect only the "interior node to interior node" interface, and therefore, should be only processed by interior nodes. 5.3.1. Modular, Simple, with Minimal Impact on Performance Although obvious, it bears saying that any QoS signalling mechanism must be as modular, simple, and scalable as possible and that it should have a minimal effect on the overall performance of the network. 5.3.1.1. Modular While it is clear that a set of mechanisms will not be standardized that is only applicable to the wired part of the wireless network, it must be possible to use only a part of the QoS signalling mechanism that is applicable to that network. That is, a standardized QoS signalling mechanism should be a toolkit from which one can choose the applicable tools in order to manage QoS in a particular networking environment. 5.3.1.2. Simple It is critical that the QoS signalling protocol be as simple as possible to implement in the interior nodes since in most cases there Partain, et al. Expires August 2002 [Page 20] Internet Draft NSIS QoS Signalling Requirements February 2002 will be more interior routers (<= 10 depending on network structure) in the path between the edges than there are edge nodes (there are typically two edge nodes located in a communication path). As such, the scheme must be optimized for the interior nodes and not for the edge nodes, thus reducing the requirements placed on the functionality of the interior routers. 5.3.1.3. Minimal Impact on Performance In several networks, the interior nodes will have to support a higher number of micro-flows (user connections) compared to the edge nodes. Therefore, a QoS signalling protocol should be very simple at the interior nodes while it might use more complex mechanisms at the edge nodes. In particular, this means is that the interior nodes must not be required to have per flow responsibilities. The performance of each network node that is used in an end-to-end communication path has an impact on the end-to-end performance. As such, the end-to-end performance of the communication path can be improved by optimizing the performance of interior nodes. One of the factors that can contribute to this optimization is the minimization of the QoS signalling protocol processing load on each device. When the dynamic reservation of the resources is on a per micro-flow basis, the QoS signalling protocol could easily overload a router, causing severe performance degradation. The QoS signalling mechanism must be designed to minimize the cycles spent on processing the signalling messages. One outcome of this requirement is that it uses a simplified lightweight model in the interior nodes and places complex per-flow handling at the edges. This requires mapping of per-flow traffic parameters at the edges into a necessary set of parameters needed for setting up reservations in interior nodes. The edge routers typically already have to perform per-session management/control, and hence complex per flow-handling is not a significant burden. 5.3.2. Ability to deal with mobility (handover) In order to support mobile users, the QoS signalling mechanism must be highly performant for at least the following reasons: Partain, et al. Expires August 2002 [Page 21] Internet Draft NSIS QoS Signalling Requirements February 2002 * Handover rates In mobile networks, the admission control process has to cope with far more admission requests than call setups alone would generate. For example, in the GSM (Global System for Mobile communications) case, mobility usually generates an average of one to two handovers per call. For third generation networks (such as UMTS), where it is necessary to keep radio links to several cells simultaneously (macro-diversity), the handover rate is significantly higher (see for example [KeMc01]). * Fast reservations Handover can also cause packet losses. This happens when the processing of an admission request causes a delayed handover to the new base station. In this situation, some packets might be discarded, and the overall speech quality might be degraded significantly. Moreover, a delay in handover may cause degradation for other users. In the worst case scenario, a delay in handover may cause the connection to be dropped if the handover occurred due to bad air link quality. Therefore, it is critical that QoS signalling in connection with handover be carried out very quickly. Furthermore, when the network is overloaded, it is preferable to keep reservations for previously established flows while blocking new requests. Therefore, the resource reservation requests in connection with handover should be given higher priority than new requests for resource reservation. 5.3.3. On-demand, dynamic signalling for efficient network utilization There are networking environments that require high network utilization for various reasons, and the signalling protocol should to its best ability support high resource utilization while maintaining appropriate QoS. For example, wireless networks typically use a large number of expensive leased lines, which means that efficient network utilization has a direct economic impact on network operators. Real- Partain, et al. Expires August 2002 [Page 22] Internet Draft NSIS QoS Signalling Requirements February 2002 time services require that a portion of network resources is available to them. These resources can be reserved on a static or dynamic basis, or potentially based on some kind of measurement of network load. Both measurement-based and static reservations may result in a poorly utilized network, primarily due to the fact that the network resources are typically reserved for peak real-time traffic values. Mobility in the network makes static configuration even less desirable as the resources will be used even less effectively. By using dynamic reservation, this problem will be avoided since the resources are reserved on demand. There is, of course, a tradeoff. Dynamic reservations will mean that the load from QoS signalling will be much higher than if static reservation of resources is used. If the dynamic reservation of the resources is done on a micro-flow basis, the resulting network load from QoS signalling might be quite high. In networks where resources are very expensive (as is the case for many wireless networks), efficient network utilization is of critical financial importance. As such, static configuration is simply not an option and an appropriately engineered solution allowing dynamic resource reservation is needed. On the other hand there are other parts of the network where high utilization is not required. In these parts of the network, the signalling protocol should be as "unobtrusive" as possible. 5.3.4. Ability to deal with severe congestion In case of a route change or link failure a severe congestion situation may occur in the network. Typically, routing algorithms are able to adapt and change their routing decisions to reflect changes in the topology and traffic volume. In such situations the re-routed traffic will have to follow a new path. Interior nodes located on this new path may become overloaded, since they suddenly might need to support more traffic than they have capacity for. These severe congestion situations will severely affect the overall performance of the traffic passing through such nodes. Therefore, the QoS signalling should exchange severe congestion information between interior and edge nodes. Partain, et al. Expires August 2002 [Page 23] Internet Draft NSIS QoS Signalling Requirements February 2002 5.3.5. Optimize for unicast transport The vast majority of the traffic in typical networks is point-to- point unicast transport. As such, the QoS signalling mechanism must deal with unicast effectively. 5.3.6. Ability to transparently traverse an interior node In some networks the QoS signalling protocol should transparently be forwarded through an interior node, without activating any resource reservation procedure. 5.3.7. Use of a simple QoS parameter In order to simplify and increase the processing speed of interior nodes the QoS signalling protocol must be able to carry a simple (or limited set of) QoS parameter(s). 5.4. BN as initiator and/or terminator of NSIS protocol These additional QoS requirements affect either the "host to border node" interface (see Section 5.1) or the "border to border" interface (see Section 5.2) when the border node is able to initiate and/or terminate the NSIS protocol. 5.4.1. Allow QoS setup for uni-directional and bi-directional reservations When QoS is only required in the upstream direction (i.e., the direction from the end host towards the network), the QoS signalling only needs to trigger QoS establishment in that direction. When QoS is only required in the downstream direction (e.g., a streaming application without a feedback channel), the QoS signalling only needs to trigger QoS setup in that direction. Therefore, the QoS signalling protocol should allow QoS setup for these uni-directional reservations. Also, QoS setup for bi-directional reservations is required, where applications require QoS setup in both directions. Partain, et al. Expires August 2002 [Page 24] Internet Draft NSIS QoS Signalling Requirements February 2002 5.4.2. Support end-to-end, edge-to-edge and end-to-edge signalling The signalling mechanism must work end-to-end, but also, if needed, more locally (i.e., end-to-edge as well as edge-to-edge). The requirement also includes the potential need for signalling towards "middle-boxes" on the transport layer, e.g. firewalls and NATs. 5.4.3. Allow efficient QoS re-establishment after handover Handover is an essential function in wireless networks. After handover, QoS may need to be completely or partially re-established due to route changes. The re-establishment may be requested by the mobile node itself or triggered by the access point that the mobile node is attached to. In the first case, the QoS signalling should allow efficient QoS re-establishment after handover. Re- establishment of QoS after handover should be as quick as possible so that the mobile node does not experience service interruption or QoS degradation. The re-establishment should be localized, and not require end-to-end signalling, if possible. 5.4.4. Enable other network entities to generate QoS request behalf of a node A QoS request is normally generated by the node that requires QoS. However, in some cases, it is beneficial to send a QoS request from a different network entity (a proxy) on behalf of the node. As an example, in a wireless network with limited bandwidth, the initial QoS request may be sent from the node itself, while subsequent requests are sent after handover or refresh messages may be generated by the access router that keeps the QoS request state for the mobile node. The QoS signalling protocol MUST allow such a scenario. 6. Conclusions This memo outlines a set of requirements to be used in the design of the NSIS QoS signalling protocol. These requirements, based on various scenarios in which the protocol would be used, attempt to focus the NSIS efforts on the most essential parts of the problem to be solved. Partain, et al. Expires August 2002 [Page 25] Internet Draft NSIS QoS Signalling Requirements February 2002 7. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. References More to be added later... [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", IETF RFC 2205, 1997. [YESSIR] YESSIR - YEt another Sender Session Internet Reservations, http://www.cs.columbia.edupingpan/projects/yessir.html [KeMc01] Kempf, J., McCann, P., Roberts, P., "IP Mobility and the CDMA Radio Access Network", IETF Draft, draft-kempf-cdma-appl-02.txt, Work in progress, September 2001. Partain, et al. Expires August 2002 [Page 26] Internet Draft NSIS QoS Signalling Requirements February 2002 9. Acknowledgments The editors wish to thank those providing feedback on this document, including (but not limited to) Steven Blake, ... 10. Editors's Addresses David Partain (editor) Ericsson Radio Systems AB P.O. Box 1248 SE-581 12 Linkoping Sweden E-mail: David.Partain@ericsson.com Anders Bergsten Telia Research AB Aurorum 6 977 75 Lulea Sweden E-mail: Anders.P.Bergsten@telia.se Marc Greis Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA E-mail: marc.greis@nokia.com Georgios Karagiannis Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands E-mail: Georgios.Karagiannis@eln.ericsson.se Jukka Manner University of Helsinki P.O. Box 26, FIN-00014 Helsinki Finland E-mail: jukka.manner@cs.helsinki.fi Jim Murphy Partain, et al. Expires August 2002 [Page 27] Internet Draft NSIS QoS Signalling Requirements February 2002 Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 E-mail: murphy@juniper.net Ping Pan Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 E-mail: pingpan@juniper.net Vlora Rexhepi Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands E-mail: Vlora.Rexhepi@eln.ericsson.se Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden E-mail: Lars.Westberg@era.ericsson.se Haihong Zheng Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA E-mail: haihong.zheng@nokia.com Table of Contents 1 Introduction .................................................... 2 2 Terminology ..................................................... 4 3 IP scenarios and application areas .............................. 5 3.1 Mobile IP ..................................................... 5 3.2 Wired part of wireless network ................................ 6 3.3 QoS signalling between PSTN gateways and backbone routers ..... 9 3.4 QoS for Virtual Private Networks .............................. 11 Partain, et al. Expires August 2002 [Page 28] Internet Draft NSIS QoS Signalling Requirements February 2002 3.4.1 Tunnel end points at the CPE ................................ 11 3.4.2 Tunnel end points at the PE ................................. 11 4 Assumptions and non-goals of the QoS Signalling Protocol ........ 12 5 QoS requirements ................................................ 13 5.1 QoS requirements on Host - BN interface ....................... 13 5.1.1 Low overhead and allow for efficient bandwidth usage ........ 14 5.1.2 Flexible and extensible ..................................... 14 5.1.3 Enable QoS negotiation between host and network in effi­ cient manner ................................................. 14 5.1.4 Allow the combination of soft state and explicit QoS re­ lease principles ............................................. 15 5.1.5 Allow QoS authorization and policy control .................. 15 5.1.6 Support common security features ............................ 15 5.1.7 Allow authentication of the QoS request ..................... 15 5.1.8 Provide hooks for accounting ................................ 16 5.1.9 Independent of different mobility protocols ................. 16 5.1.10 Network structure must be invisible to end hosts ........... 16 5.1.11 Interwork with IP tunneling ................................ 16 5.1.12 Support different types of QoS requests .................... 16 5.1.13 Work with changing IP addresses of (mobile) hosts .......... 17 5.1.14 Deal with IP fragmentation gracefully ...................... 17 5.1.15 Sender initiated ........................................... 17 5.1.16 Error handling and redundancy considerations ............... 18 5.1.17 Identification requirement ................................. 19 5.2 QoS requirements on BN - BN interface ......................... 19 5.2.1 Ability to traverse a border node transparently ............. 19 5.2.2 Allow local QoS information exchange between two border nodes ........................................................ 19 5.2.3 Allow generation of local QoS signalling messages ........... 20 5.3 QoS requirements on Interior - Interior interface ............. 20 5.3.1 Modular, Simple, with Minimal Impact on Performance ......... 20 5.3.1.1 Modular ................................................... 20 5.3.1.2 Simple .................................................... 20 5.3.1.3 Minimal Impact on Performance ............................. 21 5.3.2 Ability to deal with mobility (handover) .................... 21 5.3.3 On-demand, dynamic signalling for efficient network uti­ lization ..................................................... 22 5.3.4 Ability to deal with severe congestion ...................... 23 5.3.5 Optimize for unicast transport .............................. 24 5.3.6 Ability to transparently traverse an interior node .......... 24 5.3.7 Use of a simple QoS parameter ............................... 24 5.4 BN as initiator and/or terminator of NSIS protocol ............ 24 5.4.1 Allow QoS setup for uni-directional and bi-directional reservations ................................................. 24 5.4.2 Support end-to-end, edge-to-edge and end-to-edge sig­ Partain, et al. Expires August 2002 [Page 29] Internet Draft NSIS QoS Signalling Requirements February 2002 nalling ...................................................... 25 5.4.3 Allow efficient QoS re-establishment after handover ......... 25 5.4.4 Enable other network entities to generate QoS request be­ half of a node ............................................... 25 6 Conclusions ..................................................... 25 7 Full Copyright Statement ........................................ 26 8 References ...................................................... 26 9 Acknowledgments ................................................. 27 10 Editors's Addresses ............................................ 27 Partain, et al. Expires August 2002 [Page 30]