Subject: RE: [mobile-ip] Low Latency Issue: Where to Run the Reverse Tunne l?

From: James Kempf <[email-masked]>
Date: Tue, 4 Sep 2001 12:19:39 -0700 (PDT)

Ok, well, it seems like this issue hasn't stirred alot of comment. In
the interest of pushing the draft forward, I'd like to make the following
proposal. I think this will address Ajoy's comment about tunneling
compressed packets or PPP to the old FA, and also the comment in the
original issue summary about how to accommodate route optimization.

The proposal involves modifying the flag bits to indicate whether
the reverse tunnel should be terminated at the old FA or at the HA,
and whether route optimization is in effect.

Currently, we have 4 flag bits concerned with tunneling: M for minimal 
encapsulation supported, G for GRE encapsulation supported, T for reverse tunnel 
supported. These flag bits occur in both the Handoff Request and Handoff Reply.

I'd like to propose that we modify the tunneling flags as follows:

M - MN requested minimal encapsulation, use it in any tunnel with FA or HA
G - MN requested GRE encapsulation, use it in any tunnel with FA or HA
    (must be accompanied  by the GRE Key Extension if GRE security in 
     effect)
H -  MN requested reverse tunnel to HA, perform reverse tunnel regardless
     of egress filtering status on new subnet (the MN may be using 
     a private home address, for example). 
O - old FA is performing optimizations on MNs traffic (compression, 
    PPP, etc.), tunnel through the old FA regardless of egress filtering
     status on new subnet.
R - Route optimization is in effect and the MN is using CoA as the source
    address. MN's old CoA included in the message instead of the MN's 
    home address. The O bit MUST also be set.
    
The reverse tunnel termination point would be decided by the following
algorithm:

  If the H flag is set, the new FA MUST reverse tunnel to the HA regardless of
  the egress filtering status on the new subnet. This is because the
  MN requested reverse tunneling.
  
  If the O flag is set, the old FA is performing optimizations, such
  as compression, and therefore the new FA MUST reverse tunnel to
  the old FA regardless of the egress filtering status because the
  old FA must perform processing before the packets can be sent. This
  flag MUST also be set if the R flag is on, indicating that the 
  MN is performing route optimization.
  
  If neither the H nor the O flag are set, then the new FA can reverse tunnel
  to the HA, reverse tunnel to the old FA, or it can simply route packets
  directly onto its subnet if egress filtering is not on.
  
Note that if the new FA does NOT want to perform reverse tunneling but
the MN did not request reverse tunneling, the H flag MUST NOT be set.
The new FA indicates its unwillingness to reverse tunnel by 
a tunnel lifetime of zero in the Handoff Request or Handoff Reply, this 
indication applies to forward tunneling also.

If the R flag is set, the old FA sends the MN's old Care of Address
in place of the MN's Home Address, since the source address on
outgoing packets will be the MN's old Care of Address. The MN's 
HA address is also sent.

Comments?

			jak

---

From: Pete McCann <[email-masked]>
Date: Wed, 5 Sep 2001 14:50:00 -0500

Hi, James,

A couple of comments on your proposal below.  Basically, I think it is
possible to do something a lot simpler - see my comments at the end.

 > M - MN requested minimal encapsulation, use it in any tunnel with FA or HA

Note that the tunneling type between the FAs is really orthogonal to
the tunneling type requested by the mobile node.  See below under your
proposed 'O' flag.

 >     (must be accompanied  by the GRE Key Extension if GRE security in 

This might be a misconception, and I think it was present in your
original summary: GRE Key != security.  The GRE Key field is for an
additional layer of demultiplexing.  That is all.  It is called a
"key" in the sense of an index, not in a cryptographic sense.

 >     PPP, etc.), tunnel through the old FA regardless of egress filtering

Note that to support this, we MUST have GRE tunneling between the two
FAs, and the GRE Protocol Type could be used to signal that we will be
sending already-compressed packets.  The Protocol Type is part of the
GRE Extension:

ftp://ftp.isi.edu/internet-drafts/draft-calhoun-mobileip-gre-ext-00.txt

 >     home address. The O bit MUST also be set.

I don't understand the concern with route optimization.  As I recall
(the draft is expired and currently unavailable), R-O is run either
between MNs and CNs, or MNs and previous FAs.  In either case, it is a
signaling and security matter between the MN and those other nodes.
Packets are then tunneled to the MN's care-of address directly from
CNs or previous FAs, and the care-of address can be either co-located
or FA-located.  Why would the old FA know or even care whether the MN
is performing route optimization with CNs?  Why would it affect the
endpoint of the reverse tunneled traffic?  It seems like R-O only
affects the path taken by forward direction traffic.

 > outgoing packets will be the MN's old Care of Address. The MN's 

This seems quite complicated.  I would rather just use the 'T' bit
that we already have in the Handoff Request/Reply to signal the desire
by either side to reverse-tunnel packets to the old FA.  If
either of them set this bit, then reverse tunnel to the old FA is
enabled.  Either side could set the bit for whatever reason seemed
aprpropriate.

Now, there is an orthogonal question, which is, when we are NOT
performing reverse tunneling to old FA, we may or may not need to
reverse tunnel to the HA.  This could be one flag from the old FA to
the new FA (in either Request or Reply, depending on the trigger type)
indicating that the FA is currently supporting a reverse tunnel to the
HA, and that there is currently no security on this tunnel, and the
new FA SHOULD choose to do so as well.

I think the addition of one new flag such as this, rather than
redefining all the flags and adding 2 new flags, will cover the cases
we want to cover adequately, and conveys exactly the information we
want conveyed.  In other words, the flags in the Handoff messages
apply to the tunnels established with those messages, not to other
tunnels that may appear as side effects of the handoff.

In summary: I think your R and O bits could be combined into the
current T bit.  I would agree with adding an H bit as a form of advice
from the old FA to the new FA, but it may only be set when the T bit
is not set.

-Pete