Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments

["Giaretta, Gerardo" <[e-mail]>]

Hi Ryuji,

> -----Original Message-----
> From: Ryuji Wakikawa [mailto:[e-mail]]
> Sent: Tuesday, December 16, 2008 11:32 PM
> To: Giaretta, Gerardo
> Cc: [e-mail]; [e-mail]
> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some
> comments
> 
> Hi Gerardo,
> 
> Yes, I was reading the mail threads. sorry to catch up this thread
> late. I was in Europe;-)
> 
> I understand the reasons of BID for the home attached interface.
> 
> MN keeps sending the BU (w/ non zero lifetime) from the home link?
> It sounds like we'll remove de-registration operation from RFC-3775?
> 

The point is that the MN does no de-register as in RFC-3775 if there are other active interfaces. The MN will de-register only when only the interface on the home link is active.

> As a result, HA will have a home binding for the interface attached to
> home link,
> but will not operate proxy ND and encapsulation for that binding.

If the HA is the default router, the HA will still intercept all packets as defined in the draft. It is true that there will be no encapsulation, but again this is already mentioned in the draft.

> I don't know this is reasonable modification to RFC-3775.
> 
> My understanding was that, when MN is at home, most of traffic should
> be sent directly from the home link.
> I didn't see any strong reasons to use the interface attached to
> foreign links.
> Why not setting special flows which need to be sent from the foreign
> link by flow binding and
> rest of traffic are just sent from the home link. We don't need BID
> for the home attached interface.
> This is what I expected.
> 
> Do you think there is a case where MN attaches to home link by
> multiple interfaces?
> 

Think about this scenario: the MN has a cellular interface and a WLAN interface. Cellular is the home link. MN wants to do VoIP over cellular and all other traffic over WLAN. In this case the MN will register a match-all filter for WLAN BID and more specific FIDs for the "home binding". This is the main scenario studied in 3GPP for example. 

In my opinion, allocating a BID for the HoA in the home link sounds like the cleanest way of solving this scenario. However I am open to other suggestions as soon as the scenario is supported :-)

Gerardo

