Subject: [netlmm] Review of draft-sgundave-mip6-proxymip6-01.txt and draft-singh-netlmm-protocol-00.txt

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 25 Jan 2007 13:48:04 -0500

draft-sgundave-mip6-proxymip6-01.txt:

This draft describes a proxy mobile IPv6 procedure where some
of the existing messages from base mobile IPv6 are reused.
The Binding Updates and Binding Acks are augmented with a new
flag that informs the recipient that the registration is
a proxy registration.

The draft assumes that all the parameters about a mobile node's
session, such as home address / prefix, address configuration
modes (stateful vs. stateless, shared-prefix vs. per-mn prefix)
come from a AAA server to which both the Proxy Mobility Agent (PMA) 
and Home Agent have access.  Thus there is a dependency on the use
of some link-layer authentication based on the NAI of the user
that gets re-invoked at each PMA.

The draft describes in detail how the PMA emulates the behavior of
the home link for both shared link and point-to-point link models.
Shared-link behavior requires that Router Advertisements be link-layer
unicast to the MN although they are IP-layer broadcast.

In general this draft meets all of the goals in
draft-ietf-netlmm-nohost-req-05.txt,
although it uses different terminology from that draft.  Because
netlmm-nohost-req
is in the RFC editor's queue, I suggest adopting its terminology in all
solution drafts including this one.  This means using the terms "MAG"
and "LMA" as defined in netlmm-nohost-req.  That will help to alleviate
confusion
in readers that pick up the requirements document.

The interaction between the local mobility management defined in this
document and any global mobility management is unclear because it is
not certain whether a given "Home Agent" (using the terminology in the
draft) can be used for global (end-to-end) registrations as well as 
local registrations.  The handling of the sequence number used in global
registrations needs to be compatible with the new timestamp ordering
method used for local registrations.

One specific comment: 
Section 4.2 gives an SPD for "mobile node SPD-S".  Should be "Proxy
Mobility
Agent SPD-S" or, better yet, "MAG SPD-S".

draft-singh-netlmm-protocol-00.txt:

This draft defines yet another proxy Mobile IP scheme, except that
instead
of moving the proxy mobility agent from AR to AR, the proxy mobility
agent (called a PMIP client) stays at a fixed location in the network.
This simplifies the operation of the protocol and allows for the
complete
re-use of existing Mobile IP Home Agents as LMAs.

On the terminology issue, this draft adopts the LMA term but does not
use the MAG term.  There may be a fundamental disconnect between the
architecture defined in this document and netlmm-nohost-req-05, which
states in Section 2:

2.0   NETLMM Functional Architecture 
      
     The NETLMM architecture consists of the following components. 
     Localized Mobility Anchors (LMAs) within the backbone network 
     maintain a collection of routes for individual mobile nodes within 
     the localized mobility management domain. The routes point to the 
     Mobile Access Gateways (MAGs) managing the links on which the 
     mobile nodes currently are located. Packets for a mobile node are 
     routed to and from the mobile node through tunnels between the LMA 
     and MAG. When a mobile node moves from one link to another, the MAG

     sends a route update to the LMA. While some mobile node involvement

     is necessary and expected for generic mobility functions such as 
     movement  detection  and  to  inform  the  MAG  about  mobile  node

     movement, no specific mobile node to network protocol will be 
     required for localized mobility management itself. Host stack 
     involvement in mobility management is thereby limited to generic 
     mobility functions at the IP layer, and no specialized localized 
     mobility management software is required. 

This paragraph clearly indicates that the MAGs are both the bearer-plane
and control-plane endpoints of the signaling; thus, there is no clear
correspondence to the MAG in draft-singh.

The use of a standalone PMIP client allows for the security association
between the "virtual" MN and the HA to remain across handoff events,
which matches the behavior of "client" Mobile IP from the perspective
of the home agent.  If re-use of existing home agents is a goal, this
draft provides a good starting point.  

The separation of bearer and control offered by this protocol is also
attractive.  However, the draft calls for a new protocol to be used
between the PMIP Client and the AR, which is currently unspecified.
To promote interoperability between PMIP clients and ARs from different
vendors, the encapsulation protocol should be specified in some future
revision of this document.

I would also recommend deleting the scenarios describing the use of
an HMIP MAP.  I don't think these have seen widespread deployment
and the scenarios given in the draft distract from the main elements
of the new protocol.

-Pete

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

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 25 Jan 2007 14:12:41 -0500

Hi, Pete, 

Thanks for review. Please find inline responses to your comments made on

draft-singh-netlmm-protocol-00.txt. 

Regards,
Ajoy  

-----Original Message-----
From: McCann Peter-A001034 
Sent: Thursday, January 25, 2007 12:48 PM
To: [email-masked]
Subject: [netlmm] Review of draft-sgundave-mip6-proxymip6-01.txt
anddraft-singh-netlmm-protocol-00.txt

