Hi Alper, > > > Can this scenario not be realized by simply placing an HA in the > > > enterprise network and using Mobile IP?
You did not respond to say whether your question was answered. I think it is also fair to ask the opposite question: "Are there scenarios for MIP-based solutions that cannot be realized by simply placing an AERO Server in the network and using AERO?" Thanks - Fred [email protected] > -----Original Message----- > From: dmm [mailto:[email protected]] On Behalf Of Templin, Fred L > Sent: Thursday, September 04, 2014 7:51 AM > To: Alexandru Petrescu; [email protected] > Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User" > > Hi Alex and Alper, > > > -----Original Message----- > > From: dmm [mailto:[email protected]] On Behalf Of Alexandru Petrescu > > Sent: Thursday, September 04, 2014 2:50 AM > > To: [email protected] > > Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User" > > > > Le 04/09/2014 08:47, Alper Yegin a écrit : > > > Hi Fred, > > > > > > Can this scenario not be realized by simply placing an HA in the > > > enterprise network and using Mobile IP? > > > > I guess yes and no. > > > > YEs, in that it is a typical Mobile IP scenario with handovers > > WiFi/4G/Ethernet. > > Handovers between diverse access technologies is one aspect of the > proposal, yes. The ability to coordinate multiple access technologies > simultaneously is also included as part of the architecture, but some > future work needs to be done to put that into practice. > > > No, in that "VPN" is cited in the scenario and VPN+Mobile IP are not > > working well together. > > Right - switching between VPN and non-VPN will be important for > enterprise network mobile device users. > > > No, in that TIP (DHCPv6 Prefix Delegation?) is not clear how to work > > with a EUD device ID? Is it Ethernet's, WiFi's or 4G's interface MAC > > address? > > The mobile device applies the TIP to its downstream-attached > interfaces and not to the access technology interfaces over > which the prefix delegation was received. So the mobile device > is really a mobile router. > > But, maybe you are asking where does the mobile device get its > Device-Unique Identifier (DUID) so it can talk to the DHCPv6 > server? The DUID need not be based on a MAC address, but could > be some other unique ID assigned to the mobile. So, there is > no confusion about which MAC address to choose. > > > No, in that Mobile IP and prefixes are not known to lead to optimal > > routes, whereas the scenario says "optimal routes". > > Route optimization is indeed a key aspect of the proposal, and > in fact hard-coded into the name "AERO". Another key aspect is > the in-built distributed mobility management (dmm) architecture. > The enterprise can from day one deploy hundreds or even > thousands of AERO servers, and the mobile devices simply > associate with one or more that are close by. Beyond that, it > doesn't matter which server the mobile associates with - it > will get the same service as from any other server. > > > No - but this is a stretch - the scenario does not mention the > > neceessity of user typing secure information on a screen (authenticate > > to web page on a public hotspot prior to ability to Mobile IP, or use > > One-Time Password tokens for VPN connections); any "seamless" mobility > > mechanism will need to automate this step; this is even more needed when > > considering devices without user interfaces, such as Mobile Routers > > using Mobile IP for a vehicle. > > Aspects of how the VPN link is established (enter password, > insert active badge, etc.) are not discussed, but not really > relevant to the way in which AERO can provide the mobile with > a stable TIP that never changes. Just that the faster the VPN > link can be established, the faster the mobile device can resume > service as if it were still coming in through an on-campus > enterprise network access link. > > There is still more to this, such as how AERO can provide an > assured path MTU over the tunnel, etc. There should also be > an expanded use case analysis. I have been coming at this from > an enterprise network viewpoint, but as far as I know AERO > could also be applied in the traditional use cases envisioned > for MIPv6 and its derivatives. So, it would be good to have > some of the experts from this community examine the proposal > and provide a comparative analysis. > > Thanks - Fred > [email protected] > > > Alex > > > > > > > > Alper > > > > > > > > > On Sep 3, 2014, at 7:37 PM, Templin, Fred L wrote: > > > > > >> Hi, > > >> > > >> The specific passage from the new draft that I wanted the wg to > > >> see is the following (with references to AERO removed). Please > > >> review and send questions or comments. > > >> > > >> Thanks - Fred [email protected] > > >> > > >> --- > > >> > > >> 3. A Day in the Life of an Enterprise Mobile Device User > > >> > > >> An enterprise network mobile device user ("Bill") begins his > > >> workday by seating his primary end user device (EUD) (e.g., a > > >> laptop computer, a tablet, a smart phone, etc.) in a docking > > >> station at his office desk and turning the device on. The docking > > >> station connects Bill's EUD to the enterprise wired LAN, and the > > >> EUD receives a Topologically-Fixed Address (TFA) from the > > >> infrastructure. Bill's EUD further discovers the DMM service > > >> within the enterprise network and requests a Topology Independent > > >> Prefix (TIP)delegation. Bill's EUD receives the same TIP > > >> delegation it gets every time it connects to the enterprise > > >> network, because the DMM service has an administratively set > > >> mapping between the TIP and Bill's EUD device ID. > > >> > > >> Bill's EUD can then access topologically-fixed enterprise services > > >> using its TFA directly, and can access DMM services by using an > > >> address from its TIP as the source address for tunneling over the > > >> enterprise network. As Bill's workday unfolds, his EUD uses the > > >> DMM service to correspond with other EUDs in peer-to-peer > > >> sessions, join lengthy virtual conferencing sessions, access > > >> enterprise fileshares, etc. The DMM service ensures that optimal > > >> routes are maintained so that tunneled communications flow over > > >> direct paths and network infrastructure elements are not > > >> unnecessarily over-burdened. > > >> > > >> While communications sessions such as the video conference are > > >> still in progress, Bill leaves the office to attend a meeting in a > > >> nearby conference room. He disconnects his EUD from the docking > > >> station and in the process drops his connection to the wired LAN. > > >> The EUD quickly enables a WiFi interface that searches for a > > >> Service Set Identifier (SSID) that can provide wireless access > > >> within the enterprise network. The EUD authenticates itself to > > >> the network via the SSID using its pre-loaded certificates, and > > >> uses a securing mechanism such as IEEE 802.1x to assure > > >> Confidentiality, Integrity and Availability (CIA). The EUD > > >> receives a new TFA from the network, then communicates its new > > >> TIP-to-TFA association to the DMM service and any active peer > > >> correspondents. Any ongoing communications sessions will continue > > >> to see the same (stable) TIP. > > >> > > >> Bill then leaves the enterprise campus to attend an off-site > > >> customer meeting with his EUD still powered on and actively > > >> seeking to maintain network connectivity. As Bill departs from > > >> the building, the WiFi signal fades until it can no longer support > > >> communications, and the EUD quickly enables a 4G cellular wireless > > >> interface that connects Bill's EUD to a cellular service provider. > > >> The EUD then locates the Internet address of an enterprise network > > >> security gateway and initiates a VPN session with the gateway > > >> (which also acts participates in the DMM service). The DMM > > >> service updates the routing system, and Bill can continue to use > > >> the same TIP that was assigned to his EUD when he started his > > >> workday even though the EUD is now communicating over a VPN > > >> configured over the public Internet instead of over the secured > > >> campus LAN. > > >> > > >> Bill subsequently arrives at the customer meeting at a public > > >> restaurant with a WiFi hotspot. His EUD quickly powers up its WiFi > > >> interface and powers down the 4G interface. The EUD uses DMM > > >> signaling to communicate the new TFA to the security gateway and > > >> the VPN survives the mobility event. Moreover, the EUD can > > >> continue to use the same TIP it received at the beginning of the > > >> workday, and ongoing communication sessions can continue until > > >> Bill explicitly discontinues them. > > >> > > >> After the customer meeting, Bill leaves the restaurant and > > >> subsequently passes through several additional transitions from > > >> WiFi hotspots to 4G wireless. Again, the DMM service keeps the VPN > > >> session alive, and the TIP assigned to the EUD remains in > > >> continuous use in active communication sessions as well as to > > >> allow Bill to receive notifications and process urgent requests. > > >> When Bill returns to his office, the EUD discontinues use of the > > >> VPN while keeping its TIP active after re-attaching to the campus > > >> LAN. > > >> > > >> Bill ends his workday, powers down his EUD and returns home. Bill > > >> powers on his EUD to check e-mails, and connects to the enterprise > > >> network via a VPN configured over his home ISP service. The EUD > > >> again receives the same TIP that it used within the enterprise > > >> network domain, and Bill can access DMM services the same as if he > > >> was in the office. Bill finally shuts down for the evening, and > > >> begins his next workday in the same fashion. Again, the EUD > > >> receives the same TIP as always regardless of the access network > > >> point of connection over which the EUD enters the enterprise. > > >> > > >>> -----Original Message----- From: dmm > > >>> [mailto:[email protected]] On Behalf Of Templin, Fred L Sent: > > >>> Tuesday, September 02, 2014 11:05 AM To: [email protected] Subject: > > >>> [DMM] FW: I-D Action: draft-templin-aeroent-00.txt > > >>> > > >>> Hello, > > >>> > > >>> During the call today, there was some interest expressed in > > >>> learning more about the enterprise network mobility use case. I > > >>> have submitted a new brief document called "AERO Enterprise > > >>> Network Profile" (below) that provides a discussion of > > >>> distributed mobility management needs for enterprise networks. > > >>> Although the document specifically cites AERO, the use case > > >>> applies to any solution alternative that could meet the > > >>> requirements. Also, I am not asking this document be considered > > >>> as a dmm wg item at this time, but rather offering it for > > >>> informational purposes. Please let me know if there are any > > >>> questions or comments. > > >>> > > >>> Thanks - Fred [email protected] > > >>> > > >>> -----Original Message----- From: I-D-Announce > > >>> [mailto:[email protected]] On Behalf Of > > >>> [email protected] Sent: Tuesday, September 02, 2014 10:51 > > >>> AM To: [email protected] Subject: I-D Action: > > >>> draft-templin-aeroent-00.txt > > >>> > > >>> > > >>> A New Internet-Draft is available from the on-line > > >>> Internet-Drafts directories. > > >>> > > >>> > > >>> Title : AERO Enterprise Network Profile Author : Fred > > >>> L. Templin Filename : draft-templin-aeroent-00.txt Pages > > >>> : 12 Date : 2014-09-02 > > >>> > > >>> Abstract: Enterprise networks provide a secured data > > >>> communications infrastructure built for the purpose of > > >>> information sharing and increased productivity for end users > > >>> within the organization. Enterprise networks are often organized > > >>> as private Internets unto themselves that connect to the global > > >>> Internet either not at all or via firewalls, proxies, and/or > > >>> other network securing devices. This document discusses an AERO > > >>> enterprise network profile that outlines new and more flexible > > >>> methods for connecting, tracking and managing mobile > > >>> organizational assets. > > >>> > > >>> > > >>> The IETF datatracker status page for this draft is: > > >>> https://datatracker.ietf.org/doc/draft-templin-aeroent/ > > >>> > > >>> There's also a htmlized version available at: > > >>> http://tools.ietf.org/html/draft-templin-aeroent-00 > > >>> > > >>> > > >>> Please note that it may take a couple of minutes from the time > > >>> of submission until the htmlized version and diff are available > > >>> at tools.ietf.org. > > >>> > > >>> Internet-Drafts are also available by anonymous FTP at: > > >>> ftp://ftp.ietf.org/internet-drafts/ > > >>> > > >>> _______________________________________________ I-D-Announce > > >>> mailing list [email protected] > > >>> https://www.ietf.org/mailman/listinfo/i-d-announce > > >>> Internet-Draft directories: http://www.ietf.org/shadow.html or > > >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >>> > > >>> _______________________________________________ dmm mailing list > > >>> [email protected] https://www.ietf.org/mailman/listinfo/dmm > > >> > > >> _______________________________________________ dmm mailing list > > >> [email protected] https://www.ietf.org/mailman/listinfo/dmm > > > > > > _______________________________________________ dmm mailing list > > > [email protected] https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > > > > > _______________________________________________ > > dmm mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
