Subject: [DMM] DMM Interim call #2 - agenda forming

From: Jouni Korhonen <[email-masked]>
Date: Wed, 10 Sep 2014 21:02:47 +0300

It seems I sent this to a wrong receiver.. that explains why it did not 
appear on the list.

- Jouni

-------- Alkuperäinen viesti / Orig.Msg. --------
Aihe: DMM Interim call #2 - agenda forming
Päiväys: Mon, 08 Sep 2014 23:43:24 +0300
Lähettäjä: Jouni Korhonen <[email-masked]>
Vastaanottaja: [email-masked]
CC: [email-masked], Dapeng Liu <[email-masked]>

Folks,

The next interim is close. Assuming there are no overwhelming amount of
comments to the re-charter text, we are ready to start setting up the
work split on the solution space! Remember the discussion and the
minutes from the IETF#90 Friday session. No other agenda items are
planned for the next interim.

- Jouni & Dapeng

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Sep 2014 13:06:39 -0500

Jouni, why don't we cancel this one (#2) and do the next one (#3) with
an agenda?
I hope Alper can attend :-)

Regards,

Behcet

On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen <[email-masked]> wrote:
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 10 Sep 2014 21:36:46 +0300

What do you mean by no agenda? To me it clearly says we use the call #2 
for setting up the work split.

- Jouni

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Sep 2014 18:43:59 +0000

Hi Jouni,

I'd like to propose a slightly different charter:

  "AERO already solves distributed mobility management and provides a
   a comprehensive mobility solution for any mobile device. AERO should
   therefore be approved as the mobility management solution for DMM.
   Publication of AERO will therefore conclude the working group's
   activity."

Can we have this on the agenda?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Jouni Korhonen
> Sent: Wednesday, September 10, 2014 11:37 AM
> To: [email-masked]
> Cc: Dapeng Liu; [email-masked]
> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> 
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Sep 2014 14:04:33 -0500

This is what I saw in your mail:

No other agenda items are
planned for the next interim.

On Wed, Sep 10, 2014 at 1:36 PM, Jouni Korhonen <[email-masked]> wrote:
>
> What do you mean by no agenda? To me it clearly says we use the call #2 for
> setting up the work split.
>
> - Jouni
>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 10 Sep 2014 22:12:46 +0300

Fred,

We'll prioritize the work split we discussed in IETF90. If we have time 
left, we can look into other topics.

- Jouni

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Sep 2014 20:07:25 +0000

Hi Jouni,

> From: Jouni Korhonen [mailto:[email-masked]]
> Sent: Wednesday, September 10, 2014 12:13 PM
> To: Templin, Fred L; [email-masked]

Well, let's discuss this for a moment though. We have already seen
one case in which AERO can be used where MIP-based solutions are
deficient, i.e., in enterprise networks. But "enterprise networks"
could encompass a very broad range of applications, including not
only corporate enterprises, but also academic campuses, air traffic
management networks, operator networks, ISP networks, etc.

Like MIP, the default mode of operation for AERO requires a piece
of critical infrastructure. For MIP, it is the Home Agent. For
AERO, it is the AERO Server.

AFAICT, therefore, an AERO Server can be placed anywhere a MIP Home
Agent could be placed. Hence, the AERO service can be offered in
any environment in which a MIP service could be offered.

So looking at the services that already come in-built in the AERO 
architecture (distributed mobility management, mobile networks,
route optimization, mobile VPN, accommodation of any IP version,
no kernel changes needed, etc.) there would seem to be some
points for comparison to discuss before a solution is chosen.

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 10 Sep 2014 22:01:50 +0000

Hi Fred,

IMHO, DMM solution need to be tied to one specific protocol. We don't have
to battle this out and come up with one answer. Once we have high-level
view of the solution and the interfaces, its possible to realize those
interfaces using any protocols. You call it MIP, GTP, Aero ..does not
matter. The core specs can identify the interface requirements and the
specific protocol documents can publish extensions to the protocols. We
let the deployments make the call on the protocol choice.

Regards
Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Sep 2014 17:15:19 -0500

Hi Sri,

> let the deployments make the call on the protocol choice.

These are your views.
Not mine for sure.

Regards,

Behcet

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 10 Sep 2014 22:38:17 +0000

Hi Behcet,

Look for the qualifiers which states its an opinion. Don't just poke.
Goal is to converge - Read that.

If you disagree with this, I assume you want a debate on the protocol
choice. Go for it.

Sri

On 9/10/14 3:15 PM, "Behcet Sarikaya" <[email-masked]> wrote:

>>>> >> The next interim is close. Assuming there are no overwhelming
>>>>amount
>>>>of

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Sep 2014 22:47:08 +0000

Hi Behcet and Sri,

> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Wednesday, September 10, 2014 3:15 PM
> To: Sri Gundavelli (sgundave)
> Cc: Templin, Fred L; Jouni Korhonen; Dapeng Liu; [email-masked]

There are points of comparison between MIP and AERO that IMHO
should be taken under consideration. MIP has been around for a
long time, but AERO is not exactly new either. It has its genesis
from a long list of earlier RFCs including (in chronologic order):

