RE: timeslot at IETF68

Hi Alex,

> -----Original Message-----
> From: Alexandru Petrescu [mailto:alexandru.petrescugmail.com]
> Sent: Wednesday, March 07, 2007 5:34 PM
> To: Benjamin Lim
> Cc: Monami6 WG
> Subject: Re: [Monami6] timeslot at IETF68
> 
> Benjamin, the description you wrote below sounds very
meaningful to me,
> about the problem of MR doing flow bindings and LFN
being unaware of
> that, while LFN should be aware because it is the end
of the
communication.
> 
[Ben] The MN shown in the diagram below need not be a LFN.
As stated in the
text, I'm showing that a VMN that is attached to MR facing
the problem of
doing flow filtering efficiently.
 
> I think you could write a separate mail only with the
correct picture
> and the paragraphs that sound like problem statement,
avoid statements
> about who said what, and I will reply to that mail with
comments.
> 
> I think from that on it will be very easy to put that
initially agreed
> text in a short draft form and then a presentation slot
can be requested
> (although the draft-00 deadline has passed the draft
can be published on
>   the Internet temporarily until published by RFC
Editor after the IETF
>   meeting).
> 
[Ben] Comments made by the members of the mailing list would
most definitely
be left out if a draft is to be written on this topic. But
for now, I'm
attempting to summarize some points that has been made in
the mailing list
on this topic. My apologies if I have offended anyone when
putting names to
comments.

Regards,
Benjamin Lim

> Alex
> 
> Benjamin Lim wrote:
> > Hi,
> >
> > [snip]
> >> Usually it's the other way round. In order for
people to prepare for
> >> the discussion, a draft is useful, and it's
too late now to produce a
> >> new one. So, is there a draft to read, if no
draft, a report or
> >> something ? [/snip]
> >
> > Currently, no documentation is available for the
WG. The motivation for
such
> > presentation is there exist  use case in which a
multihomed host
requires
> > additional help in order to perform the flow
filtering when attached to
a
> > multihomed router.
> >
> > The following can be used by the audience to get
some information on
what
> > will be presented.
> >
> > Consider the following scenario (as mentioned by
Heikki)
> >
> >                                              
+------+
> >                      3G Cellular       |        
|
> >                                   /--------|  I   
  |     +----------+
> >                   CoA-3G /             |  N   
|----| HA-MR |
> >          +----+     +----+             |  T    |  
  +----------+
> >          | MN |----| MR |            |  E     |
> >          +----+     +----+             |  R    |  
  +----------+
> >             CoA-WLAN              |  N   |----|
HA-MN |
> >                                    --------|  E  
 |      +---------+
> >                          802.11g         |  T   
|
> >                                              
+-----+
> >
> > Here, the Mobile Router, MR, has two different
egress interfaces: a 3G
> > cellular interface with a Care-of Address of
CoA-3G, and a 802.11g
interface
> > with a Care-of Address of CoA-WLAN.  A Visiting
Mobile Node, MN, is
> > currently attached to the mobile network of MR. 
HA-MR is the home agent
of
> > MR and HA-MN is the home agent of MN.
> >
> > "Flow Bindings in Mobile IPv6"
(draft-soliman-monami6-flow-binding-02)
aims
> > to bind flows by introducing a new option, known
as Flow Identification
> > option, in the Binding Update and Binding
Acknowledgement messages.
With
> > this, a Mobile Node can bind one flow to an
interface while maintaining
the
> > reception of other flows on another interface. 
Flow bindings would
> > therefore be useful in cases where the Mobile Node
is connected to
different
> > access technologies with different
characteristics.
> >
> > However, when we apply the flow filtering
mechanism stated in Monami6 to
> > NEMO, the fact that the tunnel ends at the Mobile
Router whereas the
traffic
> > ends at Mobile Network Node cause problem with
flow filtering.  On one
hand,
> > while the Mobile Router has multiple egress paths,
it cannot perform
> > efficient flow filtering since the Mobile Router
has no way to know the
> > traffic requirements of Mobile Network Node's
flows.  On the other hand,
the
> > Mobile Network Node has no way of knowing the
existence of multiple
paths
> > (and their network characteristics) to start flow
filtering.
> >
> > Thierry mentioned in the ML that this issue is
also being worked out by
the
> > automotive industry, within ISO TC204 WG16 (using
SNMPv3). The solution
is
> > part of the CALM standard which is supposed to be
deployed in vehicles
for
> > ITS applications. They do not necessarily need an
IETF standard, and
don't
> > even try, though they do reuse some of the
existing standards like NEMO
> > Basic Support, etc.
> >
> > Furthermore, Alex highlighted that the NEMO WG is
rechartering to
identify
> > requirements for Route Optimization.  One possible
requirement may be
that
> > MR sends to VMN what are the subnets to which it
connects.  At that
point
> > the flow bindings should be established by VMN
somehow. This may be a
> > solution to the problem in which VMN knows nothing
about MR decisions.
> >
> > Because packets tunneling and traffic session
terminate at different
nodes
> > in a mobile network, the flow binding mechanism
currently developed by
the
> > Monami6 WG cannot be used without modification.
Thus, the purpose of the
> > presentation is to attempt to gather requirements
to provide a suitable
> > solution to be adopted by the flow binding
mechanism designed for
Monami6.
> >
> > Regards,
> > Benjamin Lim
> >
> >
> >
> > _______________________________________________
> > Monami6 mailing list
> > Monami6ietf.org
> > https:
//www1.ietf.org/mailman/listinfo/monami6
> >
> 
> 
>
____________________________________________________________
__________
> This email has been scanned by the MessageLabs Email
Security System.
> For more information please visit http://www.messagela
bs.com/email
>
____________________________________________________________
__________



