home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
ipatm
/
ipatm-minutes-94dec.txt
< prev
next >
Wrap
Text File
|
1995-02-28
|
7KB
|
175 lines
CURRENT_MEETING_REPORT_
Reported by Mark Laubach/Com21
Minutes of the IP Over Asynchronous Transfer Mode Working Group (IPATM)
Documents of the IPATM Working Group are available from
ftp://ftp.com21.com/ftp/pub/ip-atm. The group also has a WWW server,
http://www.com21.com/pages/ietf.html.
ATM Forum Liaison Report - Drew Perkins
Drew Perkins gave a report on the ATM Forum. He will also send an
e-mail report to the mailing list for the Kyoto meeting (held during the
last week of November).
The following documents are complete:
o LANE - all minor and major questions have been answered.
o IISP
o CMIP, SNMP MIBs (m4)
o Test specifications
LANE emulation has been made UNI mapping independent (UNI 3.0 and 3.1
are supported). Intelligent bus support has been added. A ready
indicate packet has been added (on data connections) and its use is now
mandatory
PNNI has started new work items for soft Permanent Virtual Paths (PVPs).
The Multiprotocol over ATM group identified some requirements and
different reference models for how the system should work centered
around defining single end system host behavior (query/response).
The Signaling working group has continued progress on ``leaf initiated
join.'' The group will start authenticated connection work at the next
meeting, and it was reported that ATM DXI for channelized DS3 has been
sent to straw ballot.
The issue of emulation of D1 circuits has been sent to straw ballot.
The support of early packet drop (cell drop, frame drop) is beginning to
get specified.
The PHY (physical) group is now allowed to specify more than one
interface.
A new Residential Broadband (RBB) group is starting up as a Birds of a
Feather (BOF) effort. The group is calling for contributions.
There was some discussion on multiprotocol BOF models: LANE model,
combined with Classical and NHRP model.
RFC 1577 Implementors Round-up
There are now about ten implementations in progress and Digital may have
passed the first interoperability test with two other vendors (who
prefer to remain anonymous).
Interpersonal Multimedia Communications over ATM
Dario Ercole gave this presentation. It was also shown at Interop '94.
Their ATM network connected Paris with Torino using 155 Mbps and 34 Mbps
links. Sun workstations with FORE SBA200 ATM adapters were used for the
presentation. They discovered that they could not run IP over ATM over
a public network if they did not perform rate control. This means
application level rate control and inter-switch rate control. The NNI
between the switches generated ``big packets.''
There was a question regarding the use of RFC 1577 over the wide-area.
Who is going to provide/specify the recommendations for the policing
function? Andy Malis stated that very much is dependent on the type of
network the traffic is being sent through. Dario agrees.
Ken Hayward asked if ATM is deregulated in Europe. He also asked about
multiple vendors and solutions. Dario responded that this topic is not
network specific. Consensus is that this is more of an ATM specific
issue and that IP over ATM will make use of available services. While
not an issue of this working group's charter, performance of ATM does
impact performance of IP over ATM.
IP Multicast Draft Review
Grenville Armitage gave an overview of his two Internet-Drafts. The
goals of the documents are to work within RFC 1577 context and utilize
UNI 3.1 multicast services. UNI 4.0 and IP multicast routing are not
goals.
Mark recommend that there be a separate registration server, i.e.,
de-couple ATMARP_REQUEST from the multicast-request. There was a
comment to please not have the user type in two 20-byte addresses.
Maybe there is a clever way to do this? A question was raised about
whether the two servers can live at the same LLC entity? Mark raised
the point of if the ARP type coding is distinct, it is possible that it
and an ATMARP server could live above 0x0806, however, old
implementations must be tolerant of receiving these types without doing
nasty things. RFC 1577 rewrite could specify that hosts must be
tolerant of receiving other type codes.
Grenville was asked if he perceived any bounds on the size of the
mcleave and join messages. He said that ARP_MULTI response is quite
large and currently exceeds the bounds on host adapters.
What happens when the ARP server fails? What happens to the VCs that
are active on the host? These issues are currently not addressed. Drew
suggested resyncing after a period of time. He thinks the document
needs to be augmented such that failure ought to reset all state.
Grenville agreed that some text is needed for this.
Drew suggested that perhaps the document's discussion of binding to LLC
entities can be skipped, as it might cause more controversy and/or
confusion. He feels that it is not necessary for this to be in the
document.
The end system architecture needs to be drawn out from the actual
implementation. It useful to understand how the protocol works.
Consensus was to move it into the framework document.
There was a discussion of the Multicast Server. A suggestion was to
name the service Multicast Address Registration Server (MARS).
Drew raised the question of the use of an ARP_REPLY instead of an
ARP_MULTI with a single member. There was discussion of various issues
surrounding setting up a multicast VC. These issues will be addressed in
subsequent rewrites of the draft.
Framework Document Discussion
Discussion of the framework document was led by David Shur. Curtis
suggested issuing the document in HTML which converts easily to both
PostScript and text. This would allow easy review and posting as an
Internet-Draft. He is willing to do the conversion if he can get the
document text in ASCII. It is up to the authors at this point to give it
to him.
General consensus that we need to close on this real soon, via a series
of interactive discussions on the e-mail list. There was also consensus
that Grenville's LLC material from the multicast document be moved to
the framework document.
Work Plan Presentation
Mark presented the suggested FY95 work plan, as follows:
o UNI 3.0 Signaling draft --> Informational RFC (submitted)
o UNI 3.1 Signaling draft --> Proposed (re-submitted 12/4)
o Framework draft --> Informational RFC
o Multicast draft(s) --> Proposed (?)
o RFC 1483 Proposed --> Draft
o RFC 1577 Proposed --> Proposed (?)
o RFC 1626 Proposed --> Draft
o UNI 4.0 Signaling draft
It was noted that ITU has a contribution for the RFC 1483 rewrite.
Questions were raised regarding when to start the RFC 1577 rewrite.
Mark proposed starting this in the March/April time frame. Drew
suggested getting started sooner.
A statement was made that RFC 1626 should be rolled into the RFC 1577
rewrite. We were not able to discuss this and clarify why they are
different.