> regards,
> ryuji
> 
> 
> 
> 
> 
> On 2008/12/17, at 15:42, Giaretta, Gerardo wrote:
> 
> > Hi Ryuji,
> >
> > one point related to Christian's comments is that we need a BID also
> > for the interface which is on the home link. This is needed in order
> > to associate FIDs to that interface. The rules to create/update/
> > delete that BID should be the same as for any other binding
> >
> > Gerardo
> >
> > ________________________________________
> > From: [e-mail] [[e-mail]] On Behalf Of
> > Ryuji Wakikawa [[e-mail]]
> > Sent: Tuesday, December 16, 2008 10:27 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals
> > and some    comments
> >
> > Hi Christian,
> >
> > thanks for comments.
> >
> > At Thu, 11 Dec 2008 15:08:16 +0100,
> > <[e-mail]> wrote:
> >>
> >> Assume a mobile node with home address HoA has two interfaces,
> >> both attached to foreign links.  After exchange of binding update
> >> and binding acknowledgement, the home agent's binding cache (at
> >> least the snip of it related to HoA) will look like this
> >>
> >>    HoA, BID= 7, CoA1, other parameters like period of validity...
> >>    HoA, BID=10, CoA2, other parameters ...
> >>
> >> The draft uses HoA=2001:db8::EUI.
> >>
> >> Draft 10, section 5.1 states, that a BID value must be unique for a
> >> home address and care-of address pair.  This is satisfied above, but
> >> it means, that the mobile station is not allowed to change the
> >> second entry such that it also uses CoA1 as care-of address.
> >>
> >> Proposal:  I think it has merit to be able to allow more than
> >> one BID value per pair of home address and care-of address.  Consider
> >> flow bindings (defined in draft-ietf-mext-flow-binding) where
> >> a flow may refer to a BID, and thus there is a simple way to move
> >> flows between interfaces: only updating the binding cache.
> >
> >
> > Do you want these bindings?
> >     HoA, BID= 7, CoA1, other parameters like period of validity...
> >     HoA, BID=10, CoA1, other parameters ...
> >
> > From the protocol operational view, we don't have any issue to relax
> > the BID assignment for this purpose.
> >
> >> Draft 10, section 4.2 (and other places) defines the H flag, which
> >> when
> >> set means the mobile node wants to use both its home link and one or
> >> more of its foreign links.  The H flag is really an instruction to
> >> the
> >> home agent, that in addition to all the bidings currently defined
> >> is shall have an extra binding where packets shall not be tunneled.
> >>
> >> Proposal:  The mobile node should be able to define a binding saying
> >>
> >>    HoA BID=0 HoA
> >>
> >> This is a kind of default binding to be used when any of the other
> >> HoA-
> >> bindings cannot be used.  I think the H flag is an indirect way of
> >> saying there is an extra binding, whereas the binding above is
> >> direct.
> >> It also avoids continuously setting the H flag when both home link
> >> and foreign links are active.
> >
> > This was originally proposed by Keigo from Panasonic and has been
> > discussed it.
> > You can check the discussion on ML archives.
> >
> >>
> >> Other comments
> >>
> >> o Figure 1: In general I think it simpler for human readers to have
> >>   the elements of the primary key to a database given first,
> >>   therefore I suggest
> >>
> >>       binding [2001:db8::EUI  BID1  care-of address1]
> >>
> >>   to be used allover.
> >
> > OK, will fix this.
> >
> >>
> >> o Figure 4: looks as if position 6 is followed by position 17.
> >
> > this is typo. i'll fix this.
> >
> >> o Section 4.2, O flag.  The O flag is carried in an Binding
> >>   Identification mobility option, but really it a kind of global
> >>   value to be understood by the receiver as "clean all HoA entries".
> >>   If it really is too much to introduce a new mobility option,
> >>   isn't it enough to set the O flag in the first Binding
> >>   Identification mobility option?
> >
> > I'm updating the document after last call. the O flag is now defined
> > in the BU itself, since this is global value for all bindings as you
> > pointedout.
> >
> >> o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet
> >> 2.
> >>   If the care-of address is omitted, the care-of address is to be
> >>   taken from the source address of the IPv6 header.
> >>   When the binding update arrives at the home agent, the
> >>   IPv6 header's source address is exactly the care-of
> >>   address used by the mobile node, but when the home agent is
> >>   actually able to understand the contents of the binding update,
> >>   then the IPv6 headers source address has been swapped with the
> >>   address found in the Destination Option extension header,
> >>   and thus the care-of address is now found in the Destination
> >>   Option extension header.
> >
> > In section 6.1.7 of RFc3775, it said
> >  "The care-of address is specified either by the Source Address field
> >   in the IPv6 header or by the Alternate Care-of Address option, if
> >   present. "
> >
> > So, I will fix this to
> >
> > the care-of address is to be taken from the source address of the
> > IPv6 header "of the Binding Update".
> >
> >
> >> o Section 5.6.2, bullet 2.  The term link-local address is used,
> >> but I
> >>   think this should be changed to be like in all the other places,
> >>   using link-layer address.
> >
> > yes, thanks.
> >
> >> o Section 6.2, bullet 7, sub-bullet 1: I think the condition should
> >> read
> >>   "If one of the 'O' flags is set, then all of the 'O' flags must be
> >>   set, else [MCOA MALFORMED] is returned."  But as suggested above,
> >>   I don't think there is reason to enforce an all-or-none 'O' flags.
> >
> > right, see above.
> >
> >> o Section 8.2, para 2.  The text says, that the IPv4 Address
> >>   Acknowledgement mobility option is included only if the mobile node
> >>   requested a home address.  When I read
> >> draft-ietf-mext-nemo-v4traversal,
> >>   section 4.2.1, the IPv4 Address Acknowledgement mobility option
> >>   is included always, indicating the home agent created a binding
> >> cache
> >>   entry for the IPv4 home address.
> >
> > correct. I will check dsmip and update it.
> >
> > thanks
> > ryuji
> >
> >
> >> Christian
> >>
> >>
> >> _______________________________________________
> >> MEXT mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mext
> > _______________________________________________
> > MEXT mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext