Subject: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a third mode

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 27 Mar 2001 08:32:34 +0200

Hello Samita, 

	Thanks for your thorough review, some comments below.

> Sorry for the late posting... But  most of the comments have been discussed with
> hmipv6 authors in private emails. 
> 
> The comments are based  mostly on hmipv6 version 2 draft.
> Also, I'd like to propose a third mode in hmipv6 especially
> for those systems which do not have ROHC implementation
> at their network.
> 
> Thus this proposed mode will save 40 bytes of tunnel overhead
> between MAP and mobile node in the basic mode. 
> 
	=> It can be used for both modes.

> I understand that
> this would be useful for IPRAN  as James Kempf had pointed out 
> earlier in the list.
> 
	=> Not really, all IP based cellular systems will use ROHC
	or something equivalent. To be more specific 3GPP will
	and I believe 3GPP2 is making (or has made a similar 
	decision). 

> Editorial comments:
> 
> section 3.0 : one or two word description of 'B' flag would be helpful
> 
> section 3.1 : Load-balancing sub-option : needs more clarification as to where the
>               sub-option is sent ( to MAP only or CN as well ?)
>               Load-balancing may be a misnomer, perhaps a more suitable name should
>               be used as this option basically is used by the MN for balancing load
>               over different interfaces. But the load-balancing is dependent on the
>               flow policies. So, how about "Policy" sub-option or other suitable names ?
> 
>               How about changing 'prot number' to 'proto number' ?
>               Needs description for dest-port, r and Destination address, I suppose
>               destination address should be LCOA
> 
>               'P' bit description should clarify which "ip-address" (LCOA?) is used
>                to identify flow.
> 
>                Since checking for flow-label or port-ipaddr pair also involve checking
>                each packet at MAP, 'per-packet' load balancing description is a bit
>                confusing in this context. Since 'per-packet' load-balancing refers to
>                'A' bit only, another beeter name or more clarification required here.
> 
	=> The load balancing will be placed in a separate
	draft that is generic for (H)MIPv6. Your comments will
	be included.
	This was requested by a few people in te WG to reduce 
	the scope of the draft.

> Section 4.0    An example of 'T' bit would help
> 
> Section 5.0    A little more detailed analysis of choices of MAP discovery will be
>                a good guide for implementors and users to pick which one to pick
>                in their implementation/operating environment.
>                
> 
> Section 5.4:   3rd paragraph mentions :
>                "If a MN has access to several ARs.......it's current MAP"
>                an example will be helpful in order to describe this scenario.
> Section 11:    Needs more clarification ( I was told that version 3 has improved texts)
> 
	=> Yes to all the above. For the last one check rev 3.

> Section 15:   Reference for AAAv6 should be recorded.
> 
	=> recorded ? I didn't get that, please explain.

> Technical :
> ----------
>  (Some of the following are discussed with hmipv6 authors)
> 
> Section 3.1 : 'r' bit may be moved adjacent to F|P|A flags for future use ?
>                Next version of draft should also specify possible error codes--
>                at least the 'errors in text form'.
> 
> Section 5  :  For simplicity, hmipv6 draft should limit the choices of MAP discovery
>               and specify one or two options as 'MUST' to implement. Otherwise,
>               implementations either will become too complex or will not interoperate.
> 
> Section 6.1 : Please specify that alternate COA sub-option is optional when RCOA is
>               used as source address of the BU. (for location privacy)> 
> 
> Section 11 : This section should also mention that the hierarchical network between
>              MAP and MNs must be a trusted network and no src-address filtering is done
>              on the outging packets from the mobile nodes.
> 
> Section 7.1 and 7.2 :
>               Added operation in HA can be easily avoided if :
>               A MN MUST (instead of SHOULD) send a BU for each different Home-addr it
>               uses for connection.
> 
>               But I think, having HA to add RH in the outer IP layer, has two
>               advantages:
> 
>               1) less signalling between MN and AR ( this is probably desirable by
>                  wirelss vendors)
>       
>               2) Supporting site-local addressed home-addr in the foreign domain.
> 
	=> Ok