_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6

Benjamin Lim wrote:
> Hi Alex,
> 
>> -----Original Message----- From: Alexandru Petrescu

>> [mailto:alexandru.petrescugmail.com] Sent: Wednesday,
March 07, 
>> 2007 5:34 PM To: Benjamin Lim Cc: Monami6 WG
Subject: Re: [Monami6]
>>  timeslot at IETF68
>> 
>> Benjamin, the description you wrote below sounds
very meaningful to
>>  me, about the problem of MR doing flow bindings
and LFN being 
>> unaware of that, while LFN should be aware because
it is the end of
>>  the
> communication. [Ben] The MN shown in the diagram below
need not be a 
> LFN. As stated in the text, I'm showing that a VMN that
is attached 
> to MR facing the problem of doing flow filtering
efficiently.

Ok.

>> I think you could write a separate mail only with
the correct 
>> picture and the paragraphs that sound like problem
statement, avoid
>>  statements about who said what, and I will reply
to that mail with
>>  comments.
>> 
>> I think from that on it will be very easy to put
that initially 
>> agreed text in a short draft form and then a
presentation slot can 
>> be requested (although the draft-00 deadline has
passed the draft 
>> can be published on the Internet temporarily until
published by RFC
>> Editor after the IETF meeting).
>> 
> [Ben] Comments made by the members of the mailing list
would most 
> definitely be left out if a draft is to be written on
this topic.

That's fine, thanks, I think administrative comments (like
conditions
for Chair to allow a timeslot, or like NEMO RO is being
chartered)
should be left out of the document; but comments on the
problem
statement itself should be put in.

> But for now, I'm attempting to summarize some points
that has been 
> made in the mailing list on this topic.

That's fine, thanks.

There was discussion on the int-area mailing list too about
the
necessity of allowing the LFN to know the flow bindings
decisions made
by MR.  Apart from the supportive comments, there was
discussion showing
that usually the network does make decisions about how to
route traffic
for endnodes (in general, when not using MCoA).

Typically, a router chooses a path to forward a packet based
on (at
least) link up/down events in the various intermediary
links; the
endnode is not aware of that.  This would translate into
allowing MR to
do same kind of operation for LFN: MR decides flow for this
LFN goes on 
a certain path and flows for another LFN to another path,
without LFN 
being aware of that.

However, I would remark that in the usual case (non-MCoA),
intermediary 
routers rarely if ever look at port numbers or addresses
within tunnels 
to make such decisions.  They mostly look at the outer base
header.  If 
an endnode application encapsulates a packet the
intermediary router 
will not look in the encapsulated base header and thus the
endnode keeps 
control.  If an endnode sets a port number the intermediary
routers 
don't look at them.

Thanks for your comments and pushing on this.  I support
describing the 
problem of MR making flow-binding decisions on behalf of a
unaware LFN.

Alex


____________________________________________________________
__________
This email has been scanned by the MessageLabs Email
Security System.
For more information please visit http://www.messagela
bs.com/email 
____________________________________________________________
__________

_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6