TODO list
=========

Could change or modify the behavior of the mcproxy:
 -- http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-06
 -- http://tools.ietf.org/html/rfc6224
 -- http://tools.ietf.org/html/rfc6636
 -- http://tools.ietf.org/html/draft-ietf-multimob-handover-optimization-03 (old)
 -- IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers draft-ietf-pim-explicit-tracking-08
 -- http://tools.ietf.org/id/draft-morin-mboned-igmpmld-error-feedback-02.txt (Expires: May 7, 2009)

Multi Upstream Proxy
 -- http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-06 (Appendix)
 -- draft-zhang-pim-multi-upstream-igmp-mld-proxy-00.txt (https://docs.google.com/file/d/0B6D0eGbv_V4rVTY3Wk55TmpYejA/edit)
 -- http://tools.ietf.org/html/draft-asaeda-pim-mldproxy-multif-01
 -- http://tools.ietf.org/html/draft-contreras-multimob-multiple-upstreams-01


add und delete mroute optimisation 
struct mfcctl {
	struct in_addr mfcc_origin;		/* Origin of mcast	*/
	struct in_addr mfcc_mcastgrp;		/* Group in question	*/
	vifi_t	mfcc_parent;			/* Where it arrived	*/
	unsigned char mfcc_ttls[MAXVIFS];	/* Where it is going	*/
	unsigned int mfcc_pkt_cnt;		/* pkt count for src-grp */
	unsigned int mfcc_byte_cnt;
	unsigned int mfcc_wrong_if;
	int	     mfcc_expire; <======== the kernel could delete its rules by itself 
};


General stuff
 -- create an how to for the configuration script
 -- implement dynamic interface state updating, what happens if the network cable is interrupted for a short time. 
 -- clean class routing 
 -- overwork recvmsg() buffer size
 -- overwork class timing with pipe and pselect
 -- implement RFC specific conditions for timers_vaules set operators 
 -- remove all ???????? from the code
 -- remove deprecated functions like htonl ...
 -- overwork exception concept ????
 -- check peering interface (ASM/SSM behaviour, timout)
 -- change receive polling / forward a signal to this thread

 

Email
 -- How much will the implementation protect against killing SSM by
ASM receivers ? Aka: If  your proxy receives an IGMPv3 INCLUDE(S,G1)
membership from host 1 and an IGMPv3 EXCLUDE({},G1) from host 2, what
will it send out on the upstream interface ?
    Very interesting question, I never thought about this problem. So the current version would sends unaware of any protection the report EXCLUDE({},G1) to the upstream
    But I think I could update the proxy in the following way:
    Currently it is possible to define filter rules, for example “forward only data of the channel (S,G1) to the downstream interface eth0 and ignore all other data”. In this case, if the proxy receives an IGMPv3 EXCLUDE({}, G1) on the downstream interface eth0, it could be easily converted to the report INCLUDE(S,G1).

future work
 -- matrace2
 -- jmrinfo 
 -- porting mcproxy to openwrt

release
send an release info to sam, pim, multimob and mbond
