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.