Subject: [netlmm] #128: Move Reference Architecture from PS to REQ document

From: netlmm <[email-masked]>
Date: Thu, 07 Sep 2006 17:38:57 -0000

#128: Move Reference Architecture from PS to REQ document
-----------------------------------------+----------------------------------
 Reporter:  [email-masked]     |       Owner:  [email-masked]
     Type:  defect                       |      Status:  new                     
 Priority:  major                        |   Milestone:  milestone4              
Component:  draft-ietf-netlmm-nohost-ps  |     Version:  2.0                     
 Keywords:  PS draft                     |  
-----------------------------------------+----------------------------------
 Eric Rescorla says:

 In particular, the reference
 architecture is hidden in draft-ietf-netlmm-nohost-ps-04 in the second
 half of a section entitled "Problems with Existing Solutions". At
 minimum the -req document should contain a section with the reference
 architecture

-- 
Ticket URL: <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/128>
netlmm <http://tools.ietf.org/wg/netlmm/>
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: netlmm <[email-masked]>
Date: Thu, 07 Sep 2006 17:46:08 -0000

#128: Move Reference Architecture from PS to REQ document
------------------------------------------+---------------------------------
  Reporter:  [email-masked]     |       Owner:  [email-masked]
      Type:  defect                       |      Status:  assigned                
  Priority:  major                        |   Milestone:  milestone4              
 Component:  draft-ietf-netlmm-nohost-ps  |     Version:  2.0                     
Resolution:                               |    Keywords:  PS draft                
------------------------------------------+---------------------------------
Changes (by [email-masked]):

  * status:  new => assigned

Comment:

 Dan Romascanu had a similar issue, and I did move the reference
 architecture to a separate section in the 05 version of the PS document,
 as yet unreleased. But I think ekr has a point also, and therefore I'm
 going to move the reference architecture description from the PS to the
 REQ document, and provide more detail, in particular, with the terms the
 WG is now using for the various components (LMA, MAG, etc.). This will
 provide more context for the goals, since they do apply to the reference
 architecture.

---

From: netlmm <[email-masked]>
Date: Fri, 08 Sep 2006 22:46:20 -0000

#128: Move Reference Architecture from PS to REQ document
------------------------------------------+---------------------------------
  Reporter:  [email-masked]     |       Owner:  [email-masked]
      Type:  defect                       |      Status:  closed                  
  Priority:  major                        |   Milestone:  milestone4              
 Component:  draft-ietf-netlmm-nohost-ps  |     Version:  2.0                     
Resolution:  fixed                        |    Keywords:  PS draft                
------------------------------------------+---------------------------------
Changes (by [email-masked]):

  * resolution:  => fixed
  * status:  assigned => closed

Comment:

 Edited Section 1 to focus on NETLMM protocol, added terminology for
 functional architecture, and inserted Section 2 discussing functional
 archtecture. The text is below.

 --------------------------

 Introduction

 In [9], the basic problems that occur when a global mobility protocol is
 used for managing local mobility are described, and two currently used
 approaches to localized mobility management - the host-based approach that
 is used by most IETF protocols, and the proprietary WLAN switch approach
 used between WLAN switches in different subnets - are examined. The
 conclusion from the problem statement document is that none of the
 approaches has a complete solution to the problem. While the WLAN switch
 approach is most convenient for network operators and users because it
 requires no software on the mobile node other than the standard drivers
 for WiFi, the proprietary nature limits interoperability and the
 restriction to a single last hop link type and wired backhaul link type
 restricts scalability. The IETF host-based protocols require host software
 stack changes that may not be compatible with all global mobility
 protocols, and also require specialized and complex security transactions
 with the network that may limit deployability. The conclusion was that a
 localized mobility management protocol that was network based and required
 no software on the host for localized mobility management is desirable.

 This document develops a brief functional architecture and detailed goals
 for a network-based localized mobility management protocol (NETLMM).
 Section 2.0 describes the functional architecture of NETLMM. In Section
 3.0, a list of goals that are desirable in the NETLMM protocol is
 presented. Section 4.0 briefly outlines security considerations. More
 discussion of security can be found in the threat analysis document [20].

 1.1     Terminology

 Mobility terminology in this draft follows that in RFC 3753 [13] and in
 [9]. In addition, the following terms are related to the functional
 architecture described in Section 2.0:

 Localized Mobility Management Domain

 An Access Network in the sense defined in [9] in which mobility is handled
 by the NETLMM protocol.

 Mobile Access Gateway

 A Mobile Access Gateway (MAG) is a functional network element that
 terminates a specific edge link and tracks mobile node IP level mobility
 between edge links, through NETLMM signaling with the Localized Mobility
 Anchor. The MAG also terminates host routed data traffic from the
 Localized Mobility Anchor for mobile nodes currently located within the
 edge link under the MAG's control, and forwards data traffic from mobile
 nodes on the edge link under its control to the Localized Mobility Anchor.

 Local Mobility Anchor

 A Local Mobility Anchor (LMA) is a router that maintains a collection of
 host routes and associated forwarding information for mobile nodes within
 a localized mobility management domain under its control. Together with
 the MAGs associated with it, the LMA uses the NETLMM protocol to manage
 mobile node mobility within the localized mobility management domain.
 Routing of mobile node data traffic is anchored at the LMA as the mobile
 node moves around within the localized mobility management domain.

 2.0     NETLMM Functional Architecture

 The NETLMM architecture consists of the following components. Localized
 Mobility Anchors (LMAs) within the backbone network maintain a collection
 of routes for individual mobile nodes within the localized mobility
 management domain. The routes point to the Mobile Access Gateways (MAGs)
 managing the links on which the mobile nodes currently are located.
 Packets for a mobile node are routed to and from the mobile node through
 tunnels between the LMA and MAG. When a mobile node moves from one link to
 another, the MAG sends a route update to the LMA. While some mobile node
 involvement is necessary and expected for generic mobility functions such
 as movement detection and to inform the MAG about mobile node movement, no
 specific mobile node to network protocol will be required for localized
 mobility management itself. Host stack involvement in mobility management
 is thereby limited to generic mobility functions at the IP layer, and no
 specialized localized mobility management software is required.