Hi Fred, Actually, you had provided the description of the scenario w/o any references to the solutions (AERO, MIP, etc.). So, I asked if that scenario could already be handled using existing MIP protocol. I didn't imply it couldn't be done using AERO.
Alper On Sep 10, 2014, at 11:21 PM, Templin, Fred L wrote: > 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
