home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rolc / rolc-ipatm-minutes-95apr.txt < prev    next >
Text File  |  1995-05-26  |  7KB  |  183 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Howard Berkowitz/PSC International and
  6. Andrew Malis/Ascom Nexion
  7.  
  8. Minutes of the Routing Over Large Clouds Working Group (ROLC) and
  9. the IP Over Asynchronous Transfer Mode Working Group (IPATM)
  10.  
  11. The ROLC and IPATM working groups met in a joint session on 3 April.
  12. There were 158 attendees.
  13.  
  14.  
  15.  
  16. Agenda
  17.  
  18.    o IP Architecture Extensions for ATM -- Yakov Rekhter
  19.    o NHRP and ATMARP interaction issues -- Mark Laubach
  20.    o ATM Forum Announcement -- Drew Perkins
  21.  
  22.  
  23.  
  24. IP Architecture Extensions for ATM
  25.  
  26.  
  27. Yakov Rekhter presented draft-rekhter-ip-atm-architecture-00.txt, which
  28. discusses IP architecture extensions for ATM (his presentation is
  29. included in these proceedings).  He assumed that applications will
  30. emerge that could benefit from ATM services, and that neither LAN
  31. emulation nor Classical IP/ATM are able to support these services.
  32.  
  33. Yakov recommended changes to the current LIS (Logical IP Subnet) model
  34. to extend the current IP over ATM architecture to better allow it to
  35. offer the full range of ATM services when necessary, while still
  36. offering current services as appropriate.
  37.  
  38. Mark Laubach presented, as a comment to Yakov's talk, a diagram of the
  39. relationships between RFC 1577, ROLC, applications, and Yakov's talk.
  40. Yakov's model is the final goal, and multiple paths are being followed
  41. concurrently to get there.
  42.  
  43. In the ensuing discussion of Yakov's talk, the working group concluded
  44. that the current ROLC work meets some of Yakov's needs, and the future
  45. work in the IPATM Working Group should address the issues; however, work
  46. must be coordinated with the Integrated Services and RSVP working
  47. groups.  It was recognized that the working group needs to encourage
  48. greater interaction between application and communication layers; the
  49. INTSERV and RSVP Working Groups have also come to this conclusion.
  50. There was working group consensus to turn Yakov's Internet-Draft into an
  51. Informational RFC and to reference it in the IP/ATM Framework Document.
  52.  
  53.  
  54. RFC 1577 Client Behavioral Changes and NHRP and ATMARP Interactions
  55.  
  56. Mark Laubach presented NHRP and ATMARP interaction issues, concentrating
  57. on RFC 1577 client behavioral changes to handle multiple address
  58. resolution services (with NHRP being one of the multiple services).  His
  59. slides follow these minutes.
  60.  
  61. Although the complete presentation is included in the proceedings,
  62. included here is a text-only transcription, updated to reflect working
  63. group decisions and consensus, so that they get properly recorded.  In
  64. the following, `(R)' before a bullet means this will be a requirement in
  65. the main body of the RFC 1577 rewrite (called RFC 1577+), and `(I)'
  66. means it will go into an informational appendix.
  67.  
  68.  
  69. RFC1577+
  70.  
  71. Client-side Update to Handle Multiple Address Resolution Services and
  72. ATMARP <> NHS Interaction Issues
  73.  
  74.  
  75.    o Intro/Problem Statement
  76.  
  77.  
  78.       -  Intro:
  79.  
  80.           * ATMARP service and server introduced in RFC1577
  81.  
  82.       -  Problem:
  83.  
  84.           * Single server issues with regard to fault tolerance -
  85.             S.P.O.F.
  86.           * No initial support for alternative services; e.g., NHRP
  87.  
  88.       -  Proposed Solution:
  89.  
  90.           * Augment classical client to support generalized multiple
  91.             address resolution services capability
  92.           * Don't break single server model for clients or ATMARP
  93.             servers
  94.           * Don't change VC state independence
  95.  
  96.  
  97.    o Generalized Multiple Service Details
  98.  
  99.       -  Summary of Changes:
  100.  
  101.           * (R) Change the single ATMARP Request Address (atm$arp-req)
  102.                 configuration parameter to be a list of server addresses
  103.           * (R) Type the entries in the list as to type of service:
  104.                 ATMARP or NHRP
  105.           * (R) Type the service address as to unicast or multicast
  106.           * (I) Keep operating state for each entry:  up/down flag, down
  107.                 timestamp
  108.           * (I) New algorithm for cruising the list and timing out
  109.                 servers
  110.  
  111.       -  Notes:
  112.  
  113.           * (R) Local administration decides which services/servers and
  114.                 which order are appropriate for the LIS
  115.           * (R) All services share/co-mingle the same ATMARP table on
  116.                 the client RFC1577+ Address Resolution Service
  117.  
  118.  
  119.    o Generalized Multiple Service Algorithm
  120.      (This material is informational)
  121.  
  122.       Init to top of the list
  123.       While cruising list and if server ``up''
  124.          If no open VC, open one, if open ok
  125.             Format a request to the server appropriate to the service
  126.             Send the request
  127.             Get a good response, ok, return with address
  128.             Get a NAK, move to next service (normal)
  129.             Get a timeout, mark entry as ``down,'' close resources
  130.          If open fails, mark as ``down,'' close resources
  131.          Move to next service
  132.       Address resolution failure
  133.  
  134.  
  135.    o Other Stuff
  136.  
  137.       -  Server States
  138.  
  139.           * (I) A server is ``up'' unless the client experiences a
  140.                 timeout after sending an address resolution request
  141.           * (I) A down server is re-tried every 5 minutes (based on down
  142.                 timestamp) by attempting to reopen a VC to the server, if
  143.                 the VC opens ok, server is marked ``up,'' otherwise it
  144.                 remains ``down.''
  145.  
  146.       -  Server Synchronization Standardization
  147.  
  148.           * (R) RFC1577+ will require server synchronization
  149.           *     Mark will look at adapting OSPF Designated Router
  150.                 specification RFC1577+
  151.  
  152.  
  153.    o What about information leakage?
  154.  
  155.           * Assumption:  initially this assume an ATMARP server and an
  156.             NHS server are in the same ``box'' -- i.e., let's not invent
  157.             another protocol!
  158.           * What information is valid to leak in each direction between
  159.             an ATMARP server and an NHS?
  160.           * When is it appropriate to leak?
  161.           * When is it not appropriate to leak?
  162.  
  163.       -  Other Stuff
  164.  
  165.           * Security is an issue
  166.           * Look at Q.2931 address verification support
  167.  
  168.  
  169. The text summarized above (both required and informational) will be
  170. included in RFC 1577+.
  171.  
  172.  
  173.  
  174. ATM Forum Announcement
  175.  
  176. Drew Perkins, the ATM Forum liaison to the IETF, announced a relaxation
  177. in the ATM Forum's document distribution policy, to allow ROLC, IPATM,
  178. and other relevant working groups easier access to ATM Forum documents,
  179. including electronic access.  There will also be a BOF at the next IETF
  180. to discuss how to foster better interactions between the IETF and the
  181. ATM Forum.
  182.  
  183.