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.