Jouni wrote: > > Hi, > > On May 25, 2012, at 3:57 PM, <[email protected]> > <[email protected]> wrote: > >> Hi Jouni, >> >> Answering to your question(s): >> >>> At least we need to make a distinction what cross administrative >>> domain would mean: a) is it the MN moving across administrative >>> domains or b) possibly (current) IP level anchor changing across >>> administrative domains. >> >> Georgios: Please note that I was referring to both cases! > > Since I have difficulties believing b) would be a successful > requirement without slicing it into different use cases, I would ask > you to list up what use cases you think b) is needed for and what > assumptions there are for IP anchoring & possible tunnel state.
Personally I think that network-based DMM should always be focusing on the intra-domain problem, because addressing the inter-domain problem requires all kinds of interworking and security relationships between domains which are hard to manage in a scalable way. Inter-domain mobility should probably always use a client-based mobility scheme, which only requires a relationship between the MN and the first network and can work over any third party network, as long as it provides Internet access. However, I think it would be in scope of DMM to consider methods of rapidly allocating/deallocating a mobility anchor in the first network for use when the MN has moved out of that network into another. This would be accomplished while the MN is in the first network and wouldn't need to require involvement or cooperation from the second network. -Pete > > - Jouni > > > > > >> >> Best regards, >> Georgios >> >> >> >> >>> -----Original Message----- >>> From: Jouni [mailto:[email protected]] >>> Sent: vrijdag 25 mei 2012 14:49 >>> To: Karagiannis, G. (EWI) >>> Cc: [email protected]; [email protected]; >>> [email protected] >>> Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment >>> (single-operator and cross-operator?) >>> >>> >>> On May 25, 2012, at 3:21 PM, <[email protected]> >>> <[email protected]> wrote: >>> >>>> Hi Pierrick, >>>> >>>> Please see in line! >>>> >>>> >>>>> -----Original Message----- >>>>> From: [email protected] >>>>> [mailto:[email protected]] >>>>> Sent: vrijdag 25 mei 2012 14:00 >>>>> To: Karagiannis, G. (EWI); [email protected] >>>>> Cc: [email protected] >>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed >>>>> deployment (single-operator and cross-operator?) >>>>> >>>>> Hi, >>>>> >>>>> As an operator guy, I will not dispute a use-case dealing with >>>>> roaming :-). However I think that it is out of the scope of our >>>>> considerations here (I mean, from the IETF standpoint). IMU, the >>>>> goal of DMM is not to specify a full system architecture (to which >>>>> statement (1) below seems to refer); the goal of DMM is, in a first >>>>> stage, to assess the use of legacy protocols in a distributed >>>>> anchoring > deployment. >>>> >>>> Georgios: Not really defining a system architecture, but more the >>>> protocol >>> framework! The definition of the "distribution anchoring deployment" >>> borders is part of that! >>> >>> From my point of view, the protocol solutions (even what we have today >>> in mobility area) do not prohibit cross administrative domain >>> mobility. It is more a deployment decision loaded with non-techninal >>> far from trivial issues. >>> >>> I do not like seeing this as a requirement. At least we need to >>> make a distinction what cross administrative domain would mean: a) >>> is it the MN moving across administrative domains or b) possibly >>> (current) IP level anchor changing across administrative domains. >>> >>> - Jouni >>> >>> >>> >>>> >>>>> >>>>> Moreover, statement (2) below, is more a solution hints than a >>>>> requirement. Typically, (2) is about HA/LMA relocation which may be, >>>>> or not, a solution to meet Anthony's req#1. So, IMHO, req#1 >>>>> addresses your >>> concern. >>>> >>>> Georgios: I think that the current description of REQ-1 is not really >>>> addressing my concern! >>>> >>>> Best regards, >>>> Georgios >>>> >>>>> >>>>> That's only my opinion; let's see what others think. >>>>> >>>>> BR, >>>>> Pierrick >>>>> >>>>>> -----Message d'origine----- De : [email protected] >>>>>> [mailto:[email protected]] Envoyé : vendredi 25 mai 2012 12:28 >>>>>> À : SEITE Pierrick RD-RESA-REN; [email protected] Cc : >>>>>> [email protected] Objet : RE: [DMM] draft requirement REQ-1: Distributed >>>>>> deployment (single-operator and cross-operator?) >>>>>> >>>>>> Hi Pierrick, >>>>>> >>>>>> The goal of such a requirement is to emphasize that the DMM >>>>>> protocol(s) that will be designed/specified by the DMM WG should be >>>>>> agnostic to whether users are roaming/moving into wireless coverage >>>>>> area(s) managed by either one single operator or by more than one >>>>>> operators. I think that this will have an impact on some of the >>>>>> requirements listed already by Anthony! Security association is one >>>>>> such requirement, other requirements are related to for example the >>>>>> possibility of the DMM protocol(s) to (1) easily use the user >>>>>> profile and mobility information when users are roaming away from >>>>>> their home operator, (2) use and support seamless, real time and >>>>>> dynamic change of the mobility anchors that could be located in >>>>>> different communication area(s) managed by different operators. >>>>>> >>>>>> Best regards, >>>>>> Georgios >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: [email protected] >>>>>>> [mailto:[email protected]] >>>>>>> Sent: vrijdag 25 mei 2012 9:49 >>>>>>> To: Karagiannis, G. (EWI); [email protected] >>>>>>> Cc: [email protected] >>>>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed >>>>>>> deployment (single-operator and cross-operator?) >>>>>>> >>>>>>> Hi Georgios, >>>>>>> >>>>>>> It seems to me that the requirement: "need of supporting both >>>>>>> single- operator and cross-operator mobility management" is a >>>>>>> deployment requirement. I understand the requirement but I do not >>>>>>> see how to "translate it" into an IP generic wording. FSo, fcusing >>>>>>> only on protocols (as we are supposed to) how would you >>>>>>> reformulate your requirement? Is talking about "capability to >>>>>>> establish security associations between mobility entities" would >>>>>>> be acceptable? >>>>>>> >>>>>>> Br, >>>>>>> Pierrick >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : [email protected] [mailto:[email protected]] De la >>> part >>>>>> de >>>>>>>> [email protected] Envoyé : vendredi 25 mai 2012 07:49 À : >>>>>>>> [email protected] Cc : [email protected] Objet : Re: [DMM] >>>>>>>> draft requirement REQ-1: Distributed deployment (single- operator >>>>>>>> and cross-operator?) >>>>>>>> >>>>>>>> Hi Anthony, >>>>>>>> >>>>>>>> I am not sure whether it can be incorporated in REQ-4 or whether >>>>>>>> it could be considered as being an additional requirement! I am >>>>>>>> in favour of adding a new requirement that satisfies this issue! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Georgios >>>>>>>> >>>>>>>> ________________________________________ Van: h chan >>>>>>>> [[email protected]] Verzonden: donderdag 24 mei 2012 >>>>>>>> 19:36 Aan: Karagiannis, G. (EWI) CC: [email protected] Onderwerp: RE: >>>>>>>> [DMM] draft requirement REQ-1: Distributed deployment >>>>>>>> (single-operator and cross-operator?) >>>>>>>> >>>>>>>> Georgios, >>>>>>>> >>>>>>>> Do you think whether REQ-4 may be a better place to discuss. >>>>>>>> REQ-4 is talking about compatibility. It already includes >>>>>>>> compatibility with other (such as 3GPP) mobility protocols. We >>>>>>>> can check what else are needed there for cross-operator mobility. >>>>>>>> >>>>>>>> If you agree, we can move this cross-operator issue over the >>>>>>>> REQ-4 thread. >>>>>>>> >>>>>>>> H Anthony Chan >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: [email protected] [mailto:[email protected]] >>>>>>>> Sent: Thursday, May 24, 2012 1:06 AM >>>>>>>> To: h chan >>>>>>>> Cc: [email protected] >>>>>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed >>>>>>>> deployment (single-operator and cross-operator?) >>>>>>>> >>>>>>>> Hi Anthony, Hi all, >>>>>>>> >>>>>>>> During the last DMM meeting in Paris, I have raised the issue >>>>>>>> of cross-operator mobility management support. >>>>>>>> Not sure if this issue can be satisfied by incorporating it > into >>>>>> REQ-1 >>>>>>>> Distributed deployment, or if it will be needed to create an >>>>>>>> additional requirement that incorporates the need of supporting >>>>>>>> both single- operator and cross-operator mobility management. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Georgios >>>>>>>> >>>>>>>> ________________________________________ Van: >>>>>>>> [email protected] [[email protected]] namens h chan >>>>>>>> [[email protected]] Verzonden: donderdag 24 mei 2012 1:20 >>>>>>>> Aan: Jouni; Peter McCann CC: [email protected] Onderwerp: Re: [DMM] >>>>>>>> draft requirement REQ-1: Distributed deployment >>>>>>>> >>>>>>>> An attempt to clean up the text for REQ-1 below: >>>>>>>> >>>>>>>> REQ-1: Distributed deployment IP mobility, network access and >>>>>>>> routing solutions provided by DMM SHALL enable a distributed >>>>>>>> deployment of mobility management of IP sessions so that the >>>>>>>> traffic can be routed in an optimal manner without traversing >>>>>>>> centrally deployed mobility anchors. REQ-1M (Motivation for >>>>>>>> REQ-1) The goals of this requirement are to match mobility >>>>>>>> deployment with current trend in network evolution: more cost and >>>>>>>> resource effective to cache and distribute contents when >>>>>>>> combining distributed anchors with caching systems (e.g., CDN); >>>>>>>> improve scalability; avoid single point of failure; mitigate >>>>>>>> threats being focused on a centrally deployed anchor, e.g., home >>>>>>>> agent and local mobility anchor. RELEVANT problems: PS1: >>>>>>>> Non-optimal routes Routing via a centralized anchor often results >>>>>>>> in a longer route, and the problem is especially manifested when >>>>>>>> accessing a local or cache server of a Content Delivery Network >>>>>>>> (CDN). PS2: Non-optimality in Evolved Network Architecture The >>>>>>>> centralized mobility management becomes non-optimal as network >>>>>>>> architecture evolves and flattens. PS3: Low scalability of >>>>>>>> centralized route and mobility context maintenance Setting up >>>>>>>> such special routes and maintaining the mobility context >>>>>>>> including the tunnel state for each MN is more difficult to scale >>>>>>>> in a centralized design with a large number of MNs. Distributing >>>>>>>> the route maintenance function and the mobility context >>>>>>>> maintenance function among different networks can be more >>>>>>>> scalable. PS4: Single point of failure and attack Centralized >>>>>>>> anchoring may be more vulnerable to single point of failure and >>>>>>>> attack than a distributed system. >>>>>>>> >>>>>>>> H Anthony Chan >>>>>>>> >>>>>>>> -----Original Message----- From: Jouni >>>>>>>> [mailto:[email protected]] Sent: Saturday, May 19, 2012 4:23 >>>>>>>> AM To: Peter McCann Cc: h chan; [email protected] Subject: Re: [DMM] >>>>>>>> draft requirement REQ-1: Distributed deployment >>>>>>>> >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> On May 18, 2012, at 5:55 PM, Peter McCann wrote: >>>>>>>> >>>>>>>>> Hi, Jouni, >>>>>>>>> >>>>>>>>> jouni korhonen wrote: >>>>>>>>>> Breaking the silence.. >>>>>>>>>> >>>>>>>>>> On May 7, 2012, at 8:55 PM, h chan wrote: >>>>>>>>>> >>>>>>>>>>> REQ-1: Distributed deployment IP mobility, network access and >>>>>>>>>>> routing solutions provided by DMM SHALL enable the functions >>>>>>>>>>> of mobility management of IP sessions to be distributed so >>>>>>>>>>> that the traffic is routed in an optimal manner without >>>>>>>>>>> relying on centrally deployed anchors. >>>>>>>>>> >>>>>>>>>> Few comments/questions.. o "SHALL enable the functions of >>>>>>>>>> mobility management" does that imply the DMM "solution" must >>>>>>>>>> always involve or extend a mobility >>>>>> protocol? >>>>>>>> IMHO >>>>>>>>>> that should not be a SHALL requirement. >>>>>>>>> >>>>>>>>> To the extent that DMM provides an "IP mobility...solution" I >>>>>> think >>>>>>>> it does >>>>>>>>> involve or extend a mobility protocol. However, I don't >>>>>>>>> think >>>>>> the >>>>>>>> requirement >>>>>>>>> implies that we will necessarily extend an existing mobility >>>>>>>> protocol. >>>>>>>> >>>>>>>> Excerpt from the charter: >>>>>>>> >>>>>>>> on managing the use of care-of versus home addresses in an >>>>>>>> efficient manner for different types of communications. >>>>>>>> Just making sure the right flavor or address is used does not >>>>>>>> necessarily extend or require any mobility protocol support. >>>>>>>> >>>>>>>>>> o "centrally deployed anchors" what if the access network >>>>>>>>>> routing is laid out in a way that even pure IP routing would >>>>>>>>>> lead packets to go through a central site/edge router? Doesn't >>>>>>>>>> that lead to similar deficiencies than with mobility anchors? >>>>>>>>> >>>>>>>>> It does indeed, which is why a good network deployment will have >>>>>>>>> redundant back-up paths throughout the network. Unfortunately, >>>>>>>>> it is difficult to provide redundancy when the path involves >>>>>>>>> tunnel state at an >>>>>> anchor >>>>>>>> point. >>>>>>>>> >>>>>>>>>>> REQ-1M (Motivation for REQ-1) The goals of this requirement >>>>>>>>>>> are to match mobility deployment with current trend in >>>>>>>>>>> network evolution: >>>>>>>>>>> more cost and resource effective to cache and distribute >>>>>> contents >>>>>>>> when >>>>>>>>>>> combining distributed anchors with caching systems (e.g., >>>>>>>>>>> CDN); improve scalability; reduce signaling overhead; avoid >>>>>>>>>>> single >>>>>> point >>>>>>>> of >>>>>>>>>>> failure; mitigate threats being focused on a centrally >>>>>>>>>>> deployed anchor, e.g., home agent and local mobility anchor. >>>>>>>>>> >>>>>>>>>> Reduce signaling overhead.. is a very good goal. However, if >>>>>>>>>> any DMM solution builds on top of an existing mobility protocol >>>>>>>>>> that hardly reduces anything. Also if setting up optimal routes >>>>>>>>>> require establishing new tunnels, signaling is bound to >>>>>>>>>> increase. I >>>>>> would >>>>>>>> say >>>>>>>>>> here "does not increase the amount of present signaling" and >>>>>>>>>> the aim for solutions that would reduce it somehow. >>>>>>>>> >>>>>>>>> It should be possible to completely avoid mobility management >>>>>>>>> signaling when the MN is stationary or doesn't need a fixed >>>>>>>>> address. I >>>>>> would >>>>>>>> say >>>>>>>>> that reduces signaling. >>>>>>>> >>>>>>>> From that point view ok. Extra care is then needed that one > does >>>>>> not >>>>>>>> move the signaling to another layer.. take DSMIP6 (S2c) as an >>>>>>>> example, which avoids BU/BA exchange but then expanded the IKE >>>>>>>> signaling :) >>>>>>>> >>>>>>>>>>> RELEVANT problems: PS1: Non-optimal routes Routing via a >>>>>>>>>>> centralized anchor often results in a longer route, and the >>>>>>>>>>> problem is especially manifested when accessing a local >>>>>> or >>>>>>>> cache >>>>>>>>>>> server of a Content Delivery Network (CDN). PS2: >>>>>>>>>>> Non-optimality in Evolved Network Architecture The centralized >>>>>>>>>>> mobility management can become non-optimal as Network >>>>>>>>>>> architecture evolves and become more flattened. >>>>>>>>>> >>>>>>>>>> More flat is kind of superfluous.. take e.g. EPS example. >>>>>>>>>> You >>>>>> have, >>>>>>>> in >>>>>>>>>> an optimal case, an eNodeB connected directly to a combined >>>>>>>>>> SGW/PGW from the user plane point of view. And the SGW/PGW you >>>>>>>>>> can allocate close to you eNodeB based on its topological >>>>>>>>>> location. How > you >>>>>> can >>>>>>>>>> make that more flat? SGW relocation changes the situation a >>>>>>>>>> bit >>>>>> but >>>>>>>> still.. >>>>>>>>> >>>>>>>>> Putting an SGW/PGW (or an LGW) inside in eNB would indeed be >>>>>>>>> a >>>>>>>> maximally >>>>>>>> >>>>>>>> Putting SGW/PGW into eNodeB is not too realistic for a wider are >>>>>>>> deployment. LGWs we already got out there but the mobility in >>>>>>>> that case ain't too great as far as I remember. >>>>>>>> >>>>>>>>> flat architecture. However, we would then need to deal with a >>>>>>>>> change of anchor point during the life of a session, which is >>>>>>>>> something >>>>>> that >>>>>>>> wasn't >>>>>>>>> contemplated by 3GPP. That is exactly the area that DMM should >>>>>>>>> focus on, IMHO. >>>>>>>> >>>>>>>> With a cost of additional signaling and new tunnel state? >>>>>>>> >>>>>>>>>>> PS3: Low scalability of centralized route and mobility >>>>>>>>>>> context maintenance Setting up such special routes and >>>>>>>>>>> maintaining the mobility context for each MN is more >>>>>>>>>>> difficult to scale in a centralized design with a large > number of MNs. >>>>>>>>>> >>>>>>>>>> Can I assume the mobility context involves a possible per MN >>>>>>>>>> tunnel state? >>>>>>>>> >>>>>>>>> Yes, I think the per-MN tunnel state is part of the mobility >>>>>>>>> context being talked about here. >>>>>>>> >>>>>>>> - Jouni >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -Pete >>>>>>>>> >>>>>>>>>>> Distributing the route maintenance function and the mobility >>>>>>>>>>> context maintenance function among different networks can be >>>>>>>>>>> more scalable. PS4: Single point of failure and attack >>>>>>>>>>> Centralized > anchoring >>>>>> may >>>>>>>> be >>>>>>>>>>> more vulnerable to single point of failure and attack than >>>>>>>>>>> a distributed system. >>>>>>>>>>> >>>>>>>>>>> (The above is drafted with contributions, inputs and >>>>>>>>>>> discussions from various people. Additional contributions and >>>>>>>>>>> comments are most welcome.) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Jouni >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> H Anthony Chan _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
