Network Working Group Ping Pan Internet Draft (Juniper Networks) Expiration Date: May 2002 Jim Murphy Network Working Group (Juniper Networks) A Network Architecture for Simplified Signaling Protocol draft-pan-signal-req-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. Abstract This memo describes a network architecture where a simplified signaling protocol is required on network routers. We list some of the assumptions and requirements for the signaling protocol. draft-pan-signal-req-00.txt ^L[Page 1] Internet Draft draft-pan-signal-req-00.txt October 2001 1. Introduction RSVP has been designed as the signaling protocol that is responsible for setting up reservations for end-to-end user flows in the Internet. However, over the years, people have been debating over its usefulness, applicability, and scalability, In this memo, we describe a network architecture where a protocol to signal between users and network routers is definitely required. Moreover, the signaling protocol needs to be simpler than what had been proposed in RSVP. We illustrate the architecture in Figure-1. Figure 1: Example Network Topology ................. ................. . . . . . User1 User2 . . User3 User4 . . \ / . . \ / . . \ / . . \ / . . Edge-A . . Edge-B . ................. ................. \\ // \\ // \\ // \\ // \\ IP Backbone // ............................... . Rtr-A Rtr-B . . | \ | . . | \----------\ | . . | \ | . . | \ | . . Rtr-C Rtr-D . ............................... || || || || || || ............ ............. . Edge-C . . Edge-D . . | . . | . . | . . | . . User5 . . User6 . . . . . ............ ............. draft-pan-signal-req-00.txt ^L[Page 2] Internet Draft draft-pan-signal-req-00.txt October 2001 As shown in the figure, network users need to communicate among each other over the Internet backbone. There are four types of users that we need to consider: 1. Wireless users: They communicate with some base-stations using whatever the protocols they desire. The base-stations in turn send user traffic over the Internet. It is likely that the network providers need to be able to keep track of traffic usage on per-user basis, and guarantee some level of service to the wireless users. Here, we refer the equipment that is used to deliver user traffic into the Internet as an edge device. 2. Traditional phone users: Telephone users may choose whatever the signaling protocol to negotiate and setup call sessions. And the phone providers may want to use the Internet to transfer voice traffic. Between phone network edge and the Internet edge, it is necessary to have a per-call signaling protocol that is responsible for admission control. 3. High speed end-users: Cable modem and DSL users should have the option to demand service guarantees such as bandwidth from the Internet providers. To access the backbone, the edge devices from the regional providers need to communicate with the backbone routers for admission control. 4. VPN users: For edge devices that support non-IP traffic into the backbone, they need to have an IP signaling protocol to communicate with the backbone to setup CoS-aware VPN tunnels. As shown in the figure, Edge A, B, C and D are responsible for signaling and sending IP packets to the backbone. The backbone edge routers (Rtr A, B, C and D) are responsible for admission control, traffic classification and possible traffic aggregation, and sending packets through the backbone. Here, we make no assumption on the exact mechanisms (over-provisioning or MPLS, etc) that network providers must use to satisfy the CoS/QoS requirements. By the way, there could exist routers between the edge devices and the backbone edge routers. These routers have the option to process the signaling messages and make resource reservation for each individual data flow. To provide end-to-end signaling requirement, the routers need to "tunnel" the signaling messages through the backbone. draft-pan-signal-req-00.txt ^L[Page 3] Internet Draft draft-pan-signal-req-00.txt October 2001 2. Assumptions Under the architecture, we have the following assumptions: - User network and IP backbone could manage their own network resources, and must satisfy CoS/QoS requirements once packets are inside their network. More importantly, it is not required to have a signal and unified resource management technique in all networks. - Though, in theory, the only type of application that requires CoS/QoS guarantees is inter-active real-time streaming traffic, such as voice data in both wired or wireless networks, the signaling described here is independent from the application type. - The edge devices have the option to encapsulate user data in any transport layer protocol (TCP, RTP, GRE or IP-IP). Thus the signaling protocol must be generic. - In case of traditional phone users, there could be a very large volume of voice traffic arriving at phone and IP network edge, we cannot make the assumption that the edge devices will always apply some adaptive schemes during packet transmission. Some level of resource reservation is always required for such users. - We cannot make the assumption that each user flow will last for long period of time. In other words, the signaling messages can be very dynamic in nature. This can cause heavy processing overhead on routers. Thus, while the signaling needs to be designed to be as efficient as possible, the signaling messages must not be processed inside the backbone. - Multicast support causes heavy processing overhead on routers, and it is not clear it will be used for the users we described here. We leave multicast support for future studies. draft-pan-signal-req-00.txt ^L[Page 4] Internet Draft draft-pan-signal-req-00.txt October 2001 3. Signaling Protocol Requirements The signaling protocol needs to be processed at edge devices, backbone routers and possibly the intermediate routers. The edge devices need to notify backbone routers regarding arriving/departure of data flows. Since the edge devices are responsible for potentially delivering a large number of data flows (including those of non-IP sessions) into the Internet, the signaling overhead on edge devices must be small. It is not clear that receiver-initiated reservation technique emphasis in RSVP is a suitable solution for the applications we are addressing here. The backbone routers must process each and every signaling message, run admission control procedure, and initiate rejection messages in case of admission control failure. We always assume that network providers have a way to create and manage a set of traffic-class specific "bandwidth trunks" across the backbone. Thus, it is possible for the backbone routers to follow some classification procedure and aggregate the incoming data flows into one of the pre-established "bandwidth trunks". To process a large number of flows at backbone routers, the signaling needs to be efficient. In addition, the signaling protocol must have enough security features that can prevent DoS attacks at backbone routers. For the intermediate routers between the edge device and the backbone routers, processing signal messages should be an option. This is because network resources may not be a constraint in many access networks. Running admission control at each router here may not be necessary but to add more overhead in resource management. However, for the edge devices that request very large amount of network resources that may cause resource constraint in the access networks, the intermediate routers must process the signaling messages and reject resource requests at early in the network as possible. 3.1. Processing overhead considerations One important factor that we need to consider is the short-lived user flows. For example, the average voice phone-call is only 3-4 minutes, as oppose to video conferencing sessions may last for hours. This requirement alters some of the design decisions for signaling protocols. In case of RSVP, routers can apply various techniques [RSVP-REFRESH], such as control message compression, to improve signaling efficiency. Unfortunately, this can only be effective if the user session is long. Given users must gain Internet access within a short period of time, draft-pan-signal-req-00.txt ^L[Page 5] Internet Draft draft-pan-signal-req-00.txt October 2001 the signaling messages must be delivered reliably. When there are reservations on the intermediate routers, the user-flows must be able to adjust to routing changes quickly. Thus, the signaling protocol needs to be the combination of both "hard-state" and "soft-state". 3.2. Error handling and redundancy considerations Edge devices and backbone routers must 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 such errors to the users 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 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 signaling protocol design. This can impact the overall signaling process overhead. 3.3. Security considerations When users signal network for flow, network resources will be consumed. Thus all signaling messages must be authenticated. draft-pan-signal-req-00.txt ^L[Page 6] Internet Draft draft-pan-signal-req-00.txt October 2001 4. References [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification," RFC2205. [RFC2961] L. Berger, et al, "RFC 2961: RSVP Refresh Overhead Reduction Extensions", RFC2961. 5. Author Information Ping Pan Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: pingpan@juniper.net Jim Murphy Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: murphy@juniper.net draft-pan-signal-req-00.txt ^L[Page 7]