rfc2098.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/3 页

Network Working Group                                        Y. Katsube
Request for Comments: 2098                                    K. Nagami
Category: Informational                                        H. Esaki
                                                     Toshiba R&D Center
                                                          February 1997


      Toshiba's Router Architecture Extensions for ATM : Overview

Status of this 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

   This memo describes a new internetworking architecture which makes
   better use of the property of ATM.  IP datagrams are transferred
   along hop-by-hop path via routers, but datagram assembly/disassembly
   and IP header processing are not necessarily carried out at
   individual routers in the proposed architecture.  A concept of "Cell
   Switch Router (CSR)" is introduced as a new internetworking
   equipment, which has ATM cell switching capabilities in addition to
   conventional IP datagram forwarding.  Proposed architecture can
   provide applications with high-throughput and low-latency ATM pipes
   while retaining current router-based internetworking concept.  It
   also provides applications with specific QoS/bandwidth by cooperating
   with internetworking level resource reservation protocols such as
   RSVP.

1.  Introduction

   The Internet is growing both in its size and its traffic volume. In
   addition, recent applications often require guaranteed bandwidth and
   QoS rather than best effort.  Such changes make the current hop-by-
   hop datagram forwarding paradigm inadequate, then accelerate
   investigations on new internetworking architectures.

   Roughly two distinct approaches can be seen as possible solutions;
   the use of ATM to convey IP datagrams, and the revision of IP to
   support flow concept and resource reservation.  Integration or
   interworking of these approaches will be necessary to provide end
   hosts with high throughput and QoS guaranteed internetworking
   services over any datalink platforms as well as ATM.

   New internetworking architecture proposed in this draft is based on
   "Cell Switch Router (CSR)" which has the following properties.



Katsube, et. al.             Informational                      [Page 1]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


    - It makes the best use of ATM's property while retaining current
      router-based internetworking and routing architecture.

    - It takes into account interoperability with future IP that
      supports flow concept and resource reservations.

   Section 2 of this draft explains background and motivations of our
   proposal.  Section 3 describes an overview of the proposed
   internetworking architecture and its several remarkable features.
   Section 4 discusses control architectures for CSR, which will need to
   be further investigated.

2.  Background and Motivation

   It is considered that the current hop-by-hop best effort datagram
   forwarding paradigm will not be adequate to support future large
   scale Internet which accommodates huge amount of traffic with certain
   QoS requirements.  Two major schools of investigations can be seen in
   IETF whose main purpose is to improve ability of the Internet with
   regard to its throughput and QoS.  One is to utilize ATM technology
   as much as possible, and the other is to introduce the concept of
   resource reservation and flow into IP.

1) Utilization of ATM

   Although basic properties of ATM; necessity of connection setup,
   necessity of traffic contract, etc.; is not necessarily suited to
   conventional IP datagram transmission, its excellent throughput and
   delay characteristics let us to investigate the realization of IP
   datagram transmission over ATM.

   A typical internetworking architecture is the "Classical IP Model"
   [RFC1577].  This model allows direct ATM connectivities only between
   nodes that share the same IP address prefix.  IP datagrams should
   traverse routers whenever they go beyond IP subnet boundaries even
   though their source and destination are accommodated in the same ATM
   cloud.  Although an ATMARP is introduced which is not based on legacy
   datalink broadcast but on centralized ATMARP servers, this model does
   not require drastic changes to the legacy internetworking
   architectures with regard to the IP datagram forwarding process.
   This model still has problems of limited throughput and large
   latency, compared with the ability of ATM, due to IP header
   processing at every router.  It will become more critical when
   multimedia applications that require much larger bandwidth and lower
   latency become dominant in the near future.






