Subject: [netlmm] Review of draft-ietf-netlmm-mn-ar-if-02

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 13 Aug 2007 12:20:17 -0400

Technical Comments

2. Terminology

   Network-based Localized Mobility Management Domain (NETLMM domain)
      an administrative domain spanning links served by a set of LMAs
      (and their associated MAGs and MNs) that provision addresses from
      the same IP subnet prefix(es).
Is it really necessary for all LMAs to use the same set of prefixes?
I can imagine deployments where different LMAs have different points
of connectivity to the Internet and so would use different prefixes.

6. MN_ATTACH Function

Because we are assuming a ptp link model, is it fair
to say that PPP will be re-established at every MAG-to-MAG
handoff?  This will need to be hidden from upper layer
applications.  The time required to re-negotiate PPP is
non-trivial.  A completely unmodified host might break
application socket connections when this happens.  It 
might be worthwhile to write a few sentences about this.

MN_GET_ADDR_PARMS seems to assume that the MAG makes up
the IPv6 subnet prefix and then registers it with the
LMA.  Doesn't it make more sense to have the LMA generate
the prefix, and then send it to the MAG/MN?

6.3. MN_GET_DEFAULT_ROUTER Sub-function

It is stated here that IPv6CP can configure a default
router.  I do not think this is true.  Only the RS/RA
can configure a default router.

8. Security Considerations

Obviously needs to be filled in...

Editorial Comments

Abstract

   This document describes an interface between mobile nodes (MN) and
   mobility access gateway (MAG)
Should be:
   This document describes an interface between mobile nodes (MN) and
   a mobility access gateway (MAG)

   The interface has two functions which
   are invocated when a MN attaches and detaches from a MAG.
Should be:
   The interface has two functions which
   are invoked when a MN attaches and detaches from a MAG.

   The
   attachment function let the MAG authenticate the MN identifier,
Should be:
   The
   attachment function lets the MAG authenticate the MN identifier,

   and inform
   the MAG about the multicast listener state of the MN.
Should be:
   and informs
   the MAG about the multicast listener state of the MN.

   The detachment function let
Should be:
   The detachment function lets

1. Introduction

There is a paragraph here that is a copy of the Abstract.  Make
all the above changes to this paragraph as well.

   this document describe
Should be:
   this document describes

4. Interactions of NETLMM Architecture with Subnet and Link Models

   There has recently been protocol proposals
Should be:
   There have recently been protocol proposals

4.1. NETLMM Subnet Model

      A unique prefix MUST be assigned by the NETLMM fabric to each of
      the MN in the domain.
Should be:
      A unique prefix MUST be assigned by the NETLMM fabric to each of
      the MNs in the domain.

4.2. NETLMM Link Model

   they are attached to different link because
Should be:
   they are attached to different links because

5. Address Collision Considerations

   and conclude that it did not changed
Should be:
   and conclude that it did not change

   However, in NETLMM the link did changed.
Should be:
   However, in NETLMM the link did change.

   when the MN first attaches to the NETLMM domain and
   execute DAD
Should be:
   when the MN first attaches to the NETLMM domain and
   executes DAD

   If SEND is used, each MAG also need to know 
Should be:
   If SEND is used, each MAG also needs to know 

6. MN_ATTACH Function

   The MN_ATTACH function is invocated by the MN
Should be:
   The MN_ATTACH function is invoked by the MN

6.1. MAG_GET_MN_ID Sub-function

   the MN initiate 
Should be:
   the MN initiates

   the MAG MUST sollicit 
Should be:
   the MAG MUST solicit 

   If these verifications succeeds, 
Should be:
   If these verifications succeed,

6.2. MN_GET_ADDR_PARMS Sub-function

   the MN_GET_ADDR_PARMS at the new MAG MUST must not change
Should be:
   the MN_GET_ADDR_PARMS at the new MAG MUST not change 

6.4. MAG_GET_MN_MCAST_GROUPS Sub-function

   A newly attached MN will
   then reports its Multicast Address Listening
Should be:
   A newly attached MN will
   then report its Multicast Address Listening

7. MN_DETACH Function

   When such link layer are used,
Should be:
   When such a link layer is used,

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Aug 2007 14:46:39 -0700

Hi Pete,

McCann Peter-A001034 wrote:

> handoff?  

Point-to-point links do not imply PPP.

> This will need to be hidden from upper layer

But that would mean special considerations (and special text) for each 
type of point-to-point link.

Vijay

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 13 Aug 2007 17:50:54 -0400

Hi, Vijay,

Vijay Devarapalli wrote:
>> Because we are assuming a ptp link model, is it fair to say that PPP
>> will be re-established at every MAG-to-MAG handoff?
> 

Can you give me an example of another that is widely deployed?