>               
> Load Balancing in general:              
> BTW, a detailed load balancing scheme for fault-tolerance for MAP should be schetched
> out so that the backup MAP can takes over when the orginial MAP goes down. Perhaps the
> policy and MAP load babalncing scenarios should be discussed in a separate draft to
> keep this draft simple. But we can toss ideas and discuss more on that in the 
> discussion team.
> 
	=> Yes, this should be done in a separate draft. I'm in the process
	of polishing off a solution for this.

> Proposal of having optional 3rd mode(Basic-non-tunneled) in a hierarchical network where
> ROHC is not available.
> 
> Basic non-tunnel mode: Supporting mobile nodes with RCOA without tunnels between MAP and MN
>          
> MAP Operation: 
>            In this mode, MAP recives BU and sends BAck after performing DAD operation
>            as described in basic mode. A new bit will be introduced in the MAP advertisement
>            to distinguish "Basic non-tunnel" mode service from other two modes.
> 
>       The new MAP option format ( as per discussion with Hesham Soliman):
> 
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |    Length     |  Distance     |  Pref         |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Plen      |R|M|T|N|            Reserved                   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         Valid Lifetime                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +                  Global IP Address for MAP                    +
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>           N  - Indicates that the MN MUST be able to replace the destination
>                address of incoming packet from LCOA to RCOA when the packets
>                are coming from either a correspondent node or it's home agent.
>                R bit MUST be set when N bit is set. N bit MUST not be set
>                when M is bit is set. Basicaly N bit is an indication of MAP
>                supporting basic-non-tunnel mode.
> 
>            The MAP keeps a binding cache containing association
>            of RCOA, LCOA and MN's home-addr. It intercepts the packets that are destined> 
>            to RCOA (either from HA or from CN. Note that in basic mode RCOA is different
>            from MAP's own address.) MAP then replaces the destination > IP-address RCOA by
>            LCOA after looking up the binding cache, and simply forwards the packet to
>            the topologically correct router in the hierarchy.
> 
> MN Operations:
>          
>            MN forms LCOA and RCOA exactly the same way as described in basic mode. It also
>            sends BU to MAP and home agent subsequently exactly the same way as described
>            in 6.1 (Basic mode MN operations). MN may also send BU to CN informing RCOA as
>            it's new COA ( same as in basic-mode operation).
> 
>            MN receives packets addressed to MN's LCOA address, MN replaces the LCOA address
>            by the corresponding RCOA address after determining that this packet is
>            coming from either it's home agent or correspondent node. MN then proceeds
>            with normal processing of packets as described in base mobile IPv6 draft.
> 
>            The differnce between basic mode MN and basic-non-tunnel mode MN is that
>            the latter, does not need to detunnel the packet from MAP at all. Instead it
>            swaps the destination address of the incoming  packet when the
>            source address is home agent address or  correspondent node address.
>            Thus a mobile node implementation may maintain a list of CNs and
>            Home agents for address verification.
> 
> HA Operation:
>            No change from basic mode operation.
> 
> ----------------------------------------------------------------------------------------
> 
	=> As I mentioned earlier, this would work at a cost of 
	more complexity in the MN. 
	Since, ROHC (or other HC techniques) are used 
	in all "BW-challenged" links, I'm inclined to think
	that this should be placed in a separate draft. 
	As you know several people have mentioned that 
	the draft is doing too much and we're working 
	on that. 
	I believe James' comments was related to context 
	transfer which is handled by seamoby. After 
	reading Mikael Degermark's (co-chair of ROHC) emails 
	I'm now convinced that this would work fine. 

	So to summarise, I think your proposal would 
	work and I (and the rest of the co-authors)
	would be more than happy to assist you in any 
	way if you would like to write another draft that 
	addresses this optimisation for HMIPv6. 

	Finally, I would strongly recommend that you 
	consult with the IPng folks as this solution
	requires some special tricks in the implementation
	and IPng is the best place to get feedback on 
	this.

	We're not saying it's not important,but simply 
	responding to the WG's comments about the 
	size/scope of the draft

	Regards,
	Hesham

---

From: James Kempf <[email-masked]>
Date: Tue, 27 Mar 2001 08:33:41 -0800 (PST)

Hesham,

>	and I believe 3GPP2 is making (or has made a similar 

Neither 3GPP nor 3GPP2 currently has all IP RANs. 3GPP2 is discussing
whether to start work on a new all IP RAN architecture. 3GPP, having
just completed the UTRAN architecture, has so far declined to
investigate all IP RAN, being content with introducing IP as an
alternate transport layer protocol.

That said, I agree that header compression will likely play a role
even in an all IP RAN. That does not negate the advantage of removing
tunnelling overhead. In particular, if the tunnel changes during
handoff, it could cause the compressor to revert back to the start
state, resulting in some number (the number is currently disputed)
of packets required to restart the compressor. I've seen numbers from
60-600 ms quoted as required on a radio link with a 20 ms frame transmit
time, I am trying to reduce the uncertainty by corresponding with the ROHC 
working group chairs. Any amount of additional delay caused by having
to restart the compression state machine at the beginning would thoroughly
negate the low latency handoff work.

Note that, unlike IPv4, the headers *will* change even if there is no
tunnel overhead in IPv6 because the CoA will change when the mobile
moves to the new access point, and the CoA gets sent out over the 
air. In IPv4, the FA strips the tunnel overhead, so the compressor
state remains the same and could potentially be shipped across the
wire in a context transfer protocol (Seamoby). In IPv6, it is as yet
uncertain if the compressor state could be maintained during handoff.
And it may turn out that changing the CoA would allow the compressor
state to be transferred, but changing the tunnel would not.

The ROHC group seems to have been exclusively focused on IPv4. From
my conversations with the working group chairs at IETF in Minneapolis,
they seemed unaware that the header would change during handover
in IPv6.

My conclusion from this is that it is dangerous to make blanket assumptions that
header compression will solve problems with fat IPv6 headers lacking
solid data about whether the compression algorithms can use context
transfer to reestablish state and also reinitialize the state machines
with the new CoA. I hope this will become somewhat clearer as we get
more data from the ROHC working group.

If you are interested in helping to find this out, I suggest you generate
a couple of HMIPv6 headers including the tunnelling overhead both
before and after handover and send them to the ROHC chairs. They requested
I do this for straight IPv6 headers. They will then be able to tell
you whether or not the compressor can be restared without moving back
to the start state. Then you can base your HMIPv6 design on solid data,
rather than assumptions.

			jak

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 27 Mar 2001 10:05:18 -0800 (PST)

Hi Hesham,

> 	=> It can be used for both modes.

Yes, in can be, but it's more easily applicable in basic mode. 
> 	This was requested by a few people in te WG to reduce 

Sounds fine.

> 	=> recorded ? I didn't get that, please explain.
Oops! I just meant a reference pointer for the AAAv6 draft or document.

> >       The new MAP option format ( as per discussion with Hesham Soliman):
--------------------------------------------------------------------------------
--------
> 	and IPng is the best place to get feedback on 
I thought, at IETF we agreed on this solution :)
I am not sure if this  option should go into a separate draft.
But, we can discuss more. Regarding IPng folks, I think many IPng
folks are also in this working group.

> 	responding to the WG's comments about the 

If you include the third option as an optional mode, that will give
flexibility to the implementors to choose to implement this option.
When 3GPP and 3GPP2 systems implement ROHC, I understand that then
this option will be redundant. But, I'd argue that, for now this
option saves 40 bytes of overhead and is useful for systems which
does not implement header compression (ROHC).  I am not saying that
this option is "MUST", but optional, in addition to the basic mode.
Also, this is in scope of hmipv6 draft.

Thanks,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 27 Mar 2001 10:26:11 -0800 (PST)

Hi Claude,

> Concerning the third mode proposal, i have 3 comments:
> 
> -in the basic mode, the MAP is nothing more that a HA.  This was one of our 
requirements
> when designing this mode. The basic mode is very simple to implement... adding 
the
> fonctionality
> you are proposing would require to modify the MAP and we won't be able to use 
a HA as MAP
> anymore...

That's not completely true. Because a MAP implementation needs to send MAP
advertisements and process MAP registration. A simple mobileIPv6 HA is not
capable of doing MAP's work. 

> -in your proposal, the MAP modifies the destination address of the packets 
that are sent to a
> Mobile host.
> What will happen if the packet is authenticated with AH? The packets will be 
rejected by the
> MN. This
> is an issue when the CN is also mobile and piggybacks  its BUs with its 
packets (the whole
> packets must then be
> authenticated with AH) ...
> 

This will not be a problem becuase MN now is 
intelligent enough to use RCOA to caculate ICV part of AH header.

When the packet is received by MN  from CN using route optimization:

 LCOA     <===== IP dst (replaced by MAP from the binding cache info)
 CN
 ----
 Home-addr    <--- Routing header

 When MN sees that there is routing header from CN,
 it  does the following steps:
  1. Uses RCOA instead of LCOA for AH validity computation.
     Note, in order to compute the ICV of AH correctly, MN must
     have the key from security association with CN and it needs
     the right set of parameters, namely src, dst addresses.
     
     If this is a spoof packet, then even though it has same src/dst
     address it's AH value will not be the same as the real packet.
     In another words, this has no worse security threat than the 
     regular IPsecv6.
     
   2. After the AH computation, it processes router header and then
      replaces LCOA with Home-addr and passes up exactly the same 
      way as mobileipv6 main draft says.

> - Most of wireless networks will use RoHC (as confirmed by Hesham email) so I 
don't see the
> motivation
> for this 3rd mode (considering the 2 previous issues).
> 

I thought, it will be useful for implementations which do not have ROHC
implementation today. 

Thanks very much,
-Samita

> 
> 
> 
> Samita Chakrabarti wrote:
> 
> > Hello:
> >
> > between MAP and mobile node in the basic mode. I understand that
> >               used as source address of the BU. (for location privacy)
> >
> >            of RCOA, LCOA and MN's home-addr. It intercepts the packets that 
are destined
> >            from MAP's own address.) MAP then replaces the destination 
IP-address RCOA by
> >
> > Thanks,
> > -Samita
> 
> --
> 
> ----------------------------------------
> Claude CASTELLUCCIA, INRIA Rhone-Alpes
> ph:  +33 4.76.61.52.15 (fax: 52.52)
> http://www.inrialpes.fr/planete/
> 
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 27 Mar 2001 23:55:47 +0200

James, 

> even in an all IP RAN. 
	=> All IP RAN (at least in 3GPP) means IP transport, user 
	traffic is _always_IP and will _always_ use HC. 

> That does not negate the advantage of removing
	=> I've talked to ROHC authors a few times and that's where I
	got my conclusions. 

> state to be transferred, but changing the tunnel would not.
	=> Yes I realise the difference, but the question is how long does it
	take to restart the compressor. We aleady got some answers 
	from Mikael, so I think that if you're not convinced perhaps 
	it would be good to bring this up on the ROHC mailing list. 
	This would be good for our understanding. I don't think 
	you'll get an answer from this list.

> to the start state. Then you can base your HMIPv6 design on solid data,
	=> I thought I already did that, are you unhappy with Mikael's 
	and the other authors' analysis ? If so please explain your concerns
	to them and I'll just believe their answers. 

	Hesham