Subject: RE: [mobile-ip] new draft

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 16 Jul 2001 14:35:55 +0200

> [draft-soliman-mobileip-flow-move-00.txt]
> 
> Browsing the draft over and over again an issue pops up I do not get 
> behind. IMHO the protocol fields specified in the Flow movement 
> suboption are not sufficient to describe flow redirection. 
> 
> - Suppose we have a flow sent by a CN and directed to a MN.
> 
> - Always keep in mind that a flow is uniquely described either by 
> 
>      (src_addr, src_port, dst_addr, dst_port, protocol) or by
>      (src_addr, flowlabel), if flowlabel is nonzero.
> 
> According to the draft the suboption can sent either to a CN, a MAP
> or a HA to redirect a flow to a particular CoA.
> 
> Case #1: BU with Flow movement suboption sent to a CN
> 
> In a PM Hesham told me the "Destination address" field contains the
> MN's CoA. However, this information is already contained in either the
> IP header source address fields or the alternate CoA option of the 
> BU. So this field seems to be redundant in this case.
> 
	=> The Destination address, is the CoA that the MN is requesting 
	the C/HA/MAP to send the flow to. 

> If the "P" flag is set, then we only have (dst_port, protocol, 
> dst_addr, src_addr) to describe a flow. This is not enough to 
> describe a flow sent as the src_port is missing.
> 
> (Suppose the MN offers a service on a dedicated TCP port x. Two
> individual applications running on the CN establish a connection to 
> the MN's TCP port x. In this case, the MN cannot redirect one of 
> these flows to a different CoA)
> 
> 
	=> Right, this is a case we didn't actually consider. Or consideration
	was for the case where you want an application to run on
	one interface for all CNs. 
	But I can see that this case (you mention above) maybe important
	as well. So if we add a filed for the src address and allow for 
	an option where the MN says "forward all flows to this dest
	address regardless of what the source is". 
	 guess this is more applicable to case 2 below, because 
	if the BU is sent to the CN there is only one source. Or 
	do you want to split the traffic from the CN as well ?
	I think this is unnecessary. 

> Case #2: BU with Flow movement suboption sent to a MAP
> 
> If the "P" flag is set the MAP has no infortmation on
> src_port and src_address of a flow. If the "F" flag is set, then
> the MAP has no information on the src_addr of the flow.
> 
> (Suppose the MN offers again a service on a dedicated TCP port x. 
> Two individual applications running on different CNs establish a 
> connection to the MN's TCP port x. Yet again, the MN cannot redirect 
> one of these flows to a different CoA)
> 
	=> Got it. I'll add a src address field. This should cover all
	cases right ? I don't think we really need a src port number. 
	Just trying to save bits.

> Case #3: BU with Flow movement suboption sent to a HA
> 
> should be somewhat similar to case #2 (?)
> 
	Thanks, 
	Hesham

---

From: Wolfgang Hansmann <[email-masked]>
Date: Mon, 16 Jul 2001 15:21:19 +0200

> > [draft-soliman-mobileip-flow-move-00.txt]

[...]

>         the C/HA/MAP to send the flow to.

I forgot the fact that several flow move suboptions can be contained 
in a single BU. OK - this field's necessary.

[...]

>         I think this is unnecessary.

IMHO it should work for all flows, regardless if they're sent by a 
single CN or different CNs.

Remember: it's the "Flow movement suboption" and not the "Flow 
movement suboption applicable to all flows except those originated 
at the same CN" :-)

> > Case #2: BU with Flow movement suboption sent to a MAP

[...]

>         Just trying to save bits.

Well, that's only 16 additional tiny bits. If you really want to save 
header space, then you should consider to specify 2 sub-options. One 
for flows identified by (src/dst addr, src/dst port and protocol) 
and one for flows identified by (src_addr, flowlabel). 

Remember - if the "P" flag is set you have "flowlabel + reserved" 
= 29 bits of idle header space. Otherwise If the "F" flag is set then 
you have 24 idle bits.

Wolfgang