>> This will need to be hidden from upper layer applications.  The time
>> required to re-negotiate PPP is non-trivial.  A completely unmodified
>> host might break application socket connections when this happens. 
>> It might be worthwhile to write a few sentences about this.
> 
> But that would mean special considerations (and special text) for
> each type of point-to-point link. 

Maybe just some text that talks about link establishment in
general terms could be crafted.

-Pete

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Aug 2007 14:56:50 -0700

> Can you give me an example of another that is widely deployed?

Probably none. But we know for a fact that SDOs that are considering 
PMIPv6 either never had PPP or are moving away from PPP. 802.16e is an 
example of p2p link when PMIPv6 may be used. There are some scenarios in 
3GPP where an IPsec tunnel provides the p2p link between the mobile node 
and the MAG.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 13 Aug 2007 17:32:16 -0500

Hi Pete,

> Can you give me an example of another that is widely deployed?

1. PDP contexts in GPRS is another example of a PtP link between the MN and
AR.
2. For IPv6 operation over 802.16, we are emulating a PtP link between the
MN and AR as well. This PtP link is also not PPP. For details on this refer
to:  draft-ietf-16ng-ipv6-over-ipv6cs-09.txt

-Raj

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 14 Aug 2007 10:21:44 -0400

Basavaraj Patil wrote:
> 1. PDP contexts in GPRS is another example of a PtP link between the
> MN and AR. 

Here I know that PDP contexts are very stateful and there will
be a connection setup protocol to bring the link up on a new
GGSN.

> 2. For IPv6 operation over 802.16, we are emulating a PtP link
> between the MN and AR as well. This PtP link is also not PPP. For
> details on this refer to:  draft-ietf-16ng-ipv6-over-ipv6cs-09.txt 

Is there a notion of a "connection" here as well?  (Haven't read
the draft).

I was suggesting that we put in a statement such as the following:

   On most point-to-point links, there is a connection setup
   protocol in which the MN participates.  Semantically, the
   old connection goes down and then the new connection comes
   up.  This link down / link up must be hidden from transport
   protocols to avoid session termination.

-Pete

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Aug 2007 07:47:34 -0700

>    protocols to avoid session termination.

This is kind of obvious, but I am fine with adding this sentence to the 
MN-AR draft.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 14 Aug 2007 12:00:31 -0500

Hi Pete,

> be a connection setup protocol to bring the link up on a new

True.