http://www.rfc-editor.org/rfc/rfc2529.txt
http://www.rfc-editor.org/rfc/rfc4214.txt
http://www.rfc-editor.org/rfc/rfc5214.txt
http://www.rfc-editor.org/rfc/rfc5320.txt
http://www.rfc-editor.org/rfc/rfc5720.txt
http://www.rfc-editor.org/rfc/rfc6139.txt
http://www.rfc-editor.org/rfc/rfc6179.txt
http://www.rfc-editor.org/rfc/rfc6706.txt

I know a lot of people throughout the IETF and other forums have
put a tremendous amount of energy into MIP-based solutions, but
to my understanding the archetype for those solutions is still
based on a host that goes wandering from its home physical link
and requires the assist of a home agent on that physical link
to keep track of its current location.

Conversely, the archetype for AERO is a router that remains
connected to a virtual link configured over its home network no
matter where the router moves to. That means that it does not
matter which "agent" on the virtual link the router associates
with, and that is why AERO has already solved the DMM problem.  
 
> Not mine for sure.

I have heard you say this on multiple occasions, Behcet, and I
am beginning to wonder if you have a better understanding of the
situation than I do. But, I do believe solution alternatives
should be discussed rather than just marching forward without
considering new approaches.

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 10 Sep 2014 23:25:50 +0000

Fred,

I'm not suggesting Aero vs MIP debate. IMO, its simply not worth it. Each
of the protocols have certain properties, which helps in some use-cases
and may be inefficient for some other use-cases. But, you can make all of
them work, MIP, GTP, MOBIKE, AERO ... There is no silver bullet in any one
of them, unless some one can prove it. Some architectures are based on
fixed anchors and some such as LISP-based are based on floating anchors.
Solutions based on fixed anchors have properties that suits a SP
deployment;  a single point of charging, policy enforcement, LI support,
subscriber control but looses the aspect of optimized routing path. As an
example, "I've the best optimized path for my traffic, but my operator has
no clue where my traffic gets routed out". That works very well for some
cases and does not work for some other deployments. These are all points
of debate and each have to be measures on its own merit.
 
The choice of the protocol is also tied to the legacy and deployed
infrastructure. Many times its about an evolution. I do not know how many
people in this WG have been involved in the AERO protocol development, or
familiar with it, at least I'm not involved in its development. But, I'm
not against AERO or some thing else. If the discussion has to be about a
protocol selection and the approach of multiple options does not work,
then we should just only do that and call for a vote and settle that
matter. I'm suggesting an approach, where we avoid this protocol debate
and allow multiple options. I'm sure, that battle will be bitter and not
worth it.

Regards
Sri

On 9/10/14 3:47 PM, "Templin, Fred L" <[email-masked]> wrote:

>> >>> >> It seems I sent this to a wrong receiver.. that explains why it
>>did
>> >>>not
>> >>> >> appear on the list.
>> >>> >>
>> >>> >> - Jouni
>> >>> >>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 11 Sep 2014 00:13:54 +0000

Hi Fred,

Looking at other solution alternative, there is this proposal from
Satoru-san. 

http://www.ietf.org/id/draft-matsushima-stateless-uplane-vepc-03.txt

Will be good to know your views on how you see this approach compare with
Aero. 

Regards
Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 11 Sep 2014 07:28:14 +0000

Hi Fred,

The below comment from you made me thinking. I must admit I'm not much
familiar with Aero, have not seen its references in CDMA, WiMAX,
CableLabs, WLAN or LTE architectures.  But, if it has all the mobility
features and you believe this can conclude the WG, I thought I will
explore this a bit. I started reviewing the charts that you sent and
started browsing some of the specs. Few high-level questions, if you can
answer or point me to some documents, it will be great.

1.) What is the interface between the Aero Server and the client ? Is it
just DHCPv6 ? There is no other signaling interface ?

2.) What is the service authorization model for a Aero client ? How is the
client identified by the server ? What is the security model ?

3.) Can the Aero solution support IP nodes that do not have Aero client
stack ?

4.) If a mobile or a cable SP deploys Aero, where is their point of
control ? Where can they do Accounting, Lawful interception ?

5.) I assume Aero client can be IPv4 or an IPv6 device ? For an IPv4-only
legacy device, is the interface DHCPv4 ?

6.) Can an operator enable location-based services for a Aero client ?

7.) How can an operator enable IP Flow Mobility type features in an Aero
system ?

8.) Taking a mobile router scenario, how does Aero client support
multi-tenancy ? Is there a single tunnel between the client and the server
?

Regards
Sri

---

From: Alper Yegin <[email-masked]>
Date: Thu, 11 Sep 2014 11:41:54 +0300

Folks,

Here's a proposal for scoping out the DMM work and identifying areas to tackle.

http://yegin.org/NGmobility/IETF_DMM_WG_work_scoping.pptx

I can present this at the upcoming DMM call. It'd be very good if people can read and send comments/questions on the list in advance.

Cheers,

Alper

On Sep 10, 2014, at 9:02 PM, Jouni Korhonen wrote:

> 
> It seems I sent this to a wrong receiver.. that explains why it did not appear on the list.
> 
> - Jouni
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Sep 2014 15:40:56 +0000

Hi Sri,

Thanks for the balanced reply, and see below for some responses:

> From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
> Sent: Wednesday, September 10, 2014 4:26 PM
> Cc: Jouni Korhonen; Dapeng Liu; [email-masked]

With AERO, as I have already mentioned it does not matter which one
of possibly hundreds or thousands of AERO Servers the Client associates
with. The Client can also easily change between Servers, e.g., to get
better performance, or can even associate with multiple Servers, e.g.,
for load balancing and to reduce path stretch. AERO also has built-in
route optimization where the Client itself requests an optimized route
to a potential correspondent Client. But, the network does not need to
honor that request, e.g., if it wants to maintain a policy enforcement
point, single point of charging, etc.

So, the AERO anchors could be either fixed or floating depending on
the network's actual policies.

> and allow multiple options. I'm sure, that battle will be bitter and not

AERO has been a work-in-progress since about the 2002 timeframe.
In about 2005, a simplified precursor to AERO was productized and
shipped by major network equipment vendors under a different name,
but it was really just a stripped down function targeted for hosts
in fixed networks. Not really AERO at all, but it did include and
validate the NBMA virtual link model AERO is based on. In the later
2000's and into the earlier part of this decade, AERO underwent
constructive development in the IRTF RRG - again, under a different
name. Then, in 2012 a first edition of AERO was published as RFC6706
through AD sponsorship.

Since that time, I have continued development on the second edition
as a sole author effort, but with the help of MANY contributors who
have been acknowledged in the document. The second edition is now at
the point where it would be good to have it brought into a working
group home, which might be worth discussing at some point.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Sep 2014 15:46:04 +0000

Hi Sri,

I thumbed through the document, but will do a more careful read
and get back to you. One aspect that the two proposals have in
common is the use of an internal instance of BGP to keep track
of mobile network prefixes while advertising only one or a few
aggregated network prefixes to the outside world. AERO (and its
predecessor IRON) have been doing that for a long time, having
learned the lessons from the Connexion-By-Boeing experience.

Thanks - Fred

> Sent: Wednesday, September 10, 2014 5:14 PM
> To: Sri Gundavelli (sgundave); Templin, Fred L; [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Sep 2014 18:00:11 +0000

Hi Sri,

See below for some follow-up:

> Sent: Thursday, September 11, 2014 12:28 AM
> To: Templin, Fred L; Jouni Korhonen; [email-masked]

DHCPv6 is used for PD as well as mobility signaling. IPv6 ND messaging
is used for NUD, route optimization, and the functional equivalent of
a "binding update" via the use of unsolicited Neighbor Advertisements.
 
> client identified by the server ? What is the security model ?

The Client is identified by the server via the DHCPv6 DUID. The DUID
is most likely based on some serial number or ID that is assigned to
the Client by the AERO service administrative staff.

The security model is based on a multi-tiered layered security approach.
First, the Client must authenticate itself to the network using whatever
access layer securing mechanisms that are available, e.g., IEEE802.1x.
For Clients that are coming into the network from the Internet, the
Client establishes a VPN link to a security gateway at the network
border.

Second, the Client must prove to the Server that it is authorized to
perform DHCPv6 signaling using DHCPv6 Auth or some other DHCPv6
securing mechanism. This is only to protect against an "insider
attack" in which a different Client pretends to be the authorized
Client in order to hijack the authorized Client's prefix, siphon
traffic, etc. Hence, a "better than nothing" authentication such
as DHCPv6 Auth is really all that is needed.

Third, the network must ensure that link-layer addresses cannot
be spoofed. Here, the "link-layer address" is the IP source
address of the encapsulating tunnel header. This is typically
done through proper application of BCP ingress filtering
practices.

Finally, the AERO Server/Relay infrastructure provides a trust
anchor to facilitate Client-to-Client route optimizations. In
particular, Clients trust their Servers but cannot trust each
other initially. If a Client receives a route optimization
signal from its trusted Server, however, it can safely engage
in the route optimization since a chain-of-trust was followed. 

> 3.) Can the Aero solution support IP nodes that do not have Aero client

Proxy AERO could be applied in the same manner as for PMIP,
but the document does not fully investigate that option at
this time.

> control ? Where can they do Accounting, Lawful interception ?

Lawful intercept, accounting, etc. can be done at the AERO Servers.
In case these functions are mandatory, direct Client-to-Client route
optimizations would not be permitted in those environments. However,
Client-to-Server-to-Client route optimizations would still be used
to reduce path stretch and reduce load on critical infrastructure.

> legacy device, is the interface DHCPv4 ?

The AERO data plane can be either IPv4 or IPv6, and can be tunneled
over either IPv4 or IPv6 access networks. The AERO control plane is
always DHCPv6 and IPv6 ND. In particular, DHCPv6 PD can be used to
delegate IPv4 prefixes in the same way that it can delegate IPv6
prefixes. So no; DHCPv4 is not used in the control plane.

> 6.) Can an operator enable location-based services for a Aero client ?

AERO Clients discover and associate with AERO Servers that are
"nearby". They discover nearby Servers by resolving the DNS
FQDN "linkupnetworks.[domain]" where "[domain]" is a link-
specific DNS suffix. This would provide topological proximity
and I guess most often also geographic proximity. Is that what
you were asking?

> 7.) How can an operator enable IP Flow Mobility type features in an Aero

I am not familiar with IP Flow Mobility, but does it mean spreading
traffic load across multiple access links? Like maybe sending streaming
video across WLAN while posting short text messages via 4G? If so,
AERO supports the use of multiple simultaneous access links - like,
keeping both the WLAN and 4G interfaces active at the same time. Or
maybe I am mis-understanding IP Flow Mobility?
 