Katsube, et. al.             Informational                      [Page 2]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   Another internetworking architecture is "NHRP (Next Hop Resolution
   Protocol) Model" [NHRP09].  This model aims at resolving throughput
   and latency problems in the Classical IP Model and making the best
   use of ATM.  ATM connections can be directly established from an
   ingress point to an egress point of an ATM cloud even when they do
   not share the same IP address prefix.  In order to enable it, the
   Next Hop Server [KAT95] is introduced which can find an egress point
   of the ATM cloud nearest to the given destination and resolves its
   ATM address.  A sort of query/response protocols between the
   server(s) and clients and possibly server and server are specified.
   After the ATM address of a desired egress point is resolved, the
   client establishes a direct ATM connection to that point through ATM
   signaling procedures [ATM3.1].  Once a direct ATM connection has been
   set up through this procedure, IP datagrams do not have to experience
   hop-by-hop IP processing but can be transmitted over the direct ATM
   connection.  Therefore, high throughput and low latency
   communications become possible even if they go beyond IP subnet
   boundaries.  It should be noted that the provision of such direct ATM
   connections does not mean disappearance of legacy routers which
   interconnect distinct ATM-based IP subnets.  For example, hop-by-hop
   IP datagram forwarding function would still be required in the
   following cases:

   - When you want to transmit IP datagrams before direct ATM connection
     from an ingress point to an egress point of the ATM cloud is
     established

   - When you neither require a certain QoS nor transmit large amount of
     IP datagrams for some communication

   - When the direct ATM connection is not allowed by security or policy
     reasons

2) IP level resource reservation and flow support

   Apart from investigation on specific datalink technology such as ATM,
   resource reservation technologies for desired IP level flows have
   been studied and are still under discussion.  Their typical examples
   are RSVP [RSVP13] and STII [RFC1819].

   RSVP itself is not a connection oriented technology since datagrams
   can be transmitted regardless of the result of the resource
   reservation process.  After a resource reservation process from a
   receiver (or receivers) to a sender (or senders) is successfully
   completed, RSVP-capable routers along the path of the flow reserve
   their resources for datagram forwarding according to the requested
   flow spec.




Katsube, et. al.             Informational                      [Page 3]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   STII is regarded as a connection oriented IP which requires
   connection setup process from a sender to a receiver (or receivers)
   before transmitting datagrams.  STII-capable routers along the path
   of the requested connection reserve their resources for datagram
   forwarding according to the flow spec.

   Neither RSVP nor STII restrict underlying datalink networks since
   their primary purpose is to let routers provide each IP flow with
   desired forwarding quality (by controlling their datagram scheduling
   rules).  Since various datalink networks will coexist as well as ATM
   in the future, these IP level resource reservation technologies would
   be necessary in order to provide end-to-end IP flow with desired
   bandwidth and QoS.

   aking this background into consideration, we should be aware of
   several issues which motivate our proposal.

   - As of the time of writing, the ATM specific internetworking
     architecture proposed does not take into account interoperability
     with IP level resource reservation or connection setup protocols.
     In particular, operating RSVP in the NHRP-based ATM cloud seems to
     require much effort since RSVP is a soft-state receiver-oriented
     protocol with multicast capability as a default, while ATM with
     NHRP is a hard-state sender-oriented protocol which does not
     support multicast yet.

   - Although RSVP or STII-based routers will provide each IP flow with
     a desired bandwidth and QoS, they have some native throughput
     limitations due to the processor-based IP forwarding mechanism
     compared with the hardware switching mechanism of ATM.

   The main objective of our proposal is to resolve the above issues.

   The proposed internetworking architecture makes the best use of the
   property of ATM by extending legacy routers to handle future IP
   features such as flow support and resource reservation with the help
   of ATM's cell switching capabilities.

3.  Internetworking Architecture Based On the Cell Switch Router (CSR)

3.1  Overview

   The Cell Switch Router (CSR) is a key network element of the proposed
   internetworking architecture.  The CSR provides cell switching
   functionality in addition to conventional IP datagram forwarding.
   Communications with high throughput and low latency, that are native
   properties of ATM, become possible by using this cell switching
   functionality even when the communications pass through IP subnetwork



