Subject: [DMM] draft requirement REQ-1: Distributed deployment

From: h chan <[email-masked]>
Date: Mon, 7 May 2012 17:55:01 +0000

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.

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.

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

H Anthony Chan

---

From: <[email-masked]>
Date: Mon, 7 May 2012 18:02:11 +0000

Hi Anthony,

When you refer to " the functions of mobility management " do you implicitly assume that to be the Home Agent?
Or is there an assumption that there could be new elements as well to enable such distributed mobility?

One of the underlying aspects of DMM (AFAICT) is to use Mobile IPv6. And hence the question above.

-Raj

From: ext chan <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 7, 2012 12:55 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [DMM] draft requirement REQ-1: Distributed deployment

RELEVANT problems:
PS1: Non-optimal routes

H Anthony Chan

---

From: h chan <[email-masked]>
Date: Mon, 7 May 2012 21:25:01 +0000

Raj,

Although many of the proposed solutions are based on Mobile IPv6, I think it is not the intension in the requirement REQ-1 to imply which functions are to be defined or distributed. If it sounds so, we should reword it.

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 07, 2012 1:02 PM
To: h chan; [email-masked]
Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment

Hi Anthony,

-Raj

RELEVANT problems:
PS1: Non-optimal routes

H Anthony Chan

---

From: jouni korhonen <[email-masked]>
Date: Fri, 18 May 2012 02:45:53 +0300

Breaking the silence..

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

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.

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?

> 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., C…

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.

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

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

> Distributing the route maintenance function and the mobility context maintenance function among different networks can be more scalable.

- Jouni

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

---

From: Peter McCann <[email-masked]>
Date: Fri, 18 May 2012 14:55:09 +0000

Hi, Jouni,

jouni korhonen wrote:
>> 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..

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.

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

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

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

Yes, I think the per-MN tunnel state is part of the mobility context
being talked about here.

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

---

From: Jouni <[email-masked]>
Date: Sat, 19 May 2012 12:22:59 +0300

Hi

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

> when the MN is stationary or doesn't need a fixed address.  I would say

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

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

> contemplated by 3GPP.  That is exactly the area that DMM should focus on,

With a cost of additional signaling and new tunnel state?

- Jouni

---

From: h chan <[email-masked]>
Date: Wed, 23 May 2012 22:16:11 +0000

>> More flat is kind of superfluous..

Let us just say "as network architecture flattens" rather than "become more flatten" to include the flattening that is already happening. 

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: h chan <[email-masked]>
Date: Wed, 23 May 2012 22:31:04 +0000

We can reword "functions of mobility management" to avoid such implication.  

H Anthony Chan

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 6:46 PM
To: h chan
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment

Breaking the silence..

Few comments/questions..

- Jouni

---

From: h chan <[email-masked]>
Date: Wed, 23 May 2012 22:34:41 +0000

Let us call it "centrally deployed mobility anchors" in the requirement. 

H Anthony Chan

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 6:46 PM
To: h chan
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment

Breaking the silence..

Few comments/questions..

- Jouni

---

From: h chan <[email-masked]>
Date: Wed, 23 May 2012 23:01:13 +0000

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

----------------------------
Regarding above comment:
I think the reduction of mobility signaling here applies more to REQ-2 (e.g., not using the HoA from the previous network you don't need to) but not REQ-1. In the motivation for this REQ-1, we can delete "reduce signaling overhead"  

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: h chan <[email-masked]>
Date: Wed, 23 May 2012 23:08:59 +0000

> Yes, I think the per-MN tunnel state is part of the mobility context

-------------------
It looks like the meaning of mobility context is broad and can have different interpretations. We can specifically name the tunnel state here. 

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: h chan <[email-masked]>
Date: Wed, 23 May 2012 23:20:46 +0000

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

- Jouni