To simplify the explanation, let's just pretend that only RR1 and RR3 exist (and let's forget about RR2 and RR4 for a second).
Similarly, let just pretend ASBR1 and ASBR3 are the only ASBRs (and let's forget about ASBR2 and ASBR4 for a second).
There is an EBGP session between RR1 and RR3, to exchange the IP VPN routes between the two ASs.
That means that there is a TCP connection between RR1 and RR3.
That means that there needs to be IP reachability between RR1 and RR3: RR1 needs to have an IP route to the loopback of RR3, which is in a different AS. And vice versa.
AS 65100 and AS 65101 are only exchanging labeled unicast routes with each other.
That means that ASBR1 must be advertising a labeled unicast route for RR1 to ASBR3.
Similarly, ASBR3 must be advertising a labeled unicast route for RR3 to ASBR1.
The cleanest way to achieve that is if RR1 advertises a labeled-unicast route for its own loopback to ASBR1, and if RR3 advertises a labeled-unicast route for its own loopback to ASBR3.
That way, we have a labeled-unicast route all the way from RR1 to RR3 and vice versa.
I have not set up a lab to verify this, but I don't think it is absolutely required to have a labeled unicast session from RR1 to ASBR1 and from RR3 to ASBR3. It just makes things more consistent and cleaner.
If you only had a normal IP unicast session between RR1 and ASBR1 (and RR3 and ASBR3) I strongly suspect that things would still work. In that case, we would only label switch the packets of the BGP TCP session up until the ASBR, and then do normal forwarding from there. The ASBR could receive a normal IP unicast route from the RR, bind an in-label (which may be the PHP implicit null label) and propagate the route as a label unicast further upstream.
But again, as I said, I haven created a test lab to verify that suspicion.