> multi-tenancy ? Is there a single tunnel between the client and the server

Again, I am not familiar with the term multi-tenancy, or at least not
with its use within this context. In terms of tunnels, however, the
tunnel is non-broadcast, multiple access (NBMA) and not point-to-point.
So each AERO node sees other AERO nodes as neighbors on the NBMA link.
The AERO interface therefore maintains a neighbor cache the same as
any IP interface, and uses the neighbor cache entries to track the
current L3/L2 address mappings. These mappings may change over time,
e.g., as the result of a mobility event.

Thanks - Fred

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 11 Sep 2014 15:36:27 -0500

Hi Sri,

Let me explain.

>>> let the deployments make the call on the protocol choice.

You have been saying these things since long time. You made a
presentation in Toronto. Before, in dmm calls you showed some slides.
I don't understand why you do not come up with a draft containing your
solution or parts of it? I know you can write drafts :-)
We do have solution drafts. You should also compete with your draft.

I think the charter is in no way prescribing a design team type of
approach and that makes sense because we already have solution
proposals and we certainly may have more.

In this step we need to scrutinize all the solution drafts and
eventually try to get consensus on one on which we can further work as
a group to build the final solution.

I saw a lot of discussion in this thread. That is a good sign.

Regards,

behcet

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 11 Sep 2014 21:51:16 +0000

Hi Fred,

Thanks for your responses. I'm beginning to get the picture on how Aero
works. Few more questions and then we should be able have meaningful
discussion. It surely saves me lot of time and I appreciate it.

9.) Are you aware of implementation of a Aero client on iPhone ? Can Aero
client be implemented in today's Apple iOS device, using standard API
interface ? Will the Apple iOS allow an application to setup a tunnel and
setup policy routes to steer a IP flow through that tunnel ?

10.) In today 3G/4G architectures, an application function can notify a
policy function to allocate QoS resources for a flow. Ex: An IMS function
requests a policy function to setup dedicated QoS resources for a RTP flow
and with guaranteed-bit-rate of 32kbps. This policy is enforced on the air
interface and on the path from the client to the gateway. We have RFC7222
providing QoS negotiation semantics on the network path and  then we have
John's draft, draft-ietf-netext-pmip-qos which extends the same to the
802.11 air interface. How do you see this aspect of dynamic QoS work in
Aero-based system ?

11.) To make sure I get the flow right.

- A client attaches to the Aero network
- Chooses a Aero server from a list of servers; DNS lookup, static list
- Sets up a UDP tunnel to a Aero servers; (What triggers the server to
setup the tunnel ? Is the DHCP message that is the trigger here ?)
- The client does DHCPv6 signaling through the tunnel. The server
allocates a special prefix. This prefix is on the Aero virtual link.
Similar to Mobile IP home link ?
- This special prefix is topologically anchored on the server
- Aero server sets up a tunnel route for the prefix towards the client
- All traffic from the client using this prefix will be tunneled through
the server; At least the first packet has to hit the server
- When RO is triggered, there will ICMP redirect messages send in the UDP
header with Aero port;
- The peers communicate directly. I assume there will be a UDP tunnel
between the peers ? If there is no need for tunnel, is ingress filtering
of the transit routers  not an issue ?

- Client moves and attaches to a different IP network; Obtains a DHCP
address
- Client sets up a tunnel to the previously attached Aero server and
continue to use the same prefix ?

The focus is all about rote optimization and by means of triggering

Is the following mapping correct ?

Aero server is almost like a home agent ?
Aero virtual link is Mobile IP home link ?
Aero prefixes given to the client are hosted on the server as in case of
Home Agent ?
Aero tunnel is similar to Mobile IP GRE or UDP tunnel ?
Aero ICMP Redirects are equivalent to the MIP RO procedure ?
Signaling is DHCPv6

Regards
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Sep 2014 22:04:45 +0000

Hi Sri,

I had to read through this document several times since it is a very
different operational world from the "traditional" enterprise networks
I am familiar with. But, figures 3 and 6 I think show useful points of
comparison with AERO. In figure 3, for example:

  - eNodeB is the place where AERO Client would go, i.e., with AERO
    operating in "proxy" mode. Otherwise, if tunneling were allowed
    all the way to the UE then the UE would be the AERO Client
  - EPC-E is analogous to AERO Server
  - RTR is analogous to AERO Relay

In both vEPC and AERO, there can be many EPC-Es (i.e., AERO Servers)
and these can be lightweight VMs in hypervisors. We already have
several AERO Servers deployed in hypervisors within Boeing.

vEPC specifies an anycast discovery service for discovering EPC-Es,
and this same approach has already been adopted by earlier solutions
such as 6to4 [RFC3068] and 6rd [RFC5969]. AERO could easily adopt an
anycast discovery approach as well, but would be used for discovery
purposes only - after discovering the closest Server via anycast,
the Client would switch to using a unicast address of the Server so
that neighbor cache state could be established. Note that this
neighbor cache state is used instead of an explicit tunnel, since
the AERO tunnel is NBMA.

With the approach in the current version of the AERO spec, however,
the AERO Client is presented with the unicast addresses of potentially
many nearby AERO Servers. The Client can then associate with one or
more Servers simultaneously and can change between Servers if necessary,
e.g., to get better performance. So, the Client chooses the best
Server(s) to use instead of leaving it up to the vagaries of the
routing system. 

As for vEPC's RTRs, AERO can have potentially many Relays. As for
vEPC, the AERO Servers and Relays also engage in an interior BGP
routing instance to track mobile node prefixes. With AERO, however,
the BGP peerings are unidirectional from Servers to Relays. So,
the Servers only need to know about their current set of associated
Clients, while the Relays get full topology information. This is a
very simple system - all Servers establish a TCP connection with
each Relay and then simply announce and withdraw routes over the
TCP connections. Conversely, the Relays never tell the Servers
anything. Unlike vEPC, however, Servers and Relays exchange packets
via tunneling - they do not use a non-tunneled routing domain,
although I suppose they could. But, one aspect of tunneling is that
it does not matter which IP protocol version is used in the IP core
network - it could be IPv4 or IPv6.

There are data flow paths for AERO that seem different from vEPC.
For example:

  1) Client A <-> Server <-> Client B (when both Clients associate
     with the same Server
  2) Client A <-> Server A <-> Relay <-> Server B <-> Client B
     (when the Clients associate with different Servers and before
     route optimization)
  3) Client A <-> Server A <-> Server B <-> Client B (when Server
     to-Server route optimization is applied)
  4) Client A -> Server B -> Client B, and
     Client B -> Server A -> Client A when Client-to-Server route
     optimization is applied
  5) Client A <-> Client B when Client-to-Client route optimization
     is applied

With vEPC I am not sure whether options 4 or 5 are available (but
maybe option 5 is not desired because it doesn't go through a
policy enforcement point?).

Other than that, I think the way AERO manages mobile node network
prefixes is probably quite different from vEPC. AERO always uses
DHCPv6 PD to delegate at least a /64 to each mobile node, and
can also delegate shorter prefixes. The mobile node gets the
same service no matter which Server it associates with, so if
it gets prefix P from Server A it will also get prefix P from
Server B.

That is about all I was able to glean from my first read, but
certainly willing to consider further.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Sep 2014 23:07:11 +0000

Hi Sri,

> Sent: Thursday, September 11, 2014 2:51 PM

We have AERO Client implemented on linux in a lightweight
user-level daemon and have it on our TODO list to port to
Android. This is all user-level code and no kernel changes
required. We haven't really looked at Apple iOS yet.

However, our target integration goal is OpenVPN since we will
then be able to use the same tool for AERO Client whether going
across a VPN or non-VPN connection. I haven't checked yet, but
if OpenVPN works on iOS, then AERO will also work on iOS when
we get this integration done.

> 802.11 air interface. How do you see this aspect of dynamic QoS work in

I really hadn't given that any thought, but looking at Section 4
of RFC7222 there is no reason the option defined there could not
be included in AERO messaging. Is this a control plane option
only, or is it also for the data plane?

I am sure there are also many other adjunct mechanisms associated
with MIP/PMIP that I haven't investigated yet. But I don't see any
reason why many/most could not be adapted for use with AERO.

> - Chooses a Aero server from a list of servers; DNS lookup, static list

Yes.

> setup the tunnel ? Is the DHCP message that is the trigger here ?)

AERO operates without explicit tunnels. Think of the AERO interface
as an ordinary NBMA IPv6 interface that maintains a neighbor cache
the same as any IPv6 interface. All nodes are single-hop neighbors
on the AERO interface, and hence can engage in IPv6 ND and DHCPv6
exchanges as on-link neighbors.

When an AERO Client discovers the address of an AERO Server, it
performs a DHCPv6 PD exchange with the Server over the AERO
interface. In the process, the Server creates an AERO interface
neighbor cache entry for the Client and the Client creates an
AERO interface neighbor cache entry for the Server and marks
the Server as "default". (RS/RA still work, but I haven't found
a need for them yet.)  

> Similar to Mobile IP home link ?

The Server delegates an AERO Client Prefix (ACP). The Client then
autoconfigures an AERO link-local address based on the ACP. So,
for example, if the ACP is 2001:db8:1:2::/64 then the AERO address
is fe80::2001:db8:1:2. The address is guaranteed to be unique,
since it is based on the ACP assigned by the Server. The Client
then uses this AERO address in all subsequent IPv6 ND messaging
over the AERO link. At the same time, it sub-delegates the ACP
to its downstream-attached links - it DOES NOT assign the ACP
to the AERO interface.

> - This special prefix is topologically anchored on the server

I would rather say that it is topologically anchored on the
Relays, since the Client can associate with multiple Servers
at the same time. But, the Relays will keep track of all
Client/Server associations.

> - Aero server sets up a tunnel route for the prefix towards the client

Actually, it does not need to set up an IP route because it
already has a neighbor cache entry with the Client's AERO
address, and the "interface ID" portion of the AERO address
can be used for IP forwarding decisions.

> the server; At least the first packet has to hit the server

The first packet (or first few packets) out will go through
one of the Client's associated Servers, but the Client can
at the same time send a Route Optimization request. If it
gets back a route optimization reply, it can then start
sending packets directly toward the route optimization target
without impacting the Server further.

> - When RO is triggered, there will ICMP redirect messages send in the UDP

