The IP over ATM Mailing List Archive by date

[laubach@terra.com21.com (Mark Laubach)]

IP over ATM Working Group Minutes - Stockholm Meeting, 20 July 1995

Mark Laubach, Chair.  Home page: http://www.com21.com/pages/ietf.html

Minutes taken by Andy Malis, edited by Mark Laubach

101 people attended the single IP-ATM meeting session.  The session
was multicast.  No comments or questions were received from the
multicast audience.

--------------------------------
Agenda:
1. Agenda bashing
2. ATM Forum update
3. draft-ietf-ipatm-ipmc-05.txt
4. draft-armitage-ipatm-encaps-02.txt
5. darft-smith-ipatm-bcast-01.txt
6. draft-ietf-ipatm-framework-doc-03.ps, .txt
7. draft-ietf-ipatm-arch-00.txt
8. draft-milliken-ipatm-services-00.txt
9. Update on rfc1755+, 1626 update
10. Action items/work plan

--------------------------------
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 (ROLC) WG.

--------------------------------
Grenville Armitage led the discussion for items 3-5.

He has a web repository for multicast drafts and related material:
http:.//gump.bellcore.com:8000/~gja/i-drafts.html

Summary of multicast changes from Danvers (-04 to -05)
o Signficant rewrite to imporve readability
o Better group revalidation algorithm.
o MARS grouplist request/reply for basic IGMP support
o Mars redirect map supports the advertising of backups MARS, and hot swapping
o Introducing class I vs class II MARS for clarity.

Summary of -05 to -06 diffs:
o React to WG decision on Class I/II MARS
o Description of new encapsuilation's applicaton
o New flag ar$copy in MARS.JOIN
o Hook in MARS packet for suppliemantary parameters to be added in future.

Version -06 coming out very soon (in a week or two).

Multicast encapsulation draft:
o Eight options discussed (LLC/SNAP variants)
o Prefer encapsulation option #6

Broadcast draft:
o Assumes MARS service, and builds an IP broadcast emulation with it.
o Discusses implications for boot-time applicatoins (e.g. bootp)
o 255.255.255.255 and net/subnet broadcast supported as special cases
  of multicast groups
o Discusses alternatives (using just ARP server)

Walter Milliken (BBN) made the argument that the draft is much more
complicated than it need be.  His comments will be considered for the
next draft.

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 (Fore), 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.

---------------------------------
Framework document:

David Shur (AT&T) gave an update on the Framework doc. 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 solicitied any additional comments to come soon, so
that they can go to the RFC asap.

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"
referencable document. Joel agreed with that reasoning. Future mods can be
done as new RFCs.

----------------------------------
We moved on to Walter's two multicast documents,
draft-ietf-ipatm-arch-00.txt and draft- milliken-ipatm-services-00.txt.

Ann Demirtjis, Sprint, presented draft-ietf-ipatm-arch-00.txt and will edit
the next version of the draft.

In these slides, italics represents points where she has added material
from Walter's draft, or disagrees with it.

Characteristics of IP multicast:
o Distribution model:
o Logical address
o No registration needed for senders
o Regristration required for receivers
o Support broadcast
o Support subnet MC scope (TTL=1) - administrative scope
o Real-time requirements: QoS support (RSVP).  Also priority levels, Others ...
o Second generation applicatoins: multiple flows and low latency
o Link sharing

Basic IP MC over ATM Service Model

Subscription:
o Hosts can send anytime.  Must register to receive.
o Routers can receive all mc packets on their subnets, can determine what
  mc groups subnet hosts are members of
o Routers must support the functional requrements of knowing which mc groups
  are active on their subnet.
o Hosts must register to the subnet broadcast group.

Distribution:
o Must support restricted distribution to the subnet (TTL=1)
o Must support the "all-hosts" multicast group (224.0.0.1) for IGMP.
o Must support broadcast distrtibution with the subnet.
o Quality of Service:
o Must use RSVP to provide QoS for multicast groups.
o QoS support either thru direct ATM QoS or through RSVP
o Must be able to support RSVP for hosts which want to use it.

There was a discussion at this point of whether IP over ATM should use
IGMP for mcast:

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.

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.

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 fare to say that people could
implement an IP over ATM driver could support IGMP via an ioctl() that
queries the MARS.

Ann: what should be in this document is that all the protocols at the
IP layer must be supported.

Walter: I would prefer the "hack" taken out so that we don't have
future interoperability problems.  I believe the IGMP support is
mandatory and should be stated in the document.

Grenville: we can restate things so that any implmentation must
support IGMP.

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.

Rob: DVMRP uses IGMP.

Ann: yes, IGMP must be supported.

Ann: Applications should be able to use ATM QOS directly without

Eric: you must pay attention to QOS when leaving the ATM cloud if you
want to have QOS carried

Unknown: It is appropriate to say that RSVP must be supported.  It is
not appropriate to say that RVSP exclusively.

