home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
ipatm
/
ipatm-minutes-95jul.txt
< prev
next >
Wrap
Text File
|
1995-10-18
|
7KB
|
186 lines
CURRENT_MEETING_REPORT_
Reported by Andy Malis/Ascom Nexion and Mark Laubach/Com21
Minutes of the IP Over Asynchronous Transfer Mode Working Group (IPATM)
The IPATM Working Group met once at the 33rd IETF on Thursday, 20 July
with 101 people in attendance. The session was multicast but there were
no comments or questions from the multicast audience.
Documents of the IPATM Working Group are available on the Web:
http://www.com21.com/pages/ietf.html
ATM Forum Update
Joel Halpern gave a very short summary of the current ATM Forum MPOA
work. MPOA will be relying heavily on the Next Hop Routing Protocol
(NHRP) work in the Routing Over Large Clouds Working Group (ROLC).
The IPMC, Multicast Encapsulation and Broadcast Drafts
``Support for Multicast over UNI 3.1 based ATM Networks''
draft-ietf-ipatm-ipmc-05.txt
``Issues surrounding a new encapsulation for IP over ATM''
draft-armitage-ipatm-encaps-02.txt
``IP Broadcast over ATM Networks''
draft-smith-ipatm-bcast-01.txt
Grenville Armitage led the discussion of these three documents. A copy
of his slides follow these minutes. He has a Web repository for
multicast drafts and related material:
http://gump.bellcore.com:8000/~gja/i-drafts.html
Version -06 of the IPMC draft will be coming out very soon (in a week or
two). Mark Laubach summarized outstanding issue decisions that effect
the next turn of the IPMC draft:
o Do Class II only, to avoid interoperability issues. This did not
get any dissent.
o The cluster scope is the same as the LIS, at least for now. Walter
agrees, and wants this emphasized. Joel Halpern also agrees. Rob
Coltun, on the other hand, wants to expand the scope, and allow
cutthrough. The current consensus is that this is premature, but
may be investigated in the future. Mark raised the point that
making the two scopes the same now is a good starting point.
Everyone seemed to agree on this.
o Choose encapsulation option #6? No dissent.
Walter Milliken (BBN) made the argument that the Broadcast draft is much
more complicated than it need be. His comments will be considered for
the next draft.
The Framework Document
``IP over ATM: A Framework Document''
draft-ietf-ipatm-framework-doc-03.ps, .txt
David Shur (AT&T) gave an update on the Framework document. Version -03
came out several weeks ago, and has received a few comments. They would
like to freeze the document as it is, and move forward to turning it
into an Informational RFC. They solicited any additional comments to
come soon, so that they can go to the RFC as soon as possible.
Joel argued in favor of keeping it an Internet-Draft, so that it can be
updated continuously. Mark pointed out that it cannot be referenced as
an Internet-Draft, so it will be made into an RFC to allow it to be a
``real'' document which can be referenced. Joel agreed with that
reasoning. Future mods can be done as new RFCs.
The IP Multicasting over ATM Draft
``IP Multicasting over ATM: System Architecture Issues''
draft-ietf-ipatm-arch-00.txt
Ann Demirtjis, Sprint, presented draft-ietf-ipatm-arch-00.txt and will
edit the next version of the draft. In her slides (which follow these
minutes), italics represent points where she has added material from
Walter's draft, or disagrees with it.
There was a discussion during her presentation of whether IP over ATM
should use IGMP for multicast:
o Walter: one additional comment is IGMPv3. It is a new thing and
requires more stuff to happen. It would require a MARS rewrite to
handle the new functionality.
o Ann: I think that this is a non-issue for IP over ATM multicast.
MARS should be able to get join information and pass it back to the
router.
o Grenville: Let me clarify a few points. The model ought to be
viewed as the MARS being the link level driver underneath
IGMP---neither requiring it or supporting it directly. There is a
distinction that the MARS lies under IGMP. It would be fair to say
that people could implement an IP over ATM driver that could
support IGMP via an ioctl() that queries the MARS.
o Ann: what should be in this document is that all the protocols at
the IP layer must be supported.
o Walter: I would prefer the ``hack'' taken out so that we do not
have future interoperability problems. I believe the IGMP support
is mandatory and should be stated in the document.
o Grenville: we can restate things so that any implementation must
support IGMP.
o Joel: clearly the document will not give anyone the right to not
implement IGMP. However, at the same time, the document should talk
about ways of improving the system so that things will work better.
o Rob: DVMRP uses IGMP.
o Ann: yes, IGMP must be supported. Applications should be able to
use ATM QoS directly without.
o Eric: you must pay attention to QoS when leaving the ATM cloud if
you want to have QoS carried.
o Unknown: It is appropriate to say that RSVP must be supported. It
is not appropriate to say that RVSP exclusively.
In Walter's draft, QoS can only be provided via RSVP. Ann feels that you
don't need to use RSVP if the host is directly on ATM---it can set up
the VC on its own that fulfills its needs. The point was made that this
works only as long as all the multicast receivers are on the same ATM
network.
The group discussed how LIJ can be used---the MARS could give the
required GCID to the host for the LIJ.
There was a discussion of when meshes make sense vs. multicast servers,
and when RSVP should or should not be used.
The document is going to be restructured based on comments, and Ann will
be producing a new version (date unknown).
Mark reviewed the multicast overview issues from the Danvers IETF that
the group asked Ann and Walter to address. Please see Mark's slides
which follow these minutes.
The Integrated Services Draft
``Integrated Services IP Multicasting over ATM''
draft-milliken-ipatm-services-00.txt
Walter Milliken presented some slides on his integrated services draft.
A copy of his slides follow these minutes.
Walter put up some diagrams, including one that illustrated using NRHP
to produce shortcut multicast path setup. However, he realizes that
there's a lot of work left to do to make this work. Shortcut also
introduces problems with using TTL to end routing loops or control
geographic distribution.
Conclusion
Mark ended the meeting with a brief summary of the status of the
RFC 1577 update and of items remaining on the group's work plan. Please
see his slides which follow these minutes.