Subject: Re: [Monami6] Comments on draft-larsson-monami6-filter-rules-00.txt

From: Heikki Mahkonen <[email-masked]>
Date: Mon, 03 Jul 2006 15:29:51 +0300

Hi,

Conny Larsson (KI/EAB) wrote:
> Gábor Fekete wrote:
>> I understand that you intentionally left out the discussion
>> of the transferring details. But is it so that it is supposed
>> to be accompanied by other documents describing
>> o Specification of Policies
>> o Specification of Filter Rules?
>>
> A separate document where handling of Filter Rules are discussed.

==> In addition, there will be a separate document about how the Filter
Rules are  associated with a CoA (interface) by using Filter Rule
Identifiers (FRID) and Binding Unique Identifier (BID). The aim of this
additional document is to tie the Filter Rule mechanism described in the
(draft-larsson...) to Mobile IPv6 and MCoA draft.

>>
>>
>> 4. Also in section 2.2.  Filter rules and Filter:
>>
>>   "A filter rule may only be associated with one care-of address, but a
>>    care-of address can be associated with multiple filter rules."
>>
>>    Should not this be "A filter rule __can__ only be associated..."
>> instead?
>>    As I see, this draft, for Mobile IPv6, depends on
>> ietf-monami6-multiplecoa
>>    and if a Filter Rule is associated with multiple CoAs then there
>> would be
>>    multiple BC entries with the same BID (FRID).
>>
> I'm thinking of it like this. When sending a Binding Update with the BID
> option
> the FRID would be added to this option.
> 
> BU {BID-1, CoA-1, [Set-of FRID]}
> 
> When a care-of address is changed and a Binding Update is sent it would
> be like
> 
> BU {BID-1, CoA-3}
> 
> The initial idea was that a filter rule can only be associated with one
> care-of
> address. We have also thought of the possibility to have a filter rule
> associated with multiple care-of addresses for bi-casting or load balancing.
> However, at this stage we stick with "one filter rule one CoA" since I'm not
> sure of the implications of having multiple care-of addresses associated
> with
> one filter rule.

==> As Conny explained above we are thinking that when mobility protocol
is Mobile IPv6 one FRID must be associated with at least one BID in
order to identify which CoA to use with a traffic flow matching with the
Filter Rule. If the associated CoA changes but the BID remains the same
(horizontal handover) the association does not have to be updated. If
the BID associated with a FRID changes (vertical handover) the
association must be updated. The intention is to transfer the FRIDs in
the Mobile IPv6 signaling (Binding Update and error signaling in Binding
Acknowledgment) by adding the FRIDs into BID sub-option. Each FRID
associated with a BID will be added into the BID sub-option carrying
that specific BID and so on. Now if a Filter Rule demands that a traffic
flow matching with it should be bi-casted or load balancing should be
applied the FRID must also be associated with more than one BID. Of
course, multiple traffic flows can use the same CoA which means that
multiple FRIDs must be mapped with a same BID. This means that BID
sub-option should be able to carry multiple FRIDs and a same FRID can be
added to multiple BIDs. I hope this gives more information on these issues?

>>
>>
>> Over all, I think this draft should/could be more independent from
>> Mobile IPv6
>> but then there is not much left in it. Then it may be extended to a fully
>> functional draft on policy/filter description and exchange (like
>> draft-mitsuya-monami6-flow-distribution-policy-01.txt) but without any
>> mobility management protocol dependency.
>>
> We will try to make it more independent of MIPv6, thats the intention.
> Further work will be done on the draft.

==> The draft that Conny Larsson sent in is planned to be mobility
protocol independent and to use the mechanism it (will) describe(s) with
a particular mobility protocol there should be a separate mechanism
which ties the Filter Rules to locators in an optimal fashion for each
mobility protocol. For Mobile IPv6 we are thinking that the optimal way
is to associate the FRID with a BID. This way if the Mobile Node moves
it does not have to send all the FRIDs again if the BID remained the
same while the CoA changes. This optimizes the solution a bit. We are
planning to submit a draft which details how this association should be
made and maintained between FRIDs and BIDs. But as this mechanism uses
the BID sub-option to transfer the FRIDs it could be that later on the
FRID transfer additions should/could be incorporated into the MCoA draft
itself. Anyway this work is in progress but comments are appreciated.

Best regards,

Heikki Mahkonen

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