Ohta: <missed comment>  Ann replied favorably to it though.

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 fulfulls its needs. The point was made that
this works only as long as all the multicast receivers are on the same
ATM network.

Major Issues for IP Multicast Over ATM
o Subscription:
o Join requests for a host to become a group member
o Address resolution mechanism to map IP addresses
o Is ARP necessary?
o Distribution of required info for senders to reach all receivers.
o Two approaches exist currently: IGMP-based with ATMARP and MARS
o Cut-through routing: Should multicast subscription be requred to work in
  a cut-through environment?
o Support of subnet broadcasting:
o Modify RFC 1577(+?) or
o Use ARMARP database with the MARS or
o Use ATMARP database with  IP multicast router solution, or
o Use the MARS (see draft-smith-ipatm-bcast-01.txt)

Major Issues for IP Multicast Over ATM (cont)
o Distribution over ATM
o Source based or multicast server based
o UNI 3.1: pt-mpt (unidirectional, root-driven) & pt-pt (bidirectional)
o UNI 4.0: pt-mpt with Leaf-Initiated Join, mpt-mpt support? LIJ not very
  useful since IP source unkown (GCIC = ?)
o Multicast servers & routers: problem with reflected packets
o Possible solutions:
o All Mcs must be implemented by routers
o New encapsulations (see encapsulation draft)
o Support of administrative scope in a cut-through environment?

We discussed how LIJ can be used - the MARS could give the required GCID to
the host for the LIJ.

Major Issues for IP Multicast Over ATM (cont)
o Quality of Service:
o IP multicast traffic taxonomity: best-effort vs real-time
o best effort: short sessions, low volume, often local, need for ATM
  VC setup?  Yakov's draft-rekhter-ip-atm-architecture-01.txt discusses
  these issues very well.
o Real time: long sessions, high volume, local or WAN - VC setup
  very desireable
o Conclusion: QoS support must be included in IP multicast systems over ATM
o IP QoS = RSVP
o Rely on ATM QoS or use RSVP

There was a discussion of when meshes make sense vs. multicast servers, and
when RSVP should or should not be used.

Major Issues for IP Multicast Over ATM (cont):
o RSVP over ATM:
o RSVP interaction with ATM: not very simple
o RSVP reservation is receiver driven.  ATM reservation is source driven.
o Transmission of path messages requires a VC from source to destination
o Reservation messages establish a new QoS-based VC
o Support of heterogenous receivers in ATM (VC teardown/setup)?
o 'On the fly' change of QoS parameters in RSVP
o ATM doesn't support dyanmic re-negotiation of QoS parameters

The document is going to be restructured based on comments, and Ann will be
producing a new version (date unknown).

and Walter to address:
1. Service definition
2. Noticing reflected packets to sending client from multicasting server
3. Noticing reflected packets to sending router from multicast server
4. Other layer two (datalink) requirements
5. Changes (if any) that are required to multicast routers
6. IDMR WG coordination needed?
7. IGMP and IGMPv2 Restricted/Promiscuous needed?
8. Any other host issues
9. Multi MARS server synchronization
10. Non-LIS interoperation issues
11. Any leverage from other ATMF work: e.g. LAN Emulation
12. MPOA
13. Specifying IP broadcast mapping

---------------------------------
Walter Milliken presented his integrated services draft:

Goals:
o Support dual traffic model (best-effort and real-time)
o Integrate RSVP into IP over ATM
o Support end-to-end ATM shortcut
o Simple implementation

QoS Support
o Need QoS support for most IP multicast applications
o RSVP is IP QoS setup signaling
o RSVP messages trace multicast tree, carrying QoS information
o Conclusion: Use RSVP Resv messages to signal QoS-based VC setup
o Easy to setup
o main problem: heterogeneous downstream QoS requirements
o fix by merging downstream requests info single VC (downstream merging
  based on max requirements)
o may need to tear down and setup VC for new requirements

Walter put up some diagrams, including one that illustrated using NRHP
to produce short- cut muilticast 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.

Open Issues(Future Work):
o Heterogeneous downstream Vcs
o Alternative short-cut mechanisms
o Short-cut merge-deferral decision algorithms
o Local subnet VC management
o when may local groups in use by one application
o Multiple IP MC routers per subnet
o ATM multicast server support for best-effort
o MARS for best-effort

---------------------------------------
Mark presented a brief summary of the status of the RFC1577 update:
1. Exepect to see first I-D around 8/1
2. All Danvers items have been incorporated
3. Server-sever synchornozation based on Xerox PARC work for Clearinghose
   and for Bayou mobile database
4. NHRP proposed-status dependency
5. Includes a MIB
---------------------------------------

Mark summarized the current items on the WG's document work plan:
1. Framework draft -> proposed
2. MARS ID -> proposed
3. Next step for 1483 (via email)
4. 1577+ -> proposed
5. Multicast systems overview completed
6. UNI 3.1 signaling updated to 4.0

End of minutes