> Is there a notion of a "connection" here as well?  (Haven't read

A notion of "connection" does exist. In 802.16 there exists what is called
as a "Transport Connection" between the MN and the BS. It is identified by a
Connection Identifier (CID). In the case of IP Convergence sublayer, the IP
stack runs over it and packets are carried via the L2 "Transport
Connection". 

>    protocols to avoid session termination.

Hmmm... Basically this would imply that the host would have to do something
special to deal with the MN changing interfaces (links). To hide the link
down/up from the IP stack to ensure session continuity will mean that there
is an impact to the host (MN). So in principle, Netlmm does not want to have
any impacts to the host. The text that you propose above would imply
otherwise and hence may not be acceptable.

-Raj

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 14 Aug 2007 13:24:00 -0400

Hi, Raj,

Basavaraj Patil wrote:
> Hmmm... Basically this would imply that the host would have to do
> something special to deal with the MN changing interfaces (links). To
> hide the link down/up from the IP stack to ensure session continuity
> will mean that there is an impact to the host (MN). So in principle,
> Netlmm does not want to have any impacts to the host. The text that
> you propose above would imply otherwise and hence may not be
> acceptable.      

Without this "change", transport connections will be blown 
away on every MAG-to-MAG handoff.  This makes netlmm pointless.
I thought the idea was to completely hide mobility events
from applications running on the host.

One way to avoid making any changes is to terminate L2 on the
LMA instead of the MAG.  However, that would make the MAG
into a L2 bridge and probably make netlmm out of scope for
the IETF.

-Pete

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Aug 2007 10:28:13 -0700

Well, rather than making it a host requirement, it should be worded as 
if it is a deployment requirement. If the link layer setup is going to 
take too long such that your application breaks, then NETLMM is not 
really suited for those link layers.

Vijay

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 14 Aug 2007 13:34:30 -0400

I believe that when you try to do a send() on a socket
and the interface is down, that call will immediately
return an error.  From cdma2000 deployments, we see
that PPP can easily take several seconds to complete.
A VOIP application (even though sending over UDP) would
then immediately break.  Even a TCP application might
try to send a packet in the interim before the new link
is up.

Vijay Devarapalli wrote:
> Well, rather than making it a host requirement, it should be worded
> as if it is a deployment requirement. If the link layer setup is
> going to take too long such that your application breaks, then NETLMM
> is not really suited for those link layers.   

I think this approach would result in NETLMM being suitable
for no real link layer at all.  Maybe that's true.

-Pete

>>> something special to deal with the MN changing interfaces (links).
>>> To hide the link down/up from the IP stack to ensure session
>>> continuity will mean that there is an impact to the host (MN). So
>>> in principle, Netlmm does not want to have any impacts to the host.
>>> The text that you propose above would imply otherwise and hence may
>>> not be acceptable.
>> 
>> Without this "change", transport connections will be blown away on
>> every MAG-to-MAG handoff.  This makes netlmm pointless.
>> I thought the idea was to completely hide mobility events from
>> applications running on the host.
>> 
>> One way to avoid making any changes is to terminate L2 on the LMA
>> instead of the MAG.  However, that would make the MAG into a L2
>> bridge and probably make netlmm out of scope for the IETF.
>> 
>> -Pete

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Aug 2007 10:47:05 -0700

McCann Peter-A001034 wrote:
> return an error.  

This is implementation specific. A typical implementation should not 
transition to a "link down" event that would result in a socket error 
during a handover. This would cause problems even for Mobile IP. If 
there is no CoA to use, there is nowhere, inside the IP stack, to send 
the packets to.

Vijay

> From cdma2000 deployments, we see

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Aug 2007 10:48:23 -0700

A minor correction below...

I wanted to say "A typical implementation would not transition...."

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 14 Aug 2007 13:59:27 -0500

Hi Pete,

On 8/14/07 12:24 PM, "ext McCann Peter-A001034" <[email-masked]>
wrote:

> away on every MAG-to-MAG handoff.

Raj> In the case of a MAG-to-MAG handover, but the MN still continuing to
use the same Physical interface would not be a problem. So within the
context of a single access type, I do not see MAG-to-MAG handovers being a
problem. The address (prefix) assigned to the interface does not change and
hence upper layer protocols and apps would survive the HO. Link
establishment of course depends on the link types and other factors. But the
link establishment can be optimized via various methods that I guess we do
not need to discuss here.

The problem that I see is when you do a MAG-to-MAG handover and the physical
interface on the host changes. Unless you are able to hide the physical
interfaces to which the addresses are associated with from the upper layers,
it will cause a reset. This is an issue that has to be dealt with by the
hosts and hence IMO an impact to the host.

> This makes netlmm pointless.

Raj> Well, the intent is to hide mobility events from the IP stack itself on
the host. And the constraint is to do so without requiring the host to do
anything special. This works quite well within the context of mobility of a
host for a single access type or interface. The problems arise when we start
considering mobility across heterogeneous access types and use of different
physical interfaces on the host.
> LMA instead of the MAG.

Raj> I do not think this is an option. This would basically be equivalent to
the GPRS model.

-Raj

> However, that would make the MAG

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 14 Aug 2007 14:06:44 -0500

Vijay,

In the case of Mobile IP, a typical implementation would ensure the
applications are unaware of the change of link or CoA and hence would not be
an issue. A link-down-up event would/may cause a change of CoA, but does not
affect the HoA and hence this issue that we are discussing here would not
arise.

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Aug 2007 12:17:29 -0700

> affect the HoA and hence this issue that we are discussing here would not

Not really. If your physical interface is down (and no CoA available), 
the IP stack wouldn't know what to do with the packets that the 
application is sending. You could buffer some, but the buffers are 
typically very small. The IP stack can either drop them or tell the 
application to stop.

Vijay

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 14 Aug 2007 17:35:03 -0400

Hi, Raj,

Basavaraj Patil wrote:
>> every MAG-to-MAG handoff.
> 
> Raj> In the case of a MAG-to-MAG handover, but the MN still continuing
> Raj> to
> context of a single access type, I do not see MAG-to-MAG handovers
> being a problem. The address (prefix) assigned to the interface does
> not change and hence upper layer protocols and apps would survive the
> HO.  

On the contrary, even though the IP address is the same before
and after the handoff, there is a period of time while the new
link is coming up when the interface is down.  An off-the-shelf
host would respond to application send() requests with an error.
This will bring down connections.  We need to make sure that
mobile nodes are implemented in such a way to hide this period
of interruption from applications.

> Link establishment of course depends on the link types and other
> factors. But the link establishment can be optimized via various
> methods that I guess we do not need to discuss here.      

The main thing that most link types do is to implement layer 2
tunneling so that the p2p link doesn't need to be re-established.

> The problem that I see is when you do a MAG-to-MAG handover and the
> physical interface on the host changes. Unless you are able to hide
> the physical interfaces to which the addresses are associated with
> from the upper layers, it will cause a reset. This is an issue that
> has to be dealt with by the hosts and hence IMO an impact to the
> host.     

Definitely, this case has a host impact.
 
> Raj> Well, the intent is to hide mobility events from the IP stack
> Raj> itself on
> the host. And the constraint is to do so without requiring the host
> to do anything special. This works quite well within the context of
> mobility of a host for a single access type or interface. The
> problems arise when we start considering mobility across
> heterogeneous access types and use of different physical interfaces
> on the host.     

I think there are problems even for a single link technology.

>> instead of the MAG.
> Raj> I do not think this is an option. This would basically be
> Raj> equivalent to
> the GPRS model.

Yes, and the 3GPP2 model.  I think these sorts of interfaces
are best left to the SDOs and are not the purview of IETF.

-Pete

>> into a L2 bridge and probably make netlmm out of scope for the IETF.
>> 
>> -Pete

---

From: Julien Laganier <[email-masked]>
Date: Wed, 15 Aug 2007 02:23:03 +0200

Hi Peter, 

Thanks for the review! Reply to your techical comments 
inlined below. Editorial comments will be addressed in 
the next revision of the draft.

On Monday 13 August 2007, McCann Peter-A001034 wrote:
> Technical Comments
>
> 2. Terminology
>
>    Network-based Localized Mobility Management
> Domain (NETLMM domain) an administrative domain
> spanning links served by a set of LMAs (and their
> associated MAGs and MNs) that provision addresses
> from the same IP subnet prefix(es).
> Is it really necessary for all LMAs to use the same
> set of prefixes? I can imagine deployments where
> different LMAs have different points of connectivity
> to the Internet and so would use different prefixes.

You're right. That is a leftover from a previous 
version. 

> to say that PPP will be re-established at every
> MAG-to-MAG handoff?

The P-t-P link model is not limited to PPP, there's 
other types of lower layers which provide a P-t-P link 
model (e.g. IEEE 802.16, 3GPP GPRS).

w.r.t. PPP yes it probably means that PPP will need to 
be re-established (unless some out-of-scope context 
transfer techniques are used).

> applications.  

Since IP is in between the link layer and the upper 
layer protocols/applications, as long as IP does not 
unconfigure the IP address in use the application or 
protocol is going to be fine. 

When the link goes down and up the stack might let the 
upper layers still use the previous addresses while it 
is trying to reconfigure the IP address (through e.g. 
DHCP, or SLAAC). When the IP address is eventually 
reconfigured it will be the same as previously so 
upper layers will not be affected. This should not be 
treated differently than a transient loss of wireless 
connectivity.

Also, DNAv6 specifies what an IP layer should do when a 
link up event is received from the link layer: tries 
to detect if the link changed or not based on prefixes 
available on that link (via RS/RA exchange). In the 
NETLMM case DNAv6 will conclude the link did not 
change since the announced prefixes remains constant. 
In that case DNAv6 specifies that the MN retain its IP 
address(es). Hence upper layers are unaffected.

> The time required to re-negotiate PPP is non-trivial.

That is right.

> A completely unmodified host might break application
> socket connections when this happens.  

Not if the stack tries to gracefully re-establish its 
context before failing application communications. If 
the context can't be re-established and a new one is 
created (with new IP address) then it is time for the 
stack to fail communications of applications (e.g. 
EADDRNOTAVAIL).

A completely unmodified host might still implement good 
common sense. A host with DNAv6 will just works fine. 
I also happen to think that a host which is expected 
to move will ship with DNA support even though it has 
no MIPv6 support. This makes sense since it allows the 
host to preserve ongoing communications when no 
movement occurred but a link_down/link_up sequence 
occured for whatever reason (transient loss of signal 
while staying on same AP, or NETLMM handover).

> It might be worthwhile to write a few sentences about

What I'd really like to write is: This interface 
assumes that the host implements minimal support for 
nomadicity, i.e. DNAv6.

> MN_GET_ADDR_PARMS seems to assume that the MAG makes
> up the IPv6 subnet prefix and then registers it with
> the LMA.  Doesn't it make more sense to have the LMA
> generate the prefix, and then send it to the MAG/MN?

What I wanted to express in that section is that the 
MAG provides the MN with the necessary parameters to 
form an address. Parameters could be a prefix (SLAAC) 
or an address (DHCP). I didn't want to imply anything 
about where the parameters come from.

Maybe you can point me to the confusing sentence.

> It is stated here that IPv6CP can configure a
> default router.  I do not think this is true.  Only
> the RS/RA can configure a default router.

This is right. I mixed with IPCP.

> Obviously needs to be filled in...

Sure! That is to come once the rest of the document has 
solidified (and I keep security in mind while writing 
other parts of the doc).

Thanks for the editorial below, I'll address them in 
next rev of the doc.

> [...]

Thanks again.

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 15 Aug 2007 02:30:18 +0200

On Tuesday 14 August 2007, Vijay Devarapalli wrote:
> Basavaraj Patil wrote:
> > Vijay,
> >
> > In the case of Mobile IP, a typical implementation
> > would ensure the applications are unaware of the
> > change of link or CoA and hence would not be an
> > issue. A link-down-up event would/may cause a
> > change of CoA, but does not affect the HoA and
> > hence this issue that we are discussing here would
> > not arise.
>
> Not really. If your physical interface is down (and
> no CoA available), the IP stack wouldn't know what
> to do with the packets that the application is
> sending. You could buffer some, but the buffers are
> typically very small. The IP stack can either drop
> them or tell the application to stop.

On a host that is mobile (e.g. has wireless), the best 
thing to do for a stack is to drop them while it's 
trying to bring the interface up again. If that fails, 
or the address changed, then the stack can tell the 
application to fail. If the interface comes up with 
the same IP address then the stack can resume sending 
packets.

If a host doesn't do that applications are going to 
fail whenever you do a L2 handoff but remains under 
same access router. That would be a bad 
implementation.

I think that is a generic problem for mobile hosts, and 
not limited to NETLMM. 

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 15 Aug 2007 02:34:17 +0200

On Tuesday 14 August 2007, McCann Peter-A001034 wrote:
> > 1. PDP contexts in GPRS is another example of a
> > PtP link between the MN and AR.
>
> Here I know that PDP contexts are very stateful and
> there will be a connection setup protocol to bring
> the link up on a new GGSN.
>
> > 2. For IPv6 operation over 802.16, we are
> > emulating a PtP link between the MN and AR as
> > well. This PtP link is also not PPP. For details
> > on this refer to: 
> > draft-ietf-16ng-ipv6-over-ipv6cs-09.txt
>
> Is there a notion of a "connection" here as well? 
> (Haven't read the draft).
>
>    On most point-to-point links, there is a
> connection setup protocol in which the MN
> participates.  Semantically, the old connection goes
> down and then the new connection comes up.  This
> link down / link up must be hidden from transport

I don't think we should include that text in the MN-AR 
interface. What a stack should do upon 
link-up/link-down is either:

- out-of-scope if the events are hidden at the link 
layer.
- in the scope of the DNAv6 working group if the events 
are hidden at the network layer.

So either we do not write anything (L2 scope) or we 
write that the host has to implement DNA. I actually 
happens to think that any reasonable nomadic/wireless 
host software vendor should implement DNA.

--julien

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 15 Aug 2007 23:36:06 -0700

Hi Pete,

Taking the ppp example, if context transfers are in place, I'd 
expect the inter MAG session handoff to handle the ppp context
transfer. Effectively, the session/link is carried to the new MAG
and hence there should not be any link state changes on the other
end of the link. 

I agree, we need to make sure there is no impact on the session
on the mobile node, at the time of handoff. 

I can only say, context transfer is the way to solve this issue,
as supposed to L2 termination on the LMA. But, we dont deal with
CT in the base spec. This issue was thought out and certainly,
some guidance is required for various operating environments or
link types. But, keeping the protocol neutral, additional specs
corresponding to each access link, can provide some guidance on
this issue, IMO.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Aug 2007 14:47:19 +0200

Vijay Devarapalli wrote:
>>>> Because we are assuming a ptp link model, is it fair to say 
>>>> that PPP will be re-established at every MAG-to-MAG handoff?
> PMIPv6 either never had PPP or are moving away from PPP. 802.16e is 
> an example of p2p link when PMIPv6 may be used.

In a MN-AR interface document it is essential to describe what kind of
point-to-point implementation is used, right?

There may be some interactions with the 16ng document on this topic as well.

FYI, there exist a wireshark profile displaying 802.16 MN-AR exchanges
according to the 802.16 spec.  However, from what I know, that has only
been used on emulators, and not on real 802.16 systems deployed.  The
underlying ptp link was emulated on Ethernet MAC by a well-known 802.16
supporter and on UDP  connection by somebody else.

If you are aware of other MN-AR systems which are not emulated (either
by Ethernet MAC, by UDP or by IPsec) - it will be very useful for the
netlmm MN-AR interface document.

> There are some scenarios in 3GPP where an IPsec tunnel provides the 
> p2p link between the mobile node and the MAG.

Can this be described somehow?

I think IPsec tunnel being the ptp interface has a lot of consequences
on all descriptions of 802.16 link and 16ng document.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Aug 2007 14:47:55 +0200

> to:  draft-ietf-16ng-ipv6-over-ipv6cs-09.txt

It is _not_ PPP then it is what?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Aug 2007 14:50:38 +0200

McCann Peter-A001034 wrote:
>> 1. PDP contexts in GPRS is another example of a PtP link between
>> the MN and AR.
> 
> Here I know that PDP contexts are very stateful and there will be a
> connection setup protocol to bring the link up on a new GGSN.
> 
> Is there a notion of a "connection" here as well?  (Haven't read the
> draft).
> 
> On most point-to-point links, there is a connection setup protocol in
> which the MN participates.  Semantically, the old connection goes
> down and then the new connection comes up.  This link down / link up
> must be hidden from transport protocols to avoid session termination.
> 
I agree that when trying to do handovers with an interface that we don't
know whether it's emulated  or other kind we can run the risk of tearing
the interface down when changing MAG, unless special precaution is taken.

I know also that ppp connections used normally will break down upon
connection establishment, sockets forcefully reset, apps broken, etc,
unless special option is used.  That option is necessary when doing
handovers with ppp-over-ethernet for example.

Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Aug 2007 14:54:22 +0200

Vijay Devarapalli wrote:
>> I believe that when you try to do a send() on a socket and the
>> interface is down, that call will immediately return an error.
> 
>  transition to a "link down" event that would result in a socket
> error during a handover. This would cause problems even for Mobile
> IP.

MIP uses IPinIP tunnel interface that stays up all the time with the mip
daemon dynamically changing its parameters.

When one tries to implement 802.16 MN-AR interface one typically finds
him/herself with a few options that offer interfaces that typically
don't have the characteristic of staying up uppon handover.

I'm not sure why you mention MIP behaviour here... it has nothing to do.
MIP uses virtual interfaces whereas on netlmm we consider real
interfaces, I hope.

Alex

  If
> there is no CoA to use, there is nowhere, inside the IP stack, to
> send the packets to.
> 
> Vijay
> 
>> From cdma2000 deployments, we see that PPP can easily take several
>> seconds to complete. A VOIP application (even though sending over
>> UDP) would then immediately break.  Even a TCP application might 
>> try to send a packet in the interim before the new link is up.
> 
> 
>> Vijay Devarapalli wrote:
>>> Well, rather than making it a host requirement, it should be
>>> worded as if it is a deployment requirement. If the link layer
>>> setup is going to take too long such that your application
>>> breaks, then NETLMM is not really suited for those link layers.
>>> 
>> 
>> I think this approach would result in NETLMM being suitable for no
>> real link layer at all.  Maybe that's true.
>> 
>> -Pete
>> 
>>> Vijay
>>> 
>>>>> Hmmm... Basically this would imply that the host would have
>>>>> to do something special to deal with the MN changing
>>>>> interfaces (links). To hide the link down/up from the IP
>>>>> stack to ensure session continuity will mean that there is an
>>>>> impact to the host (MN). So in principle, Netlmm does not
>>>>> want to have any impacts to the host. The text that you
>>>>> propose above would imply otherwise and hence may not be
>>>>> acceptable.
>>>> Without this "change", transport connections will be blown away
>>>> on every MAG-to-MAG handoff.  This makes netlmm pointless. I
>>>> thought the idea was to completely hide mobility events from 
>>>> LMA instead of the MAG.  However, that would make the MAG into
>>>> a L2 bridge and probably make netlmm out of scope for the IETF.
>>>> 
>>>> 
>>>> -Pete
>> 
> 
> 
>

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 20 Aug 2007 09:17:37 -0500

Hi Alex,

> It is _not_ PPP then it is what?

PPP is a protocol implementation as per RFC 1661. 802.16 has a MAC which
includes convergence sublayers (various) that is used for the transmission
of IP packets. The "transport connection" between the MS and BS forms a PtP
link. The point is PPP as per RFC1661 is not used below the IP layer in .16
for the transmission of IP packets.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Aug 2007 16:38:26 +0200

> Hi Alex,

Hi Raj, thank you for the reply.

[...]
>>> 1. PDP contexts in GPRS is another example of a PtP link between

Yes, but we don't consider GPRS as a candidate for netlmm deployment, I
think we agree...

>>> draft-ietf-16ng-ipv6-over-ipv6cs-09.txt

Please be more specific, I can't seem to find in that draft what do you
actually use to transport the 802.16 frames.  Do you use Ethernet MAC?
Do you use UDP?  Other?

You keep saying it's not ppp and at the same time you avoid saying what
you transport these frames on.

Sorry, but that is my understanding when reading, and no offence intended.

> PPP is a protocol implementation as per RFC 1661. 802.16 has a MAC
> which includes convergence sublayers (various) that is used for the
> transmission of IP packets. The "transport connection" between the MS
> and BS forms a PtP link. The point is PPP as per RFC1661 is not used
> below the IP layer in .16 for the transmission of IP packets.

This is too evasive for a MN-AR interface document, IMHO.

What do you mean by "PPP as per rfc1661 is not used below the IP layer
in .16 for the transmission of IP packets"?

Do you mean that your emulation doesn't use ppp?

Do you mean that .16 ieee spec doesn't use ppp?

Do you mean that a wimax pcmcia card that can be bought on the market
today doesn't use ppp? (there are at least two on the consumer market).

My emulation _does_ use ppp.  Actually I have several such emulators and
several of them use ppp, under different forms: ppp-over-ethernet,
ppp/vtun, ppp/vtun/sshd, etc.  Other emulators I have don't use ppp, but
udp virtual tunnels, or even straight Ethernet MAC.

There are also at least two possible ways to deploy this: MN-CPE-AP or
MN-AP.  How is your transport protocol run?  Between CPE and AP?  Or
between MN and AP?

These are relevant things to describe in the MN-AR interface document.
In my humble oppinion.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 20 Aug 2007 10:15:10 -0500

Hi Alex,

Inline:

> Yes, but we don't consider GPRS as a candidate for netlmm deployment, I

Yes.

> actually use to transport the 802.16 frames.  Do you use Ethernet MAC?

802.16 frames??? Well... Please refer to the 802.16 spec for the operation
of the PHY which explains how the 802.16 MAC frame is sent over the air. It
is not Ethernet MAC. Very simplistically stated, the IP packet is
encapsulated by a .16 MAC header and then transmitted over the air by the
PHY (coding/modulation schemes that are specific). So there is no question
of Ethernet MAC or UDP. It is Other in the list of your choices above.
Anyway the encoding of the MAC frame over-the-air is an L1 function that is
not really within the IETFs domain.

> you transport these frames on.

Okay... Let me try again.... The IP stack (L3) interfaces to the IP
convergence sublayer of the 802.16 MAC (L2). The 802.16 frame that is
created by the CS which includes the IP packet (payload) encapsulated by a
.16 MAC header is transmitted by the PHY (L1). That's it...

Anyway, I am not sure if this thread makes sense in the netlmm WG at all.
For a second there I thought this was on the 16NG ML ;)

> Sorry, but that is my understanding when reading, and no offence intended.

None taken... I am just wondering where the confusion is arising....

> in .16 for the transmission of IP packets"?

See above..

> Do you mean that your emulation doesn't use ppp?

There is no emulation.

> Do you mean that .16 ieee spec doesn't use ppp?

Yes.

> today doesn't use ppp? (there are at least two on the consumer market).

I don't know of any "WiMAX" pc cards that exist today. There may be .16d CPE
boxes but I don't know of any pc cards that you are talking about.

> udp virtual tunnels, or even straight Ethernet MAC.

Okay... 

> These are relevant things to describe in the MN-AR interface document.

I guess the MN-AR authors can respond.

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 20 Aug 2007 08:15:58 -0700

Alexandru Petrescu wrote:
>> example of p2p link when PMIPv6 may be used.
> 

Proxy Mobile IPv6 is intended for use on various kinds of p2p links. The 
MN-AR interface document currently assumes a generic p2p link with a few 
assumptions. I think this is the right approach.

> netlmm MN-AR interface document.

Why is this relevant?

> Can this be described somehow?

In the document, why?

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Mon, 20 Aug 2007 17:40:11 +0200

Hi Alex,

On Monday 20 August 2007, Alexandru Petrescu wrote:
> > Probably none. But we know for a fact that SDOs that are
> > considering PMIPv6 either never had PPP or are moving away from
> > PPP. 802.16e is an example of p2p link when PMIPv6 may be used.
>
> In a MN-AR interface document it is essential to describe what kind
> of point-to-point implementation is used, right?

Actually exactly the contrary :)

In this MN-AR interface we try to abstract as much as possible from the 
details of the underlying point-to-point link that we assume. 

That allows to keep the interface as generic as possible, which expand 
its applicability. That is, the best description of the point-to-point 
link for which the interface is described is that it is, well, 
point-to-point.

In case we need to make additional assumptions on the underlying link to 
make the interface viable (for example that packets needs to be 
delivered in-order -- that's is just a random example), then that 
certainly need to be documented in the interface.

So far, it is unclear whether any other assumptions should be made on 
the underlying link on which the interface would work.
 
Then the specifics of what kind of support would be needed on the 
interface to optimize behavior on specific link layers are out-of-scope 
of that document (IMHO they belong either in other drafts, or in 
documents from SDOs in charge of these link layers).

> There may be some interactions with the 16ng document on this topic

I don't see which.

[...]

> Can this be described somehow?

Why? Why would that belong to that document?

> I think IPsec tunnel being the ptp interface has a lot of
> consequences on all descriptions of 802.16 link and 16ng document.

Here I'm completely lost... What's the relation between IPsec, IEEE 
802.16 and 16ng docs?!

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Aug 2007 18:09:05 +0200

Basavaraj Patil wrote:
>>>>> 2. For IPv6 operation over 802.16, we are emulating a PtP
>>>>> link between the MN and AR as well. This PtP link is also not
>>>>> PPP. For details on this refer to: 
>> Please be more specific, I can't seem to find in that draft what do
>> you actually use to transport the 802.16 frames.  Do you use
>> Ethernet MAC? Do you use UDP?  Other?
> 
> 802.16 frames??? Well... Please refer to the 802.16 spec for the
> operation of the PHY which explains how the 802.16 MAC frame is sent
> over the air. It is not Ethernet MAC. Very simplistically stated, the
> IP packet is encapsulated by a .16 MAC header and then transmitted
> over the air by the PHY (coding/modulation schemes that are
> specific). So there is no question of Ethernet MAC or UDP. It is
> Other in the list of your choices above. Anyway the encoding of the
> MAC frame over-the-air is an L1 function that is not really within
> the IETFs domain.

Right, that's what the 802.16 standard says.

>> You keep saying it's not ppp and at the same time you avoid saying
>> what you transport these frames on.
> 
>  created by the CS which includes the IP packet (payload)
> encapsulated by a .16 MAC header is transmitted by the PHY (L1).
> That's it...
> 
> Anyway, I am not sure if this thread makes sense in the netlmm WG at
> all. For a second there I thought this was on the 16NG ML ;)

