Re: [DMM] WG Review: Distributed Mobility Management (dmm)

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 08 October 2014 14:25 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C501A1B26; Wed, 8 Oct 2014 07:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level:
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zsd50ZccEggq; Wed, 8 Oct 2014 07:25:48 -0700 (PDT)
Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2781A1B1F; Wed, 8 Oct 2014 07:25:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s98EPmdL027775; Wed, 8 Oct 2014 07:25:48 -0700
Received: from XCH-BLV-505.nw.nos.boeing.com (xch-blv-505.nw.nos.boeing.com [130.247.25.195]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s98EPeLm027732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 8 Oct 2014 07:25:40 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.191]) with mapi id 14.03.0181.006; Wed, 8 Oct 2014 07:25:40 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Jouni <jouni.nospam@gmail.com>, Alexandru Petrescu <alexandru.petrescu@gmail.com>
Thread-Topic: [DMM] WG Review: Distributed Mobility Management (dmm)
Thread-Index: AQHP4uxwgZMiI8yKjk6iNPqATAL5xZwmnxkA//+gelA=
Date: Wed, 08 Oct 2014 14:25:39 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D3A660@XCH-BLV-504.nw.nos.boeing.com>
References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> <54352235.7070304@gmail.com> <5BBFF707-2F25-4D30-9871-B5F17B9AF0B4@gmail.com>
In-Reply-To: <5BBFF707-2F25-4D30-9871-B5F17B9AF0B4@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/R9a_Pfb6JeWvYsyaL7_gspL299E
Cc: "iesg@ietf.org" <iesg@ietf.org>, dmm WG <dmm@ietf.org>
Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Oct 2014 14:25:51 -0000

