Project.Project History
Hide minor edits - Show changes to output
Changed lines 5-6 from:
''mrinfo'' is a fascinating probing tool since it natively comes with a router level vision and also provides an L2 aware vision. Furthermore, it is not forwarding dependent such as traceroute and does not suffer from the same limitations.
to:
''mrinfo'' is a fascinating probing tool since it natively comes with a router level vision and also provides an L2 aware vision (see our [[Publications/Publications#imc-2010 | IMC 2010 paper]] and our [[Download/Download#l2l3 | L2L3 bipartite graph analysis]]). Furthermore, it is not forwarding dependent such as traceroute and does not suffer from the same limitations ([[Publications/Publications#imc-2009 | IMC 2009]]).
Changed lines 21-22 from:
input of mrinfo-rec the next day. Datasets related to mrinfo-rec are available [[ Download/Download#mrinfog | here (global data on a daily basis)]] and [[Download/Download#mrinfoAS | here (per AS data on a per month basis)]]. More information are available [[Download/Download#mrinfouds | here (UdS)]] and [[Download/Download#mrinfoucl | here (UCL)]].
to:
input of mrinfo-rec the next day. Datasets related to mrinfo-rec are available [[ Download/Download#mrinfog | here (global data on a daily basis)]] and [[Download/Download#mrinfoAS | here (per AS data on a per month basis)]]. More information are available [[Download/Download#mrinfouds | here (UdS)]] and [[Download/Download#mrinfoucl | here (UCL)]]. We also develop an efficient router-to-AS algorithm to extract intra-domain graphs and mark boundaries between AS (take a look to the [[Publications/Publications#pam-2010 | PAM 2010 paper]] and the [[Download/Download#r2as | related code]]).
Added line 46:
Changed lines 53-55 from:
to:
We provide two datasets based on MERLIN: one targets the [[Download/Download#merlinc | whole Internet]] while the other one targets a subset of [[Download/Download#merlins | specifics ASes]].
Changed lines 58-59 from:
MERLIN could suffer from the multicast graph "disconnection" due to IGMP filtering: some multicast routers do not reply to IGMP probes (''local filtering'') while some other do not forward IGMP queries (''transit filtering''). While the second problem can be somehow overcome with the use of multiple vantage points in a cooperative distributed platform, the first one is more challenging as it impacts the collected topologies. Indeed, multicast routers that do not respond to IGMP probes may divide the resulting collected multicast graph into disjoint components.
to:
MERLIN could suffer from the multicast graph "disconnection state" due to IGMP filtering: some multicast routers do not reply to IGMP probes (''local filtering'') while some other do not forward IGMP queries (''transit filtering''). While the second problem can be somehow overcome with the use of multiple vantage points in a cooperative distributed platform, the first one is more challenging as it impacts the collected topologies. Indeed, multicast routers that do not respond to IGMP probes may divide the resulting collected multicast graph into disjoint components.
Changed line 77 from:
Reconnected topologies are available in the Download section.
to:
Reconnected graphs are available [[Download/Download#merlinsplus | here]].
Added lines 13-14:
!!mrinfo-rec
Changed lines 20-22 from:
This recursive probing scheme comes with the strong advantage of being very easy to setup as it initially requires only a single IP address as input. However, it has the drawback of limiting the mrinfo-rec probing spectrum. If the address set specified as input for a given day corresponds to non-responding routers (because, simply, the ISP filters IGMP messages), mrinfo-rec will not be able to discover any topological information. To overcome this
limitation, the set of responding router addresses of a given day is given as
input of mrinfo-rec the next day.
limitation, the set of responding router addresses of a given day is given as
input of mrinfo-rec the next day.
to:
This recursive probing scheme comes with the strong advantage of being very easy to setup as it initially requires only a single IP address as input. However, it has the drawback of limiting the mrinfo-rec probing spectrum. If the address set specified as input for a given day corresponds to non-responding routers (because, simply, the ISP filters IGMP messages), mrinfo-rec will not be able to discover any topological information. To overcome this limitation, the set of responding router addresses of a given day is given as
input of mrinfo-rec the next day. Datasets related to mrinfo-rec are available [[ Download/Download#mrinfog | here (global data on a daily basis)]] and [[Download/Download#mrinfoAS | here (per AS data on a per month basis)]]. More information are available [[Download/Download#mrinfouds | here (UdS)]] and [[Download/Download#mrinfoucl | here (UCL)]].
input of mrinfo-rec the next day. Datasets related to mrinfo-rec are available [[ Download/Download#mrinfog | here (global data on a daily basis)]] and [[Download/Download#mrinfoAS | here (per AS data on a per month basis)]]. More information are available [[Download/Download#mrinfouds | here (UdS)]] and [[Download/Download#mrinfoucl | here (UCL)]].
Changed lines 71-73 from:
The next step, Reassembling, aims at reconnecting the IGMP components in order to, at best, obtained a single large and highly connected component. Using IP level links discovered with our traceroutes between distinct IGMP components, the alias resolution step can start. The main challenge here is to identify IP addresses pairs that are good candidates for alias resolution in order to efficiently expand IGMP components and so reassemble them. We do not want to test all possible pairs: only selected candidate IP addresses pairs (using a Neighborhood Computation) are tested using a standard alias resolution technique, Ally (note that our reassembling process can work with any alias resolution technique). The alias resolution recursion continues until no new candidates are found. At the end of the process, we can expect to achieve our goal: providing a single large and highly connected graph at the router level.
to:
The next step, Reassembling, aims at reconnecting the IGMP components in order to, at best, obtained a single large and highly connected component. Using IP level links discovered with our traceroutes between distinct IGMP components, the alias resolution step can start. The main challenge here is to identify IP addresses pairs that are good candidates for alias resolution in order to efficiently expand IGMP components and so reassemble them. We do not want to test all possible pairs: only selected candidate IP addresses pairs (using a Neighborhood Computation) are tested using a standard alias resolution technique, Ally (note that our reassembling process can work with any alias resolution technique). The alias resolution recursion continues until no new candidates are found. At the end of the process, we can expect to achieve our goal: providing a single large and highly connected graph at the router level.
Reconnected topologies are available in the Download section.
Reconnected topologies are available in the Download section.
Added lines 61-62:
Therefore, one of the objective beyond MERLIN is to merge the maximum possible number of disjoint IGMP components into a large one. For that purpose, after an IGMP probing phase, we use traceroute like exploration and alias resolution: IP level links and ''aliased'' IP addresses - forming so routers - fill the gap among disjoint components discovered during IGMP probing.
Changed lines 65-71 from:
Fig.4 focuses on the whole process: after probing the topology with IGMP and ICMP probing, MERLIN use alias resolution technique to reassemble collected topologies.
to:
Fig. 4 summarizes the whole topology collection process. Two steps
are required: ''Discovering'' and ''Reassembling''.
The Discovering step is
based on IGMP probing with MERLIN, as explained above. Once the IGMP router level topology has been collected, we have a scattered topology made of disjoint IGMP components,
The next step, Reassembling, aims at reconnecting the IGMP components in order to, at best, obtained a single large and highly connected component. Using IP level links discovered with our traceroutes between distinct IGMP components, the alias resolution step can start. The main challenge here is to identify IP addresses pairs that are good candidates for alias resolution in order to efficiently expand IGMP components and so reassemble them. We do not want to test all possible pairs: only selected candidate IP addresses pairs (using a Neighborhood Computation) are tested using a standard alias resolution technique, Ally (note that our reassembling process can work with any alias resolution technique). The alias resolution recursion continues until no new candidates are found. At the end of the process, we can expect to achieve our goal: providing a single large and highly connected graph at the router level.
are required: ''Discovering'' and ''Reassembling''.
The Discovering step is
based on IGMP probing with MERLIN, as explained above. Once the IGMP router level topology has been collected, we have a scattered topology made of disjoint IGMP components,
The next step, Reassembling, aims at reconnecting the IGMP components in order to, at best, obtained a single large and highly connected component. Using IP level links discovered with our traceroutes between distinct IGMP components, the alias resolution step can start. The main challenge here is to identify IP addresses pairs that are good candidates for alias resolution in order to efficiently expand IGMP components and so reassemble them. We do not want to test all possible pairs: only selected candidate IP addresses pairs (using a Neighborhood Computation) are tested using a standard alias resolution technique, Ally (note that our reassembling process can work with any alias resolution technique). The alias resolution recursion continues until no new candidates are found. At the end of the process, we can expect to achieve our goal: providing a single large and highly connected graph at the router level.
Changed lines 52-59 from:
to:
!!Multicast Core Reconstruction
MERLIN could suffer from the multicast graph "disconnection" due to IGMP filtering: some multicast routers do not reply to IGMP probes (''local filtering'') while some other do not forward IGMP queries (''transit filtering''). While the second problem can be somehow overcome with the use of multiple vantage points in a cooperative distributed platform, the first one is more challenging as it impacts the collected topologies. Indeed, multicast routers that do not respond to IGMP probes may divide the resulting collected multicast graph into disjoint components.
Assuming that the "globally accessible" multicast graph is physically connected, we can expect that scattered components and isolated routers result from non-responding multicast routers (these routers might be partially seen at the IP level through neighborhood information of IGMP compliant routers). Indeed, even a low proportion of non-responding routers may result in an huge disconnection of the multicast graph. This leads to a situation in which discovered multicast maps are, actually, a set of disconnected components.
This "disjoint state" may be exacerbate by unicast adjacencies lacks. In practice, a multicast router can be configured at the interface granularity:
each interface can independently support multicast or not. Nevertheless, an ISP supporting IP multicast should enable multicast everywhere in its network to ensure the correct PIM tree establishment. Some exceptions may arise at inter-area border routers and AS border routers. An area border router does not need to support multicast adjacencies with routers belonging to non-multicast areas. Between ASes, the BGP routing protocol can use specific multicast forwarding entries to disseminate PIM messages. Thus, although it is likely that a multicast border router will not enable multicast on all its interfaces, it is also likely that the multicast graph should be connected. Even in presence of non multicast adjacencies, there should exist at least one multicast path between each multicast component. Despite this reasonable assumption, it is also true that the connectivity of the multicast graph can be lower than the physical one (including unicast-only components).
MERLIN could suffer from the multicast graph "disconnection" due to IGMP filtering: some multicast routers do not reply to IGMP probes (''local filtering'') while some other do not forward IGMP queries (''transit filtering''). While the second problem can be somehow overcome with the use of multiple vantage points in a cooperative distributed platform, the first one is more challenging as it impacts the collected topologies. Indeed, multicast routers that do not respond to IGMP probes may divide the resulting collected multicast graph into disjoint components.
Assuming that the "globally accessible" multicast graph is physically connected, we can expect that scattered components and isolated routers result from non-responding multicast routers (these routers might be partially seen at the IP level through neighborhood information of IGMP compliant routers). Indeed, even a low proportion of non-responding routers may result in an huge disconnection of the multicast graph. This leads to a situation in which discovered multicast maps are, actually, a set of disconnected components.
This "disjoint state" may be exacerbate by unicast adjacencies lacks. In practice, a multicast router can be configured at the interface granularity:
each interface can independently support multicast or not. Nevertheless, an ISP supporting IP multicast should enable multicast everywhere in its network to ensure the correct PIM tree establishment. Some exceptions may arise at inter-area border routers and AS border routers. An area border router does not need to support multicast adjacencies with routers belonging to non-multicast areas. Between ASes, the BGP routing protocol can use specific multicast forwarding entries to disseminate PIM messages. Thus, although it is likely that a multicast border router will not enable multicast on all its interfaces, it is also likely that the multicast graph should be connected. Even in presence of non multicast adjacencies, there should exist at least one multicast path between each multicast component. Despite this reasonable assumption, it is also true that the connectivity of the multicast graph can be lower than the physical one (including unicast-only components).
Changed line 33 from:
platforms. A central server ([[Publications/Publications#jsac-2011 | JSAC-2011]]), written in Python and C++, controls the vantage
to:
platforms. A central server ([[Publications/Publications#jsac-2011 | JSAC 2011]]), written in Python and C++, controls the vantage
Changed lines 13-14 from:
Our initial approach in probing the network with mrinfo is recursive and we call such a probing scheme ''mrinfo-rec'' (see IMC 2009, PAM 2010, and IMC 2010). Initially, mrinfo-rec is fed with a single IP address corresponding to the first router attached to the mrinfo-rec vantage point. mrinfo-rec probes this router and recursively applies its probing mechanism on all the collected IP addresses. These recursive queries stop at unresponsive routers or when all discovered routers have been queried. The same process is run every day. It is worth to notice that an address not replying to an IGMP probe during a given day will not be queried the days after except if it appears again in a list of captured addresses.
to:
Our initial approach in probing the network with mrinfo is recursive and we call such a probing scheme ''mrinfo-rec'' (see [[Publications/Publications#imc-2009 | IMC 2009]], [[Publications/Publications#imc-2010 | IMC 2010]], and [[Publications/Publications#pam-2009 | IMC 2010]]). Initially, mrinfo-rec is fed with a single IP address corresponding to the first router attached to the mrinfo-rec vantage point. mrinfo-rec probes this router and recursively applies its probing mechanism on all the collected IP addresses. These recursive queries stop at unresponsive routers or when all discovered routers have been queried. The same process is run every day. It is worth to notice that an address not replying to an IGMP probe during a given day will not be queried the days after except if it appears again in a list of captured addresses.
Changed line 33 from:
platforms. A central server, written in Python and C++, controls the vantage
to:
platforms. A central server ([[Publications/Publications#jsac-2011 | JSAC-2011]]), written in Python and C++, controls the vantage
Changed line 47 from:
Fig. 3 depicts the architecture of the MERLIN monitor. The monitor is composed of two parallel processes: ''send'', in charge of sending probes to the network, and ''receive'', in charge of processing the replies returned back by the routers. To minimize redundancy, the sending process never probes an IP address previously discovered: the "history" box in Fig. 3 is initialized with the Stop Set and is maintained up-to-date by the monitor, avoiding so the redundancy in probing.
to:
Fig. 3 depicts the architecture of the MERLIN monitor ([[Publications/Publications#ngi-2011 | NGI 2011]]). The monitor is composed of two parallel processes: ''send'', in charge of sending probes to the network, and ''receive'', in charge of processing the replies returned back by the routers. To minimize redundancy, the sending process never probes an IP address previously discovered: the "history" box in Fig. 3 is initialized with the Stop Set and is maintained up-to-date by the monitor, avoiding so the redundancy in probing.
Changed line 49 from:
The ''send' process is fed by both a static IP address list and a dynamic IP address list collected from replies. This dynamic list is used for recursion. When the monitor starts, the ''send'' process operates in a static mode using so IP addresses from the static list. Once replies are collected from the ''receive'' process, the dynamic list is built based on publicly routable neighbor IP addresses: the recursion is engaged. The ''send'' process enters in the dynamic mode and gives priority to targets of the dynamic list. Each time the dynamic list becomes empty (i.e., the current recursion is finished), the ''send'' process is again fed with remaining IP addresses from the static list. This recursion first scheme was a design choice that has been made in order to minimize the probability of reprobing a given router.
to:
The ''send'' process is fed by both a static IP address list and a dynamic IP address list collected from replies. This dynamic list is used for recursion. When the monitor starts, the ''send'' process operates in a static mode using so IP addresses from the static list. Once replies are collected from the ''receive'' process, the dynamic list is built based on publicly routable neighbor IP addresses: the recursion is engaged. The ''send'' process enters in the dynamic mode and gives priority to targets of the dynamic list. Each time the dynamic list becomes empty (i.e., the current recursion is finished), the ''send'' process is again fed with remaining IP addresses from the static list. This recursion first scheme was a design choice that has been made in order to minimize the probability of reprobing a given router.
Changed line 49 from:
to:
The ''send' process is fed by both a static IP address list and a dynamic IP address list collected from replies. This dynamic list is used for recursion. When the monitor starts, the ''send'' process operates in a static mode using so IP addresses from the static list. Once replies are collected from the ''receive'' process, the dynamic list is built based on publicly routable neighbor IP addresses: the recursion is engaged. The ''send'' process enters in the dynamic mode and gives priority to targets of the dynamic list. Each time the dynamic list becomes empty (i.e., the current recursion is finished), the ''send'' process is again fed with remaining IP addresses from the static list. This recursion first scheme was a design choice that has been made in order to minimize the probability of reprobing a given router.
Deleted line 40:
Changed lines 47-53 from:
Fig.3 provides details about the MELRIN monitor.
to:
Fig. 3 depicts the architecture of the MERLIN monitor. The monitor is composed of two parallel processes: ''send'', in charge of sending probes to the network, and ''receive'', in charge of processing the replies returned back by the routers. To minimize redundancy, the sending process never probes an IP address previously discovered: the "history" box in Fig. 3 is initialized with the Stop Set and is maintained up-to-date by the monitor, avoiding so the redundancy in probing.
Changed lines 39-44 from:
addresses called ''current seeds'' (CD in Fig. 2). This set is made of previously collected mrinfo-rec data, external traceroute collected by Archipelago, initial traceroutes run by the server.
to:
addresses called ''current seeds'' (CD in Fig. 2). This set is made of previously collected mrinfo-rec data, external traceroute collected by Archipelago, and initial traceroutes run by the server.
Each input list is subject to a standard IP-to-AS mapping filtering process so
that only IP addresses mapped to the targeted AS are used. Each monitor probes
the network recursively (see below for details). For "controlling" this recursion and then avoiding ''inter-monitor'' redundancy, the server computes a list of IP addresses, called the ''Stop Set'' (ST in Fig. 2). This list contains IP addresses that have been previously discovered by MERLIN monitors and, thus, do not have to be probed again.
Each input list is subject to a standard IP-to-AS mapping filtering process so
that only IP addresses mapped to the targeted AS are used. Each monitor probes
the network recursively (see below for details). For "controlling" this recursion and then avoiding ''inter-monitor'' redundancy, the server computes a list of IP addresses, called the ''Stop Set'' (ST in Fig. 2). This list contains IP addresses that have been previously discovered by MERLIN monitors and, thus, do not have to be probed again.
Changed lines 38-39 from:
to:
The input sent by the server to each monitor is composed of a list of IP
addresses called ''current seeds'' (CD in Fig. 2). This set is made of previously collected mrinfo-rec data, external traceroute collected by Archipelago, initial traceroutes run by the server.
addresses called ''current seeds'' (CD in Fig. 2). This set is made of previously collected mrinfo-rec data, external traceroute collected by Archipelago, initial traceroutes run by the server.
Changed lines 32-43 from:
to:
MERLIN is based on a centralized client-server architecture and runs over Unix
platforms. A central server, written in Python and C++, controls the vantage
points, called ''monitors'', written in C. The MERLIN monitors are
potentially spread all over the world and logically organized as a ring, as
illustrated in Fig. 2. Only one monitor actively probes the targeted domain at a given time. This probing period by a single monitor is called ''run''. There are as many runs as monitors in the system per probing ''cycle''. A ''cycle'' is completed when all monitors have probed the targeted domain during a given round around the monitor ring. Note that, for a given targeted AS, several cycles can be required per IGMP probing ''stage'', i.e., the number of cycles required to take advantage of all current seeds including those recursively found during previous runs. An IGMP probing stage might be made of an incomplete number of cycles: a stage stops when no more topological data can be collected using the current seed set. In order to increase the coverage of an AS probing ''campaign'', between each stage, MERLIN launches internal Paris traceroute campaigns to collect new fresh seeds and better understand the topology lacks.
platforms. A central server, written in Python and C++, controls the vantage
points, called ''monitors'', written in C. The MERLIN monitors are
potentially spread all over the world and logically organized as a ring, as
illustrated in Fig. 2. Only one monitor actively probes the targeted domain at a given time. This probing period by a single monitor is called ''run''. There are as many runs as monitors in the system per probing ''cycle''. A ''cycle'' is completed when all monitors have probed the targeted domain during a given round around the monitor ring. Note that, for a given targeted AS, several cycles can be required per IGMP probing ''stage'', i.e., the number of cycles required to take advantage of all current seeds including those recursively found during previous runs. An IGMP probing stage might be made of an incomplete number of cycles: a stage stops when no more topological data can be collected using the current seed set. In order to increase the coverage of an AS probing ''campaign'', between each stage, MERLIN launches internal Paris traceroute campaigns to collect new fresh seeds and better understand the topology lacks.
Added lines 23-24:
The objective of MERLIN is to collect an accurate router-level topology snapshot of a targeted AS by combining IGMP probing, traceroute, and an alias resolution technique. More precisely, the first challenge of MERLIN is to use traceroute seeds in order to improve its probing coverage by overcoming the limitations of a pure IGMP recursion scheme. Then, the use of an alias resolution technique and traceroute allows us to provide consistent ISP maps by reconstructing a connected topologies.
Added lines 19-22:
However, mrinfo (and by extension mrinfo-rec) suffers from several drawbacks. First, its view is limited to multicast components and, in the same way that ICMP messages may be rate limited or filtered for traceroute probing, IGMP messages can be filtered by some ISPs. Second, we observed several technical limitations: it suffers from an IP fragmentation issue and the lack of multiplexing support.
In order to fix those issues (at least a maximum of them), we implemented a new tool, still based on IGMP probing, called ''MEasure the Router Level of the INternet'' (MERLIN). MERLIN is a distributed platform and allows one to infer the multicast map of the Internet at the router level and is designed for large scale topology discovery campaigns.
Changed lines 20-21 from:
%center% %lframe, width=210% Attach:Project/GlobalOverview.png | [-Fig.2: The MERLIN platform-]
to:
%center% %width=210% Attach:Project/GlobalOverview.png | [-Fig.2: The MERLIN platform-]
Changed line 24 from:
%center% %rframe, width=450% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-Fig.3: The MERLIN monitor-]
to:
%center% %width=450% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-Fig.3: The MERLIN monitor-]
Changed lines 20-21 from:
%lframe, width=210% Attach:Project/GlobalOverview.png | [-Fig.2: The MERLIN platform-]
to:
%center% %lframe, width=210% Attach:Project/GlobalOverview.png | [-Fig.2: The MERLIN platform-]
Changed line 24 from:
%rframe, width=450% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-Fig.3: The MERLIN monitor-]
to:
%center% %rframe, width=450% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-Fig.3: The MERLIN monitor-]
Changed lines 11-21 from:
to:
Our initial approach in probing the network with mrinfo is recursive and we call such a probing scheme ''mrinfo-rec'' (see IMC 2009, PAM 2010, and IMC 2010). Initially, mrinfo-rec is fed with a single IP address corresponding to the first router attached to the mrinfo-rec vantage point. mrinfo-rec probes this router and recursively applies its probing mechanism on all the collected IP addresses. These recursive queries stop at unresponsive routers or when all discovered routers have been queried. The same process is run every day. It is worth to notice that an address not replying to an IGMP probe during a given day will not be queried the days after except if it appears again in a list of captured addresses.
To illustrate this behavior, let us apply it on the topology depicted in
Fig. 1. mrinfo-rec receives, as input, an IP address belonging to router R[-0-]. From R[-0-], mrinfo-rec collects a set of neighbor IP addresses, i.e., {1.1.1.2, 1.1.0.2}. For all IP addresses in this set that were not previously probed, mrinfo-rec sends an IGMP ASK_NEIGHBORS message and, if the probed router replied, it again runs through the set of neighbor IP addresses collected.
This recursive probing scheme comes with the strong advantage of being very easy to setup as it initially requires only a single IP address as input. However, it has the drawback of limiting the mrinfo-rec probing spectrum. If the address set specified as input for a given day corresponds to non-responding routers (because, simply, the ISP filters IGMP messages), mrinfo-rec will not be able to discover any topological information. To overcome this
limitation, the set of responding router addresses of a given day is given as
input of mrinfo-rec the next day.
%lframe, width=210% Attach:Project/GlobalOverview.png | [-Fig.2: The MERLIN platform-]
To illustrate this behavior, let us apply it on the topology depicted in
Fig. 1. mrinfo-rec receives, as input, an IP address belonging to router R[-0-]. From R[-0-], mrinfo-rec collects a set of neighbor IP addresses, i.e., {1.1.1.2, 1.1.0.2}. For all IP addresses in this set that were not previously probed, mrinfo-rec sends an IGMP ASK_NEIGHBORS message and, if the probed router replied, it again runs through the set of neighbor IP addresses collected.
This recursive probing scheme comes with the strong advantage of being very easy to setup as it initially requires only a single IP address as input. However, it has the drawback of limiting the mrinfo-rec probing spectrum. If the address set specified as input for a given day corresponds to non-responding routers (because, simply, the ISP filters IGMP messages), mrinfo-rec will not be able to discover any topological information. To overcome this
limitation, the set of responding router addresses of a given day is given as
input of mrinfo-rec the next day.
%lframe, width=210% Attach:Project/GlobalOverview.png | [-Fig.2: The MERLIN platform-]
Deleted lines 23-26:
Fig.3 provides details about the MELRIN monitor.
Added line 26:
Fig.3 provides details about the MELRIN monitor.
Changed line 8 from:
R[-0-] (through interface 1.1.0.1). We can also notice that R[-0-] is connected to routers R[-5-] and R[-6-] through an L2 network (labeled ``switch'' in Fig. 1) because interface 1.1.2.3 appears twice in the mrinfo reply (see bold text in Fig. 1). Finally, mrinfo reports that interface 1.1.3.1 has no multicast neighbor because the right IP address is equal to 0.0.0.0 (or is directly connected to a LAN, as indicated by the ``leaf'' keyword). All this
to:
R[-0-] (through interface 1.1.0.1). We can also notice that R[-0-] is connected to routers R[-5-] and R[-6-] through an L2 network (labeled "switch" in Fig. 1) because interface 1.1.2.3 appears twice in the mrinfo reply (see bold text in Fig. 1). Finally, mrinfo reports that interface 1.1.3.1 has no multicast neighbor because the right IP address is equal to 0.0.0.0 (or is directly connected to a LAN, as indicated by the "leaf" keyword). All this
Changed lines 3-5 from:
''mrinfo'' is a fascinating probing tool since it natively comes with a router level vision and also provides an L2 aware vision. Furthermore, it is not forwarding dependent such as traceroute and does not suffer from the same limitations. Fig.1 illustrates the mrinfo output for the router R[-2-].
to:
''mrinfo'' is a fascinating probing tool since it natively comes with a router level vision and also provides an L2 aware vision. Furthermore, it is not forwarding dependent such as traceroute and does not suffer from the same limitations.
Added lines 6-10:
Fig. 1 shows an example of the usage of mrinfo to query the router R[-2-], 1.1.0.2 being the responding interface of R[-2-]. mrinfo reports that this router is directly connected to
R[-0-] (through interface 1.1.0.1). We can also notice that R[-0-] is connected to routers R[-5-] and R[-6-] through an L2 network (labeled ``switch'' in Fig. 1) because interface 1.1.2.3 appears twice in the mrinfo reply (see bold text in Fig. 1). Finally, mrinfo reports that interface 1.1.3.1 has no multicast neighbor because the right IP address is equal to 0.0.0.0 (or is directly connected to a LAN, as indicated by the ``leaf'' keyword). All this
information is obtained by sending a single IGMP message. In practice, mrinfo provides information similar to the output of a ''show'' command on the router's command line interface.
Changed lines 16-18 from:
%center% %width=600% Attach:Project/Reassembling.png | [
to:
%center% %width=600% Attach:Project/Reassembling.png | [-Fig.4: The whole MERLIN process-]
Fig.4 focuses on the whole process: after probing the topology with IGMP and ICMP probing, MERLIN use alias resolution technique to reassemble collected topologies.
Changed lines 2-4 from:
''mrinfo''is a fascinating probing tool since it natively comes with a router level vision and also provides an L2 aware vision. Furthermore, it is not forwarding dependent such as traceroute and does not suffer from the same limitations.
to:
''mrinfo'' is a fascinating probing tool since it natively comes with a router level vision and also provides an L2 aware vision. Furthermore, it is not forwarding dependent such as traceroute and does not suffer from the same limitations. Fig.1 illustrates the mrinfo output for the router R[-2-].
Changed lines 8-9 from:
to:
Fig.2 gives a global overview of our MELRIN distributed platform.
Added lines 12-13:
Fig.3 provides details about the MELRIN monitor.
Added line 16:
Fig.4 focuses on .
Changed lines 2-3 from:
''mrinfo''is a fascinating tool since it natively comes with a router level vision and also provide
to:
''mrinfo''is a fascinating probing tool since it natively comes with a router level vision and also provides an L2 aware vision. Furthermore, it is not forwarding dependent such as traceroute and does not suffer from the same limitations.
Added line 2:
''mrinfo''is a fascinating tool since it natively comes with a router level vision and also provide
Changed lines 3-11 from:
%center% %width=500% Attach:Project/MRinfo.png | [-IGMP probing output-]
%lframe, width=210% Attach:Project/GlobalOverview.png | [-The MERLIN platform-]
%rframe, width=450% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-The MERLIN monitor-]
%center% %width=600% Attach:Project/Reassembling.png | [-The whole process-]
%lframe, width=210% Attach:Project/GlobalOverview.png | [-The MERLIN platform-]
%rframe, width=450% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-The MERLIN monitor-]
%center% %width=600% Attach:Project/Reassembling.png | [-The whole process-]
to:
%center% %width=500% Attach:Project/MRinfo.png | [-Fig.1: IGMP probing output-]
%lframe, width=210% Attach:Project/GlobalOverview.png | [-Fig.2: The MERLIN platform-]
%rframe, width=450% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-Fig.3: The MERLIN monitor-]
%center% %width=600% Attach:Project/Reassembling.png | [-Fig.4: The whole MERLIN process-]
%lframe, width=210% Attach:Project/GlobalOverview.png | [-Fig.2: The MERLIN platform-]
%rframe, width=450% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-Fig.3: The MERLIN monitor-]
%center% %width=600% Attach:Project/Reassembling.png | [-Fig.4: The whole MERLIN process-]
Changed lines 6-8 from:
%lframe thumb, width=400% [[ http:/inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-The MERLIN monitor-] %lframe thumb, width=185% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/GlobalOverview.png ]] [-The MERLIN platform-]
to:
%lframe, width=210% Attach:Project/GlobalOverview.png | [-The MERLIN platform-]
%rframe, width=450% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-The MERLIN monitor-]
%rframe, width=450% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-The MERLIN monitor-]
Changed lines 3-12 from:
%center% %width=500% Attach:Project/MRinfo.png
%center% %width=400% Attach:Project/MerlinClient.png
%center% %width=300% Attach:Project/GlobalOverview.png
%center% %width=600% Attach:Project/Reassembling.png
%center% %width=400% Attach:Project/Merlin
%center% %width=300% Attach:Project/GlobalOverview.png
to:
%center% %width=500% Attach:Project/MRinfo.png | [-IGMP probing output-]
%lframe thumb, width=400% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-The MERLIN monitor-] %lframe thumb, width=185% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/GlobalOverview.png ]] [-The MERLIN platform-]
%center% %width=600% Attach:Project/Reassembling.png | [-The whole process-]
%lframe thumb, width=400% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/Merlin-Client.png]] | [-The MERLIN monitor-] %lframe thumb, width=185% [[ http://inl.info.ucl.ac.be/system/files/paper_3.pdf | Attach:Project/GlobalOverview.png ]] [-The MERLIN platform-]
%center% %width=600% Attach:Project/Reassembling.png | [-The whole process-]
Changed lines 6-12 from:
%center% %width=500% Attach:Project/Merlin-Client.png
%center% %width=500% Attach:Project/GlobalOverview.png
%center% %width=500% Attach:Project/Reassembling.png
%center% %width=
%center% %width=
to:
%center% %width=400% Attach:Project/Merlin-Client.png
%center% %width=300% Attach:Project/GlobalOverview.png
%center% %width=600% Attach:Project/Reassembling.png
%center% %width=300% Attach:Project/GlobalOverview.png
%center% %width=600% Attach:Project/Reassembling.png
Changed lines 3-12 from:
Attach:Project/MRInfo.png
to:
%center% %width=500% Attach:Project/MRinfo.png
%center% %width=500% Attach:Project/Merlin-Client.png
%center% %width=500% Attach:Project/GlobalOverview.png
%center% %width=500% Attach:Project/Reassembling.png
%center% %width=500% Attach:Project/Merlin-Client.png
%center% %width=500% Attach:Project/GlobalOverview.png
%center% %width=500% Attach:Project/Reassembling.png
Changed lines 1-3 from:
In the late 1980s, the developers of IP Multicast designed the MBone, an overlay network composed of tunnels that interconnected workstations running an implementation of the ''Distance Vector Multicast Routing Protocol'' (DVMRP). Several tools have been developed to monitor and debug the MBone. Most of these tools have been deprecated with the replacement of DVMRP by the ''Protocol Independent Multicast'' (PIM) family of multicast routing protocols with one notable exception: ''mrinfo''.
to:
In the late 1980s, the developers of IP Multicast designed the MBone, an overlay network composed of tunnels that interconnected workstations running an implementation of the ''Distance Vector Multicast Routing Protocol'' (DVMRP). Several tools have been developed to monitor and debug the MBone. Most of these tools have been deprecated with the replacement of DVMRP by the ''Protocol Independent Multicast'' (PIM) family of multicast routing protocols with one notable exception: ''mrinfo''.
Attach:Project/MRInfo.png
Attach:Project/MRInfo.png
Changed line 1 from:
to:
In the late 1980s, the developers of IP Multicast designed the MBone, an overlay network composed of tunnels that interconnected workstations running an implementation of the ''Distance Vector Multicast Routing Protocol'' (DVMRP). Several tools have been developed to monitor and debug the MBone. Most of these tools have been deprecated with the replacement of DVMRP by the ''Protocol Independent Multicast'' (PIM) family of multicast routing protocols with one notable exception: ''mrinfo''.
Changed line 1 from:
to:
%justify%In the late 1980s, the developers of IP Multicast designed the MBone, an overlay network composed of tunnels that interconnected workstations running an implementation of the ''Distance Vector Multicast Routing Protocol'' (DVMRP). Several tools have been developed to monitor and debug the MBone. Most of these tools have been deprecated with the replacement of DVMRP by the ''Protocol Independent Multicast'' (PIM) family of multicast routing protocols with one notable exception: ''mrinfo''.