Yes, the RO "request" is known as a "Predirect". (I suppose it
could also be called a "Redirect Solicitation", but the acronym
"RS" is already taken.) When the target gets a Predirect, it
returns a Redircet.

> between the peers ?

Yes, peers communicate directly via tunneling.

> If there is no need for tunnel, is ingress filtering

The Predirect/Redirect exchange sets up neighbor cache entries that
list the acceptable link-layer address(es) allowed to be used for
the node's claimed network-layer prefix. So, the nodes do a simple
data origin test to make sure that packets are coming from an
acceptable L2 address.

> - Client moves and attaches to a different IP network; Obtains a DHCP

When the Client moves, it will stay with the same Server if it hasn't
moved too far. If so, the Client sends a DHCPv6 Rebind to the Server
to inform the Server of its new link-layer address. If the Client
has moved too far away from the previous Server, it contacts a new
Server then tells its old Server goodbye.

> continue to use the same prefix ?

Again, Clients may be associated with multiple Servers, and it
is the Client's responsibility to make sure that its current
set of Servers are good ones. The Client will always update
its current set of Servers whenever it moves. The Client gets
to use its same prefix wherever it moves to.
 
> The focus is all about rote optimization and by means of triggering

Route optimization is one aspect. Maintaining a stable, unchanging
Client network prefix in spite of mobility events is another. 

> Aero server is almost like a home agent ?

I would rather say that the AERO Relay is like a home agent.
The AERO Relay is the entry point to the AERO virtual link
from the outside world. The AERO Relay is the one who knows
where all Clients are located. The AERO Servers are more
like L2 (L2.5?) devices that keep AERO Clients grouped into
manageable sets so that the load is spread and Clients get
good performance. 

> Aero virtual link is Mobile IP home link ?

Yes. However, unlike MIP Clients, the AERO Clients never leave
the virtual link no matter where they move to, and the virtual
link is link-local-only. So, there is really no concept of
Home Address/Care-of Address.

> Aero prefixes given to the client are hosted on the server as in case of

The AERO Relay is analogous to the MIP Home Agent and host all
AERO Client Prefixes. AERO Servers are "L2.5" devices that keep
track of a dynamically changing subset of all prefixes.

> Aero tunnel is similar to Mobile IP GRE or UDP tunnel ?

AERO can use any tunnel type. AERO has an assigned UDP port
number (8060) and by default does IP-in-UDP-in-IP tunneling.
But, the same AERO messaging can be used over any tunnel
type (GRE, IPsec, probably GTP but I haven't looked at that
very closely, etc.).

> Aero ICMP Redirects are equivalent to the MIP RO procedure ?

AERO Predirect/Redirect signaling is pretty unique (first
documented in RFC6706) and is unidirectional (i.e., first
A gets redirected to B, then B gets redirected to A). Is
that equivalent to MIP RO?

> Signaling is DHCPv6

and IPv6 ND, yes.

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 12 Sep 2014 00:59:23 +0000

Hi Fred,

Thanks again for your responses.

Lets zoom into the following two points.

>we get this integration done.

I understand, this can be realized in Android and in Linux based
platforms. However, from what I understand, the Apple's published SDK does
not allow applications to create IP tunnels and setup forwarding of IP
packets through those tunnels. Essentially, we may not be able to build a
Aero client for the currently deployed millions of iOS devices.

Forget alone the tunnel part, the MIP community over the years realized
that managing a client-eco system is not trivial. In the glory days of
Microsoft window's rule, Microsoft they never integrated MIP stack in
their windows operating system and the industry struggled to see the MIP
client eco-system and eventually that forced us to look at network-based
approaches. We invested in mobility models that did not require client
support. All thought MIP flourished during the CDMA days, as Qualcom
integrated the stack into the chipset, but however operators chose a
network-based approach for 4G architectures.

>> >but the document does not fully investigate that option at

Ok. So, the current experimental AERO RFC does not support network-based
approaches and we cannot build client for a platform with most dominant
market share.

Based on these points #3 and #9, can we conclude that we cannot apply AERO
for DMM ? If not, how do we apply and deploy Aero for DMM networks ?

Regards
Sri

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 12 Sep 2014 16:51:27 +0300

Folks,

I've learned that I may have a force majeure at the time of interim call 
#2. Fortunately we got two chairs so Dapeng will lead the call.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 12 Sep 2014 17:03:27 +0300

The interim #2 agenda is now also online:
http://www.ietf.org/proceedings/interim/2014/09/16/dmm/agenda/agenda-interim-2014-dmm-2

- jouni

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Sep 2014 15:17:06 +0000

Hi Sri,

> Sent: Thursday, September 11, 2014 5:59 PM

I'll be honest that I have not had a chance to look into iOS, but
surely those devices must support some form of VPN solution - I
guess OpenVPN? If an iOS phone can be made to do OpenVPN, then
it can be made to do AERO.

> network-based approach for 4G architectures.

I don't mind talking about proxy-AERO - which should be a trivial
extension of the base mechanisms. The only problem with that is
that it has to exist in the access routers, and AFAICT it would
be difficult to switch between different data link technologies
on the fly, e.g., going from a wired LAN to WiFi, going from
WiFi to 4G, going from non-VPN to VPN, etc. Do the proxy
solutions talk about this?

