What is unique about NetBSD is that they have been structuring their driver code on top of well-specified portable APIs inside the kernel (AFAIK beginning with bus_space in NetBSD 1.2 in 1996: http://netbsd.gw.com/cgi-bin/man-cgi?bus_space++NetBSD-curre...). At first this was to increase portability by making it possible to write a single device driver that would work on different architectures and over different buses (contrast to Linux, where you basically have to write a new driver for the same device over PCI vs USB).
Having these well-specified API layers is what makes it easy to take the NetBSD drivers and use them outside of the NetBSD kernel, which is what rump does. This makes it possible to write and debug drivers in NetBSD userspace (and run them too, there are proposals that are essentially steering NetBSD into a microkernel: https://wiki.netbsd.org/projects/project/userland_pci/). You can also implement the NetBSD APIs that the drivers use in your own kernel and run the NetBSD drivers.
There was a similar project for Linux drivers (DDEKit: http://os.inf.tu-dresden.de/ddekit/) but the ad-hoc nature of how Linux device drivers interact with the rest of the Linux kernel and the major changes across different Linux versions make such a project much harder to use and keep current.
So, in short, a rump kernel is a building block that can be used to build a unikernel, but the rump kernel can also be used in other contexts as well.
links with some more information on a conceptual level: http://wiki.rumpkernel.org/Repo#the-big-picture http://wiki.rumpkernel.org/Info:-FAQ
The idea is to run directly on the hypervisor/hardware, and they both do that.
In actuality they're pretty far from each-other but conceptually they are the same.
Here is the rumprun unikernel: