Loop Join in SQL Server 2008

I'm not clear about working difference between queries mentioned below.

Specifically I'm unclear about the concept of OPTION(LOOP JOIN).

1st approach: it's a traditional join used, which is most expensive than all of below.

SELECT * 
FROM [Item Detail] a
LEFT JOIN [Order Detail] b ON a.[ItemId] = b.[fkItemId] OPTION (FORCE ORDER);

2nd approach: It includes OPTION in a statement with sorted data, merely optimized.

SELECT * 
FROM [Item Detail] a
LEFT LOOP JOIN [Order Detail] b ON a.[ItemId] = b.[fkItemId] OPTION (FORCE ORDER);

3rd approach: Here, I am not clear, how the query works and includes OPTION with loop join!!?

SELECT * 
FROM [Item Detail] a
LEFT LOOP JOIN [Order Detail] b ON a.[ItemId] = b.[fkItemId] OPTION (LOOP JOIN);

Can anybody explain difference and way of working and advantages of each one over other?

Note: These are not Nested OR Hash loops!

From Query Hints (Transact-SQL)

FORCE ORDER Specifies that the join order indicated by the query syntax is preserved during query optimization. Using FORCE ORDER does not affect possible role reversal behavior of the query optimizer.

also

{ LOOP | MERGE | HASH } JOIN Specifies that all join operations are performed by LOOP JOIN, MERGE JOIN, or HASH JOIN in the whole query. If more than one join hint is specified, the optimizer selects the least expensive join strategy from the allowed ones.

Advanced Query Tuning Concepts

If one join input is small (fewer than 10 rows) and the other join input is fairly large and indexed on its join columns, an index nested loops join is the fastest join operation because they require the least I/O and the fewest comparisons.

If the two join inputs are not small but are sorted on their join column (for example, if they were obtained by scanning sorted indexes), a merge join is the fastest join operation.

Hash joins can efficiently process large, unsorted, nonindexed inputs.

And Join Hints (Transact-SQL)

Join hints specify that the query optimizer enforce a join strategy between two tables

Your option 1 tells the optimizer to keep the join order as is. So the JOIN type can be decided by the optimizer, so might be MERGE JOIN.

You option 2 is telling the optimizer to use LOOP JOIN for this specific JOIN. If there were any other joins in the FROM section, the optimizer would be able to decide for them. Also, you are specifying the order of JOINS to take for the optimizer.

Your last option OPTION (LOOP JOIN) would enforce LOOP JOIN across all joins in the query.

This all said, it is very seldom that the optimizer would choose an incorrect plan, and this should probably indicate bigger underlying issues, such as outdated statistics or fragmented indexes.