CLNP multicast update
David Marlow <dmarlow%sunoco@relay.nswc.navy.mil> Thu, 19 May 1994 03:45 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22607; 18 May 94 23:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22596; 18 May 94 23:45 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa26223; 18 May 94 23:45 EDT
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.8.1/1.2) id VAA10841; Wed, 18 May 1994 21:44:42 -0600
Received: by noc-gw.lanl.gov (8.6.8.1/SMI-4.1) id VAA15391; Wed, 18 May 1994 21:44:10 -0600
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.8.1/SMI-4.1) id VAA15388; Wed, 18 May 1994 21:44:09 -0600
Received: from relay.nswc.navy.mil by mailhost.lanl.gov (8.6.8.1/1.2) id VAA10833; Wed, 18 May 1994 21:44:11 -0600
Received: from sunoco.nswc.navy.mil by relay.nswc.navy.mil (4.1/SMI-4.1) id AA20644; Wed, 18 May 94 23:44:03 EDT
Received: from beavis.b35ita.sunoco (beavis_e) by sunoco.nswc.navy.mil (5.0/SMI-SVR4) id AA11382; Wed, 18 May 1994 23:44:07 +0500
Received: by beavis.b35ita.sunoco (5.0/SMI-SVR4) id AA00348; Wed, 18 May 1994 23:43:15 +0500
Date: Wed, 18 May 1994 23:43:15 +0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: David Marlow <dmarlow%sunoco@relay.nswc.navy.mil>
Message-Id: <9405190343.AA00348@beavis.b35ita.sunoco>
To: tuba@lanl.gov
Subject: CLNP multicast update
Content-Length: 5005
All, As discussed in Seattle I have completed an update of the "Host Group Extensions for CLNP Multicasting" Internet Draft. I am in the process of sending the ID to CNRI. The new ID is available for anonymous ftp from sunoco.nswc.navy.mil in directory pub/tuba. The new name (should be): draft-ietf-tuba-host-clnp-multicas-01.txt I believe that the changes discussed in Seattle have been completed. Summary of the changes follow: 1. The primary change in this updated Internet Draft is the incorporation of "direct origination of multicast packets" as discussed at the March TUBA meeting and over the email. This change to the behavior of hosts originating multicast packets enables hosts announcing an interest in particular group Network addresses to directly receive such multicast packets originated on a subnetwork to which they are connected. This replaces the previous method which in some cases required a multicast capable router to resend such packets. This affected quite a few sections. The primary sections changed were: 5.3.2, 6.1.2, 6.1.3, 6.8, 6.9.1.2, 6.11 (now 6.13) and Appendix B (now Appendix A). Two new functions have been written as new sections 6.10 and 6.11. Appendix C (now Appendix B) was also updated. Note that an overview of this is contained in 6.1.2. The changes provide that a host which does not know the correct SNPA mapping (but does know that there is a multicast router attached to the subnetwork) can send a multicast packet to the multicast routers without waiting for a MAM refresh. Thus I believe that the Level 1 Conformance level which was previously undefined is now defined. The Level 1 description of Section 2 has been updated to reflect this. As discussed in March, the Active Multicast IS upon receiving a multicast packet incorrectly addressed to the "All Multicast Capable Intermediate Systems" address is responsible for resending it on the originating subnet(s), this is covered in new section 6.11. In addition the Active Multicast IS sends out the appropriate MAM PDU, rate controlled in case the host continues to send it to the incorrect address. For rate control of such messages I used "no more than once a second, at least after 10 seconds (for events continuing )". No values were discussed in March, any feedback on these is appreciated. 2. One of the new functions "Extensions to the ISO CLNP Route Function by End Systems" is an ES-IS extension for a CLNP function. This was done since this function requires knowledge of the ES-IS (current unicast) Configuration functions. As Steve Deering discussed in March, a host connected to multiple subnets needs to forward a copy of any packet that it originates on to every subnet for which it is actively reporting the NSAP address that is used as multicast packet's Source address. Section 5.3.2 (covering CLNP) allows a host connected to multiple subnets to originate packets on more than one subnet and a pointer is placed to section 6.10 (covering ES-IS) where the actual spec is. 3. As discussed at the March meeting, a third standard SNPA address is defined for originating multicast data (MD) PDUs when there are no hosts on that subnetwork requesting the group Network address used as a destination of the MD PDU. I believe this will help the Damping function. Renamed the other two standard SNPA addresses. Thus the three discussed are: (1)"All Multicast Announcements", (2)"All Multicast Capable Intermediate Systems" (i.e. for originating MD PDUs in the case described above) and (3)"All Multicast Capable End Systems" SNPA address. I hope to get a request into the July IEEE 802 meeting for actual allocations of global addresses for these. 4. As discussed at the March meeting, made the ESMAT (Suggested Multicast Announcement Timer) processing function mandatory for multicast capable hosts (and generation of such for routers). Making this mandatory for hosts will provide a means for a multicast capable routers to get hosts to perform their Report Multicast Announcement function in the case of such events as the start-up of a multicast router. By the Active Multicast IS setting the ESMAT parameter to a small value, ESs will quickly report the group Network addresses of interest on a particular subnetwork (note that jittering will still be applied). 5. The previous Appendix A "Consideration for ESGH and MAM destination SNPA address parameters" was dropped. If there is interest in retaining this I can update this and put it back into an updated Internet Draft. The previous Appendix B is now Appendix A... 6. I noticed that the second paragraphs of both 6.7.3 and 6.8.3 in the previous version of the Internet Draft were not needed and I eliminated them. These sections cover the Flush functions. 7. I had heard at the March meeting that the term "originate" was much better than the term in the previous Internet Draft ("source") and I think I changed all occurrences.
- CLNP multicast update David Marlow