Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/95apr/colip-minutes-95apr.txt

Text File | 1995-05-27 | 15KB | 363 lines

CO and CL IP Transport over ATM BOF (COLIP)

Reported by Hiroshi Esaki/Toshiba Corporation

The COLIP BOF met on Tuesday, 4 April, at the 32nd IETF. The meeting was
chaired by Hiroshi Esaki and Masataka Ohta.

Mailing list information:


        Mailing list: [e-mail]
        To Subscribe: [e-mail]



I. Abstract


The issues and framework of IP packet transport with the provision of
QoS using ATM in large scale and heterogeneous Internet were discussed.
The methodology and framework of mapping between the QoS'ed IP packet
flow defined by the resource reservation protocol (e.g., ST-II and RSVP)
and the ATM data-link connection (i.e., QoS'ed cell-relaying channel) is
the important issue to explore and this issue has not been discussed in
other working groups.  The roughly identified work items are:


   o Architecture model documentation.
   o Protocol development associated with the interaction between ATM
     and ST-II/RSVP.
   o Large scale multicast over the Internet including ATM.
   o Methodology and framework to optimize (i.e., cut-thru packet
     switching) IP packet forwarding.


The work items should be clarified on the mailing list.



II. Agenda

  1. Purpose of the BOF -- H. Esaki
  2. Conventional model of IP over ATM -- M. Ohta
  3. IP packet transport using Cell Switch Router (CSR) model -- Y.
     Katsube
  4. Flow management and control issues on ATM -- H. Esaki
  5. Conclusion


Item 4 was not discussed.



III. Purpose of the BOF

The purpose of this BOF is to discuss the protocol and architecture that
extract the capability of ATM, that can provide QoS data-link pipe for
each communication flow, for IP communication with new network and
transport protocol suite (e.g., resource reservation oriented protocol
such as RSVP).

In the wide area Internet, it was said that it was almost impossible to
provide cell-relay based end-to-end pipe.  When the QoS requirement and
the required bandwidth for the IP flow can be explicitly indicated to
the router, it will be easy to relay the IP packet cell-by-cell in the
router, while provide QoS assurance.  In other words, the interaction
between the QoS oriented network/transport protocol (e.g., RSVP/ST-II)
and the ATM protocol must be explored to provide end-to-end QoS
provision over the Internet.

The conventional connectionless service can be provided just using a
connection oriented data-link pipe among the routers.

The discussed architecture and protocol should accommodate all
architecture models discussed in the IETF (e.g., NHRP with NBMA) and the
ATM Forum (LAN Emulation).  The point that should be discussed is how to
transport the IP packets, when the data-link is connection oriented
platform (especially ATM) providing QoS pipes.  By the use of routers,
we can provide hard-state, soft-state and stateless paths over the
heterogeneous Internet.


IV. Conventional Model of IP over ATM

Presentation Summary

Masataka Ohta presented the conventional model of IP over ATM. The
issues of the currently discussed IP over ATM models from the viewpoint
of global Internet are clarified, and the cell-relay capable router was
introduced.


   o Signaling by IP, not by Q.2931

     One of the difficulties of ``IP over ATM'' is that ATM signaling
     carried by Q.2931 packet cannot be sent over IP routers.

     As IP routers do not recognize Q.2931, the global Internet must use
     IP style packet format for signaling.  Just as legacy ATM switches
     recognize Q.2931 signaling requests and setup switching hardware
     appropriately, cell switching routers or IP-routing switches,
     having hardware cell switching capability, should recognize IP
     signaling requests, consult IP routing table, and setup switching
     hardware appropriately.

     IP signaling preserves CATENET model including scalability and
     dynamic re-routability.

   o Transport layer resource reservation protocol

     As the network layer of the Internet does not have any notion of
     QoS, higher layers must be consulted to know the QoS requirement to
     link-layer ATM connection.  Existing transport layer resource
     reservation protocol (e.g., RSVP/ST-II) of the Internet can map
     directly to the ATM link level resource reservation requirement.
     That is, RSVP/ST-II can be regarded as ``IP signaling,'' when we
     use similar terminology to ATM.

     Multiple datalink segments, which may or may not be ATM based, will
     be signaled by RSVP/ST-II. Within ATM based datalink segments,
     Q.2931 signaling will be performed.

   o Communication without QoS

     IP packets without QoS specification will be relayed by default VC
     between cell relaying IP routers packet by packet.  ABR, having
     poor feedback over long segments, will be useful, if control is
     terminated on cell relaying IP routers.  In other words, ABR should
     be terminated at the IP router and ABR connection should be used
     for the short-haul connection between IP routers.

   o Large cloud issues

     Cell switching routers can offer cell-by-cell connection between
     ATM large clouds.

     But, instead of implementing ATM public data networks as large
     cloud NSAP based networks, they should be constructed with cell
     relaying routers connecting small datalink layers.

   o IPv6 autoconfiguration

     IPv6 autoconfiguration means complete autoconfiguration.  That is,
     it is not allowed to manually configure each host of NSAP addresses
     of ARP and/or multicast servers.  In order to support this type of
     autoconfiguration, the ATM protocol must be extended to have real,
     server-less, broadcast functionality.

   o Multi-protocol issues

     On the Internet, multiprotocol means single IP over multiple
     datalink layer protocols.  Applications should not be required as
     special case handling only because end hosts are connected purely
     by ATM. That is, for multiprotocolness, QoS requirement must be
     signaled by IP packet format.

     On the other hand, in a pure ATM world, it is often desired to
     support end-to-end ATM connection regardless of the format of the
     data.  As IP signaling sets up cell-by-cell relaying end-to-end
     path even through routers, users, who know they are using pure ATM
     datalink segments, may use any non-IP data in the path.

   o IP packet forwarding by cell switching

     A Router that interconnects the ATM clouds could have both packet
     switch and cell switch simultaneously.  The IP packet flows, whose
     required bandwidth and QoS requirement is realized, can be
     forwarded only through cell switch with bypassing packet switch.



Discussion

The following are questions/comments received and the
realizations/solutions for them.


   o How to map between IP packet flows and ATM cell-relaying channel?

     How to aggregate the IP flows into the ATM cell-relaying channel
     should be the router's local decision.  One to one mapping between
     IP flows and ATM cell-relaying channel is possible, but multiple IP
     flows can aggregated into a single ATM cell-relaying channel by the
     router's local decision.

   o Is the use of RSVP required for the communication within the ATM
     cloud?

     As long as we need QoS'ed communication on the global Internet, we
     need some reservation protocol (i.e., RSVP/ST-II). Data without QoS
     can be transmitted packet by packet even over ATM without
     reservation protocols.  ABR over ATM cannot assure delay bound that
     is the QoS parameter discussed in the INTSERV Working Group.

   o Must we interconnect small ATM (data-link) clouds by routers, even
     in LPDN?

     It is impossible to force the use of the architecture that small
     ATM clouds are interconnected by routers.  However, at least, LPDNs
     should not be forced to use a large cloud model.

   o IPv6 autoconfigurable data-link platform

     IPv6 does not always require a complete autoconfigurable platform,
     that does not need any configuration server.  Some data-link
     platforms require the complete autoconfigurable capability.  ATM
     platform may not be able to satisfy IPv6 autoconfiguration
     requirement.


V. IP Packet Transport Using CSR Architecture

Presentation Summary

The architecture of Cell Switch Router (CSR) was introduced by Y.
Katsube, from the viewpoint of RSVP over ATM. The introduced router
architecture is the router to interconnect any size ATM cloud.  The
features of the introduced architecture follow.


   o Segregation of control packet flow from application data flow

     The control message (e.g., path message and reservation message in
     RSVP) packet flow and application data packet flow use the
     different ATM cell-relaying channel.  The information exchange
     related to the control of cut-through pipe is performed using the
     control message packet also.

     Such information exchange is performed hop-by-hop, not end-to-end.

   o Packet forwarding by cell switch

     When the IP packet flow(s), whose requiring bandwidth is specified
     and whose destinations are common (e.g., the same subnet), are
     conveyed over dedicated-VCs, it can be forwarded by cell-switch
     without any examination of IP packet header at the intermediate
     routers.  Other IP packet flows are forwarded using an IP packet
     forwarder.

   o Any size/model of ATM clouds interconnection

     CSR router does not care about the size and model of ATM cloud that
     the CSR router is attached.  Any size and any model of ATM clouds
     can be interconnected, while the packet forwarding performance will
     be the same as the case where the ATM clouds are interconnected
     without routers using P-NNI protocol.



Discussion

The following issues were discussed.


   o RSVP Path/Reserve message over large cloud model

     In the large cloud ATM model, a RSVP multicast would have a scaling
     problem.

     For the large scale multicast including large ATM cloud, there
     would not be any router between the ingress router to the ATM cloud
     and the down-stream routers (egress routers from ATM cloud).  When
     ATM cloud is large and RSVP multicast is large scale, i.e., large
     fan-out within the multicast tree, the upstream router (ingress
     router to the ATM cloud) will receive a large number of reserve
     messages from the down-stream routers.

   o Dynamic reservation status changing over ATM

     RSVP and Integrated Service model allow to change the reservation
     status (e.g., QoS class) during a session.  Q.2931 does not have
     QoS re-negotiation capability at this time.  How to support dynamic
     reservation status changing over ATM network must be solved.

   o ATM-VCC channel and cut-through pipe establishment and tear-down

     The decision criteria of ATM-VCC channel and cut-through pipe
     establishment and tear-down is not clear enough.  Basically, the
     decision of ATM-VCC (i.e., dedicated VC) establishment and
     tearing-down should be CSR router's local decision.

   o Benefit of CSR model

     The introduced CSR model may provide a new service benefit.
     However, it is not explored enough during this BOF session.  When
     the introduced model can provide something, a new benefit, that ATM
     cloud model cannot provide, it should be clarified.

   o What is the standardization issue

     Obviously, CSR architecture itself is not for standardization item.
     But, for the implementation, we need some protocol to map flow
     labels and VCI/VPI values.  The point of standardization item must
     be clarified, with the clarification of the benefits when we have
     new protocol messages associated with the introduced CSR model.

   o Document handling

     The Internet-Drafts associated with CSR router (e.g.,
     draft-katsube-router-atm-overview-00.txt) should be published as an
     Informational RFC, from the viewpoint of the interworking between
     ATM and RSVP.


VI. Conclusion and Summary

The issues and framework of IP packet transport with the provision of
QoS using ATM in large scale and heterogeneous Internet were discussed.
It was realized that the methodology and framework of mapping between
the QoS'ed IP packet flow defined by the resource reservation protocol
(e.g., ST-II and RSVP) and the ATM data-link connection (i.e., QoS'ed
cell-relaying channel) is the important issue to explore and this issue
has not been discussed in other working groups.  The roughly identified
work items are:


   o Architecture model documentation.

     It was understood that CATENET does not need to be abandoned to
     support ATM on the Internet; and, for example, the use of CATENET
     model in ATM may provide the functions that LIS and large ATM cloud
     model cannot.

     It was agreed that architecture documents should be published as
     Informational RFCs (i.e., there was no explicit objection to
     requesting to publish the architectural documents as Informational
     RFCs).

   o Protocol development associated with the interaction between ATM
     and ST-II/RSVP.

     It was not understood by everybody that new protocols are needed
     for the interaction between ATM and ST-II/RSVP. And even if they
     are needed, whether it should be developed in a new working group
     or in existing working groups.

   o Large scale multicast over the Internet including ATM.


The work items should be clarified on the mailing list.  The work items
raised in the BOF session relate to many other working groups, and may
overlap with other groups.  The group could not decide whether to
propose to create a new working group.  Joel Halpern said that a working
group cannot be created to only design a router.  Further discussion and
clarification will take place on the mailing list.



VII. Existing Drafts

 Internet-Draft:  M. Ohta, H. Esaki, K. Nagami, ``Conventional IP over ATM,''
                  draft-ohta-ip-over-atm-02.txt, March, 1995.

 Internet-Draft:  H. Esaki, M. Ohta, K. Nagami, ``Connection Oriented and
                  Connectionless IP Forwarding over ATM Networks,''
                  draft-esaki-co-cl-ip-forw-atm-01.txt, Oct., 1994.

 Internet-Draft:  Y. Katsube, K. Nagami, H. Esaki, ``Router Architecture
                  Extensions for ATM: Overview,''
                  draft-katsube-router-atm-overview-00.txt.