> approaches and we cannot build client for a platform with most dominant

This version of AERO is far evolved from the experimental RFC.
If you want it to talk about proxy AERO, then I don't mind
talking about new text to add to the current draft.

> for DMM ? If not, how do we apply and deploy Aero for DMM networks ?

I don't think so. Surely we can do proxy AERO, and surely iOS
phones can do VPN. So, pick one or both of these alternatives
and I think the concern is addressed?

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 13 Sep 2014 02:02:16 +0000

Hi Fred,

>and I think the concern is addressed?

If the latest releases of iOS has support for tunnel interface and route
management, I'll be happy to know the specifics. For a minute, lets go
with that assumption we can realize Aero client on iOS. That immediately
makes the solution relevant (assuming it supports other basic
capabilities) to a class of solutions that are client-based and not
network-based. As I said earlier, the MIP community has failed to realize
client eco-system and any proposals that are client-based have limited
value. Lets talk about RO for an IP flow between a host and an application
server in some SP's data center. The probability that the peer supports RO
capabilities defined by a protocol are close to zero. MIPv6 has RO in the
form of IPv6 Type-2 routing header, defined as part of baseline IPv6
specs, but still the MIP community almost gave up on client-based
solutions. This is one data point.

I understand, Aero can be extended to support a Proxy function. But, will
it not look exactly like Proxy Mobile IP ? I'm looking for fundamental
properties which are unique to Aero and that PMIP/MIPv6 lacks ?

Instead of the approach, "Aero may be extended to do it", what is that one
capability that Aero offers and that the current mobility protocols lack ?
One line of thinking could be to integrate such unique ideas, if any, to
protocols that are feature rich and were defined before, standardized,
integrated in SDO architectures and has a deployment base.

Aero uses DHCP/ND as a signaling interface, instead of dedicated signaling
interface, and uses tunnels to setup the overlay routing path. For RO, it
uses ICMP, where as MIP uses special messages HoTi/CoTi (please ask
Charlie why they chose those terms :)). Furthermore, it misses all the
features that the other protocols already can support.

Regards
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Sep 2014 15:43:46 +0000

Hi Sri,

> Sent: Friday, September 12, 2014 7:02 PM
> with that assumption we can realize Aero client on iOS.

iOS supports the TUN half of the TUN/TAP interface. OpenVPN uses
the TUN interface, and runs on iOS. AERO assumes OpenVPN as its
target integration platform, and requires no kernel changes nor
any kernel routing table nor neighbor cache manipulations. AERO
can therefore go anywhere OpenVPN can go, including iOS.

> That immediately
> network-based.

My "day in the life" thread shows a use case for a client-based
solution.

> As I said earlier, the MIP community has failed to realize
> value.

Client-based solutions are necessary for the enterprise mobility
use case, as expressed in "day in the life" as well as:

https://datatracker.ietf.org/doc/draft-templin-aeroent/

> Lets talk about RO for an IP flow between a host and an application
> server in some SP's data center.

AERO supports RO for two peers that both participate in the same
AERO service domain. It is not for peers that participate in
different AERO service domains, nor when one peer is AERO and
the other is non-AERO.

> The probability that the peer supports RO

AERO requires no kernel changes nor any special IPv6 headers.

> solutions. This is one data point.

AERO route optimization is different. AERO route optimization
manipulates the neighbor cache (usually an application-based
neighbor cache and not a kernel-resident one) based on IPv6 ND
messaging. Client AERO addresses are used to key the neighbor
cache entries.

> properties which are unique to Aero and that PMIP/MIPv6 lacks ?

The AERO proxy messaging would be based on DHCPv6 request/release.
I will put this in the next draft version since, as you said, the
framework is similar to PMIP.

In the AERO model, the AERO Client is analogous to the PMIP MAG and
the AERO Server is analogous to the PMIP LMA. However, AERO uses an
NBMA tunnel virtual link model that connects all Client and Servers
instead of point-to-point tunnels. It also uses neighbor cache
entries based on the Client's AERO address(es) instead of explicit
tunnel state. Most importantly, it does not matter which Server the
Client associates because the mobile node's home network prefixes
are not bound to the Server -they are bound to AERO Relays instead.

> capability that Aero offers and that the current mobility protocols lack ?

AERO can be applied at multiple levels, both as a network-based proxy
system and as a Client-based end system. Consider an AERO Client that
is based in a home enterprise network and is currently using its 4G
interface. The Client would use one instance of AERO to coordinate
with its home network, while the 4G network would use its own
instance of AERO to provide the Client with network-based mobility
management services within the cellular provider network. AERO can
therefore be applied recursively.

Consider also a "nested NEMO" situation in which a first mobile
router provides an access link to a second mobile router, the
second mobile router provides an access link to a third mobile
router, the third mobile router ... etc. In such a scenario,
a separate AERO instance could be applied at each level.

There is still more (including distributed mobility management,
route optimization, etc.) that AERO handles easily where the other
approaches may not handle so easily.

> integrated in SDO architectures and has a deployment base.

To name one thing, the tunnel virtual link model is a point of
departure and I think an area where AERO provides a better model
especially for handling route optimization and distributed
mobility management.
 
> Charlie why they chose those terms :)).

OK.

> Furthermore, it misses all the

