📄 rfc1821.txt
字号:
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 evenBorden, 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 whenBorden, 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.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -