rfc1821.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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