Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?)

From: <[email-masked]>
Date: Thu, 24 May 2012 06:06:27 +0000

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-masked] [[email-masked]] namens h chan [[email-masked]]
Verzonden: donderdag 24 mei 2012 1:20
Aan: Jouni; Peter McCann
CC: [email-masked]
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-masked]]
Sent: Saturday, May 19, 2012 4:23 AM
To: Peter McCann
Cc: h chan; [email-masked]
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-masked]
>>> https://www.ietf.org/mailman/listinfo/dmm
>>
>> _______________________________________________
>> dmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmm
>
>
>

_______________________________________________
dmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmm

---

From: h chan <[email-masked]>
Date: Thu, 24 May 2012 17:36:58 +0000

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-masked] [mailto:[email-masked]] 
Sent: Thursday, May 24, 2012 1:06 AM
To: h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?)

Hi Anthony, Hi all,

Best regards,
Georgios

H Anthony Chan

-----Original Message-----
From: Jouni [mailto:[email-masked]]
Sent: Saturday, May 19, 2012 4:23 AM
To: Peter McCann
Cc: h chan; [email-masked]
Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment

Hi

- Jouni

---

From: <[email-masked]>
Date: Fri, 25 May 2012 05:49:21 +0000

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-masked]]
Verzonden: donderdag 24 mei 2012 19:36
Aan: Karagiannis, G. (EWI)
CC: [email-masked]
Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?)

Georgios,

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 24, 2012 1:06 AM
To: h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?)

Hi Anthony, Hi all,

Best regards,
Georgios

H Anthony Chan

-----Original Message-----
From: Jouni [mailto:[email-masked]]
Sent: Saturday, May 19, 2012 4:23 AM
To: Peter McCann
Cc: h chan; [email-masked]
Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment

Hi

- Jouni

---

From: <[email-masked]>
Date: Fri, 25 May 2012 09:48:51 +0200

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-masked] [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : vendredi 25 mai 2012 07:49
> À : [email-masked]
> Cc : [email-masked]
> 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!
> 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.
> 
> 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
> 
> 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.
> 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
> 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.

---

From: <[email-masked]>
Date: Fri, 25 May 2012 10:27:50 +0000

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: vrijdag 25 mei 2012 9:49
> To: Karagiannis, G. (EWI); [email-masked]
> Cc: [email-masked]
> 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
> 
> > [email-masked] Envoyé : vendredi 25 mai 2012 07:49 À :
> > [email-masked] Cc : [email-masked] Objet : Re: [DMM] draft
> > requirement REQ-1: Distributed deployment (single-operator and
> > cross-operator?)
> >
> > Hi Anthony,
> >
> > 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
> >
> > 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.
> > 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
> > mobility management becomes non-optimal as network architecture
> > evolves and flattens.
> > mobility context including the tunnel state for each MN is more
> > difficult to scale in a centralized design with a large number of MNs.
> > >>> SHALL enable the functions of mobility management of IP sessions
> > >>> to
> > be
> > 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?
> > >
> > > back-up paths throughout the network.  Unfortunately, it is
> > > difficult
> > to
> > >>> The goals of this requirement are to match mobility deployment
> > >>> with current trend in network evolution:
> > >> 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
> > >> here "does not increase the amount of present signaling" and the
> > >> aim for solutions that would reduce it somehow.
> > >
> > >>> and the problem is especially manifested when accessing a local or
> > cache
> > >>> PS2: Non-optimality in Evolved Network Architecture The
> > >>> centralized mobility management can become non-optimal as Network
> > >>> architecture evolves and become more flattened.
> > >>
> > > flat architecture.  However, we would then need to deal with a
> > > change
> > of
> > > contemplated by 3GPP.  That is exactly the area that DMM should
> > > focus
> > on,
> > > IMHO.
> >

---

From: <[email-masked]>
Date: Fri, 25 May 2012 14:00:29 +0200

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. 

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.

That's only my opinion; let's see what others think.

BR,
Pierrick

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : vendredi 25 mai 2012 12:28
> À : SEITE Pierrick RD-RESA-REN; [email-masked]
> Cc : [email-masked]
> Objet : RE: [DMM] draft requirement REQ-1: Distributed deployment
> 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.
> 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
> 
> 
> 
> 
> 
> > > Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed
> deployment
> > > >>  DMM "solution" must always involve or extend a mobility
> protocol?
> > > IMHO
> > > > 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
> > > > provide redundancy when the path involves tunnel state at an
> anchor
> > > point.
> > > >
> > > >>> more cost and resource effective to cache and distribute
> contents
> > > when
> > > >>> improve scalability; reduce signaling overhead; avoid single
> point
> > > of
> > > >> establishing new tunnels, signaling is bound to increase. I
> would
> > > say
> > > > when the MN is stationary or doesn't need a fixed address.  I
> would
> > > say
> > > > that reduces signaling.
> > >
> > > >> More flat is kind of superfluous.. take e.g. EPS example. You
> have,
> > > in
> > > >> make that more flat? SGW relocation changes the situation a bit
> but
> > > still..
> > > >
> > > > anchor point during the life of a session, which is something
> that
> > > wasn't
> > > >>> PS4: Single point of failure and attack Centralized anchoring
> may
> > > be

---

From: <[email-masked]>
Date: Fri, 25 May 2012 12:21:39 +0000

Hi Pierrick,

Please see in line!

> Sent: vrijdag 25 mei 2012 14:00
> 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!

> 
> 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

> > De : [email-masked] [mailto:[email-masked]] Envoyé :
> > vendredi 25 mai 2012 12:28 À : SEITE Pierrick RD-RESA-REN;
> > [email-masked] Cc : [email-masked] Objet : RE: [DMM] draft
> > 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.
> > > 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
> > > about "capability to establish security associations between
> > > mobility
> > entities"
> > > would be acceptable?
> > >
> > > Br,
> > > Pierrick
> > >
> > > > [email-masked] Cc : [email-masked] 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!
> > > > 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.
> > > >
> > > > 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
> > > > centralized mobility management becomes non-optimal as network
> > > > architecture evolves and flattens.
> > > > >>> 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
> > > > >> 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
> > > > >> here "does not increase the amount of present signaling" and
> > > > >> the aim for solutions that would reduce it somehow.
> > > > >
> > > > >>> and the problem is especially manifested when accessing a
> > > > >>> local
> > or
> > > > cache

---

From: Jouni <[email-masked]>
Date: Fri, 25 May 2012 15:48:35 +0300

> 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

---

From: <[email-masked]>
Date: Fri, 25 May 2012 12:57:33 +0000

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!

Best regards,
Georgios

> Sent: vrijdag 25 mei 2012 14:49
> To: Karagiannis, G. (EWI)
> Cc: [email-masked]; [email-masked];
> [email-masked]
> >> 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!
> 
> mobility area) do not prohibit cross administrative domain mobility. It is more
> a deployment decision loaded with non-techninal far from trivial issues.
> 
> 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
> 
> 
> 
> >
> >>
> >> 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.
> >
> >>> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>> De : [email-masked] [mailto:[email-masked]] De la
> part
> >>> de
> >>>>> Van: [email-masked] [[email-masked]] namens h
> chan
> >>>>> [[email-masked]]