This draft defines yet another proxy Mobile IP scheme, except that
instead of moving the proxy mobility agent from AR to AR, the proxy
mobility agent (called a PMIP client) stays at a fixed location in the
network.
This simplifies the operation of the protocol and allows for the
complete re-use of existing Mobile IP Home Agents as LMAs.

Ajoy-> I agree. Our draft allows for complete re-use of MIPv6 HA. 

use the MAG term.  

There may be a fundamental disconnect between the architecture defined
in this document and netlmm-nohost-req-05, which states in Section 2:

Ajoy-> Sure. I am surprised to find out why CP/BP split was not
considered in netlmm-nohost-req-05. This is a key concept and should
have been addressed given the trend in wireless access network design. 

The use of a standalone PMIP client allows for the security association
between the "virtual" MN and the HA to remain across handoff events,
which matches the behavior of "client" Mobile IP from the perspective of
the home agent.  If re-use of existing home agents is a goal, this draft
provides a good starting point.  

Ajoy-> Absolutely. The complete re-use of Home Agent is good thing for
PMIPv6 based LMM solution. 

Ajoy-> This can be considered. 

I would also recommend deleting the scenarios describing the use of an
HMIP MAP.  I don't think these have seen widespread deployment and the
scenarios given in the draft distract from the main elements of the new
protocol.

Ajoy-> We will remove this. You have correctly pointed out that HMIPv6
is not widely deployed. Probably this can be considered in separate
document. 

-Pete

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 25 Jan 2007 11:22:11 -0800 (PST)

Hi Pete,

Thanks for the review. Comments inline ..

> in readers that pick up the requirements document.

Its important to keep the terminology close the MIP6. I'm personally ok
to have a "local" or a "proxy" prefix for the terms. Complete change in
terminology will make the document appear like a different protocol, IMHO.

> local registrations.

The PMIP-Capable home agent will be able to support both global and
local registrations. The state in the BCE identifies the type of
registration. In a given deployment, the home agent can be functioning
as both a global and local home agent, the type of request (PBU vs BU),
identifies the type of service the mobile is requesting. We did not
want to tag the home agent for a specific service. However, deployments
MAY certainly choose to do so.

> The handling of the sequence number used in global

To avoid the one race condition, when the mobile is oscilatting
between PMIP and CMIP domains, for the home agent to predictably
order the Binding Update requests, a stamp extension on the BU
from a CMIP node, will resolve the issue.

> Agent SPD-S" or, better yet, "MAG SPD-S".

Yes. This was a typo. Mentioned on some other thread with Alex.

Thanks again for the time.

Regards
Sri

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 26 Jan 2007 14:42:04 -0800

I apologize if this issue has been raised before but the draft is
currently mandating that the sequence number of the PBU MUST be ignored
and that timestamps SHOULD be used instead. I think we should not
restrict the sequencing of PBUs to be done by timestamps only. 

PMIP clients that have no way of setting the sequence numbers correctly
should set them to zero and use timestamps instead. PMIP clients,
however, that can set the sequence numbers as expected by MIPv6 (e.g.,
because they use context transfer or whatever) they should be able to do
that and either not use timestamps at all or combine timestamps with the
sequence number in some fashion. 

The protocol should be able to signal what kind of sequencing is
performed.

Thoughts?
George

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 26 Jan 2007 15:06:42 -0800

Agreed, I think what you suggest below with regard to falling back to
SeqNums when Timestamps are not present is probably sufficient.

Thanks
George

> From: Sri Gundavelli [mailto:[email-masked]]
> Sent: Friday, January 26, 2007 6:04 PM
> To: Tsirtsis, George
> Cc: [email-masked]
> Subject: Re: TimeStamps vs Sequence Numbers
> 
> 
> Hi George,
> 
> We can certainly make this bit more flexible. The context
> transfer support that may come in future will allow the serving
> proxy mobile agent to send the correct sequence number,
> but this will not work for the scenario where a node being
> a PMIP node, later moves to become a CMIP node, there is no
> way sync the seq number between the PMA's and MIP6 client.
> 
> We can make the home agent return the sequence number that
> the proxy or the mobile should be using, but this always adds
> a extra round trip for all BU's that are sent after movement.
> 
> Using a global scale such as time stamp, in such situations
> will enable the receiver to establish the order of the requests.
> In any case, we can make this flexible. If there is no time
> stamp option, fall back to seq number logic.
> 
> Sri
> 
> 
> 
> On Fri, 26 Jan 2007, Tsirtsis, George wrote:
> 
> Ok

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 26 Jan 2007 15:04:11 -0800 (PST)

Hi George,

Sri

Ok