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.