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: colip-atm@necom830.cc.titech.ac.jp To Subscribe: colip-atm-request@necom830.cc.titech.ac.jp 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.