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

["Templin, Fred L" <[e-mail]>]

Hi Sri,

> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:[e-mail]]
> Sent: Thursday, September 11, 2014 2:51 PM
> To: Templin, Fred L; Jouni Korhonen; [e-mail]
> Cc: Dapeng Liu; [e-mail]
> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> 
> 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 ?

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.

> 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 ?

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.

> 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

Yes.

> - 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 ?)

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.)  

> - 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 ?

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.

> - All traffic from the client using this prefix will be tunneled through
> 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
> header with Aero port;

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.

> - The peers communicate directly. I assume there will be a UDP tunnel
> between the peers ?

Yes, peers communicate directly via tunneling.

> If there is no need for tunnel, is ingress filtering
> of the transit routers  not an issue ?

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
> address

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.

> - Client sets up a tunnel to the previously attached Aero server and
> 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. 

> Is the following mapping correct ?
> 
> 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
> Home Agent ?

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
[e-mail]

> Regards
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 9/11/14 11:00 AM, "Templin, Fred L" <[e-mail]> wrote:
> 
> >Hi Sri,
> >
> >See below for some follow-up:
> >
> >> -----Original Message-----
> >> From: Sri Gundavelli (sgundave) [mailto:[e-mail]]
> >> Sent: Thursday, September 11, 2014 12:28 AM
> >> To: Templin, Fred L; Jouni Korhonen; [e-mail]
> >> Cc: Dapeng Liu; [e-mail]
> >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> >>
> >> 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 ?
> >
> >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.
> >
> >> 2.) What is the service authorization model for a Aero client ? How is
> >>the
> >> 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
> >> stack ?
> >
> >Proxy AERO could be applied in the same manner as for PMIP,
> >but the document does not fully investigate that option at
> >this time.
> >
> >> 4.) If a mobile or a cable SP deploys Aero, where is their point of
> >> 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.
> >
> >> 5.) I assume Aero client can be IPv4 or an IPv6 device ? For an
> >>IPv4-only
> >> 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
> >> system ?
> >
> >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?
> >
> >> 8.) Taking a mobile router scenario, how does Aero client support
> >> 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
> >[e-mail]
> >
> >> ?
> >>
> >>
> >> Regards
> >> Sri
> >>
> >>
> >>
> >>
> >> On 9/10/14 11:43 AM, "Templin, Fred L" <[e-mail]>
> >>wrote:
> >>
> >> >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
> >> >[e-mail]
> >> >
> >> >> -----Original Message-----
> >> >> From: dmm [mailto:[e-mail]] On Behalf Of Jouni Korhonen
> >> >> Sent: Wednesday, September 10, 2014 11:37 AM
> >> >> To: [e-mail]
> >> >> Cc: Dapeng Liu; [e-mail]
> >> >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> >> >>
> >> >>
> >> >> What do you mean by no agenda? To me it clearly says we use the call
> >>#2
> >> >> for setting up the work split.
> >> >>
> >> >> - Jouni
> >> >>
> >> >> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti:
> >> >> > 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
> >> >><[e-mail]> wrote:
> >> >> >>
> >> >> >> 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 <[e-mail]>
> >> >> >> Vastaanottaja: [e-mail]
> >> >> >> CC: [e-mail], Dapeng Liu <[e-mail]>
> >> >> >>
> >> >> >> 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
> >> >> >>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> dmm mailing list
> >> >> >> [e-mail]
> >> >> >> https://www.ietf.org/mailman/listinfo/dmm
> >> >>
> >> >> _______________________________________________
> >> >> dmm mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/dmm
> >> >_______________________________________________
> >> >dmm mailing list
> >> >[e-mail]
> >> >https://www.ietf.org/mailman/listinfo/dmm
> >