---

From: Jouni <[email-masked]>
Date: Sat, 26 May 2012 17:13:14 +0300

Hi,

> 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.

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Sun, 27 May 2012 01:47:00 +0000

Jouni wrote:
>>> 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.
>> 
> 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

>>>>> 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.
>>>> 
>>> 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.
>>>> 
>>>>>> -----Message d'origine----- De : [email-masked]
>>>>>> [mailto:[email-masked]] Envoyé : vendredi 25 mai 2012 12:28
>>>>>> À : SEITE Pierrick RD-RESA-REN; [email-masked] Cc :
>>>>>> [email-masked] Objet : RE: [DMM] draft requirement REQ-1: Distributed
>>>>>> deployment (single-operator and cross-operator?)
>>>>>> 
>>>>>> Hi Pierrick,
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed
>>>>>>> deployment (single-operator and cross-operator?)
>>>>>>> 
>>>>>>> Hi Georgios,
>>>>>>> 
>>>>>>> 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
>>>>>>> 
>>>>>>>> draft requirement REQ-1: Distributed deployment (single- operator
>>>>>>>> and cross-operator?)
>>>>>>>> 
>>>>>>>> Hi Anthony,
>>>>>>>> 
>>>>>>>> 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-masked]] Verzonden: donderdag 24 mei 2012
>>>>>>>> 19:36 Aan: Karagiannis, G. (EWI) CC: [email-masked] Onderwerp: RE:
>>>>>>>> [DMM] draft requirement REQ-1: Distributed deployment
>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> 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
>>>>>>>> additional requirement that incorporates the need of supporting
>>>>>>>> both single- operator and cross-operator mobility management.
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> Georgios
>>>>>>>> 
>>>>>>>> ________________________________________ Van:
>>>>>>>> [email-masked] [[email-masked]] namens h chan
>>>>>>>> [[email-masked]] Verzonden: donderdag 24 mei 2012 1:20
>>>>>>>> Aan: Jouni; Peter McCann CC: [email-masked] Onderwerp: Re: [DMM]
>>>>>>>> draft requirement REQ-1: Distributed deployment
>>>>>>>> 
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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-masked]] Sent: Saturday, May 19, 2012 4:23
>>>>>>>> AM To: Peter McCann Cc: h chan; [email-masked] Subject: Re: [DMM]
>>>>>>>> draft requirement REQ-1: Distributed deployment
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi
>>>>>>>> 
>>>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>> 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:
>>>>>>>>>> require establishing new tunnels, signaling is bound to
>>>>>>>>>> increase. I
>>>>>> would
>>>>>>>> say
>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>> Putting an SGW/PGW (or an LGW) inside in eNB would indeed be
>>>>>>>>> a
>>>>>>>> maximally
>>>>>>>> 
>>>>>>>> deployment. LGWs we already got out there but the mobility in
>>>>>>>> that case ain't too great as far as I remember.
>>>>>>>> 
>>>>>>>>> change of anchor point during the life of a session, which is
>>>>>>>>> something
>>>>>> that
>>>>>>>> wasn't
>>>>>>>>> focus on, IMHO.
>>>>>>>>>>> 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
>>>>>>>>>> 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