Well I think it makes sense for the MN-AR interface document.  I think
it makes sense that this MN-AR interface document works in tandem with
the 16ng documents.

I think netlmm pmipv6 protocol is designed for wimax and 3gpp2...

I think overall it makes no sense at all to discard the use of ppp from
pmipv6... at least because we didn't see anybody with a deployment
saying they don't use ppp.

We've seen people referring to standard documents, people with
prototypes and emulators and people with past 3G experience.  But we
haven't seen anybody with a more real 802.16/wimax deployment saying
they don't use ppp.

> None taken... I am just wondering where the confusion is arising....

Yes, sorry, I think there may be some confusion until wimax gets
deployed more widely.

[...]
>> Do you mean that a wimax pcmcia card that can be bought on the
>> market today doesn't use ppp? (there are at least two on the
>> consumer market).
> 
> I don't know of any "WiMAX" pc cards that exist today. There may be
> .16d CPE boxes but I don't know of any pc cards that you are talking
> about.

There are some since several months now, it's sufficient to google them.

[snip]

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Aug 2007 18:14:40 +0200

Hi Vijay,

Vijay Devarapalli wrote:
> Proxy Mobile IPv6 is intended for use on various kinds of p2p links.
> The MN-AR interface document currently assumes a generic p2p link
> with a few assumptions. I think this is the right approach.

