headers
Peer Azmat Shah | 22 Dec 2011 06:25
Picon
Favicon

Re: [MEXT] MEXT Digest, Vol 54, Issue 12

In my opinion, the term " traffic is distributed in an optimal way" seems ambiguous. 
From this statement, one can get confused, that aim of DMM is to distribute the whole data traffic along-with handling mobility in a distributed manner.

One thing more: when we talk about DMM, then it means that we have to make changes in the network (routers, gateways, access points, base stations) so that they can handle mobility in a combined effort, not relying on a single MAP. But in 2nd paragraph of charter, it is written "either host- or network-based" means that new solutions can be either network based or host based (E2E). How, a mobility solution that works in a distributed manner can be host based (E2E)? It will be a network based solution.
 
regards
---------------

Peer Azmat Shah

1.  Ph.D Fellow | Department of CIS | Universiti Teknologi PETRONAS, Malaysia | +60 14 345 6020
2.  Lecturer | Department of CS | COMSATS University of Science & Technology, Pakistan | +92 321 582 2507


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

Message: 1
Date: Tue, 20 Dec 2011 10:29:53 +0200
From: Jari Arkko <jari.arkko <at> piuha.net>
To: jouni korhonen <jouni.nospam <at> gmail.com>
Cc: "julien.ietf <at> gmail.com Laganier" <julien.ietf <at> gmail.com>,
    mext <at> ietf.org
Subject: Re: [MEXT] The first proposal for the DMM charter
Message-ID: <4EF04781.3080700 <at> piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I think this looks very good, but I would still take into account Pierrick's suggested edits, and I think we have to be far more specific about that "can be transparent to any underlying mobility protocol part", because it confuses me. And per questions on the list, it seems to confuse other people too.

Suggested edits below. I have sent this version to the IESG and IAB, but I expect that the chairs may produce additional refined versions.

Distributed Mobility Management (DMM)
-------------------------------------

Charter

  Current Status: Active

  Chairs:
      Julien Laganier <julien.ietf <at> gmail.com>
      Jouni Korhonen <jouni.nospam <at> gmail.com>

  Internet Area Directors:
      Ralph Droms <rdroms.ietf <at> gmail.com>
      Jari Arkko <jari.arkko <at> piuha.net>

  Internet Area Advisor:
      Jari Arkko <jari.arkko <at> piuha.net>

  Mailing Lists:
      General Discussion: mext <at> ietf.org
      To Subscribe:      https://www.ietf.org/mailman/listinfo/mext
      Archive:            http://www.ietf.org/mail-archive/web/mext

