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
 -- tab completion file/syntax highlighting file for the mcproxy script

send bugreports to linux kernel guys
 -- In the opposite of IPv4, the IPv6 multicast stack of a current linux kernel doesn't have any group limits. This is very bad because the linux kernel will kill itself if it try to handle to much multicast groups.
 -- We tried to testing IGMPv3 proxy with CDRouter, most of the test cases failed. The causes of failure are similar, the CDRouter can't receive expected IGMPv3 message.  I listed the steps one of the failure cases here.
        1. CDRouter sends a IGMPv3 report from LAN side, with a Group record ALLOW_NEW_SOURCES{x.x.x.x}
        2. CDRouter waits IGMPv3 message on WAN side, it expects to receive the same Group record with ALLOW_NEW_SOURCES{x.x.x.x}

        But our linux kernel always sends the Group record with CHANGE_TO_INCLUDE_MODE{x.x.x.x}, that doesn't meet the test criterion of CDRouter. So those cases failed.
        I have contacted the CDRouter support team, they said the default filter mode should be INCLUDE mode, and they gave the proof:

        The default filter-mode state is specified in Section 5.1 of the RFC: 5.1. Action on Change of Interface State 

        If no interface state existed for that multicast address before the change (i.e., the change consisted of creating a new per-interface record), or if no state exists after the change (i.e., the change consisted of 
        deleting a per-interface record), then the "non-existent" state is considered to have a filter mode of INCLUDE and an empty source list. 

        I debugged this issue in linux kernel, and found the default filter mode is EXCLUDE, it's strange when linux did so. So it always sends CHANGE_TO_INCLUDE_MODE{x.x.x.x} when a Group  joining at first time.

        If the upstream interface sends a TO_IN-record instead of a ALLOW-record at the startup, I think the biggest problem is that the querier of the corresponding network could be forced to send unnecessary 
        'Group Specific Queries' and/or 'Group and Source Specific Queries' depends on the current state of the querier. This does not lead to misbehavior but increases a little bit the overhead.

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
 -- mrinfo 
 -- porting mcproxy to openwrt

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