NSIS Working Group B. Sarikaya (Ed.) Internet Draft Document:draft-sarikaya-nsis-wiredreqs-00.txt Category: Standards track Alcatel November 2001 QoS Signaling Protocol Requirements for Wired Networking draft-sarikaya-nsis-wiredreqs-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. Abstract A set of requirements are stated for a signaling protocol for QoS on wired networks. The requirements are classified into the categories of general and security related. Table of Contents Status of this Memo............................................ ..1 Abstract....................................................... ..1 Table of Contents............................................. ...2 1. Introduction................................................ ..2 2. Terms....................................................... ..2 3. General Requirements.............................. .. .. .. .. 3 4 Security, Reliability and Privacy Related Requirements.........4 5. References.................................................. ..4 6 Author' Address....................... . ................ .. ..5 Sarikaya 1 QoS signaling Protocol Requirements November 2001 1. Introduction This document states the requirements for a QoS signaling protocol. The requirements developed are from wired networks. The requirements are taken from the edge and core network component point of view. The requirements from Mobile IP point of view are stated in [1]. Some additional requirements are stated in [2] for cellular RAN resource allocation issues. 2. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [3]. 3. General Requirements Signaling for QoS and path setup must interact with routing. You cannot layer signaling on routing or routing on signaling. We have L2 mechanisms for signaling but no routing, and L3 mechanisms for routing, but no signaling. So we must think recursively about planning and topology. A receiver should be able to control what it receives from the network, and it should be able to do this without having to cooperate with the sender. This is important for handling Denial-of- Service attacks. Notification of errors in a previously set up path should be fast and the protocol should enable fast rerouting of paths. The real scalability problem is "manageability": - need to shrink the number of reservations to be managed; - need to avoid manual configuration; - need to interface with policy and accounting; - need good measurements and instrumentation. This implies that no "manual configuration", a smaller number of states, the use of policy, and having good measurement instrumentation are the requirements for the new signaling protocol. There is a need to support signaling for large numbers of call reservations where the bandwidth for signaling is restricted. Signaling for 2000-3000 calls per second using end-to-end signaling over low-bit-rate hops is one such requirement. We need resource reservations to support audio and video pipes. The network has multiple millions of end points and is bandwidth-limited at the edges. The reservations have to be hard end-to-end reservations. The new signaling protocol should be capable of things like setting up paths independent of what routing says on the global scale. Sarikaya Expires May 2002 2 QoS signaling Protocol Requirements November 2001 Signaling state should be able to dip into the path of IP packets and dip out. The end system should not have to be involved. We need the ability to transparently carry objects such as pricing detail. The protocol should be a lightweight protocol. Signaling protocols have different time scale requirements (milliseconds, microseconds, seconds etc). Knowing the time scale requirement may solve the problem by enabling dynamic policies that can be very fast, minimize complexity and are centrally controlled. A good requirement is the development of a generic QoS mechanism similar to RSVP which is quite generic, unlike Intserv, which has two specific QoS mechanisms. Generic service will rely only on "frame" and is protocol agnostic. We need to be flexible in our approach. There is no one protocol that is right for all purposes. For example, a signaling protocol involving an end user must be very fast. But reliability/redundancy issues are more important for a signaling protocol between backbone routers. Signaling should not destroy the good quality of service that raw IP networks already have. i.e., it must still be possible for things to be done between consenting end systems without requiring them to first have a conversation with the network about their intentions. There should be a strict decoupling between protocol and the information it is carrying. Signaling should work over all kinds of networks, e.g., high error networks, asymmetric networks, slow networks, broadcast networks and unidirectional networks. The protocol needs to be simple. A simple protocol stands the chance of succeeding better than a complex one. 3.1 Stateful versus Stateless The tradeoff is between stateful versus stateless protocols. We do have the capability of building stateless protocols - and that should be the requirement. We need both sender-oriented and receiver-oriented protocols. We need both soft state and hard state protocols, and protocols with in- between state (e.g., "ice cream state", that starts off hard and softens over time), especially for voice over IP. 3.2 Midcom Any signaling protocol we design needs to be able to handle signaling to or from middleboxes in transport layer e.g. firewalls and NATs. Either the middlebox needs to be aware of applications or vice versa. We've been doing the former -- it doesn't scale, things break, etc. Sarikaya Expires May 2002 3 QoS signaling Protocol Requirements November 2001 Data and control paths are separated in applications. But in many cases the control path is mediated by some third party (e.g. an ALG or a Call Center or something). Whatever we do here needs to be aware of that fact. Concealing the network topology from the end user is nice, if/when it is possible. But midcom requires exposing network topology to applications. We need on-the-path signaling, without exposing topology to the edge host. 3.3 SIP and Domains As the experience of SIP shows, for any QoS signaling to be widely deployed and be useful for an extended time, extensibility of the signaling protocol to accommodate new communication events and modes is important. In an end-to-end QoS delivery involving a cascade of differentiated services domain, issues of inter- and intra-domain signaling is important. The events in these two domains are by no means independent. It is clear that end-to-end signaling mechanisms are affected by intra- and inter-domain routing, admission control, AAA functions. It is also possible that the end-to-end path may include non-differentiated services domains. Any signaling QoS must strive to be simple and yet flexible enough to directly or indirectly interact with these events. 4. Security, Reliability and Privacy Related Requirements The signaling protocol has to ensure security and integrity of packets, and it must be able to signal the security requirements for packets. Privacy and anonymity need to be taken into account. We should be able to deal with multiple "presentations" of an individual. There is a need for simple authentication. We need "extremely lightweight authentication." We need to be able to do secure and reliable signaling for anycast groups. Acknowledgements. The requirements stated in this document originate largely from the requirements stated by people who attended NSIS BOF at IETF 50 in Minneapolis, USA. 5. References Sarikaya Expires May 2002 4 QoS signaling Protocol Requirements November 2001 1 Chaskar, H., "Requirements of a QoS Solution for Mobile IP", draft- ietf-mobileip-qos-requirements-01.txt, work-in-progress, August 2001. 2 Partain, D., et al., "Cellular RAN Resource Issues", draft- westberg-rmd-cellular-issues-00.txt, work-in-progress, June 2001. 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 7. Author's Address The working group can be contacted via the current chair: John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland Email: john.loughney@nokia.com Questions about this memo can also be directed to: Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S CTO2 1201 E. Campbell Rd. Richardson, TX 75081-1936 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 996-5075 Fax: (972) 996 5174 Sarikaya Expires May 2002 5