You can enable Junos OS to maintain the indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table.As a result, fewer route to forwarding next-hop bindings need to be updated, which improves the route convergence time.
However, for other types of deployments (L2 MPLS services, or L3VPNs with perprefix label allocation) indirect next hop does not improve restoration times.The number of next hops that need to be removed during failure event does not change. Therefore, Junos offers the next generation of hierarchical next-hop structures, chained composite next hop, to address these issues.The problem with indirect next hop is the service label. Different service labels advertised by the same egress PE results in completely separate hierarchical next-hop structures being required in the FIB. Chained composite next hop removes that obstacle. Service labels are no longer associated with unicast next hops at the end of the next-hop hierarchy; instead, they are moved to the very top level of the next-hop hierarchy.
I would suggest to refer chapter 5 from the below link :
Although it has already been answered above, below is a simplified example. Let's say you have 3 L3VPNs configured, and there are 3 LSPs towards the remote PE. Thus we have 3 different VPN labels (assume vrf-table-label is configured), say 16, 17, 18 and 3 different transport labels, say 100000, 100001, 100002. Without composite-nexthops the PFE has to be programmed with 3 x 3 = 9 next-hops:
nexthop1: push 16, push 100000, send out interface X
nexthop2: push 17, push 100000, send out interface X
nexthop3: push 18, push 100000, send out interface X
nexthop4: push 16, push 100001, send out interface Y
nexthop5: push 17, push 100001, send out interface Y
nexthop6: push 18, push 100001, send out interface Y
nexthop7: push 16, push 100002, send out interface Z
nexthop8: push 17, push 100002, send out interface Z
nexthop9: push 18, push 100002, send out interface Z
With composite next-hops you will only need 3 + 3 = 6 next-hops and the ability to apply two of them to the same packet:
nexthop1: push 16
nexthop2: push 17
nexthop3: push 18
nexthop4: push 100000, send out interface X
nexthop5: push 100001, send out interface Y
nexthop6: push 100002, send out interface Z
In the case above the advantage is not that big, but if there are 1000 VRFs and 16 LSPs between PEs then you go from 1000 x 16 = 16000 nexthops to 1000 + 16 = 1016 saving precious FIB space and reducing the time it takes to update the nexthops in case of a network event.
The description above is by no means 100% accurate but hopefully it gives the idea.