I'm sorry, this is nonsense to me.  It is nonsense to talk about
"generic" p2p links when real p2p links have real characteristics with
real implementations.  There exist indeed several types of such ptp
links (and only some are with ppp).

This comes to mind at least when we talk handover.  Anyone who tried in
practice to hand-over a ptp link between two anchors has realized that
things apps may not survive.  HEnce that ppp recommendation Pete talked
about, to which I agree.

If we stay with "generic" ptp links then we can not make any particular
recommendation with respect to PMIPv6 protocol and netlmm handovers.

>> FYI, there exist a wireshark profile displaying 802.16 MN-AR
>> exchanges according to the 802.16 spec.  However, from what I know,
>> that has only been used on emulators, and not on real 802.16
>> systems deployed.  The underlying ptp link was emulated on Ethernet
>> MAC by a well-known 802.16 supporter and on UDP  connection by
>> somebody else.
>> 
>> If you are aware of other MN-AR systems which are not emulated
>> (either by Ethernet MAC, by UDP or by IPsec) - it will be very
>> useful for the netlmm MN-AR interface document.
> 
> Why is this relevant?

What are people going to do with the MN-AR interface document?  Are they
going to implement?  Something generic?

>>> There are some scenarios in 3GPP where an IPsec tunnel provides
>>> the p2p link between the mobile node and the MAG.
>> 

Such that people can implement it?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 20 Aug 2007 18:18:54 +0200

Hi Julien,

Julien Laganier wrote:
> In this MN-AR interface we try to abstract as much as possible from
> the details of the underlying point-to-point link that we assume.
> 
> That allows to keep the interface as generic as possible, which
> expand its applicability. That is, the best description of the
> point-to-point link for which the interface is described is that it
> is, well, point-to-point.
> 
> In case we need to make additional assumptions on the underlying link
> to make the interface viable (for example that packets needs to be 
> interface to optimize behavior on specific link layers are
> out-of-scope of that document (IMHO they belong either in other
> drafts, or in documents from SDOs in charge of these link layers).

I think I understand what you mean, but in this case I can't say I
personally agree with the goal and purpose of this document.  I don't
see why writing such a document at all.  Take it as just one oppinion,
sorry and I'll shut up here.

>> There may be some interactions with the 16ng document on this topic

Come on :-) pmipv6 is for wimax and 3gpp2.  16ng is for wimax.  So
pmipv6 should work with 16ng, right?

Some people keep saying netlmm protocol should stay independent from the
access link but at the same time there is nothing neither in pmipv6 nor
in MN-AR interface that is not wimax :-)

Alex