diff options
Diffstat (limited to 'doc/rfc/rfc1821.txt')
| -rw-r--r-- | doc/rfc/rfc1821.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc1821.txt b/doc/rfc/rfc1821.txt new file mode 100644 index 0000000..af0ae8b --- /dev/null +++ b/doc/rfc/rfc1821.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group M. Borden +Request for Comments: 1821 E. Crawley +Category: Informational Bay Networks + B. Davie + Bellcore + S. Batsell + NRL + August 1995 + + + Integration of Real-time Services in an IP-ATM Network Architecture + +Status of the Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + The IETF is currently developing an integrated service model which is + designed to support real-time services on the Internet. + Concurrently, the ATM Forum is developing Asynchronous Transfer Mode + networking which similarly provides real-time networking support. The + use of ATM in the Internet as a link layer protocol is already + occurring, and both the IETF and the ATM Forum are producing + specifications for IP over ATM. The purpose of this paper is to + provide a clear statement of what issues need to be addressed in + interfacing the IP integrated services environment with an ATM + service environment so as to create a seamless interface between the + two in support of end users desiring real-time networking services. + +Table of Contents + + 1.0 Introduction 2 + 2.0 Problem Space Overview 3 + 2.1 Initial Assumptions 3 + 2.2 Topologies Under Consideration 4 + 2.3 Providing QoS in IP over ATM - a walk-though 5 + 3.0 Service Model Issues 6 + 3.1 Traffic Characterization 7 + 3.2 QoS Characterization 8 + 4.0 Resource Reservation Styles 10 + 4.1 RSVP 10 + 4.2 ST-II 13 + 4.3 Mapping IP flows to ATM Connections 15 + 5.0 End System Issues 16 + 6.0 Routing Issues 16 + + + +Borden, et al Informational [Page 1] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + 6.1 Multicast routing 17 + 6.2 QoS Routing 17 + 6.3 Mobile Routing 18 + 7.0 Security Issues 19 + 8.0 Future Directions 20 + 9.0 References 22 + 10.0 Authors' Addresses 24 + +1.0 Introduction + + The traditional network service on the Internet is best-effort + datagram transmission. In this service, packets from a source are + sent to a destination, with no guarantee of delivery. For those + applications that require a guarantee of delivery, the TCP protocol + will trade packet delay for correct reception by retransmitting those + packets that fail to reach the destination. For traditional + computer-communication applications such as FTP and Telnet in which + correct delivery is more important than timeliness, this service is + satisfactory. However, a new class of application which uses multiple + media (voice, video, and computer data) has begun to appear on the + Internet. Examples of this class of application are video + teleconferencing, video-on-demand, and distributed simulation. While + these applications can operate to some extent using best-effort + delivery, trading packet delay for correct reception is not an + acceptable trade-off. Operating in the traditional mode for these + applications results in reduced quality of the received information + and, potentially, inefficient use of bandwidth. To remedy this + problem the IETF is developing a real-time service environment in + which multiple classes of service are offered [6]. This environment + will greatly extend the existing best-effort service model to meet + the needs of multimedia applications with real-time constraints. + + At the same time that this effort is underway in the IETF, + Asynchronous Transfer Mode (ATM) is being developed, initially as a + replacement for the current telephone network protocols, but more + recently as a link-layer protocol for computer communications. As it + was developed from the beginning with telephone voice applications in + mind, a real-time service environment is an integral part of the + protocol. With the approval of UNI 3.1 by the ATM Forum, the ATM + standards now have several categories of service. Given the wide + acceptance of ATM by the long-line carriers, the use of ATM in the + Internet is, if not guaranteed, highly likely. The question now + becomes, how can we successfully interface between the real-time + services offered by ATM and the new,integrated service environment + soon to be available in the IP protocol suite. The current IP over + ATM standards assume no real-time IP protocols. It is the purpose of + this RFC to clearly delineate what the issues are in integrating + real-time services in an IP-over-ATM network [10,15,19,20,21]. + + + +Borden, et al Informational [Page 2] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + In the IP-over-ATM environment, as in many others, multicast routing + adds an additional set of challenges. While the major focus of this + paper is quality of service (QoS) issues, it is unwise at best to + ignore multicast when considering these issues, especially since so + many of the applications that motivate the provision of real time QoS + also require efficient multicast support. We will therefore try to + keep considerations of multicast in the foreground in the following + discussion. + + One of the primary motivations for this document is a belief by the + authors that ATM should, if possible, be used as more than a leased + line replacement. That is to say, while it is possible for the + Internet to be overlaid on constant bit rate (CBR), permanent virtual + circuits (PVCs), thus reducing IP over ATM to a previously solved + problem, we believe that this is unlikely to be the most efficient + way to use ATM services as they are offered by carriers or as they + appear in LANs. For example, a carrier offering a CBR service must + assume that the peak bit rate can be used continuously with no + degradation in quality and so resources must be allocated to the + connection to provide that service, even if the peak rate is in fact + rarely used. This is likely to make a CBR service more expensive that + a variable bit rate service of the same peak capacity. Another way + to view this is that the new IP service model will allow us to + associate information about the bandwidth requirements of + applications with individual flows; surely it is not wise to discard + this information when we request a service from an ATM subnet. + + While we believe that there is a range of capabilities in ATM + networks that can be effectively used by a real-time Internet, we do + not believe that just because ATM has a capability, the Internet must + use it. Thus, our goal in this RFC is to begin to explore how an + Internet with real time service capability might make most effective + use of ATM networks. Since there are a number of problems to be + resolved to achieve this effective use, our major goal at this point + is to describe the scope of the problems that need to be addressed. + +2.0 Problem Space Overview + + In this section we aim to describe in high level terms the scope of + the problem that will be explored in more detail in later sections. + +2.1 Initial Assumptions + + We begin by assuming that an Integrated Services Internet, i.e., an + Internet with a range of qualities of service to support both real- + time and non-real-time applications, will eventually happen. A number + of working groups are trying to make this happen, notably + + + + +Borden, et al Informational [Page 3] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + * the Integrated Services group (int-serv), which is working to define + a new IP service model, including a set of services suited to a + range of real-time applications; + + * the Resource reservation Setup Protocol group (rsvp), which is + defining a resource reservation protocol [7] by which the + appropriate service for an application can be requested from the + network; + + * the Internet Streams Protocol V2 group (ST-II), which is updating + [27], a stream-oriented internet protocol that provides a range of + service qualities. + + In addition, the IETF IP over ATM working group and the ATM Forum + Multiprotocol over ATM group are working to define a model for + protocols to make use of the ATM layer. + + Since these groups have not yet generated standards, we will need to + do some amount of extrapolation to predict the problems that may + arise for IP over ATM. We also assume that the standards being + developed in the ATM Forum will largely determine the service model + for ATM. Again, some extrapolation may be needed. Given these + assumptions, this paper aims to explore ways in which a future + Integrated Services Internet might make effective use of ATM as it + seems likely to be deployed. + +2.2 Topologies Under Consideration + + Figure 1 shows a generic internetwork that includes ATM and non-ATM + subnetworks. This paper aims to outline the problems that must be + addressed to enable suitable quality of service to be provided end- + to-end across such a network. The problem space, therefore, includes + + * communication across an 'ATM-only' network between two hosts + directly connected to the ATM network; + + * communication between ATM-connected hosts which involves traversing + some non-ATM subnets; + + * communication between a host on a non-ATM subnet and a host directly + connected to ATM; + + * communication between two hosts, neither of which has a direct ATM + connection, but which may make use of one or more ATM networks for + some part of the path. + + + + + + +Borden, et al Informational [Page 4] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + [H] + | [H] + ________|________________________ | + | | | + ________|__ ______|___|____ + | | | | + | ATM [R] [R] ATM | + | Cloud | | Cloud |___[H] + | | Non-ATM Internet | | + | | [R] | + |________[R] |_____________| + | | | + | | | + [H] |________________________________| + | + | + [H] + + [H] = Host + [R] = Router + Figure 1 + + In the last case, the entities connected to the ATM network are IP + routers, and it is their job to manage the QoS provided by the ATM + network(s) in such a way that the desired end-to-end QoS is provided + to the hosts. While we wish to describe the problem space in a way + that covers all of these scenarios, the last is perhaps the most + general, so we will use it for most illustrative purposes. In + particular, we are explicitly not interested in ways of providing QoS + that are applicable only to a subset of these situations. We claim + that addressing these four situations is sufficiently general to + cover other situations such as those in which several ATM and non-ATM + networks are traversed. + + It is worth mentioning that the ATM networks in this case might be + local or wide area, private or public. In some cases, this + distinction may be significant, e.g., because there may be economic + implications to a particular approach to providing QoS. + +2.3 Providing QoS in IP over ATM - a walk-through + + To motivate the following discussion, this section walks through an + example of what might happen when an application with a certain set + of QoS needs starts up. For this example, we will use the fourth case + mentioned above, i.e., two hosts connected to non-ATM networks, + making use of an ATM backbone. + + + + + +Borden, et al Informational [Page 5] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + A generic discussion of this situation is made difficult by the fact + that the reservation of resources in the Internet may be sender or + receiver initiated, depending on the specifics of the setup protocol. + We will attempt to gloss over this distinction for now, although we + will return to it in Section 4. We will assume a unicast application + and that the traffic characteristics and the QoS requirements (such + as delay, loss, throughput) of the application are known to at least + one host. That host launches a request for the desired QoS and a + description of the expected traffic into the network; at some point + this request hits a router at the edge of the ATM network. The router + must examine the request and decide if it can use an existing + connection over the ATM network to honor the request or whether it + must establish a new connection. In the latter case, it must use the + QoS and traffic characterizations to decide what sort of ATM + connection to open and to describe the desired service to the ATM + network. It must also decide where to open the connection to. Once + the connection is opened, the request is forwarded across the ATM + network to the exit router and then proceeds across the non-ATM part + of the network by the normal means. + + We can see from the above description that there are several sets of + issues to be discussed: + + * How does the IP service model, with certain service classes and + associated styles of traffic and QoS characterization, map onto + the ATM service model? + + * How does the IP reservation model (whatever it turns out to be) map + onto ATM signalling? + + * How does IP over ATM routing work when service quality is added to + the picture? + + These issues will be discussed in the following sections. + +3.0 Service Model Issues + + There are several significant differences between the ways in which + IP and ATM will provide QoS. When IP commits to provide a certain + QoS to an application according to the Internet service model, it + must be able to request an appropriate QoS from the ATM network using + the ATM service model. Since these service models are by no means the + same, a potentially complex mapping must be performed for the IP + layer to meet its commitments. The details of the differences + between ATM and IP and the problems presented by these differences + are described below. + + + + + +Borden, et al Informational [Page 6] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + We may think of a real-time service model as containing the following + components: + + * a way to characterize traffic (sometimes called the Tspec); + + * a way to characterize the desired quality of service (the Rspec). + + We label these components as traffic characterization and QoS + characterization. Each of these components is discussed in turn in + the following sections. + + As well as these aspects of the service model, both ATM and IP will + have a number of mechanisms by which the model is implemented. The + mechanisms include admission control, policing, and packet + scheduling. A particularly important mechanism is the one by which + end-nodes communicate their QoS needs and traffic characteristics to + the network, and the network communicates admission control decisions + to the end-nodes. This is referred to as resource reservation or + signalling, and is the subject of Section 4. In fact, it seems to be + the only mechanism where significant issues of IP/ATM integration + arise. The details of admission control, policing and packet + scheduling are largely internal to a single network element and we do + not foresee significant problems caused by the integration of IP and + ATM. For example, while there may be plenty of challenges in + designing effective approaches to admission control for both IP and + ATM, it is not apparent that there are any special challenges for the + IP over ATM environment. As the walk-through of Section 2.3 + described, a reservation request from a host would at some point + encounter the edge of the ATM cloud. At this point, either a new + connection needs to be set up across the ATM cloud, or the router can + decide to carry the requested traffic over an existing virtual + circuit. If the ATM cloud cannot create a new connection as + requested, this would presumably result in an admission control + failure which would cause the router to deny the reservation request. + +3.1 Traffic Characterization + + The traffic characterization provided by an application or user is + used by the network to make decisions about how to provide the + desired quality of service to this application and to assess the + effect the new flow will have on the service provided to existing + flows. Clearly this information feeds into the admission control + decision process. + + In the Internet community, it is assumed that traffic will in general + be bursty and that bursty traffic can be characterized by a `token + bucket'. While ATM does not expect all traffic to be bursty (the + Continuous Bit Rate class being defined specifically for non-bursty + + + +Borden, et al Informational [Page 7] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + traffic), it uses an essentially equivalent formulation for the + characterization of traffic that is bursty, referred to as the + Generic Cell Rate Algorithm (GCRA). However, ATM in some classes also + requires specification of peak cell rate, whereas peak rates are not + currently included in the IP traffic characterizations. It may be + possible to use incoming interface speeds to determine an approximate + peak rate. + + One of the functions that must be performed in order to carry IP + traffic over an ATM network is therefore a mapping from the + characterization of the traffic as supplied to IP to a + characterization that is acceptable for ATM. While the similarity of + the two characterizations suggests that this is straightforward, + there is considerable flexibility in the mapping of parameters from + IP to ATM. As an extreme example, a router at the edge of an ATM + cloud that expects to receive bursts of IP packets on a non-ATM + interface, with the bursts described by some token bucket parameters, + could actually inject ATM cells at a constant rate into the ATM + network. This may be achieved without significant buffering if the + ATM link speed is faster than the point-to-point link speed; + alternatively, it could be achieved by buffering out the burstiness + of the arriving traffic. It seems more reasonable to map an IP flow + (or a group of flows) with variable bandwidth requirements onto an + ATM connection that accommodates variable bit rate traffic. + Determining how best to map the IP traffic to ATM connections in this + way is an area that warrants investigation. + + A potential complication to this process is the fact that the token + bucket parameters are specified at the edge of the IP network, but + that the specification of the GCRA parameters at the entry to an ATM + network will frequently happen at a router in the middle of an IP + network. Thus the actual burstiness that is encountered at the router + may differ from that described by the IP token bucket parameters, as + the burstiness changes as the traffic traverses a network. The + seriousness of this problem needs to be understood to permit + efficient resource utilization. + +3.2 QoS Characterization + + In addition to specifying the traffic that they will submit to the + network, applications must specify the QoS they require from the + network. Since the goal is to carry IP efficiently over ATM networks, + it is necessary to establish mechanisms by which QoS specifications + for IP traffic can be translated into QoS specifications that are + meaningful for an ATM network. + + + + + + +Borden, et al Informational [Page 8] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + The proposed method of QoS specification for the Internet is to + specify a `service class' and some set of parameters, depending on + the service class. The currently proposed service classes are + + * guaranteed, which provides a mathematically guaranteed delay + bound [23]; + + * predictive delay, which provides a probabilistic delay bound + [24];and + + * controlled delay, which merely tries to provide several levels of + delay which applications may choose between [25]. + + These are in addition to the existing `best-effort' class. More IP + service classes are expected in the future. ATM has five service + classes: + + * CBR (constant bit rate), which emulates a leased line, providing + very tightly constrained delay and designed for applications which + can use a fixed bandwidth pipe; + + * VBR (variable bit rate)-real-time which attempts to constrain delay + for applications whose bandwidth requirements vary; + + * VBR-non-real-time, intended for variable bandwidth applications + without tight delay constraints; + + * UBR (unspecified bit rate) which most closely approximates the best + effort service of traditional IP; + + * ABR (available bit rate) which uses a complex feedback mechanism + to control loss. + + Each class requires some associated parameters to be specified, e.g., + CBR requires a peak rate. Observe that these classes are by no means + in direct correspondence with the IP classes. In some cases, ATM + classes require parameters which are not provided at the IP level, + such as loss rate, to be specified. It may be necessary to assume + reasonable default values in these cases. + + The major problem here is this: given traffic in a particular IP + service class with certain QoS parameters, how should it be sent + across an ATM network in such a way that it both meets its service + commitments and makes efficient use of the ATM network's resources? + For example, it would be possible to transport any class of IP + traffic over an ATM network using the constant bit rate (CBR) ATM + class, thus using the ATM network like a point-to-point link. This + would allow IP to meet its service commitments, but would be an + + + +Borden, et al Informational [Page 9] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + inefficient use of network resources in any case where the IP traffic + was at all bursty (which is likely to be most cases). A more + reasonable approach might be to map all IP traffic into a variable + bit rate (VBR) class; certainly this class has the flexibility to + accommodate bursty IP traffic more efficiently than CBR. + + At present, the IETF is not working on any service classes in which + loss rate is considered as part of the QoS specification. As long as + that is the case, the fact that ATM allows target loss rates to be + specified is essentially not an issue. However, we may certainly + expect that as the IP service model is further refined, service + classes that include specifications of loss may be defined. At this + point, it will be necessary to be able to map between loss rates at + the IP level and loss rates at the ATM level. It has already been + shown that relatively small loss rates in an ATM network can + translate to high loss rates in IP due to the fact that each lost + cell can cause the loss of an entire IP packet. Schemes to mitigate + this problem, which include the proposed approach to implementing the + ABR class, as well as other solutions [22], have been proposed. This + is clearly likely to be an important issue in the future. + +4.0 Resource Reservation Styles + + ATM uses a signalling protocol (Q.2931) both to establish virtual + connections and to allocate resources to those connections. It has + many of the characteristics of a 'conventional' signalling protocol, + such as being sender-driven and relying on hard-state in switches to + maintain connections. Some of the key characteristics are listed in + the table below. In the current standards, the QoS associated with a + connection at setup time cannot be changed subsequently (i.e., it is + static); in a unicast connection, resources are allocated in both + directions along the path, while in the multicast case, they are + allocated only from the sender to the receivers. In this case, all + senders receive the same QoS. + + Two protocols have been proposed for resource reservation in IP. The + first (chronologically) is ST-II, the other is RSVP. Each of these, + and its relationship to ATM, is discussed in the following sections. + +4.1 RSVP + + IP has traditionally provided connectionless service. To support + real-time services in a connectionless world, RSVP has been proposed + to enable network resources to be reserved for a connectionless data + stream. ATM, on the other hand, provides a connection-oriented + service, where resource reservations are made at connection setup + time, using a user-network interface (UNI) and a network-network + interface (NNI) signalling protocol. + + + +Borden, et al Informational [Page 10] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + ----------------------------------------------------------------- + | Category | RSVP | ATM (UNI 3.0) | + ----------------------------------------------------------------- + | | | | + | Orientation | Receiver-based | Sender-based | + | | | | + ---------------------------------------------------------------- + | | | | + | State | Soft state | Hard state | + | | (refresh/time-out) | (explicit delete) | + ----------------------------------------------------------------- + | | | | + |QoS SetupTime | Separate from | Concurrent with | + | | route establishment | route establishment | + ----------------------------------------------------------------- + | | | | + |QoS Changes? | Dynamic QoS | Static QoS | + | | | (Fixed at setup time) | + ----------------------------------------------------------------- + | | | Bidirectional allocation| + |Directionality| Unidirectional | for unicast | + | |resource allocation |Unidirectional allocation| + | | | for multicast | + ----------------------------------------------------------------- + | | | | + |Heterogeneity | Receiver | Uniform QoS to | + | | heterogeneity | all receivers | + ----------------------------------------------------------------- + + The principles used in the design of RSVP differ from those of ATM in + the following respects: + + * Resource reservations in IP hosts and routers are represented by + soft state, i.e., reservations are not permanent, but time out + after some period. Reservations must be refreshed to prevent + time-out, and may also be explicitly deleted. In ATM, resources are + reserved for the duration of a connection, which must be explicitly + and reliably deleted. + + * The soft state approach of RSVP allows the QoS reserved for a flow + to be changed at any time, whereas ATM connections have a static + QoS that is fixed at setup time. + + * RSVP is a simplex protocol, i.e., resources are reserved in one + direction only. In ATM, connections (and associated reservations) + are bi-directional in point-to-point calls and uni-directional in + point-to-multipoint calls. + + + + +Borden, et al Informational [Page 11] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + * Resource reservation is receiver-initiated in RSVP. In ATM, + resources are reserved by the end system setting up the connection. + In point-to-multipoint calls, connection setup (and hence resource + reservation) must be done by the sender. + + * RSVP has explicit support for sessions containing multiple senders, + namely the ability to select a subset of senders, and to + dynamically switch between senders. No such support is provided + by ATM. + + * RSVP has been designed independently of other architectural + components, in particular routing. Moreover, route setup and + resource reservation are done at different times. In ATM, resource + reservation and route setup are done at the same time (connection + setup time). + + The differences between RSVP and ATM state establishment, as + described above, raise numerous problems. For example, since point- + to-point connections are bidirectional in ATM, and since reservations + can be made in both directions, receiver-initiated resource + reservations in RSVP can be simulated in ATM by having the receiver + set up the connection and reserve resources in the backward direction + only. However, this is potentially wasteful of connection resources + since connections are only ever used to transfer data in one + direction even though communication between the two parties may be + bidirectional. One option is to use a `point-to-multipoint' ATM + connection with only one receiver. Of course, the fact that the RSVP + reservation request is made by the receiver(s) means that this + request must be somehow communicated to the sender on the ATM + network. This is somewhat analogous to the receiver-oriented join + operation of IP multicast and the problems of implementing it over + ATM, as discussed in Section 6. In general, the efficiency of any + proposed connection management scheme needs to be investigated in + both unicast and multicast contexts for a range of application + requirements, especially at a large scale. + + The use by RSVP of `soft state' as opposed to explicit connections + means that routers at the ATM network's edges need to manage the + opening and closing of ATM connections when RSVP reservations are + made and released (or time out). The optimal scheme for connection + setup and tear-down will depend on the cost of setting up a + connection versus the cost of keeping the connection open for + possible future use by another stream, and is likely to be service + class-dependent. For example, connections may be left open for reuse + by best-effort traffic (subject to sufficient connections being + available), since no resources are explicitly reserved. On the other + hand, connections supporting the real-time service classes are likely + to be expensive to leave open since resources may be allocated even + + + +Borden, et al Informational [Page 12] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + when the connection is idle. Again, the cost incurred will depend on + the class. For example, the cost of an open, idle `guaranteed' QoS + connection is likely to be significantly more expensive than a + connection providing predictive or controlled delay service. Note + that connections can be reused for traffic of the same class with + compatible QoS requirements, and that it may sometimes be possible to + use a `higher quality' class to substitute for a lower quality one. + + Another characteristic of RSVP which presents problems for ATM is the + use of PATH messages to convey information to receivers before any + reservation is made. This works in IP because routing is performed + independently of reservation. Delivery of PATH messages across an ATM + network is therefore likely to require a mechanism for setting up + connections without reservations being made. The connection also + needs to be of sufficient quality to deliver PATH messages fairly + reliably; in some circumstances, a low quality best effort service + may be inadequate for this task. A related issue is the problem of + advertising services prior to reservations. The OPWA model (one pass + with advertising) requires network elements to advertise the QoS that + they are able to provide so that receivers can decide what level of + reservation to request. Since these advertisements may be made prior + to any resources having been reserved in the ATM network, it is not + clear how to make meaningful advertisements of the QoS that might be + provided across the ATM cloud. + + Finally, the multiparty model of communication is substantially + different in RSVP and ATM. Emulating RSVP receiver-initiation using + ATM point-to-multipoint connections is likely to cause severe scaling + problems as the number of receivers becomes large. Also, some + functions of RSVP are not currently provided by ATM. For example, + there is no support for different receiver requirements and + capabilities-all receivers in a session receive the same QoS, which + is fixed at the time the first receiver is added to the multicast + tree. It is likely that ATM support for multi-party sessions will be + enhanced in later versions of the standards. It is necessary for such + support to evolve in a manner compatible with RSVP and IP multicast + routing protocols if large ATM clouds are to be deployed + successfully. + +4.2 ST-II + + ST-II [27] and ST2+ [12] (referred to generically as ST hereafter) + have data distribution and resource reservation schemes that are + similar to ATM in many respects. + + * ST is connection oriented using "hard state". Senders set up + simplex data flows to all receivers closely matching point-to- + multipoint connections in ATM. Routing decisions are made when + + + +Borden, et al Informational [Page 13] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + the connection is made and are not changed unless there is a + failure in the path. Positive acknowledgment is required from all + receivers. ST2+ [12] adds a receiver-based JOIN mechanism that can + reduce the burden on senders to track all receivers. + + * ST reserves network resources at connection setup time. The ST + CONNECT message contains a flowspec indicating the resources to be + reserved for the stream. Agents along the path may change the + flowspec based on restrictions they may need to impose on the + stream. The final flowspec is returned to the sender in the ACCEPT + message from each receiver or target. + + ----------------------------------------------------------------- + | Category | RSVP | ATM (UNI 3.0) | + ----------------------------------------------------------------- + | | | | + | Orientation | Sender-based | Sender-based | + | | | | + ---------------------------------------------------------------- + | | | | + | State | Hard state | Hard state | + | | (explicit disconnect)| (explicit delete) | + ----------------------------------------------------------------- + | | | | + |QoS SetupTime | Concurrent with | Concurrent with | + | | stream setup | route establishment | + ----------------------------------------------------------------- + | | | | + |QoS Changes? | Dynamic QoS | Static QoS | + | | | (Fixed at setup time) | + ----------------------------------------------------------------- + | | | Bidirectional allocation| + |Directionality| Unidirectional | for unicast | + | |resource allocation |Unidirectional allocation| + | | | for multicast | + ----------------------------------------------------------------- + | | | | + |Heterogeneity | Receiver | Uniform QoS to | + | | heterogeneity | all receivers | + ----------------------------------------------------------------- + + These similarities make mapping ST services to ATM simpler than RSVP + but the mapping is still not trivial. The task of mapping the ST + flowspec into an ATM service class still has to be worked out. There + may be policy issues related to opening a new VC for each stream + versus aggregating flows over an existing VC. + + + + + +Borden, et al Informational [Page 14] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + Additionally, ST has some differences with UNI 3.1 that can cause + problems when integrating the two protocols: + + * In ST, changes to active stream reservations are allowed. For + example, if the flowspec received from the target is not sufficient + for the stream, the sender can send a CHANGE message, requesting a + different QoS. UNI 3.1 does not allow changes to the QoS of a VC + after it is set up. Future ATM UNI specifications are contemplating + allowing changes to a VC after set up but this is still preliminary. + In the meantime, policies for over reservation or aggregation onto + a larger VC may be needed. + + * ST uses simplex streams that flow in only one direction. This is + fine for UNI 3.1 point-to-multipoint connections since the data flow + is only in one direction. When mapping a point-to-point ST + connection to a standard point-to-point ATM VC, the reverse flow + connection is wasted. + + This can be solved simply by using only point-to-multipoint VCs, even + if there is only one receiver. + +4.3 Mapping IP flows to ATM connections + + In general, there will be a great deal of flexibility in how one maps + flows at the IP level to connections at the ATM level. For example, + one could imagine setting up an ATM connection when a reservation + message arrives at the edge of an ATM cloud and then tearing it down + as soon as the reservation times out. However, to minimize latency or + perhaps for economic reasons, it may be preferable to keep the ATM + connection up for some period in case it is needed. Similarly, it may + be possible or desirable to map multiple IP flows to a single ATM + connection or vice versa. + + An interesting situation arises when a reservation request is + received for an existing route across the cloud but which, when added + to the existing reservations using that connection, would exceed the + capacity of that connection. Since the current ATM standards do not + allow the QoS of a connection to be changed, there are two options: + tear down the old connection and create a new one with the new, + larger allocation of resources, or simply add a new connection to + accommodate the extra traffic. It is possible that the former would + lead to more efficient resource utilization. However, one would not + wish to tear down the first connection before the second was + admitted, and the second might fail admission control because of the + resources allocated to the first. The difficulties of this situation + seem to argue for evolution of ATM standards to support QoS + modification on an existing connection. + + + + +Borden, et al Informational [Page 15] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + +5.0 End System Issues + + In developing an integrated IP-ATM environment the applications need + to be as oblivious as possible of the details of the environment: the + applications should not need to know about the network topology to + work properly. This can be facilitated first by a common application + programing interface (API) and secondly by common flow and filter + specifications [18]. + + An example of a common API that is gaining momentum is the BSD + sockets interface. This is a UNIX standard and, with Winsock2, has + also become a PC standard. With the IETF integrated service + environment just beginning to appear in the commercial marketplace, + the ability to standardize on one common interface for both IP and + ATM applications is still possible and must be seriously and quickly + pursued to insure interoperability. + + Since the IP integrated service and ATM environments offer different + QoS service types, an application should specify sufficient + information in its flow specification so that regardless of the + topology of the network, the network can choose an acceptable QoS + type to meet the applicationUs needs. Making the application provide + sufficient information to quantify a QoS service and allowing the + network to choose the QoS service type is essential to freeing the + application from requiring a set network topology and allowing the + network to fully utilize the features of IP and ATM. + +6.0 Routing Issues + + There is a fundamental difference between the routing computations + for IP and ATM that can cause problems for real-time IP services. + ATM computes a route or path at connection setup time and leaves the + path in place until the connection is terminated or there is a + failure in the path. An ATM cell only carries information + identifying the connection and no information about the actual source + and destination of the cell. In order to forward cells, an ATM + device needs to consult a list of the established connections that + map to the next hop device, without checking the final destination. + + In contrast, routing decisions in IP are based on the destination + address contained in every packet. This means that an IP router, as + it receives each packet, has to consult a table that contains the + routes to all possible destinations and the routing decision is made + based on the final destination of the packet. This makes IP routing + very robust in the face of path changes and link failures at the + expense of the extra header information and the potentially larger + table lookup. However, if an IP path has been selected for a given + QoS, changes in the route may mean a change in the QoS of the path. + + + +Borden, et al Informational [Page 16] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + +6.1 Multicast routing + + Considerable research has gone into overlaying IP multicast models + onto ATM. In the MARS (Multicast Address Resolution Server) model + [1], a server is designated for the Logical IP Subnet (LIS) to supply + the ATM addresses of the hosts in the IP multicast group, much like + the ATM ARP server [15]. When a host or router wishes to send to a + multicast group on the LIS, a query is made to the MARS and a list of + the ATM address of the hosts or routers in the group is returned. The + sending host can then set up point-to-point or point-to-multipoint + VCs to the other group members. When a host or a router joins an IP + multicast group, it notified the MARS. Each of the current senders to + the group is then notified of the new group member so that the new + member can be added to the point to multipoint VC's. + + As the number of LIS hosts and multicast groups grows, the number of + VCs needed for a one-to-one mapping of VCs to multicast groups can + get very large. Aggregation of multicast groups onto the same VC may + be necessary to avoid VC explosion. Aggregation is further + complicated by the QoS that may be needed for particular senders in a + multicast group. There may be a need to aggregate all the multicast + flows requiring a certain QoS to a set of VCs, and parallel VCs may + be necessary to add flows of the same QoS. + +6.2 QoS Routing + + Most unicast and multicast IP routing protocols compute the shortest + path to a destination based solely on a hop count or metric. OSPF + [16] and MOSPF [17] allow computation based on different IP Type of + Service (TOS) levels as well as link metrics, but no current IP + routing protocols take into consideration the wide range of levels of + quality of service that are available in ATM or in the Integrated + Services models. In many routing protocols, computing all the routes + for just the shortest path for a large network is computationally + expensive so repeating this process for multiple QoS levels might be + prohibitively expensive. + + In ATM, the Private Network-to-Network Interface (PNNI) protocol [13] + communicates QoS information along with routing information, and the + network nodes can utilize this information to establish paths for the + required QoS. Integrated PNNI (I-PNNI) [9] has been proposed as a way + to pass the QoS information available in ATM to other routing + protocols in an IP environment. + + Wang & Crowcroft [28] suggest that only bandwidth and delay metrics + are necessary for QoS routing and this would work well for computing + a route that required a particular QoS at some setup time, but this + goes against the connectionless Internet model. One possible solution + + + +Borden, et al Informational [Page 17] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + to the exhaustive computation of all possible routes with all + possible QoS values would be to compute routes for a common set of + QoS values and only then compute routes for uncommon QoS values as + needed, extracting a performance penalty only on the first packets of + a flow with an uncommon QoS. Sparse multicast routing protocols that + compute a multicast path in advance or on the first packets from a + sender (such as CBT [5] and MOSPF [17]) could also use QoS routing + information to set up a delivery tree that will have adequate + resources. + + However, no multicast routing protocols allow the communication of + QoS information at tree setup time. Obtaining a tree with suitable + QoS is intended to be handled by RSVP, usually after the distribution + tree has been set up, and may require recomputation of the + distribution tree to provide the requested QoS.One way to solve this + problem is to add some "hints" to the multicast routing protocols so + they can get an idea of the QoS that the multicast group will require + at group initiation time and set up a distribution tree to support + the desired QoS. The CBT protocol [5] has some TBD fields in its + control headers to support resource reservation. Such information + could also be added to a future IGMP [11] JOIN message that would + include information on the PIM Rendezvous Point (RP) or CBT Core. + + Another alternative is to recompute the multicast distribution tree + based on the RSVP messages but this has the danger of losing data + during the recomputation. However, this can leave a timing window + where other reservations can come along during the tree recomputation + and use the resources of the new path as well as the old path, + leaving the user with no path to support the QoS desired. + + If unicast routing is used to support multicast routing, we have the + same problem of only knowing a single path to a given destination + with no QoS information. If the path suggested by unicast routing + does not have the resources to support the QoS desired, there are few + choices available. Schemes that use an alternate route to "guess" at + a better path have been suggested and can work for certain topologies + but an underlying routing protocol that provides QoS information is + necessary for a complete solution. As mentioned earlier, I-PNNI has + the potential to provide enough information to compute paths for the + requested QoS. + +6.3 Mobile Routing + + In developing an integrated IP-ATM network, potential new growth + areas need to be included in the planning stages. One such area is + mobile networking. Under the heading of mobile networks are included + satellite extensions of the ATM cloud, mobile hosts that can join an + IP subnetwork at random, and a true mobile network in which all + + + +Borden, et al Informational [Page 18] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + network components including routers and/or switches are mobile. + + The IP-ATM real-time service environment must be extended to include + mobile networks so as to allow mobile users to access the same + services as fixed network users. In doing so, a number of problems + exist that need to be addressed. The principle problems are that + mobile networks have constrained bandwidth compared to fiber and + mobile links and are less stable than fixed fiber links. The impact + of these limitations affect IP and ATM differently. In introducing + one or more constrained components into the ATM cloud,the effects on + congestion control in the overall network are unknown. One can + envision significant buffering problems when a disadvantaged user on + a mobile link attempts to access information from a high speed data + stream. Likewise, as ATM uses out of band signalling to set up the + connection, the stability of the mobile links that may have + significant fading or complete loss of connectivity could have a + significant effect on ATM performance. + + For QoS, fading on a link will appear as a varying channel capacity. + This will result in time-dependent fluctuations of available links to + support a level of service. Current routing protocols are not + designed to operate in a rapidly changing topology. QoS routing + protocols that can operate in a rapidly changing topology are + required and need to be developed. + +7.0 Security Issues + + In a quality of service environment where network resources are + reserved, hence potentially depriving other users access to these + resources for some time period, authentication of the requesting host + is essential. This problem is greatly increased in a combined IP-ATM + topology where the requesting host can access the network either + through the IP or the ATM portion of the network. Differences in the + security architectures between IP and ATM can lead to opportunities + to reserve resources without proper authorization to do so. A common + security framework over the combined IP-ATM topology would be + desirable. In lieu of this, the use of trusted edge devices + requesting the QoS services are required as a near term solution. + + Significant progress in developing a common security framework for IP + is underway in the IETF [2]. The use of authentication headers in + conjunction with appropriate key management is currently being + considered as a long range solution to providing QoS security [3,8]. + In developing this framework, the reality of ATM portions of the + Internet should be taken into account. Of equal importance, the ATM + Forum ad-hoc security group should take into account the current work + on an IP security architecture to ensure compatibility. + + + + +Borden, et al Informational [Page 19] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + +8.0 Future Directions + + Clearly, there are some challenging issues for real-time IP-ATM + services and some areas are better understood than others. For + example, mechanisms such as policing, admission control and packet or + cell scheduling can be dealt with mostly independently within IP or + ATM as appropriate. Thus, while there may be hard problems to be + solved in these areas that need to be addressed in either the IP or + ATM communities, there are few serious problems that arise + specifically in the IP over ATM environment. This is because IP does + not particularly care what mechanisms a network element (such as an + ATM network) uses to provide a certain QoS; what matters is whether + the ATM service model is capable of offering services that can + support the end-to-end IP service model. Most of the hard problems + for IP over ATM therefore revolve around the service models for IP + and ATM. The one piece of mechanism that is important in an IP/ATM + context is signalling or resource reservation, a topic we return to + below. + + The following paragraphs enumerate some of the areas in which we + believe significant work is needed. The work falls into three areas: + extending the IP over ATM standards; extensions to the ATM service + model; and extensions to the IP service model. In general, we expect + that practical experience with providing IP QoS over ATM will suggest + more enhancements to the service models. + + We need to define ways of mapping the QoS and traffic + characterizations (Tspecs and Rspecs) of IP flows to suitable + characterizations for ATM connections. An agreement is needed so + that some sort of uniform approach is taken. Whatever agreement is + made for such mappings, it needs to be done so that when traversing + several networks, the requested QoS is obtained end-to-end (when + admission is possible). Practical experience should be gained with + these mappings to establish that the ATM service classes can in fact + provide suitable QoS to IP flows in a reasonably efficient way. + Enhancement of the ATM service classes may be necessary, but + experience is needed to determine what is appropriate. + + We need to determine how the resource reservation models of IP (RSVP + and ST-II) interact with ATM signalling. Mechanisms for establishing + appropriate connection state with suitable QoS in ATM networks that + are part of a larger integrated services Internet need to be defined. + It is possible that the current IP/ATM mechanisms such as ARP servers + and MARS can be extended to help to manage this state. + + There is a need for better QoS routing. While this functionality is + needed even in the pure ATM or pure IP environment, there is also an + eventual need for integrated QoS routing between ATM and IP. Further + + + +Borden, et al Informational [Page 20] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + research and practical experience is needed in the areas of QoS + routing in IP in order to support more than the shortest best-effort + path, especially when this path may traverse ATM networks. In many + IP networks, there are multiple paths between a given source and + destination pair but current routing technologies only pay attention + to the current shortest path. As resources on the shortest path are + reserved, it will be necessary and viable to explore other paths in + order to provide QoS to a flow. + + Enrichment of the ATM model to support dynamic QoS would greatly help + the IP over ATM situation. At present, the QoS objectives for ATM are + established at call set-up and then fixed for the duration of a call. + It would be advantageous to have the ability to provide a dynamic QoS + in ATM, so that an existing call could be modified to provide altered + services. + + Another possible area of enhancement to the ATM service model is in + the area of multicasting. The multicast QoS offered is equal for all + receivers, and thus may be determined by the least favorable path + through the tree or by the most demanding receiver. Furthermore, + there is no current provision for multipoint to multipoint + connections. This limitation may rule out some of the services + envisioned in the IP service model. + + There are areas of potential enrichment of the IP model as well. + While the receiver-based approach of RSVP has nice scaling properties + and handles receiver heterogeneity well, it is not clear that it is + ideal for all applications or for establishing state in ATM networks. + It is possible that a sender-oriented mode for RSVP might ease the + IP/ATM integration task. + + Since the widespread availability of QoS raises new security concerns + (e.g., denial of service by excessive resource reservation), it seems + prudent that the IP and ATM communities work closely to adopt + compatible approaches to handling these issues. + + This list is almost certainly incomplete. As work progresses to + define IP over ATM standards to support QoS and to implement + integrated services internetworks that include ATM, more issues are + likely to arise. However, we believe that this paper has described + the major issues that need to be taken into consideration at this + time by those who are defining the standards and building + implementations. + + + + + + + + +Borden, et al Informational [Page 21] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + +9.0 References + + 1. Armitage, G., "Support for Multicast over UNI 3.1 based ATM + Networks", Work in Progress, Bellcore, February 1995. + + 2. Atkinson, R., "Security Architecture for the Internet Protocol", + RFC 1825, NRL, August 1995. + + 3. Atkinson, R., "IP Authentication Header", RFC 1826, NRL, + August 1995. + + 4. Ballardie, A., and J. Crowcroft, "Multicast-Specific Security + Threats and Counter-Measures", Proceedings of ISOC Symposium on + Network and Distributed System Security, San Diego, Feb. 1995, + pp. 2-16. + + 5. Ballardie, T., Jain, N., Reeve, S. "Core Based Trees (CBT) + Multicast, Protocol Specification", Work In Progress, University + College London, Bay Networks, June, 1995. + + 6. Braden, R., Clark, D., and S. Shenker, "Integrated Services in + the Internet Architecture: an Overview", RFC 1633, ISI/MIT/Xerox + PARC, July 1994. + + 7. Braden, R., Zhang, L., Estrin, Herzog, D., and S. Jamin, + "Resource ReSerVation Protocol (RSVP) - Version 1 Functional + Specification", Work in Progress, ISI/PARC/UCS, July 1995. + + 8. Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB + Workshop on Security in the Internet Architecture", RFC 1636, ISI, + MIT, TIS, INRIA, June 1994. + + 9. Callon, R., and B. Salkewicz, An Outline for Integrated PNNI for + IP Routing", ATM Forum/ 95-0649, Bay Networks, July 1995. + + 10. Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework + Document", Work in Progress, AT&T Bell Laboratories/ ANS, April + 1995. + + 11. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC + 1112, Stanford University, August 1989. + + 12. Delgrossi, L., and L. Berger, Editors, "Internet Stream Protocol + Version 2 (ST-2) Protocol Specification - Version ST2+", RFC 1819, + ST2 Working Group, August 1995. + + 13. Dykeman, D., Ed., "PNNI Draft Specification", ATM Forum/94-0471R8, + IBM Zurich Research Lab, May 1995. + + + +Borden, et al Informational [Page 22] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + 14. Goyal, P., Lam, S., and Vin, H., "Determining End-to-End Delay + Bounds in Heterogeneous Networks," 5th International Workshop on + Network and Operating System Support for Digital Audio and Video, + April, 1995.(Available via URL http://www.cs.utexas.edu/users/dmcl) + + 15. Laubach, M., "Classical IP and ARP over ATM", RFC 1577, HP, + January 1994. + + 16. Moy, J., "OSPF Version 2", RFC 1583, Proteon, March 1994. + + 17. Moy, J., "Multicast Extensions to OSPF," RFC 1584, Proteon, March + 1994. + + 18. Partridge, C., "A Proposed Flow Specification", RFC 1363, BBN, + September 1992. + + 19. Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and + A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, + ISI, Fore, Motorola Codex, Ascom Timeplex, February 1995. + + 20. Perkins, D., and Liaw, Fong-Ching, "Beyond Classical IP-Integrated + IP and ATM Architecture Overview", ATM Forum/94-0935, Fore Systems, + September 1994. + + 21. Perkins, D. and Liaw, Fong-Ching, "Beyond Classical IP-Integrated + IP and ATM Protocol Specifications", ATM Forum/94-0936, Fore + Systems, September 1994. + + 22. Romanow, A., and S. Floyd, "The Dynamics of TCP Traffic over ATM + Networks", Proceedings of ACM SIGCOMM U94, London, August 1994, + pp.79-88. + + 23. Shenker, S., and C. Partridge. "Specification of Guaranteed Quality + of Service", Work in Progress, Xerox/BBN, July 1995. + + 24. Shenker, S., and C. Partridge. "Specification of Predictive Quality + of Service", Work in Progress, Xerox/BBN, March 1995. + + 25. Shenker, S., C. Partridge and J. Wroclawski. "Specification of + Controlled Delay Quality of Service", Work in Progress, + Xerox/BBN/MIT, June 1995. + + 26. Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: + A Transport Protocol for Real-time Applications", Work in Progress, + GMD/ISI/Xerox/LBL, March 1995. + + 27. Topolcic, C., "Experimental Internet Stream Protocol, Version 2 + (ST-II)", RFC 1190, BBN, October 1990. + + + +Borden, et al Informational [Page 23] + +RFC 1821 Real-time Service in IP-ATM Networks August 1995 + + + 28. Wang, Z., and J. Crowcroft, "QoS Routing for Supporting Resource + Reservation", University College of London white paper, 1995. + +10. Authors' Addresses + + Eric S. Crawley + Marty Borden + Bay Networks + 3 Federal Street + Billerica, Ma 01821 + 508-670-8888 + esc@baynetworks.com + mborden@baynetworks.com + + + Bruce S. Davie + Bellcore + 445 South Street + Morristown, New Jersey 07960-6438 + 201-829-4838 + bsd@bellcore.com + + + Stephen G. Batsell + Naval Research Laboratory + Code 5521 + Washington, DC 20375-5337 + 202-767-3834 + sgb@saturn.nrl.navy.mil + + + + + + + + + + + + + + + + + + + + + + +Borden, et al Informational [Page 24] + |