CURRENT_MEETING_REPORT_ Reported by Howard Berkowitz/PSC International and Andrew Malis/Ascom Nexion Minutes of the Routing Over Large Clouds Working Group (ROLC) and the IP Over Asynchronous Transfer Mode Working Group (IPATM) The ROLC and IPATM working groups met in a joint session on 3 April. There were 158 attendees. Agenda o IP Architecture Extensions for ATM -- Yakov Rekhter o NHRP and ATMARP interaction issues -- Mark Laubach o ATM Forum Announcement -- Drew Perkins IP Architecture Extensions for ATM Yakov Rekhter presented draft-rekhter-ip-atm-architecture-00.txt, which discusses IP architecture extensions for ATM (his presentation is included in these proceedings). He assumed that applications will emerge that could benefit from ATM services, and that neither LAN emulation nor Classical IP/ATM are able to support these services. Yakov recommended changes to the current LIS (Logical IP Subnet) model to extend the current IP over ATM architecture to better allow it to offer the full range of ATM services when necessary, while still offering current services as appropriate. Mark Laubach presented, as a comment to Yakov's talk, a diagram of the relationships between RFC 1577, ROLC, applications, and Yakov's talk. Yakov's model is the final goal, and multiple paths are being followed concurrently to get there. In the ensuing discussion of Yakov's talk, the working group concluded that the current ROLC work meets some of Yakov's needs, and the future work in the IPATM Working Group should address the issues; however, work must be coordinated with the Integrated Services and RSVP working groups. It was recognized that the working group needs to encourage greater interaction between application and communication layers; the INTSERV and RSVP Working Groups have also come to this conclusion. There was working group consensus to turn Yakov's Internet-Draft into an Informational RFC and to reference it in the IP/ATM Framework Document. RFC 1577 Client Behavioral Changes and NHRP and ATMARP Interactions Mark Laubach presented NHRP and ATMARP interaction issues, concentrating on RFC 1577 client behavioral changes to handle multiple address resolution services (with NHRP being one of the multiple services). His slides follow these minutes. Although the complete presentation is included in the proceedings, included here is a text-only transcription, updated to reflect working group decisions and consensus, so that they get properly recorded. In the following, `(R)' before a bullet means this will be a requirement in the main body of the RFC 1577 rewrite (called RFC 1577+), and `(I)' means it will go into an informational appendix. RFC1577+ Client-side Update to Handle Multiple Address Resolution Services and ATMARP <> NHS Interaction Issues o Intro/Problem Statement - Intro: * ATMARP service and server introduced in RFC1577 - Problem: * Single server issues with regard to fault tolerance - S.P.O.F. * No initial support for alternative services; e.g., NHRP - Proposed Solution: * Augment classical client to support generalized multiple address resolution services capability * Don't break single server model for clients or ATMARP servers * Don't change VC state independence o Generalized Multiple Service Details - Summary of Changes: * (R) Change the single ATMARP Request Address (atm$arp-req) configuration parameter to be a list of server addresses * (R) Type the entries in the list as to type of service: ATMARP or NHRP * (R) Type the service address as to unicast or multicast * (I) Keep operating state for each entry: up/down flag, down timestamp * (I) New algorithm for cruising the list and timing out servers - Notes: * (R) Local administration decides which services/servers and which order are appropriate for the LIS * (R) All services share/co-mingle the same ATMARP table on the client RFC1577+ Address Resolution Service o Generalized Multiple Service Algorithm (This material is informational) Init to top of the list While cruising list and if server ``up'' If no open VC, open one, if open ok Format a request to the server appropriate to the service Send the request Get a good response, ok, return with address Get a NAK, move to next service (normal) Get a timeout, mark entry as ``down,'' close resources If open fails, mark as ``down,'' close resources Move to next service Address resolution failure o Other Stuff - Server States * (I) A server is ``up'' unless the client experiences a timeout after sending an address resolution request * (I) A down server is re-tried every 5 minutes (based on down timestamp) by attempting to reopen a VC to the server, if the VC opens ok, server is marked ``up,'' otherwise it remains ``down.'' - Server Synchronization Standardization * (R) RFC1577+ will require server synchronization * Mark will look at adapting OSPF Designated Router specification RFC1577+ o What about information leakage? * Assumption: initially this assume an ATMARP server and an NHS server are in the same ``box'' -- i.e., let's not invent another protocol! * What information is valid to leak in each direction between an ATMARP server and an NHS? * When is it appropriate to leak? * When is it not appropriate to leak? - Other Stuff * Security is an issue * Look at Q.2931 address verification support The text summarized above (both required and informational) will be included in RFC 1577+. ATM Forum Announcement Drew Perkins, the ATM Forum liaison to the IETF, announced a relaxation in the ATM Forum's document distribution policy, to allow ROLC, IPATM, and other relevant working groups easier access to ATM Forum documents, including electronic access. There will also be a BOF at the next IETF to discuss how to foster better interactions between the IETF and the ATM Forum.