FWIW, AERO is a mobile router solution. But, it is easy to make an AERO mobile router
act like a mobile host. Cell phones, tablets, laptops, etc. are all good candidate AERO
mobile router/hosts. (Airplanes, automobiles, ocean-going vessels, etc. are also good
candidate AERO mobile routers.)

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni
> Sent: Wednesday, October 08, 2014 6:00 AM
> To: Alexandru Petrescu
> Cc: iesg@ietf.org; dmm WG
> Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm)
> 
> Alex,
> 
> Do you have a specific change to the text in mind? The charter text uses systematically "mobile host/router" to make sure mobile
> routers are not forgotten. However, charter also allows solutions that are not specifically tailored to mobile routers.
> 
> Jouni
> 
> --
> Jouni Korhonen
> Broadcom
> 
> (Sent from my mobile..)
> 
> > Alexandru Petrescu <alexandru.petrescu@gmail.com> kirjoitti 8.10.2014 kello 14.38:
> >
> > Hello,
> >
> > I would like to comment on reusing prior work.
> >
> > Citing RFC3963 and RFC 5177 (v4 and v6 extensions to Mobile IP for network mobility) seems logical to me, since they're about
> Mobile IP too.
> >
> > Citing RFC 4888 and RFC 4889 (NEMO Route Optimization PS and solution analysis) seems logical to me, since the charter says
> "optimal" routes.
> >
> > Currently there is discussion in the DMM WG sketching potential solutions.  When they're ready they'll certainly compare to these
> two sets of RFCs, and will have to answer same questions: does it work with Mobile Router (not just Mobile Host)?  does it offer
> optimal routes? does it modify CN?  is it subject to 'stalemate' situations (RFC4888 section 2.7)?  does it involve multiple
> encapsulations?  does it permit nestedness?
> >
> > Alex
> >
> > Le 03/10/2014 21:38, The IESG a écrit :
> >> The Distributed Mobility Management (dmm) working group in the Internet
> >> Area of the IETF is undergoing rechartering. The IESG has not made any
> >> determination yet. The following draft charter was submitted, and is
> >> provided for informational purposes only. Please send your comments to
> >> the IESG mailing list (iesg at ietf.org) by 2014-10-13.
> >>
> >> Distributed Mobility Management (dmm)
> >> ------------------------------------------------
> >> Current Status: Active WG
> >>
> >> Chairs:
> >>   Dapeng Liu <liudapeng@chinamobile.com>
> >>   Jouni Korhonen <jouni.nospam@gmail.com>
> >>
> >> Assigned Area Director:
> >>   Brian Haberman <brian@innovationslab.net>
> >>
> >> Mailing list
> >>   Address: dmm@ietf.org
> >>   To Subscribe: https://www.ietf.org/mailman/listinfo/dmm
> >>   Archive: http://www.ietf.org/mail-archive/web/dmm
> >>
> >> Charter:
> >>
> >> Mobility management solutions lie at the center of the wireless Internet
> >> and enable mobile devices to partake in IP networks anytime and
> >> anywhere. The IETF Distributed Mobility Management (DMM) working group
> >> (WG) specifies solutions for IP networks so that traffic between mobile
> >> and correspondent nodes can take an optimal route. DMM solutions aim for
> >> transparency above the IP layer, including maintenance of active
> >> transport level sessions when mobile hosts or mobile networks change
> >> their point of attachment to the Internet.
> >>
> >> Wireless network deployments have traditionally relied on hierarchical
> >> schemes that often lead to centralized deployment models, where a small
> >> number of mobility anchors manage both mobility and reachability for a
> >> mobile node. The DMM WG will consider the latest developments in mobile
> >> networking research and operational practice (i.e. flattening network
> >> architectures, the impact of virtualization, new deployment needs as
> >> wireless access technologies evolve in the coming years) and will
> >> describe how distributed mobility management addresses the new needs in
> >> this area better than previously standardized solutions.
> >>
> >> A topic of particular focus will be mobility anchoring in this new
> >> context, and the DMM working group is chartered to work on
> >> maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC
> >> 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new
> >> approaches which capitalize on other protocols specified by the IETF.
> >> For example, mobility management in a limited area, such as within an
> >> autonomous system, is not strictly limited to mentioned IP mobility
> >> protocols but can be any existing or a new protocol solution enabling
> >> the movement of a mobile node such as routing protocols. When extending
> >> protocols that are not based on Mobile IP, DMM solutions will have to be
> >> reviewed by the corresponding WGs.
> >>
> >> IPv6 is assumed to be present in both the mobile host/router and the
> >> access networks. DMM solutions are primarily targeted at IPv6
> >> deployments and are not required to support IPv4, in particular for the
> >> case where private IPv4 addresses and/or NATs are used. DMM solutions
> >> must maintain backward compatibility:  If the network or the mobile
> >> host/router does not support the distributed mobility management
> >> protocol that should not prevent the mobile host/router gaining basic
> >> access (i.e., nomadic) to the network.
> >>
> >> Contrary to earlier IP mobility protocols, mobility management signaling
> >> paths and end-user traffic forwarding paths may differ. Further,
> >> mobility-related functions may be located in separate network nodes. DMM
> >> solutions should not distinguish between physical or virtualized
> >> networking functions. Whenever applicable, clarifications and additional
> >> features/capabilities for specific networking function deployment
> >> models, e.g. in virtualized environments, are in-scope and encouraged.
> >> Solutions may also specify the selection between the care-of addresses
> >> and home address(es)/prefix(es) for different application use cases.
> >>
> >> The working group will produce both informational architectural and
> >> standards track protocol solutions on the following work item topics.
> >>
> >>       o Distributed mobility management deployment models and scenarios:
> >>         describe the target high-level network architectures and
> >>         deployment models where distributed mobility management
> >>         protocol solutions would apply.
> >>
> >>       o Enhanced mobility anchoring: define protocol solutions for a
> >>         gateway and mobility anchor assignment and mid-session mobility
> >>         anchor switching that go beyond what has been specified, for
> >>         example, in RFC 6097, 6463, and 5142. Traffic steering
> >>         associated with the anchor switch is also in-scope if deemed
> >>         appropriate.
> >>
> >>       o Forwarding path and signaling management: the function
> >>         that handles mobility management signaling interacts with the
> >>         DMM network elements for managing the forwarding state
> >>         associated with a mobile node's IP traffic.  These two functions
> >>         may or may not be collocated. Furthermore, the forwarding state
> >>         may also be distributed into multiple network elements instead
> >>         of a single network element (e.g., anchor).  Protocol extensions
> >>         or new protocols will be specified to allow the above mentioned
> >>         forwarding path and signalling management.
> >>
> >>       o Exposing mobility state to mobile nodes and network nodes:
> >>         define solutions that allow, for example, mobile nodes to select
> >>         either a care-of address or a home address depending on an
> >>         application' mobility needs. In order to enable this
> >>         functionality, the network-side control functions and other
> >>         networking nodes must also be able to exchange appropriate
> >>         control information, as well as to the mobile nodes and their
> >>         applications.
> >>
> >> The working group may decide to extend the current milestones based on
> >> the new information and knowledge gained during working on other
> >> documents listed in the initial milestones. Possible new documents and
> >> milestones must still fit into the overall DMM charter scope as outlined
> >> above.
> >>
> >> Milestones:
> >
> >
> > _______________________________________________
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
> 
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm