Hi Alper, > -----Original Message----- > From: Alper Yegin [mailto:[email protected]] > Sent: Wednesday, September 10, 2014 11:37 PM > To: Templin, Fred L > Cc: Alexandru Petrescu; [email protected] > Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User" > > Hi Fred, > > Actually, you had provided the description of the scenario w/o any references > to the solutions (AERO, > MIP, etc.).
The scenario was pulled out of a document titled: "AERO Enterprise Network Model", but then scrubbed to remove references to AERO before posting to the list to provide a neutral platform for discussion. > So, I asked if that scenario could already be handled using existing MIP > protocol. Right, and reasons were given as to why AERO instead of MIP. > I didn't imply it couldn't be done using AERO. Well, again, the scenario was pulled from an AERO-specific document. So I didn't think you were implying it couldn't be done using AERO. Thanks - Fred [email protected] > 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