You lost me there. What features? And could they not be used on
AERO the same as they are used with the other protocols?

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 15 Sep 2014 22:32:28 +0000

Hi Fred,

Thanks for your response.

Lets focus on the Route Optimization. If you can share some views on how
the above model is better compared to the below standardized approaches,
it will really help.

To your comment on feature gaps, I will try to compile a list and send it
out. I also owe you a response on the thread related to Sataru-san's draft.

In MIP architectures, we have Route optimization support in two modes:

1.) Client-based 

- Signaling is based on MIPv6; (http://tools.ietf.org/html/rfc6275#page-25
)
- User-plane RO management based on Type-2 Routing
header;(http://tools.ietf.org/html/rfc6275#page-55)
- Scope is global
- Requires Mobile IPv6 software functionality

2.) Network-based

- Signaling is based on PMIPv6; (http://tools.ietf.org/html/rfc6705#page-8)
- User plane is based on direct tunneling
- Scope is localized PMIP domain
- Works with any mobile node with no additional software capabilities

Regards
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Sep 2014 23:02:10 +0000

Hi Sri,

> Sent: Monday, September 15, 2014 3:32 PM

AERO route optimization is quite different than this. AERO route
optimization is based on a chain-of-trust whereby the RO requests
and replys always come from the Client's trusted Server instead
of an untrusted node. AERO RO is unidirectional - to set up a
bidirectional RO requires two unidirectional ROs. These can
happen simultaneously or separately, and in some cases it may
even be preferable to have only one of the two directions
optimized.

In the process of setting up the RO, the Clients also come to know
the permissible encapsulation IP address or addresses for the
encapsulated address. So, the RO also provides a simple data
origin authentication capability. 
 
> - Works with any mobile node with no additional software capabilities

This looks very close to the way AERO handles RO in the network
based case. In this case, the AERO Client is analogous to the 
PMIPv6 MAG, and the RO can go MN1<->Client1<->Client2<->MN2.

One of the key differences again is that the AERO NBMA virtual
link does not require any explicit tunnel configurations. So,
tunneling between Client1<->Client2 is guided by neighbor cache
information on the NBMA link.

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 18 Sep 2014 00:46:57 +0000

Hi Fred,

>information on the NBMA link.

There is no explicit tunnel configuration in any of the mobility
architectures. The tunnel state creation is dynamic and is created based
on the events from the signaling functions. The tunnel is a standard L3
tunnel with standard encapsulation methods such as GRE, IP-in-IP and UDP.

I'm trying to understand the advantages of this NBMA virtual link. I
assumed the encapsulation is a standard encapsulation such as with UDP.
The specific rules for selection of the IP traffic for tunneling, or
tunnel header selection is a more implementation specific aspect. One can
create a tunnel between two points A and B and apply a policy route, which
state all traffic from MAc-1/IP-1 needs to be encapsulated with tunnel
header A-B. If I'm monitoring the link of a tunneled traffic, I would not
know the difference between traffic tunneled from a NBMA virtual link and
a tunneled traffic with dynamically created tunnels. How we realize
tunneling is internal to the operating system and has no bearing on the
interoperability  ?. Do you agree with this ?

Ok. In MIPv6 RO scheme the MN's trusted entity is the home agent and it
provides the frame work for a CN to trust the MN's relation/association
with its home address (anchored on HA) and its care-of address (direct
route). The approach does not require both the peers to have a mobility
anchor, but the Return Routability test procedure assures any
correspondent node to trust the HoA to CoA relation and use direct routing
paths. I'm not sure how one approach is better over the other.

Again, I've my views against using any client-based solutions for RO
solutions.

Regards
Sri

On 9/15/14 4:02 PM, "Templin, Fred L" <[email-masked]> wrote:

>> - Signaling is based on MIPv6;
>>(http://tools.ietf.org/html/rfc6275#page-25
>> )
>> - Signaling is based on PMIPv6;
>>(http://tools.ietf.org/html/rfc6705#page-8)

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Sep 2014 18:33:44 +0000

Hi Sri,

> Sent: Wednesday, September 17, 2014 5:47 PM
> To: Templin, Fred L
> Cc: [email-masked]

The AERO NBMA virtual link mode applies to any tunnel type (UDP, GRE,
IP-in-IP, GTP (I guess), etc.).

> interoperability  ?. Do you agree with this ?

Right, there is no difference in the way the tunneled packets appear
as bits-over-the-wire. The difference is that the AERO NBMA virtual
link model allows for L2 address resolution via IPv6 ND messaging
the same as on any IP interface. 

> paths. I'm not sure how one approach is better over the other.

Let me think about this.

> Again, I've my views against using any client-based solutions for RO

AERO RO is initiated by the source Client and directed toward the
target Client. When the source Client sends packets destined for
a target Client, the source also sends a RO message. Both the data
packets and the RO message are sent via a routing chain. In the
PMIPv6 deployment model, it would go as:

  MAG1 -> LMA1 -> (some forwarding agent) -> LMA2 -> MAG2

After the RO, subsequent communications would go directly as:

  MAG1 -> MAG2

But, it is important to note that AERO generalizes to any mobility
scenario, and not just the PMIP deployment model. For AERO RO, mobile
Clients may have no way of trusting each other without involving some
chain of trust as provided by the AERO Servers and Relays.

Thanks - Fred