Katsube, et. al.             Informational                      [Page 4]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   boundaries.  In an ATM internet composed of CSRs, VPI/VCI-based cell
   switching which bypasses datagram assembly/disassembly and IP header
   processing is possible at every CSR for communications which lend
   themselves to such (e.g., communications which require certain amount
   of bandwidth and QoS), while conventional hop-by-hop datagram
   forwarding based on the IP header is also possible at every CSR for
   other conventional communications.

   By using such cell-level switching capabilities, the CSR is able to
   concatenate incoming and outgoing ATM VCs, although the concatenation
   in this case is controlled outside the ATM cloud (ATM's control/
   management-plane) unlike conventional ATM switch nodes.  That is, the
   CSR is attached to ATM networks via an ATM-UNI instead of NNI.  By
   carrying out such VPI/VCI concatenations at multiple CSRs
   consecutively, ATM level connectivity composed of multiple ATM VCs,
   each of which connects adjacent CSRs (or CSR and hosts/routers), can
   be provided.  We call such an ATM pipe "ATM Bypass-pipe" to
   differentiate it from "ATM VCC (VC connection)" provided by a single
   ATM datalink cloud through ATM signaling.

   Example network configurations based on CSRs are shown in figure 1.
   An ATM datalink network may be a large cloud which accommodates
   multiple IP subnets X, Y and Z.  Or several distinct ATM datalinks
   may accommodate single IP subnet X, Y and Z respectively.  The latter
   configuration would be straightforward in discussing the CSR, but the
   CSR is also applicable to the former configuration as well.  In
   addition, the CSR would be applicable as a router which interconnects
   multiple NHRP-based ATM clouds.

   Two different kinds of ATM VCs are defined between adjacent CSRs or
   between CSR and ATM-attached hosts/routers.

1) Default-VC

   It is a general purpose VC used by any communications which select
   conventional hop-by-hop IP routed paths.  All incoming cells received
   from this VC are assembled to IP datagrams and handled based on their
   IP headers.  VCs set up in the Classical IP Model are classified into
   this category.

2) Dedicated-VC

   It is used by specific communications (IP flows) which are specified
   by, for example, any combination of the destination IP address/port,
   the source IP address/port or IPv6 flow label.  It can be
   concatenated with other Dedicated-VCs which accommodate the same IP
   flow as it, and can constitute an ATM Bypass-pipe for those IP flows.




Katsube, et. al.             Informational                      [Page 5]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   Ingress/egress nodes of the Bypass-pipe can be either CSRs or ATM-
   attached routers/hosts both of which speak a Bypass-pipe control
   protocol.  (we call that "Bypass-capable nodes") On the other hand,
   intermediate nodes of the Bypass-pipe should be CSRs since they need
   to have cell switching capabilities as well as to speak the Bypass-
   pipe control protocol.

   The route for a Bypass-pipe follows IP routing information in each
   CSR.  In figure 1, IP datagrams from a source host or router X.1 to a
   destination host or router Z.1 are transferred over the route X.1 ->
   CSR1 -> CSR2 -> Z.1 regardless of whether the communication is on a
   hop-by-hop basis or Bypass-pipe basis.  Routes for individual
   Dedicated-VCs which constitutes the Bypass-pipe X.1 --> Z.1 (X.1 ->
   CSR1, CSR1 -> CSR2, CSR2 -> Z.1) would be determined based on ATM
   routing protocols such as PNNI [PNNI1.0], and would be independent of
   IP level routing.

   An example of IP datagram transmission mechanism is as follows.

   o The host/router X.1 checks an identifier of each IP datagram,
     which may be the "destination IP address (prefix)",
     "source/destination IP address (prefix) pair", "destination IP
     address and port", "source IP address and Flow label (in IPv6)",
     and so on.  Based on either of those identifiers, it determines
     over which VC the datagram should be transmitted.

   o The CSR1/2 checks the VPI/VCI value of each incoming cell.  When
     the mapping from the incoming interface/VPI/VCI to outgoing
     interface/VPI/VCI is found in an ATM routing table, it is directly
     forwarded to the specified interface through an ATM switch module.
     When the mapping in not found in the ATM routing table (or the
     table shows an IP module as an output interface), the cell is
     assembled to an IP datagram and then forwarded to an appropriate
     outgoing interface/VPI/VCI based on an identifier of the datagram.

















Katsube, et. al.             Informational                      [Page 6]