Subject: [Mip6] issue 60: Lightweight mechanism for keepalives

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 22 Sep 2006 07:19:49 -0700

Issue description
-----------------

The current draft assumes that NAT bindings can be maintained through 
binding updates. However, this operation is costly from a power and 
bandwidth point of view. This can be particularly expensive for 
low power wireless devices. Hence, there is a need for a lightweight
keepalive mechanism to maintain the NAT bindings. Such keepalive
mechanism
will not modify the binding in anyway. The message should be initiated 
by the mobile node and responded to, by the HA. The response may contain
a refresh interval for the mobile node to use.

Issue analysis:
---------------

The issue was raised (by Hesham) to suggest a lightweight (from a
processing point of view)
mechanism to maintain keepalives. Several opinions were mentioned
ranging from support to rejection of the issue. There doesn't seem to be
an agreement on this issue within the DT or during the WG meeting. 

Conclusion:
-----------

Since there is no concensus for the change, I suggest we reject this
issue. 

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 22 Sep 2006 10:07:23 -0700

Agree.

            jak

----- Original Message ----- 
From: "Soliman, Hesham" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 22, 2006 7:19 AM
Subject: [Mip6] issue 60: Lightweight mechanism for keepalives

Issue description
-----------------

Issue analysis:
---------------

Conclusion:
-----------

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 26 Sep 2006 07:54:31 -0700

Seems like there is no objection here either. Issue rejected and closed.

 Hesham

 > -----Original Message-----
 > From: James Kempf [mailto:[email-masked]] 
 > Sent: Saturday, September 23, 2006 3:07 AM
 > To: Soliman, Hesham; [email-masked]
 > Subject: Re: [Mip6] issue 60: Lightweight mechanism for keepalives
 > 
 > Agree.
 > 
 >             jak
 >

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 26 Sep 2006 22:21:39 +0200

> Seems like there is no objection here either. Issue rejected and 

It is a little bit a pitty.

It is obvious to me that (1) some NATs don't maintain state even if
outgoing traffic through it and (2) it is necessary to maintain state at
HA about NAT state (namely MN periodically sens "updates" to HA).

This can be achieved with new MIP4 messages (as suggested by the MIP4
NAT Traversal rfc).

Without doing this it is possible that a continuous incoming flow to MN
(video stream) gets interrupted because NAT has changed its outgoing
port number and HA does not know it.

It seems however that I'm the only one observing this problem, and
I'll bow to the WG decision on this.

Alex

> 
> 
> Hesham
> 
>> -----Original Message----- From: James Kempf 
>> [mailto:[email-masked]] Sent: Saturday, September 23, 
>> 2006 3:07 AM To: Soliman, Hesham; [email-masked] Subject: Re: [Mip6]
>>  issue 60: Lightweight mechanism for keepalives
>> 
>> Agree.
>> 
>> jak
>> 
>> ----- Original Message ----- From: "Soliman, Hesham" 
>> <[email-masked]> To: <[email-masked]> Sent: Friday, September
>>  22, 2006 7:19 AM Subject: [Mip6] issue 60: Lightweight mechanism 
>> for keepalives
>> 
>> 
>> 
>> Issue description -----------------
>> 
>> The current draft assumes that NAT bindings can be maintained 
>> through binding updates. However, this operation is costly from a 
>> power and bandwidth point of view. This can be particularly 
>> expensive for low power wireless devices. Hence, there is a need 
>> for a lightweight keepalive mechanism to maintain the NAT bindings.
>>  Such keepalive mechanism will not modify the binding in anyway. 
>> The message should be initiated by the mobile node and responded 
>> to, by the HA. The response may contain a refresh interval for the 
>> mobile node to use.
>> 
>> Issue analysis: ---------------
>> 
>> processing point of view) mechanism to maintain keepalives. Several
>>  opinions were mentioned ranging from support to rejection of the 
>> issue. There doesn't seem to be an agreement on this issue within 
>> the DT or during the WG meeting.
>> 
>> Conclusion: -----------
>> 
>> Since there is no concensus for the change, I suggest we reject 
>> this issue.
>> 
>> 
>> _______________________________________________ Mip6 mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>> 
> 
> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>