Subject: Re: [Monami6] Flow Bindings and destination address in draft-soliman-monami6-flow-binding-00.txt

From: Nicolas Montavont <[email-masked]>
Date: Thu, 01 Jun 2006 20:53:32 +0200

Hi Gabor,

First of all, thank you for the comments.
You are right, the document needs several clarifications.
See my comments inline.

On Fri, 2006-05-26 at 11:31 +0300, Gábor Fekete wrote:
> Hi Andy,
> 
> On Friday 26 May 2006 07:20, Andy Huang wrote:
> > Hello Gabor Fekete,
> > 
> > I didn't read the draft very carefully, here is my own thoughts, perhaps 
> > it's different from the draft.
> > 
> 
> [snip]
> 
> > 
> > If the existing (HoA-1, CoA-1) binding is the default binding,  all 
> > packets(all kinds of  FID) to HoA-1 must be sent to CoA-1, so HA need not 
> > create an association between the binding and the said FID. But HA must 
> > update the BC entry according to BU, the update process is described in 
> > RFC3775.
> > 
> OK. So,
> preconditions:
> o the HA has a (HoA-1, CoA-1) default binding.
>   (It does not qualify as a "standard entry", does it? Since it is marked as
>    "default".)

This is right. First, the HA must have what we call a default binding,
which is created upon the reception of a BU with a Flow Id option, with
the D flag set.

> event:
> o the HA receives a BU for (HoA-1, CoA-1) with FID (dst=IP-X, E set, D not-set)
> 
> The draft says in Section 7.3:
>   "When the home agent receives a BU which includes at least one Flow
>    Identification option, it first performs the operation described in
>    section 10.3.1 of RFC3775."
>   So, the algorithm jumps to 10.3.1.
> 
> RFC 3775 10.3.1:
>   "If home agent accepts the Binding Update, it MUST then create a new
>    entry in its Binding Cache for this mobile node or update its
>    existing Binding Cache entry, if such an entry already exists."
>   So, the algorithm updates the (HoA-1, CoA-1) binding.

In this case, the HA will not automatically update the existing entry.
The BC is proposed to be extended to include additional fields, such as
a Flow Id. With these extension, a BC entry is identified by the couple
(HoA, Flow Id). Therefore, the BC entry is updated only if the HoA and
the Flow Id in the BU are already identifying an existing entry.
Otherwise, either a new entry will be created or the BU will be rejected
depending on the validity of the FID option.

> 
> Later in the draft in Serction 7.3:
>   "o  Action = 0: add flow binding.  If the FID in the BU is the same as
>       the FID in an existing binding cache entry for the same home
>       address, the home agent sends back to the mobile node a BA with a
>       error code 136 (FID already in use).  Otherwise, the home agent
>       needs to create a new entry in the binding cache with the
>       associated flow policies."
>   So, the algorithm "needs to create a new entry". But what entry?

In your example, you never specified which Flow Id are used. Is the one
in the BU is the same than the one stored in the BC?
	-> if yes, there is an error in the BU ("add a FID" while the FID is
already used) and therefore there is no update.
	-> The FID is different, so a new entry may be created. However, as
IP-X is different from HoA1, I fail to see when this entry would be
used... 

>  A new
>   binding cache entry or just a Flow Identifier attached/associated to
>   the existing entry or a totally new binsing cache entry with HoA set
>   to IP-X (assuming IP-X being a HoA that is diferent from HoA-1)?
>   (And it is a HA BU, so no Return Routability is needed.)

As we wrote the draft, the additional fields are part of the BC and BUL.

> 
> The draft is quite chaotic to me. It does not clearly define the relation
> between Binding Cache entries and Flow Identifiers.

We'll try to clarify this in the next revision.

> It suggests that Flow Identifiers are managed separately from the
> BU in which it was delivered (and in that case, piggybacked). E.g. why
> the Dest Addr in the Flow Identifier Option needed? For HMIP? Why?
> 
> Section 2 of the draft:
>   "Destination Address
> 
>       This field identifies the destination address of the data packet
>       as seen by the receiver of the binding update.  For a
>       correspondent node, the destination is the home address of the
>       mobile node.  However, a mobility anchor point would see the
>       destination address as the regional care-of address of the mobile
>       node.  Hence, the mobile node needs to specify this field as seen
>       by the receiver of the binding update."
> 
> And Section 6.1 of RFC4140 (HMIPv6), 1st paragraph:
>   "After forming the RCoA based on the prefix received in the MAP
>    option, the mobile node sends a local BU to the MAP with the A and M
>    flags set.  The local BU is a BU defined in [1] and includes the
>    mobile node's RCoA in the Home Address Option.  ..."
>   So even for BUs to MAPs, this Dest Addr in the Flow Identifier is not
>   needed since the HoA is set properly (i.e. to the RCoA) by the
>   protocol-obeying HMIPv6 MN.
> 
> > I think FID can be used to select a specific CoA in case of multiple CoAs 
> > bound to the same HoA.
> > Let's focus on the packet forwarding, when HA receive the packet from CN to 
> > MN(destination address of IP header is HoA), HA will search the binding in 
> > the BC and select a specific BC entry (different CoA, same HoA) to forward 
> > the packet according to FID(such as port number, protocol number ).

That's correct.

> > 
> I think the same but the draft is not clear.
> 
> > In your example, FID is bound to a destination address IP-X. IMHO, it's 
> > useless because FID is used to forward the packet whose destination address 
> > must be  HoA.

That's correct. That's why I think Destination address must be the HoA
(except in HMIP)

> > 
> Exactly, it is useless if the draft "works" in the way you and I think.
> But if it works in a different way then it makes me wonder if it's just broken
> or I just simply don't understand it.
> 
> I wonder if the draft authors are planning to release an updated version.

Sure, we definitely need it :)

Nicolas

> 
> Regards,
> Gabor
> 
> _______________________________________________
> Monami6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/monami6

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Gábor Fekete <[email-masked]>
Date: Thu, 1 Jun 2006 23:54:20 +0300

Hi Nicolas,

On Thursday 01 June 2006 21:53, Nicolas Montavont wrote:

[snip]

> depending on the validity of the FID option.
I see.

> in the BU is the same than the one stored in the BC?

Sorry! I meant a completely different FID.

> IP-X is different from HoA1, I fail to see when this entry would be
Exactly. That's one reason for the existence of this thread. :)

> As we wrote the draft, the additional fields are part of the BC and BUL.
So does it mean that we can have a BC with these entries? :

HoA-1, CoA-1, ..., FID-1, ...
HoA-1, CoA-1, ..., FID-2, ...

If no, then why is it allowed to have multiple Flow Identifier options
in one single BU (Section 2, 1st paragraph) and why does the BC entry
modified to contain only a single FID?
If yes, then according to the draft, would the following BC entry be created
in my scenario (regardless when this entry would be used)? :

IP-X, Coa-1, ..., FID-from-the-BU

> We'll try to clarify this in the next revision.
Great! E.g. with some visual ASCII-art BC representations :)

> That's correct. That's why I think Destination address must be the HoA
And do you think that the Destination Address is needed in the Flow Identifier
option? Please, see my comments above about the HMIP case.
I fail to see the usefulness and necessity of the destination address field.
In my opinion all it causes is confusion and it is totally unnecessary.
Or do I fail to see some use case for it which cannot live without it?

Regards,
Gabor