Subject: [netlmm] NETLMM protocol document status and timelines

From: "Shyam Hemadpant" <[email-masked]>
Date: Tue, 3 Apr 2007 21:11:09 -0700

Hello Sri and other Authors,

  We are doing a Proxy Mobile IPv6 implementation based on your current
document
  draft-sgundave-mip6-pmip6-02.txt. Can you please tell us if your forsee
any changes in
  the next revision of this document and if we need to hold off till the
next rev comes out
  and if so when you plan to release the document.

  Can we know the estimated timelines as when this draft will become the
proposed standard.
  We also need some metrics on the protocol scalability and performance to
present to
  our partner and any data that you can share, will help our project.

Cheers,
- Shyam
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 3 Apr 2007 21:48:02 -0700

Hi Shyam,
 
Please see inline ...

  _____  

 >  From: Shyam Hemadpant [mailto:[email-masked]] 
 >  Sent: Tuesday, April 03, 2007 9:11 PM
 > To: [email-masked]; [email-masked]
 > Subject: NETLMM protocol document status and timelines
 > 

document
any changes in
next rev comes out
 >  and if so when you plan to release the document. 
 
The consensus call for the document selection is complete last week and the
formal announcement is pending.
We the authors are working on making changes to the current document, based
on the feedback that we received
over the last few weeks and things that we missed in the last revision due
to time pressure. The changes will be 
specific to:
 
- Textual Comments and Nits
- Other changes reflecting the wg consensus
- Review comments received offline and in the ML
- Authors discussion ..etc
 
Generally, the base protocol operation will not change. We will attempt to
improve the presentation and provide
clarity on the protocol operation, as required.
 
proposed standard. 
 
The document is in a good shape with good positive feedback. Our goal is to
send the document to
IESG in July time frame, if things go the way they are supposed to go.
 
present to
 >  our partner and any data that you can share, will help our project. 
 
Cisco Japan has implemented Proxy Mobile IPv6 and we have some data on this.
Hopefully. we will
present this in the next IETF, if we get a slot.  Also, some university in
Korea has the implementation, at least
there were some implementation specific queries. Also, one or two other
vendor implementations, that I don't
know if I can comment. Any case,  we should be able to get some good data on
this aspect from multiple sources,
hopefully.

Regards
Sri

---

From: "Sangjin Jeong" <[email-masked]>
Date: Wed, 4 Apr 2007 16:53:37 +0900

Hi Sri,

Please see inline.

----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: "'Shyam Hemadpant'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 04, 2007 1:48 PM
Subject: [netlmm] RE: NETLMM protocol document status and timelines

> there were some implementation specific queries. 

FYI.
Currently, ETRI and KUT are jointly implementing the draft-sgundave-mip6-proxymip6-02. 

Regards
Sangjin

> Also, one or two other

--------------------------------------------------------------------------------

---

From: "Kalin Getov" <[email-masked]>
Date: Wed, 04 Apr 2007 13:35:02 +0200

Hi all,

the per-MN-prefix model means that each MN becomes an unique home network prefix. In the draft is written:

"At the end of a successful address configuration procedure, the mobile node would have obtained an address from its home network prefix."

I was wondering if this will be exactly the same address as before the handoff or just from the same home network prefix. For example, if with the handoff the radio interface is also changed, there are different MAC addresses, which are eventually used as identifiers. I'm assuming a network prefix length of 64 bit(or maybe the draft assumes prefix length of 128 bit?) . What happens with the running applications at this moment? With the change of the address, the application data stream is interrupted I think. Am I missing something here? Please comment...thanks!
-- 
******************************************
Best Regards
Kalin Getov

[email-masked]
******************************************

"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 4 Apr 2007 10:18:59 -0700

Hi Kalin,

Please see inline. 

-----Original Message-----
From: Kalin Getov [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 4:35 AM
To: Sri Gundavelli
Cc: [email-masked]
Subject: [netlmm] Some questions to Per-MN-Prefix model

  Hi all,

the per-MN-prefix model means that each MN becomes an unique home network
prefix. In the draft is written:

"At the end of a successful address configuration procedure, the mobile node
would have obtained an address from its home network prefix."

I was wondering if this will be exactly the same address as before the
handoff or just from the same home network prefix. For example, if with the
handoff the radio interface is also changed, there are different MAC
addresses, which are eventually used as identifiers. I'm assuming a network
prefix length of 64 bit(or maybe the draft assumes prefix length of 128
bit?) . What happens with the running applications at this moment? With the
change of the address, the application data stream is interrupted I think.
Am I missing something here? Please comment...thanks!
-- 

There are two things here. The home network prefix of the mobile and the
chosen
identifier from that prefix for the mobile node's home address. The protocol
ensures,
the mobile node always sees its home network prefix on the access link. The
prefix
length need not be 128-bit, but could be 64-bit per 3587. Now, the
identifier
or the home address selection depends on the enabled address configuration
modes.

If Statefull Address Configuration using DHCP is supported on the link, when
the
the mobile node sends a DHCPv6 Request message, the relay agent function on
the
access router will set the link-address field in the DHCPv6 message to the
mobile
node's home network prefix and that serves as a prefix hint. Now, the
specific 
identifier that the DHCP server allocates depends on the client identifier
option
sent by the mobile. If the MAC address of the mobile changes from link to
link,
the client-identifier option in the DHCP request will allow the DHCP server
to
offer the same address. So, the client identification as per 3315 is not
just based
on the MAC address, its an identifier that is used as the key.

If the mobile node uses Stateless Auto Address Configuration using 3041
based
scheme, the mobile node can generate multiple addresses from its home
network
prefix, using them as ephemeral addresses, vista does this. In this mode of
address configuration, the mobile is in charge of the identifier selection
and so
it can always obtain the same address across handoffs.

Bottom line, the mobile can obtain the same global address across handoffs.

Regards
Sri

[email-masked]

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 4 Apr 2007 10:20:28 -0700

Hi Sangjin,

> Currently, ETRI and KUT are jointly implementing the
draft-sgundave-mip6-proxymip6-02. 

Thanks for the info.

Regards
Sri

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 6 Apr 2007 09:51:16 +0900

> > this aspect from multiple sources,

In the implementation of ETRI and KUT, we are now modifying MIPL 
Mobile IPv6 for Linux and setting up a testbed for PMIPv6. 

It would be premature to report some useful data about the performance.
But, we can say that the testbed has four MAGs: two of them are 
IPv6-enabled MAGs and the other two are IPv4-enabled MAG. 
In the test scenario, therefore, network-based v4-v6 traversal 
as well as the core function of PMIPv6 will be tested.

Regards,

Youn-Hee