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

["Sri Gundavelli (sgundave)" <[e-mail]>]

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










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
>