Subject: Re: Support for multicast in the ForCES protocol

From: Tal Anker <[email-masked]>
Date: Sat, 22 Nov 2003 01:06:10 +0200

Just one comment on the text below...
I would add on the justification of using multicast, that as oppose to the merits on using multicast in the Internet (BW saving, etc) in the scope of forces I would say that saving the CE cpu resources is even more important... I.e., instead of having to send a transaction (command) on multiple connections, the CE cpu can send a single packet... there is a good chance that even fast-ethernet used as he NE "backplane" would be enough in terms of bandwidth, while the CPU processing power may be a bottleneck...
 
- Tal

	-----Original Message----- 
	From: Putzolu, David [mailto:[email-masked]] 
	Sent: Fri 11/21/2003 10:04 PM 
	To: [email-masked] 
	Cc: 
	Subject: Re: Support for multicast in the ForCES protocol

	[chair hat off]
	Jamal Hadi Salim wrote>
	Joel Halpern wrote> >
	> > Even when the forwarding table is disjoint from the next hop
	> > table (a good idea in its own right) there are many uses of
	> > a "forwarding table LFB" which will not be populated with the
	> > same information.
	>
	> I think thats a detail which belongs to the model.  There will be
	> different types of IPV4 LFBs - some requiring the clear
	> demarcation you make.
	
	I'm not sure I follow here.  The justification for the added
	complexity of multicast is that it will save bandwidth.  Evaluating
	some realistic examples of saved bandwidth seems to me to
	be an important part of the discussion rather than just a detail!
	
	Aside from the issue of performance, there is also the question
	of feasibility.  Whether unicast or multicast is used, the following
	requirements must be met when downloading FIB entries:
	
	1 Data must not be corrupted in transit.
	2 Data must not be reordered in transit.
	3 Once delivered to the FE, the success or failure of a route
	  addition attempt must be explicitly acknowledged.
	4 There must be a way for the FE to know which LFB the
	  route pertains to (FE will have many LFBs, and may even
	  have multiple forwarding LFBs).
	5 Route additions may sometimes be part of a larger transaction
	  on a FE (e.g. "Add this prefix entry to LFB1, AND add this
	  nexthop entry to LFB2, and use all or nothing semantics.")
	6 When used over multiple hops, route additions (and all
	  other forces messages) must use an existing RFC2914 L4 transport.
	  (charter requirement)
	
	For #1, TCP is satisfactory in unicast. In multicast,
	it will be necessary to add some sort of CRC to packets,
	or use an existing reliable multicast protocol.
	
	For #2, TCP is satisfactory in unicast. In multicast,
	sequence numbers will be necessary, or a reliable
	multicast transport protocol will need to be used.
	
	For #3, the same TCP connection can be used in unicast. In
	multicast, either the same multicast connection is used
	(this results in every FE seeing every other FE's ack - yuck!)
	or a separate TCP connection must be maintained by the FE to
	the CE.
	
	For #4, either the protocol or its payload probably needs a
	LFB identifier in the unicast case.  In the multicast case,
	it will be necessary to come up with some sort of binding
	protocol, where LFBs are dynamically associated at runtime
	with multicast groups.
	
	For #5, in the unicast case, a single message could contain
	transaction information and a set of sub-messages.  In the
	multicast case I cannot off the top of my head come up with
	a mechanism to even support transactioning.
	
	For #6, in the unicast case, TCP is satisfactory.  In the
	multicast case, a 2914 compliant multicast-based standard
	protocol would be needed.  Are there existing, standard,
	robust implementations of a 2914 compliant multicast protocol
	available in the operating systems commonly used in CEs and FEs?
	
	In my (technical - chair hat still off) opinion, all of the
	above requirements have to be met for any solution (multicast
	or unicast) to be feasible.  I can understand how the above
	are satisfied by unicast, and would like to understand better
	how the above can be satisfied when using multicast.
	
	Thanks,
	David

---

From: Subrata Goswami <[email-masked]>
Date: Fri, 21 Nov 2003 18:13:00 -0500

See in-line

Quoting Tal Anker <[email-masked]>:
> I would add on the justification of using multicast, that as oppose to the
> merits on using multicast in the Internet (BW saving, etc) in the scope of
> forces I would say that saving the CE cpu resources is even more important...
> I.e., instead of having to send a transaction (command) on multiple
> connections, the CE cpu can send a single packet... there is a good chance
> that even fast-ethernet used as he NE "backplane" would be enough in terms of
> bandwidth, while the CPU processing power may be a bottleneck...
>
> - Tal

Good point. On the flip side, the FE CPU(?) would have to spend more cycles
to go through all the mcast packets and filtering the ones it needs.

Subrata

>       how the above can be satisfied when using multicast.

Subrata Goswami, Ph.D.