Description of Working Group:

  The Distributed Mobility Management (DMM) working group specifies IP
  mobility, access network and routing solutions, which allow for
  setting up IP networks so that traffic is distributed in an
  optimal way and does not rely on centrally deployed anchors to manage
  IP mobility sessions. The distributed mobility management solutions
  aim for transparency above the IP layer, including maintenance of
  active transport level sessions as mobile hosts or entire mobile
  networks change their point of attachment to the Internet.

  The protocol solutions should be based on existing IP mobility
  protocols, either host- or network-based, such as Mobile IPv6
  [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
  NEMO [RFC3963]. Solutions may also focus specifically
  on managing the use of care-of versus home addresses in an
  efficient manner for different types of communications.

  Although the maintenance of stable home address(es) and/or prefix(es)
  and upper level sessions is a desirable goal when mobile hosts/routers
  change their point of attachment to the Internet, it is not a strict
  requirement. Mobile hosts/routers should not assume that IP
  addressing including home address(es) and/or home network prefix(es)
  remain the same throughout the entire upper level session lifetime,
  or that support for mobility functions is provided on the network side
  in all conditions.

  The distributed mobility management solutions primarily target IPv6
  Deployment and should not be tailored specifically to support IPv4,
  in particular in situations where private IPv4 addresses and/or NATs
  are used. At least IPv6 is assumed to be present in both the mobile
  host/router and the access networks. Independent of the distributed
  mobility management solution, backward compatibility must be
  maintained. If the network or the mobile host/router do not support
  the distributed mobility management enabling protocol, nothing should
  break.

Work items related to the distributed mobility management include:

  o Solution Requirements: Define precisely the problem of distributed
    mobility management and identity the requirements for a distributed
    mobility management solution.

  o Best practices: Document best practices for the
      deployment of existing mobility protocols in a distributed mobility
      management environment.

  o  Gap Analysis and extensions: identify the limitations in the best current
      practices with respect to providing the expected functionality.

  o If limitations are identified as part of the above deliverable,
    specify extensions to existing protocols that removes these
    limitations within a distributed mobility management environment.

Goals and Milestones:

  Aug 2012 - Submit I-D 'Solution Requirements' as a working
              group document. To be Informational RFC.
  Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working
              group document. To be Informational RFC.
  Nov 2012 - Evaluate the need for additional working group document(s)
              for extensions to fill the identified gaps.
  Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
              consideration as an Informational RFC.
  Jan 2013 - Submit I-D 'Best practices ' to the IESG for
              consideration as an Informational RFC.
  Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for
              consideration as an Informational RFC.
  Mar 2013 - Evaluate the need for further work based on the identified gaps
              and revise the milestones and/or the charter of the group



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

Message: 2
Date: Tue, 20 Dec 2011 10:52:15 +0200
From: jouni korhonen <jouni.nospam <at> gmail.com>
To: Jari Arkko <jari.arkko <at> piuha.net>
Cc: "julien.ietf <at> gmail.com Laganier" <julien.ietf <at> gmail.com>,
    mext <at> ietf.org
Subject: Re: [MEXT] The first proposal for the DMM charter
Message-ID: <563F11DB-2F08-40AC-A788-70CBE9EFE745 <at> gmail.com>
Content-Type: text/plain; charset=us-ascii


Jari,


On Dec 20, 2011, at 10:29 AM, Jari Arkko wrote:

> I think this looks very good, but I would still take into account Pierrick's suggested edits, and I think we have to be far more specific about that "can be transparent to any underlying mobility protocol part", because it confuses me. And per questions on the list, it seems to confuse other people too.

Thanks for the edit. The "transparent" part was definitely poorly worded as it was meant for bettering the use of CoAs.. But wording ended up far too open ended. The new text expresses the original intent clearly.

I also agree with Pierrick's comments that are now also included.

- Jouni


>
> Suggested edits below. I have sent this version to the IESG and IAB, but I expect that the chairs may produce additional refined versions.
>
> Distributed Mobility Management (DMM)
> -------------------------------------
>
> Charter
>
> Current Status: Active
>
> Chairs:
>    Julien Laganier <julien.ietf <at> gmail.com>
>    Jouni Korhonen <jouni.nospam <at> gmail.com>
>
> Internet Area Directors:
>    Ralph Droms <rdroms.ietf <at> gmail.com>
>    Jari Arkko <jari.arkko <at> piuha.net>
>
> Internet Area Advisor:
>    Jari Arkko <jari.arkko <at> piuha.net>
>
> Mailing Lists:
>    General Discussion: mext <at> ietf.org
>    To Subscribe:      https://www.ietf.org/mailman/listinfo/mext
>    Archive:            http://www.ietf.org/mail-archive/web/mext
>
> Description of Working Group:
>
>  The Distributed Mobility Management (DMM) working group specifies IP
>  mobility, access network and routing solutions, which allow for
>  setting up IP networks so that traffic is distributed in an
>  optimal way and does not rely on centrally deployed anchors to manage
>  IP mobility sessions. The distributed mobility management solutions
>  aim for transparency above the IP layer, including maintenance of
>  active transport level sessions as mobile hosts or entire mobile
>  networks change their point of attachment to the Internet.
>
>  The protocol solutions should be based on existing IP mobility
>  protocols, either host- or network-based, such as Mobile IPv6
>  [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
>  NEMO [RFC3963]. Solutions may also focus specifically
>  on managing the use of care-of versus home addresses in an
>  efficient manner for different types of communications.
>
>  Although the maintenance of stable home address(es) and/or prefix(es)
>  and upper level sessions is a desirable goal when mobile hosts/routers
>  change their point of attachment to the Internet, it is not a strict
>  requirement. Mobile hosts/routers should not assume that IP
>  addressing including home address(es) and/or home network prefix(es)
>  remain the same throughout the entire upper level session lifetime,
>  or that support for mobility functions is provided on the network side
>  in all conditions.
>
>  The distributed mobility management solutions primarily target IPv6
>  Deployment and should not be tailored specifically to support IPv4,
>  in particular in situations where private IPv4 addresses and/or NATs
>  are used. At least IPv6 is assumed to be present in both the mobile
>  host/router and the access networks. Independent of the distributed
>  mobility management solution, backward compatibility must be
>  maintained. If the network or the mobile host/router do not support
>  the distributed mobility management enabling protocol, nothing should
>  break.
>
> Work items related to the distributed mobility management include:
>
>  o Solution Requirements: Define precisely the problem of distributed
>    mobility management and identity the requirements for a distributed
>    mobility management solution.
>
>  o Best practices: Document best practices for the
>    deployment of existing mobility protocols in a distributed mobility
>    management environment.
>
> o  Gap Analysis and extensions: identify the limitations in the best current
>    practices with respect to providing the expected functionality.
>
>  o If limitations are identified as part of the above deliverable,
>    specify extensions to existing protocols that removes these
>    limitations within a distributed mobility management environment.
>
> Goals and Milestones:
>
>  Aug 2012 - Submit I-D 'Solution Requirements' as a working
>            group document. To be Informational RFC.
>  Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working
>            group document. To be Informational RFC.
>  Nov 2012 - Evaluate the need for additional working group document(s)
>            for extensions to fill the identified gaps.
>  Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
>            consideration as an Informational RFC.
>  Jan 2013 - Submit I-D 'Best practices ' to the IESG for
>            consideration as an Informational RFC.
>  Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for
>            consideration as an Informational RFC.
>  Mar 2013 - Evaluate the need for further work based on the identified gaps
>            and revise the milestones and/or the charter of the group
>



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

Message: 3
Date: Mon, 19 Dec 2011 11:57:44 +0100
From: <pierrick.seite <at> orange.com>
To: <jouni.nospam <at> gmail.com>,    <mext <at> ietf.org>
Cc: julien.ietf <at> gmail.com, jari.arkko <at> piuha.net
Subject: Re: [MEXT] The first proposal for the DMM charter
Message-ID:
    <843DA8228A1BA74CA31FB4E111A5C46202169B1B <at> ftrdmel0.rd.francetelecom.fr>
   
Content-Type: text/plain;    charset="iso-8859-1"

Hi Jouni,

It seems that I've some trouble with my mail box.... Please see below my comments sent on Friday...

Pierrick

> -----Message d'origine-----
> De?: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] De la part de
> jouni korhonen
> Envoy??: dimanche 18 d?cembre 2011 23:21
> ??: mext <at> ietf.org
> Cc?: julien.ietf <at> gmail.com Laganier; jouni korhonen; Jari Arkko
> Objet?: Re: [MEXT] The first proposal for the DMM charter
>
>
> Folks,
>
> Based of the "feedback" can I assume folks are mostly happy with the
> current text?
>
> - Jouni
>


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

Hi Jouni & Julien,

This charter looks good. However, please see inline few suggestions for modifications.

Thanks,
Pierrick

> -----Message d'origine-----
> De : mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] De la part
> de jouni korhonen Envoy? : mercredi 14 d?cembre 2011 09:54 ? :
> mext <at> ietf.org Cc : julien.ietf <at> gmail.com Laganier; jouni korhonen;
> Jari Arkko Objet : [MEXT] The first proposal for the DMM charter
>
> Folks,
>
> We have been working on a charter text from DMM based on the initial
> goal setting and the input we received during the Taipei meeting. Note
> that this is the first draft and now we are soliciting for input.
>
> - Jouni & Julien
>
>
> ----------------------------------------------------------------------
> -
> --
>
> Distributed Mobility Management (DMM)
> -------------------------------------
>
> Charter
>
>  Current Status: Active
>
>  Chairs:
>      Julien Laganier <julien.ietf <at> gmail.com>
>      Jouni Korhonen <jouni.nospam <at> gmail.com>
>
>  Internet Area Directors:
>      Ralph Droms <rdroms.ietf <at> gmail.com>
>      Jari Arkko <jari.arkko <at> piuha.net>
>
>  Internet Area Advisor:
>      Jari Arkko <jari.arkko <at> piuha.net>
>
>  Mailing Lists:
>      General Discussion: mext <at> ietf.org
>      To Subscribe:      https://www.ietf.org/mailman/listinfo/mext
>      Archive:            http://www.ietf.org/mail-archive/web/mext
>
> Description of Working Group:
>
>  The Distributed Mobility Management (DMM) working group specifies IP
>  mobility, access network and routing solutions, which allow for
>  setting up IP networks so that traffic is distributed in an
>  optimal way and does not rely on centrally deployed anchors to manage
>  IP mobility sessions. The distributed mobility management solutions
>  aim for transparency above the IP layer, including maintenance of
>  active transport level sessions as mobile hosts or entire mobile
>  networks change their point of attachment to the Internet.
>
>  The protocol solutions should be enhancements to existing IP mobility
>  protocols, either host- or network-based, such as Mobile IPv6
>  [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
>  NEMO [RFC3963].

This sentence gives the impression that extensions to MIP/PMIP will be necessary, i.e. here, the charter seems put extensions as a requirement (I don't think it is the goal :-)). It appears to be inconsistent with the two steps approach suggested by the work items: best current practices (without protocol modification), then, if necessary, specify extensions. So, I'd suggest to reword as follows:

The protocol solutions should be based on existing IP mobility
  Protocols and related mechanisms, either host- or network-based, such as Mobile IPv6
  [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
  NEMO [RFC3963].

Alternatively, the distributed mobility management
>  solution can be transparent to any underlying IP mobility protocol.
>  Although the maintenance of stable home address(es) and/or prefix(es)
>  and upper level sessions is a desirable goal when mobile
> hosts/routers
>  change their point of attachment to the Internet, it is not a strict
>  requirement. Mobile hosts/routers should not assume that IP
>  addressing including home address(es) and/or home network prefix(es)
>  remain the same throughout the entire upper level session lifetime.
>

I suggest to add the following statement:

Mobile hosts/routers should not assume always-on mobility support.

>  The distributed mobility management solutions primarily target IPv6
>  Deployment and should not be tailored specifically to support IPv4,
>  in particular in situations where private IPv4 addresses and/or NATs
>  are used. At least IPv6 is assumed to be present in both the mobile
>  host/router and the access networks. Independent of the distributed
>  mobility management solution, backward compatibility must be
>  maintained. If the network or the mobile host/router do not support
>  the distributed mobility management enabling protocol, nothing should
>  break.
>
> Work items related to the distributed mobility management include:
>
>  o Solution Requirements: Define precisely the problem of distributed
>    mobility management and identity the requirements for a distributed
>    mobility management solution.
>
>  o Best practices and Gap Analysis: Document best practices for the
>    deployment of existing mobility protocols in a distributed mobility
>    management environment and identify the limitations of each such
>    approach with respect to fulfillment of the solution requirements.
>
>  o If limitations are identified as part of the above deliverable,
>    specify extensions to existing protocols that removes these
>    limitations within a distributed mobility management environment.
>

IMHO, the gap analysis should not be part of the best current practices. The BCP may stress some limitations but an exhaustive gap analysis should be the motivation for protocols extensions. So, I suggest to rearrange work items as follows:

  o Best practices: Document best practices for the
    deployment of existing mobility protocols in a distributed mobility
    management environment.


o  Gap Analysis and extensions: identify the limitations of each such
    approach with respect to fulfillment of the solution requirements. If limitations are,
    specify extensions to existing protocols that removes these
    limitations within a distributed mobility management environment.


> Goals and Milestones:
>
>  Aug 2012 - Submit I-D 'Solution Requirements' as a working
>              group document. To be Informational RFC.
>  Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working
>              group document. To be Informational RFC.

As explained above, I think the gap analysis should not be part of the BCP. So, this goal should be:

  Aug 2012 - Submit I-D 'Best practices' as a working
              group document. To be Informational RFC.

>  Nov 2012 - Evaluate the need for additional working group document(s)
>              for extensions to fill the identified gaps.

Extensions should be motivated by a complete gap analysis. So, this goal should be:

Nov 2012 - Gap analysis and evaluation for the need of additional working group document(s)
            for extensions to fill the identified gaps.

>  Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
>              consideration as an Informational RFC.
>  Jan 2013 - Submit I-D 'Best practices and Gap Analysis' to the IESG
> for
>              consideration as an Informational RFC.
>  Mar 2013 - Conclude the working group or re-charter.
>
>
> _______________________________________________
> MEXT mailing list
> MEXT <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mext


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

Message: 4
Date: Tue, 20 Dec 2011 19:54:13 +0100
From: Conny Larsson <conny.larsson <at> ericsson.com>
To: jouni korhonen <jouni.nospam <at> gmail.com>, "julien.ietf <at> gmail.com
    Laganier"    <julien.ietf <at> gmail.com>
Cc: Jari Arkko <jari.arkko <at> piuha.net>, "mext <at> ietf.org" <mext <at> ietf.org>
Subject: Re: [MEXT] The first proposal for the DMM charter
Message-ID: <4EF0D9D5.2070609 <at> ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed

Hi Jouni, Julien

I believe the charter looks good but I would like to ask you if
deployment scenarios are covered by the charter or not (I'm thinking of
a Informational RFC)?

Let me be a bit more specific. When discussing DMM (in a 3GPP
perspective) with people I  get the impression that many operators are
interested in the topic but that they have very few peering points. They
are not always interested (or they do not see the need) in deploying
more peering points since they are expensive. Perhaps the reason for
this is related to the current hierarchical architecture and will change
with a more distributed architecture.

So what do you think? Is there a need for this kind of document?

Best Regards
Conny


On 2011-12-14 09:54, jouni korhonen wrote:
> Folks,
>
> We have been working on a charter text from DMM based on the initial goal setting and the input we received during the Taipei meeting. Note that this is the first draft and now we are soliciting for input.
>
> - Jouni&  Julien
>
>
> -------------------------------------------------------------------------
>
> Distributed Mobility Management (DMM)
> -------------------------------------
>
> Charter
>
>  Current Status: Active
>
>  Chairs:
>      Julien Laganier<julien.ietf <at> gmail.com>
>      Jouni Korhonen<jouni.nospam <at> gmail.com>
>
>  Internet Area Directors:
>      Ralph Droms<rdroms.ietf <at> gmail.com>
>      Jari Arkko<jari.arkko <at> piuha.net>
>
>  Internet Area Advisor:
>      Jari Arkko<jari.arkko <at> piuha.net>
>
>  Mailing Lists:
>      General Discussion: mext <at> ietf.org
>      To Subscribe:      https://www.ietf.org/mailman/listinfo/mext
>      Archive:            http://www.ietf.org/mail-archive/web/mext
>
> Description of Working Group:
>
>    The Distributed Mobility Management (DMM) working group specifies IP
>    mobility, access network and routing solutions, which allow for
>    setting up IP networks so that traffic is distributed in an
>    optimal way and does not rely on centrally deployed anchors to manage
>    IP mobility sessions. The distributed mobility management solutions
>    aim for transparency above the IP layer, including maintenance of
>    active transport level sessions as mobile hosts or entire mobile
>    networks change their point of attachment to the Internet.
>
>    The protocol solutions should be enhancements to existing IP mobility
>    protocols, either host- or network-based, such as Mobile IPv6
>    [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
>    NEMO [RFC3963]. Alternatively, the distributed mobility management
>    solution can be transparent to any underlying IP mobility protocol.
>    Although the maintenance of stable home address(es) and/or prefix(es)
>    and upper level sessions is a desirable goal when mobile hosts/routers
>    change their point of attachment to the Internet, it is not a strict
>    requirement. Mobile hosts/routers should not assume that IP
>    addressing including home address(es) and/or home network prefix(es)
>    remain the same throughout the entire upper level session lifetime.
>
>    The distributed mobility management solutions primarily target IPv6
>    Deployment and should not be tailored specifically to support IPv4,
>    in particular in situations where private IPv4 addresses and/or NATs
>    are used. At least IPv6 is assumed to be present in both the mobile
>    host/router and the access networks. Independent of the distributed
>    mobility management solution, backward compatibility must be
>    maintained. If the network or the mobile host/router do not support
>    the distributed mobility management enabling protocol, nothing should
>    break.
>
> Work items related to the distributed mobility management include:
>
>    o Solution Requirements: Define precisely the problem of distributed
>      mobility management and identity the requirements for a distributed
>      mobility management solution.
>
>    o Best practices and Gap Analysis: Document best practices for the
>      deployment of existing mobility protocols in a distributed mobility
>      management environment and identify the limitations of each such
>      approach with respect to fulfillment of the solution requirements.
>
>    o If limitations are identified as part of the above deliverable,
>      specify extensions to existing protocols that removes these
>      limitations within a distributed mobility management environment.
>
> Goals and Milestones:
>
>    Aug 2012 - Submit I-D 'Solution Requirements' as a working
>              group document. To be Informational RFC.
>    Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working
>              group document. To be Informational RFC.
>    Nov 2012 - Evaluate the need for additional working group document(s)
>              for extensions to fill the identified gaps.
>    Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
>              consideration as an Informational RFC.
>    Jan 2013 - Submit I-D 'Best practices and Gap Analysis' to the IESG for
>              consideration as an Informational RFC.
>    Mar 2013 - Conclude the working group or re-charter.
>
>
> _______________________________________________
> MEXT mailing list
> MEXT <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>




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

_______________________________________________
MEXT mailing list
MEXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext


End of MEXT Digest, Vol 54, Issue 12
************************************


_______________________________________________
MEXT mailing list
MEXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext
Permalink | Reply |
headers
jouni korhonen | 22 Dec 2011 08:05
Picon

Re: [MEXT] The first proposal for the DMM charter was Re: MEXT Digest, Vol 54, Issue 12


On Dec 22, 2011, at 7:25 AM, Peer Azmat Shah wrote:
> 
> 
> One thing more: when we talk about DMM, then it means that we have to make changes in the network (routers,
gateways, access points, base stations) so that they can handle mobility in a combined effort, not
relying on a single MAP. But in 2nd paragraph of charter, it is written "either host- or network-based"
means that new solutions can be either network based or host based (E2E). How, a mobility solution that
works in a distributed manner can be host based (E2E)? It will be a network based solution. 

Not necessarily. Say that a mobile node evaluates each time it moves whether there is a need to a) find a more
suitable anchor for subsequent sessions or b) whether use CoA instead of HoA for new sessions. For that
network based solution is not needed.

- Jouni

ps: please, do not change the subject.. it complicates following the thread.

>  
> regards
> ---------------
> 
> Peer Azmat Shah
> 
> 1.  Ph.D Fellow | Department of CIS | Universiti Teknologi PETRONAS, Malaysia | +60 14 345 6020
> 2.  Lecturer | Department of CS | COMSATS University of Science & Technology, Pakistan | +92 321 582 2507
> 
> 

[snip]
Permalink | Reply |
headers
pierrick.seite | 22 Dec 2011 10:44

Re: The first proposal for the DMM charter


> -----Message d'origine-----
> De : mext-bounces@...
[mailto:mext-bounces@...] De la part de
> jouni korhonen
> Envoyé : jeudi 22 décembre 2011 08:05
> À : Peer Azmat Shah
> Cc : mext@...
> Objet : Re: [MEXT] The first proposal for the DMM charter was Re:
> MEXTDigest, Vol 54, Issue 12
> 
> 
> On Dec 22, 2011, at 7:25 AM, Peer Azmat Shah wrote:
> >
> >
> > One thing more: when we talk about DMM, then it means that we have to
> make changes in the network (routers, gateways, access points, base
> stations) so that they can handle mobility in a combined effort, not
> relying on a single MAP. But in 2nd paragraph of charter, it is written
> "either host- or network-based" means that new solutions can be either
> network based or host based (E2E). How, a mobility solution that works
> in a distributed manner can be host based (E2E)? It will be a network
> based solution.
> 

I do not see the point. Why are you saying only network based solutions apply to DMM?

> Not necessarily. Say that a mobile node evaluates each time it moves
> whether there is a need to a) find a more suitable anchor for
> subsequent sessions or b) whether use CoA instead of HoA for new
> sessions. For that network based solution is not needed.
> 

I second Jouni. Moreover, a  basic of DMM is the distribution of mobility anchors. IMHO, this is independent
of the location of the mobility client; this principle can be applied either to host based or network based
mobility management.

Pierrick

> - Jouni
> 
> ps: please, do not change the subject.. it complicates following the
> thread.
> 
> 
> >
> > regards
> > ---------------
> >
> > Peer Azmat Shah
> >
> > 1.  Ph.D Fellow | Department of CIS | Universiti Teknologi PETRONAS,
> Malaysia | +60 14 345 6020
> > 2.  Lecturer | Department of CS | COMSATS University of Science &
> Technology, Pakistan | +92 321 582 2507
> >
> >
> 
> [snip]
> 
> _______________________________________________
> MEXT mailing list
> MEXT@...
> https://www.ietf.org/mailman/listinfo/mext
Permalink | Reply |
headers
pierrick.seite | 22 Dec 2011 10:44

Re: [MEXT] The first proposal for the DMM charter


> -----Message d'origine-----
> De : mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] De la part de
> jouni korhonen
> Envoyé : jeudi 22 décembre 2011 08:05
> À : Peer Azmat Shah
> Cc : mext <at> ietf.org
> Objet : Re: [MEXT] The first proposal for the DMM charter was Re:
> MEXTDigest, Vol 54, Issue 12
> 
> 
> On Dec 22, 2011, at 7:25 AM, Peer Azmat Shah wrote:
> >
> >
> > One thing more: when we talk about DMM, then it means that we have to
> make changes in the network (routers, gateways, access points, base
> stations) so that they can handle mobility in a combined effort, not
> relying on a single MAP. But in 2nd paragraph of charter, it is written
> "either host- or network-based" means that new solutions can be either
> network based or host based (E2E). How, a mobility solution that works
> in a distributed manner can be host based (E2E)? It will be a network
> based solution.
> 

I do not see the point. Why are you saying only network based solutions apply to DMM?

> Not necessarily. Say that a mobile node evaluates each time it moves
> whether there is a need to a) find a more suitable anchor for
> subsequent sessions or b) whether use CoA instead of HoA for new
> sessions. For that network based solution is not needed.
> 

I second Jouni. Moreover, a  basic of DMM is the distribution of mobility anchors. IMHO, this is independent
of the location of the mobility client; this principle can be applied either to host based or network based
mobility management.

Pierrick

> - Jouni
> 
> ps: please, do not change the subject.. it complicates following the
> thread.
> 
> 
> >
> > regards
> > ---------------
> >
> > Peer Azmat Shah
> >
> > 1.  Ph.D Fellow | Department of CIS | Universiti Teknologi PETRONAS,
> Malaysia | +60 14 345 6020
> > 2.  Lecturer | Department of CS | COMSATS University of Science &
> Technology, Pakistan | +92 321 582 2507
> >
> >
> 
> [snip]
> 
> _______________________________________________
> MEXT mailing list
> MEXT <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mext
Permalink | Reply |
headers
jouni korhonen | 22 Dec 2011 08:05
Picon

Re: [MEXT] The first proposal for the DMM charter was Re: MEXT Digest, Vol 54, Issue 12


On Dec 22, 2011, at 7:25 AM, Peer Azmat Shah wrote:
> 
> 
> One thing more: when we talk about DMM, then it means that we have to make changes in the network (routers,
gateways, access points, base stations) so that they can handle mobility in a combined effort, not
relying on a single MAP. But in 2nd paragraph of charter, it is written "either host- or network-based"
means that new solutions can be either network based or host based (E2E). How, a mobility solution that
works in a distributed manner can be host based (E2E)? It will be a network based solution. 

Not necessarily. Say that a mobile node evaluates each time it moves whether there is a need to a) find a more
suitable anchor for subsequent sessions or b) whether use CoA instead of HoA for new sessions. For that
network based solution is not needed.

- Jouni

ps: please, do not change the subject.. it complicates following the thread.

>  
> regards
> ---------------
> 
> Peer Azmat Shah
> 
> 1.  Ph.D Fellow | Department of CIS | Universiti Teknologi PETRONAS, Malaysia | +60 14 345 6020
> 2.  Lecturer | Department of CS | COMSATS University of Science & Technology, Pakistan | +92 321 582 2507
> 
> 

[snip]
Permalink | Reply |

Gmane