Colin Perkins
University College London
This report provides a summary of discussion which took place during the 47th IETF meeting, held between 27th and 31st March 2000 in Adelaide. It is submitted to satisfy the SCIMITAR funding requirements.
The contents of this document are based on personnal notes taken during the meeting, and do not provide an official record of the meeting. The official minutes are available from the IETF web site at
http://www.ietf.org/.The opinions and interpretations expressed herein are those of the author, and do not necessarily represent those of the IETF, the audio/video transport working group chairs, or other persons mentioned herein. If this document differs in its record of events from the official proceedings of the meeting, then those proceedings should be considered accurate.
The goals of the zero configuration networking group at this meeting were to work through remaining issues in requirements document, discuss ongoing work in individual protocol areas, and to assess the next steps for the working group.
After an overview of requirements document, the changes since the last version were noted:
The goal is to produce a new version by the end of April, and this is expected to be the final version.
Discussion took place questioning the assumption that a zeroconf network must change from zeroconf to non-zeroconf when a configuration server comes online? it may make sense for the local system to continue to work during the mode change (but this requires changes to the IP protocol stacks (for IPv4) which may be problematic).
Discussion also took place on the requirements for service location: some think that the current document is too SLP specific.
Two RFCs have been published since the last meeting: RFC2770 on GLOP addressing in 233/8, and RFC2776 on the Multicast Scope Zone Announcement Protocol (mzap). One, draft-ietf-mboned-anycast-rp-05.txt, is pending, since it depends on the publication of the MSDP specification as an RFC before it can advance.
An overview of single source multicast (SSM) activity was presented. The following drafts were outlined: draft-holbrook-ssm-00.txt, draft-bhattach-diot-pimso-00.txt, draft-bhasker-pim-ss-00.txt, draft-sandick-pimsm-ssmrules-00.txt, draft-shepard-ssm232-00.txt, draft-ietf-idmr-igmp-v3-03.txt, draft-ietf-idmr-msf-api-00.txt.
Some measurments on the current usage in 232/8 were presented. See http://www.caida.org/Tools/Mantra/ries/ssm-ana/. This shows that 232/8 is used for standard multicast at present, due to Dave Meyer telling some content providers to use this space for their "single source" content (which is really using normal multicast). This may cause problems when real single source multicast is deployed, since IANA has allocated that space for SSM only.
The presentation of draft-shepherd-ssm232-00.txt discussed filtering our non-SSM usage in 232/8 (i.e. dropping non-SSM multicast packets using that address range). This has broad - but not universal support.
Dave Thaler presented the alternative view: don't filter non-SSM traffic in this range. If we filter (*, G) joins, then we'll black-hole all non-IGMPv3 capable sources/receivers, making the transition very hard, and creates a disincentive to ever use 232/8. The solution is don't filter. We can revisit this when everyone supports IGMPv3, in the meantime this provides the right incentives:
It was asserted that this gives an incentive for sender to start using this space, since existing receivers can receive their traffic (whereas if filtering is deployed receivers have to be upgraded before they can receive traffic); and receivers get an incentive to upgrade (since they receive less spurious traffic if they do).
There was discussion of whether the 232/8 space should be hardcoded into places, etc. comparisons with 10/8. Resolved that we shouldn't hardcode 232/8 support into routers, but maybe include knobs in routing software to turn on specific support for it (e.g. filtering MSDP advertisments in 232/8).
Sprint's PIM-SO deployment plans were mentioned briefly. It was noted that they are working on a linux implementation of IGMPv3 and modifying some of the applications (vic, vat, sdr) to use it.
The BGMP working group session was very poorly attended, in comparison with MboneD where the SSM work was discussed.
Dave Thaler presented the fix to a specification bug Isidor Kouvelas found at the previous meeting. Work on the implementation is ongoing.
The meeting started with a status update. There are 3 support documents which outline the process:
The first two are believed ready for working group last call, the third is yet to be written.
Roger Kermode discuseed the yet-to-be-written guidelines draft. This will have two parts: for authors of building blocks and for authors of protocol instantiation. He first outlined the guidelines for writing a building block, which should include:
This was followed by a discussion of protocol instantiation guidelines:
Discussion followed on the choice between building RM protocols atop UDP or native IP. The firewall vendors want all protocols to be built directly on top of IP (not on UDP!). Brian Whetten noted that UDP is easier to deploy from an end-user point of view, but can see wy firewall people want native-on-IP. Mark Handley interesting question: what does it mean to have an IP protocol number assigned to RMT? If we just have one, we don't solve the problem, since each application will have a different security considerations but the same IP protocol number. If we give each a different IP protocol ID, we'll exhaust the field. Vern Paxson noted that a fixed packet header with a well known RMT protocol identifier field within it would solve this problem. Lorenzo Vicisano noted that a fixed IP protocol id might help GRA? Vern Paxson noted that the experiene of SIGTRAN was that implementability over native-IP is easy. No real consensus was reached.
The FEC building block was presented by Mike Luby. The goals of this are to describe applicability of FEC codes to RMT in general, describe FEC codes and their properties, and suggest high level usage and conventions. A number of issues were noted:
This was followed by the ALC protocol instantiation, also presented by Mike Luby. Aside from an overview of the protocol, the following were noted:
Roger Kermode noted that some of the FEC codecs are patented. Usual issues apply.
The TRACK (TRee-based ACK) protocol architecture was presented by Brian Whetten. This builds on work in NACK-only protocol instantiation and can use NACKs, GRA, FEC, etc. TRACK adds complexity, but provides confirmed packet delivery and knowledge of group membership; flow control for higher maximum performance; local retransmissions, hierarchical NACK suppression, and ACK aggregation; and an ACK-only mode for high latency, high loss and/or non-real time applications.
The TRACK protocol uses three types of entity: senders, receiver(s) and "repair heads" which may be deployed as infrastructure, but are not strictly necessary. The simplest mode is the sender talking directly to receivers, but usually a number of repair heads will be deployed and the protocol will auto-configure into a tree structure using the repair heads as the internal nodes in the tree.
A number of open issues were noted:
Brian Whetten made an attempt to summarize progress with tree building. He noted that there is a lot of work in progress here, and it is not at all clear that this is the consensus of the group.
The basic requirements are as follows:
The TRACK protocol imposes a number of additional requirements: should still be useful with static configuration of RH-RH connections (the top goal is receiver auto-configuration, not necessarily repair head auto configuration), it must support repair heads as network infrastructure and it must scale to 10000+ receivers, with a fan out of 50-1000.
The general approaches are:
How will RH's be deployed in a tree building scenerio? Can we assume that a RH is always statically deployed infrastructure (this is the model of NNTP, web caches, etc)? Maybe, but a tree is only needed if the group is large, and at these sizes managers will want control. The assumption that RH's are infrastrcutre has advantages:
but there are also advantages to having the end systems being RH's, and not having them as infrastructure: flexibility, ad-hoc deployment, etc. We will need to explore both approaches.
Other general requirements which are noted:
The tree building session was concluded by Roger Kermode, who presented the chairs' requirements for this work.
If these requirements can't be met auto-tree config will have to be pushed back into the RMRG and some alternative for constructing the tree for TRACK protocols will have to be found.
Finally, Brian Adamson presented NACK-oriented building blocks (NORM). The applicability of these is targeting "flat" multicast topologies, with few assumptions on network architecture or dependencies on the infrastructure, the system is end to end and simple to deploy. NACK is the primary technique to achieve reliability. Interacts with and uses other BBs (e.g. FEC, congestion control).
Bill Fenner noted that the mtrace specification has been updated. Still to do: document the heuristics the mtrace client uses to work around bogus replies, and add IPv6 support (next revision, last call the current spec first?). This is thought ready for last call.
Isidor Kouvelas presented an update on the IGMP v3 specification. This missed the submission deadline, will submit -03 as soon as the archives open. A few minor edits needed, which will make a -04 draft (in a couple of weeks time), after that ready for last call. Changes since last version:
A proposed multicast source filter API was presented by Dave Thaler. This is draft-ietf-idmr-msf-api-00.txt. The goals are to
Dave Thaler also presented some thoughts on IPv6 multicast routing MIBs. He noted that RFC2465 defines an IPv6Address type, for IPv6 specific MIBS and draft-ops-endpoint-mib-07.txt define a protocol independent InetAddress type. We have a set of IPv4 specific multicast routing MIBs (multicast, PIM, etc) which should be defined in a protocol independent manner. This should be just change the address family from IPv4 into InetAddress.
Hugh Holbrook presented IGMP modifications for source specific multicast. The aim is to be able to prevent people doing (*,G) joins in the single source multicast range (there is actually a problem here, since a single IGMPv2 host will force the whole LAN to switch to IGMPv2 operation, preventing source specific joins from that LAN. They want to avoid this in the single soure address range, by filtering IGMPv2/v1 messages in this range).
The session announcmement protocol (SAP) was presented by Colin Perkins. This is now complete, and will go forwards to last call for experimental RFC as of now. Joerg Ott noted that SAP is primarily an inter-server protocol, and a server-to-client protocol is also needed. We should work on this, or at least document current solutions.
Ross Finlayson presented the SAP directory type. This is intended to become an experimental RFC eventually. The claim is that directory sessions are useful for organizing sessions, even within small directories, and special purpose single-source multicast directories may become useful. The main issue was the MIME type? Mark Handley suggested that this should be "m=application sap sdp" The type is "application/sdp" and the transport SAP.
Dave Thaler discussed source filters in SDP (draft-ietf-idmr-msfapi-00.txt). These are required for single-source sessions in 232/8 and other include-mode sessions? Also an exclusion list may be useful in some scenarios. We want applications getting SDP to be able to translate directly into API calls.
There are two ways of doing this: as a new address family in the c= line, e.g. "c=IN IP4SF 224.2.17.12/127 excl 1.1.1.1 2.2.2.2". This is not backwards compatible and seems to be problematic for exclude mode.
Alternatively, a new attribute (a= line) can be defined, e.g.
c=IP IP4 224.2.17.12/127 a=excl:IN IP4 224.2.17.12 1.1.1.1 2.2.2.2"
This is backwards compatible since existing receivers ignore the filter and join the group, but one result of ignoring the unrecognized attribure means legacy receivers may try to join 232/8 groups. The consensus seems to be that this approach is better.
Meeting started with a discussion of the charter and the role of the group. Draft-ietf-rohc-rtp-requirements-00.txt was presented by Degermark. The main discussion was about handoffs, and what requirements we should impose on their performance. Draft-svanbro-rohc-lower-layer-guidelines-00.txt was presented. The main discussion was over the requirement for bidirectional connectivity at layer 2.
Summaries of the four proposals were made: ROCCO, ACE Robust header compression using keyword packets (draft-miyazaki-rohc-kwhc-00.txt) and enhanced CRTP (draft-koren-avt-crtp-enhance-01.txt).
Carsten Bormann suggested that using the mailing list to develop a common set of reference scenarios and loss patterns would be very useful, to enable us to validate the different approaches.
Future work: republish all drafts with draft-ietf-rohc- prefix. Consider convergence of these proposals, since we desire to have a single solution in the end. We'll need to decompose these protocols, to find their common componenets and features. Once this is done, we'll try to perform a synthesis of these components. Propose an interim meeting on week commencing 29th May. Proposed venue is the Nokia site in Stockholm.