Subject: Re: [Mip4] I-D Action:draft-ietf-mip4-nemo-haaro-02.txt

From: Xiangsong Cui <[email-masked]>
Date: Fri, 05 Nov 2010 11:57:16 +0800

Hi,

I have read this draft, I think it is in good shape and provides useful
feature, so I support it.

I have a minor comment on race condition registration, (end of section
3.3.3, page 18).
The draft reads,

   If a router with a smaller Home Address (meaning a normal 32-
   bit integer comparison treating IPv4 addresses as 32-bit unsigned
   integers) receives a registration request (in CR role) while its own
   registration request (sent in MR role) is still pending, the attempt
   should be rejected with reply code "concurrent registration".  If
   receiving such an indication, the recipient should not attempt to re-
   register again until a grace period has passed without route
   optimization occurring.

I think maybe we can use a successful reply to replace the rejected reply,
the conflict may still be avoided.

>From perspective of either mobile router, its CoA is unknown to the peer
mobile router before it replies the CoA in registration reply message, so,
if only it includes the same CoA (as which is used in its registration
request message) in the registration reply message, there will be only one
CoA pair between the mobile router pair.

On the other hand, (if I understand right here) the CR establishes the
inter-NR tunnel after it accepts the registration request message, while the
MR establishes the inter-MR tunnel after it accepts the registration reply
message, so, when the mobile router (either above MR or CR) receives a
registration reply message, if there is already a inter-MR tunnel about the
related CoA pair, it SHOULD utilize the existing tunnel, for the mobile
router pair.

Does this make sense?  We can simplify the procedure by this way, e.g., get
rid of grace period and rejected-reply-lost case.

Regards,
Xiangsong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, October 18, 2010 5:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Mip4] I-D Action:draft-ietf-mip4-nemo-haaro-02.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Mobility for IPv4 Working Group of the
IETF.
> 
> 
> 	Title           : Home Agent assisted Route Optimization between
> Mobile IPv4 Networks
> 	Author(s)       : A. Makela, J. Korhonen
> 	Filename        : draft-ietf-mip4-nemo-haaro-02.txt
> 	Pages           : 49
> 	Date            : 2010-10-18
> 
> This document describes a Home Agent assisted Route Optimization
> functionality to IPv4 Network Mobility Protocol.  The function is designed
to
> facilitate optimal routing in cases where all nodes are connected to a
single
> Home Agent, thus the use case is Route Optimization within single
> organization or similar entity.  The functionality adds possibility to
discover
> eligible peer nodes based on information received from Home Agent, Network
> Prefixes they represent, and how to establish direct tunnel between such
> nodes.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mip4-nemo-haaro-02.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: Antti Mäkelä <[email-masked]>
Date: Fri, 5 Nov 2010 09:56:21 +0200 (EET)

> CoA pair between the mobile router pair.

   Hmm, this is an interesting point. So let me see the events here in 
detail and analyze a bit:

If we have

   MR #1                 MR #2
HoA: 1.1.1.1            2.2.2.2
CoA: 11.11.11.11        22.22.22.22

Concurrently occurring events (arriving to destination)

   Reg request
   sent from 11.11.11.11 to 2.2.2.2
   Reg request
   sent from 22.22.22.22 to 1.1.1.1

As per current spec, MR#1 rejects the request with the concurrent 
registration message, MR#2 replies with accept (and tunnel is set up). The 
tunnel will go from random port at 11.11.11.11 (from where the Reg Req 
was sent) to port 434 at 22.22.22.22.
   Once MR#1 receives the reply to his request (the accept), he can re-send 
his registration request. This time it is accepted, although the effect is 
that only routing is altered, the tunnel is already known and up.

   Now, if we instead accept, at the point in time where both MR's have 
accepted, we have:

   MR#1, tunnel interface up, from 11.11.11.11 to 22.22.22.22, source port 
434, destination port random (same ones as in reg req message from MR#2)
   MR#2, tunnel interface up, from 22.22.22.22 to 11.11.11.11, source port 
434, destination port random (same ones as in reg req message from MR#1)

   If processing as per your suggestion, after reply is received, both 
routers simply check that there is a tunnel-if in place and stop further 
processing. However, the tunnel endpoints are wrong so initial keepalive 
check is bound to fail no matter what.
   The spec does state that due to possible PATs and whatnot (such as the 
port number simply being in use) affecting source port numbers the tunnel 
endpoint should be able to accept packets from a tunnel even if the 
"random" port number changes (since we are not reusing the path taken by 
registration request, it can and probably will change), but one end of the 
tunnel is always fixed port 434.

   If we *do* set up tunnels even if one exists before then there will be 2 
(connected) tunnel interfaces at both routers. Of course, we could drop 
one of them at this point instead, but I'd think that establishing a new 
interface with all the associated state maintaining is more expensive 
procedure than simply rejecting a registration request.

> rid of grace period and rejected-reply-lost case.

   Instead of this, a potential approach could be a "concurrent 
accept"-type reply code which tells the other end that no need for a grace 
period and re-sending reply code, the request is accepted, but you should 
wait for the peer to complete his registration and create the tunnel.

   So idea is good, if refined as so, where I omit the keepalive checks:

At MR#1:

   Reg request
   sent from 11.11.11.11 to 2.2.2.2

   Note that myself (1.1.1.1) is pending registration to 2.2.2.2

   Reg request from 22.22.22.22 arrives

   Since registration is still pending and our HoA is smaller than 2.2.2.2,
   reply with "concurrent accept".
   No tunnel interface goes up.

   Reg reply from 2.2.2.2 arrives. Tunnel interface goes up as normal. 
Since we had a "concurrent accept" sent, start keepalive and after first 
success set routes to the tunnel.

At MR#2
   Reg request
   sent from 22.22.22.22 to 1.1.1.1

   Note that myself (2.2.2.2) is pending registration to 1.1.1.1

   Reg request from 11.11.11.11 arrives

   Registration is still pending to the peer, but our HoA is larger 
(2.2.2.2), reply with accept. Tunnel interface goes up. After first 
keepalive check is success, point the routes to the tunnel.

   Reg reply from 1.1.1.1 arrives. It's a "concurrent accept". Since we 
already have a tunnel up (clearly we have accepted request from 1.1.1.1), 
we just use existing tunnel.

   So this just might work...it requires a bit more state information to be 
maintained, though.

-- 
- Antti Mäkelä | Researcher -
- Department of communications and networking -
- Aalto University -

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 05 Nov 2010 16:57:03 +0800

Oh, sorry, I forgot port number issue,
but how about taking 434 as both the source and the destination port number?

Regards,
Xiangsong

> Antti M?kel?
> Sent: Friday, November 05, 2010 3:56 PM
> To: Xiangsong Cui
> Cc: [email-masked]
> Subject: Re: [Mip4] I-D Action:draft-ietf-mip4-nemo-haaro-02.txt
> 
> Mip4 mailing list: [email-masked]
>     Web interface: https://www.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/