ROLC/IPATM Joint meeting final minutes

[Andy Malis <[e-mail]>]

Routing Over Large Clouds (ROLC) and IP/ATM Joint Working Group Minutes
IETF Meeting, April 3, 1995
Danvers, Massachusetts

Chairs: Andrew Malis, Ascom Nexion, and Mark Laubach, Com21
Minutes: Howard Berkowitz and Andrew Malis

The ROLC and IP/ATM working groups met in a joint session on 3 April.
There were 158 attendees.


Agenda:
1. IP Architecture Extensions for ATM
   Yakov Rekhter, IBM
2. NHRP and ATMARP interaction issues
   Mark Laubach, Com21
3. ATM Forum Announcement
   Drew Perkins, Fore


1. 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 the 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 WG concluded that the
current ROLC work meets some of Yakov's needs, and the future work in
the IP/ATM WG should address the issues, however, work must be
coordinated with the Integrated Services and RSVP working groups.  It
was recognized that the WG needs to encourage greater interaction
between application and communication layers; the int-serv and RSVP
groups have also come to this conclusion.  There was WG consensus to
turn Yakov's I-D into an informational RFC and to reference it in the
IP/ATM Framework Document.


2. 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).

Although the complete presentation is included in the proceedings,
included here is a text-only transcription, updated to reflect WG
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
              +
ATMARP <> NHS Interaction Issues

---

Intro/Problem Statement

Intro:

* ATMARP service and server introduced in RFC1577

Problem:

* Single server issues w.r.t. 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

---

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

---

Generalized Multiple Service Algorithm
[This entire slide 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

---

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+

---

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 result of the talk will be the new text summarized above (both
required and informational) in RFC 1577+.


3. 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, IP/ATM,
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.