Re: [DMM] regarding the re-chartering..

[Jouni Korhonen]

Behcet,

Obviously that protocols are known that the intended deployment is going 
to use. The details what goes inside that protocol are not. This holds 
for my example case 3GPP as well.


We do not need to into same level of detail that e.g. 3GPP stage-2 has 
detailing all signaling flows and so on. I believe we as a WG are 
competent enough to make a fine division what level of detail is left 
for the "deployment models and scenarios" and what goes into protocol 
solutions.


- Jouni

9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti:

On Mon, Sep 1, 2014 at 3:25 AM, Jouni  wrote:


Alper,

I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 and stage-3 work. 
The ""deployment models and scenarios" are the stage-2 descriptions and then we 
also need the protocol level solutions that are in separate documents.



Thanks Alper for raising this issue.

3GPP Stage 2 like in SA2 documents are architecture documents.
I don't understand what is going on here.

I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses.

Yes, this document talks about deployment in just a few places, here
is one occurrence: on page 64, PCC deployment options
on page 94, PMIP based S5/S8 deployments, etc.

So in all cases the protocol, i.e. PCC or PMIP is known.

Regards,

Behcet

Makes sense?

- Jouni


On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote:


Okay, we are not going to define how the existing 3FPP system works - that 
knowledge is assumed. What I thought goes into the document, for example, in the 
case of 3GPP system would be identifying the architecture changes or modifications 
needed. If the deployment model assumes all network functions are virtualized, the 
document states that and lays out the architecture based on that. Satoru's & 
Ryuji's vEPC deployment model (based on their solution) is IMHO a good example of 
what could be documented. The similar applies for other system architectures such 
as SP Wi-Fi etc.



Jouni,

The "architecture changes" would be based on the a "specific solution". So, as part of 
describing a solution one can be talking about what you are suggesting above. But I don't understand how we 
can be talking about "deployment models and scenarios" before we agree on the solutions.

Alper





o Enhanced mobility anchoring: define protocol solutions for a
  gateway and mobility anchor assignment and mid-session mobility
  anchor switching that go beyond what has been specified, for
  example, in RFC 6097, 6463, and 5142. Traffic steering
  associated with the anchor switch is also in-scope if deemed
  appropriate.

o Forwarding path and signaling management: the function
  that handles mobility management signaling interacts with the
  DMM network elements for managing the forwarding state
  associated with a mobile node's IP traffic. These two functions
  may or may not be collocated. Furthermore, the forwarding state
  may also be distributed into multiple network elements instead
  of a single network element (e.g., anchor). Protocol extensions
  or new protocols will be specified to allow the above mentioned
  forwarding path and signalling management.



I cannot separate "mobility anchoring" from "fwding path and
signaling management".
Wherever you want to set your anchor or move your anchor to, you'd
need signaling
and setting up data path. The two are inseparable.
Having said that, I'm OK to keep the current work item descriptions
and finalize
rechartering. Once we have detailed discussions about the breakdown

of the work, we

can come back and refine the goals and milestones (as already stated

below [*]).

The enhanced mobility anchoring above is/was rather MIP type solutions
influenced with "anchors" like we understand today, while the
"forwarding path and signaling management" was meant for more future
oriented solutions where the forwarding path does not necessarily have
anything mobility specific etc.



(Just FYI: It's not possible to gather what you are saying from reading
the charter. Different people reading the charter may not have the same
understanding. But like I said, this is just FYI, I can live with this
text until we come back and refine it later).


Ok. I'll try to clarify the point the text tries to make.

- Jouni



Thanks.

Alper





Any other opinions on collapsing these two?

- Jouni


o Exposing mobility state to mobile nodes and network nodes:
  define solutions that allow, for example, mobile nodes to select
  either a care-of address or a home address depending on an
  application' mobility needs. In order to enable this
  functionality, the network-side control functions and other
  networking nodes must also be able to exchange appropriate
  control information, as well as to the mobile nodes and their
  applications.

The working group may decide to extend the current milestones based on
the new information and knowledge gain

Re: [DMM] regarding the re-chartering..

[Behcet Sarikaya]

On Mon, Sep 1, 2014 at 3:25 AM, Jouni  wrote:
>
> Alper,
>
> I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 
> and stage-3 work. The ""deployment models and scenarios" are the stage-2 
> descriptions and then we also need the protocol level solutions that are in 
> separate documents.
>

Thanks Alper for raising this issue.

3GPP Stage 2 like in SA2 documents are architecture documents.
I don't understand what is going on here.

I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses.

Yes, this document talks about deployment in just a few places, here
is one occurrence: on page 64, PCC deployment options
on page 94, PMIP based S5/S8 deployments, etc.

So in all cases the protocol, i.e. PCC or PMIP is known.

Regards,

Behcet
> Makes sense?
>
> - Jouni
>
>
> On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote:
>
>>> Okay, we are not going to define how the existing 3FPP system works - that 
>>> knowledge is assumed. What I thought goes into the document, for example, 
>>> in the case of 3GPP system would be identifying the architecture changes or 
>>> modifications needed. If the deployment model assumes all network functions 
>>> are virtualized, the document states that and lays out the architecture 
>>> based on that. Satoru's & Ryuji's vEPC deployment model (based on their 
>>> solution) is IMHO a good example of what could be documented. The similar 
>>> applies for other system architectures such as SP Wi-Fi etc.
>>>
>>
>> Jouni,
>>
>> The "architecture changes" would be based on the a "specific solution". So, 
>> as part of describing a solution one can be talking about what you are 
>> suggesting above. But I don't understand how we can be talking about 
>> "deployment models and scenarios" before we agree on the solutions.
>>
>> Alper
>>
>>
>>
>>
>>>o Enhanced mobility anchoring: define protocol solutions for a
>>>  gateway and mobility anchor assignment and mid-session mobility
>>>  anchor switching that go beyond what has been specified, for
>>>  example, in RFC 6097, 6463, and 5142. Traffic steering
>>>  associated with the anchor switch is also in-scope if deemed
>>>  appropriate.
>>>
>>>o Forwarding path and signaling management: the function
>>>  that handles mobility management signaling interacts with the
>>>  DMM network elements for managing the forwarding state
>>>  associated with a mobile node's IP traffic. These two functions
>>>  may or may not be collocated. Furthermore, the forwarding state
>>>  may also be distributed into multiple network elements instead
>>>  of a single network element (e.g., anchor). Protocol extensions
>>>  or new protocols will be specified to allow the above mentioned
>>>  forwarding path and signalling management.
>>>
>>
>> I cannot separate "mobility anchoring" from "fwding path and
>> signaling management".
>> Wherever you want to set your anchor or move your anchor to, you'd
>> need signaling
>> and setting up data path. The two are inseparable.
>> Having said that, I'm OK to keep the current work item descriptions
>> and finalize
>> rechartering. Once we have detailed discussions about the breakdown
> of the work, we
>> can come back and refine the goals and milestones (as already stated
> below [*]).
>
> The enhanced mobility anchoring above is/was rather MIP type solutions
> influenced with "anchors" like we understand today, while the
> "forwarding path and signaling management" was meant for more future
> oriented solutions where the forwarding path does not necessarily have
> anything mobility specific etc.
>

 (Just FYI: It's not possible to gather what you are saying from reading
 the charter. Different people reading the charter may not have the same
 understanding. But like I said, this is just FYI, I can live with this
 text until we come back and refine it later).
>>>
>>> Ok. I'll try to clarify the point the text tries to make.
>>>
>>> - Jouni
>>>

 Thanks.

 Alper




> Any other opinions on collapsing these two?
>
> - Jouni
>
>>>o Exposing mobility state to mobile nodes and network nodes:
>>>  define solutions that allow, for example, mobile nodes to select
>>>  either a care-of address or a home address depending on an
>>>  application' mobility needs. In order to enable this
>>>  functionality, the network-side control functions and other
>>>  networking nodes must also be able to exchange appropriate
>>>  control information, as well as to the mobile nodes and their
>>>  applications.
>>>
>>> The working group may decide to extend the current milestones based on
>>> the new information and knowledge gained during working on other
>>> documents lis

Re: [DMM] 3GPP CSIPTO

[Alper Yegin]

Hi Marco,

> thanks for posting the update. One clarifying question on the following 
> service requirement:
>  
> ‘The 3GPP system shall minimize the number of connections of a UE without 
> disrupting the
> UE’s services, e.g. to ensure economical use of network resources’
>  
> Can this be understood as the number of connections, which is to be 
> minimized, is equal to the
> number of mobility session and associated IP addresses?

You can say that.

The idea is to make sure the simultaneous PDN connections do not keep adding up 
each time the UE encounters a new GW.

Alper





>  
> Is this to minimize the states in the network, or is the intention to limit 
> the control-plane
> signaling with the mobile device to setup/teardown the connection?
>  
> Thanks for your feedback in advance,
> marco
>  
>  
>  
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin
> Sent: Montag, 1. September 2014 09:51
> To: dmm@ietf.org
> Subject: [DMM] 3GPP CSIPTO
>  
> Dear DMMers,
>  
> Here's an update on 3GPP SA1 CSIPTO work…
>  
> Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting SA1 has 
> completed the CSIPTO normative work.
> As you might remember, SA1 is in charge of defining service requirements.
>  
> The next step for CSIPTO is to initiate a work item in SA2.
>  
>  
> And here's a copy-paste of the normative requirements (accepted doc is 
> S1-143607.zip):
>  
>  
> Some types of services (e.g. streaming services, VOIP, VPN, HTTPS-Based 
> Services) cannot tolerate a change of IP address of the UE without disruption 
> of the service.
> SIPTO can be performed with or without coordination between the UE and the 
> network. The following requirements apply to coordinated SIPTO:
> 
> - The 3GPP system shall be able to support multiple connections that are 
> associated with the same defined IP network where each connection may or may 
> not support IP address preservation.
> 
> - The 3GPP system shall be able to determine if an IP flow requires IP 
> address preservation or not. Based on this determination, the 3GPP network 
> shall be able to offload selected IP traffic in coordinated manner between UE 
> and the network, in order to minimize service disruption.
> 
> -  The 3GPP system shall be able to detect when a connection becomes 
> suboptimal and decide when to establish a new optimal connection to the same 
> defined IP network or use an existing connection.
> Note 1:  The definition of optimal and suboptimal can be based on a 
> number of implementation criteria like geography, topology and load balancing 
> etc.
> - The 3GPP system shall minimize the number of connections of a UE 
> without disrupting the UE’s services, e.g. to ensure economical use of 
> network resources.
> - The 3GPP system shall be able to ensure that the actual average 
> aggregate bit rate for IP flows of packet data network connections associated 
> with the same packet data network does not significantly exceed the 
> subscribed aggregate maximum bit rate for this packet data network when two 
> connections are used with the same defined IP network.
> Note 2:  Requirements for Coordinated SIPTO do not apply to IMS.
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] 3GPP CSIPTO

[Marco Liebsch]

Hi Alper,

thanks for posting the update. One clarifying question on the following service 
requirement:

'The 3GPP system shall minimize the number of connections of a UE without 
disrupting the
UE's services, e.g. to ensure economical use of network resources'

Can this be understood as the number of connections, which is to be minimized, 
is equal to the
number of mobility session and associated IP addresses?

Is this to minimize the states in the network, or is the intention to limit the 
control-plane
signaling with the mobile device to setup/teardown the connection?

Thanks for your feedback in advance,
marco



From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin
Sent: Montag, 1. September 2014 09:51
To: dmm@ietf.org
Subject: [DMM] 3GPP CSIPTO

Dear DMMers,

Here's an update on 3GPP SA1 CSIPTO work...

Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting SA1 has 
completed the CSIPTO normative work.
As you might remember, SA1 is in charge of defining service requirements.

The next step for CSIPTO is to initiate a work item in SA2.


And here's a copy-paste of the normative requirements (accepted doc is 
S1-143607.zip):


Some types of services (e.g. streaming services, VOIP, VPN, HTTPS-Based 
Services) cannot tolerate a change of IP address of the UE without disruption 
of the service.

SIPTO can be performed with or without coordination between the UE and the 
network. The following requirements apply to coordinated SIPTO:

- The 3GPP system shall be able to support multiple connections that are 
associated with the same defined IP network where each connection may or may 
not support IP address preservation.

- The 3GPP system shall be able to determine if an IP flow requires IP 
address preservation or not. Based on this determination, the 3GPP network 
shall be able to offload selected IP traffic in coordinated manner between UE 
and the network, in order to minimize service disruption.
-  The 3GPP system shall be able to detect when a connection becomes 
suboptimal and decide when to establish a new optimal connection to the same 
defined IP network or use an existing connection.
Note 1:  The definition of optimal and suboptimal can be based on a number 
of implementation criteria like geography, topology and load balancing etc.
- The 3GPP system shall minimize the number of connections of a UE without 
disrupting the UE's services, e.g. to ensure economical use of network 
resources.
- The 3GPP system shall be able to ensure that the actual average aggregate 
bit rate for IP flows of packet data network connections associated with the 
same packet data network does not significantly exceed the subscribed aggregate 
maximum bit rate for this packet data network when two connections are used 
with the same defined IP network.

Note 2:  Requirements for Coordinated SIPTO do not apply to IMS.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] regarding the re-chartering..

[Jouni]

Alper,

I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 and 
stage-3 work. The ""deployment models and scenarios" are the stage-2 
descriptions and then we also need the protocol level solutions that are in 
separate documents.

Makes sense?

- Jouni


On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote:

>> Okay, we are not going to define how the existing 3FPP system works - that 
>> knowledge is assumed. What I thought goes into the document, for example, in 
>> the case of 3GPP system would be identifying the architecture changes or 
>> modifications needed. If the deployment model assumes all network functions 
>> are virtualized, the document states that and lays out the architecture 
>> based on that. Satoru's & Ryuji's vEPC deployment model (based on their 
>> solution) is IMHO a good example of what could be documented. The similar 
>> applies for other system architectures such as SP Wi-Fi etc.
>> 
> 
> Jouni,
> 
> The "architecture changes" would be based on the a "specific solution". So, 
> as part of describing a solution one can be talking about what you are 
> suggesting above. But I don't understand how we can be talking about 
> "deployment models and scenarios" before we agree on the solutions.
> 
> Alper
> 
> 
> 
> 
>>o Enhanced mobility anchoring: define protocol solutions for a
>>  gateway and mobility anchor assignment and mid-session mobility
>>  anchor switching that go beyond what has been specified, for
>>  example, in RFC 6097, 6463, and 5142. Traffic steering
>>  associated with the anchor switch is also in-scope if deemed
>>  appropriate.
>> 
>>o Forwarding path and signaling management: the function
>>  that handles mobility management signaling interacts with the
>>  DMM network elements for managing the forwarding state
>>  associated with a mobile node's IP traffic. These two functions
>>  may or may not be collocated. Furthermore, the forwarding state
>>  may also be distributed into multiple network elements instead
>>  of a single network element (e.g., anchor). Protocol extensions
>>  or new protocols will be specified to allow the above mentioned
>>  forwarding path and signalling management.
>> 
> 
> I cannot separate "mobility anchoring" from "fwding path and
> signaling management".
> Wherever you want to set your anchor or move your anchor to, you'd
> need signaling
> and setting up data path. The two are inseparable.
> Having said that, I'm OK to keep the current work item descriptions
> and finalize
> rechartering. Once we have detailed discussions about the breakdown
 of the work, we
> can come back and refine the goals and milestones (as already stated
 below [*]).
 
 The enhanced mobility anchoring above is/was rather MIP type solutions
 influenced with "anchors" like we understand today, while the
 "forwarding path and signaling management" was meant for more future
 oriented solutions where the forwarding path does not necessarily have
 anything mobility specific etc.
 
>>> 
>>> (Just FYI: It's not possible to gather what you are saying from reading
>>> the charter. Different people reading the charter may not have the same
>>> understanding. But like I said, this is just FYI, I can live with this
>>> text until we come back and refine it later).
>> 
>> Ok. I'll try to clarify the point the text tries to make.
>> 
>> - Jouni
>> 
>>> 
>>> Thanks.
>>> 
>>> Alper
>>> 
>>> 
>>> 
>>> 
 Any other opinions on collapsing these two?
 
 - Jouni
 
>>o Exposing mobility state to mobile nodes and network nodes:
>>  define solutions that allow, for example, mobile nodes to select
>>  either a care-of address or a home address depending on an
>>  application' mobility needs. In order to enable this
>>  functionality, the network-side control functions and other
>>  networking nodes must also be able to exchange appropriate
>>  control information, as well as to the mobile nodes and their
>>  applications.
>> 
>> The working group may decide to extend the current milestones based on
>> the new information and knowledge gained during working on other
>> documents listed in the initial milestones. [*]
> 
> 
> Cheers,
> 
> Alper
> 
> 
> 
> 
>> Possible new documents and
>> milestones must still fit into the overall DMM charter scope as outlined
>> above.
>> 
>> Goals and Milestones:
>> 
>> Feb 2015 - Submit 'The deployment models and scenarios' as a working
>>   group document(s). To be Informational RFC.
>> 
>> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group
>>   document. To be Proposed Standard.
>> 
>> Feb 2015 - Submit 'Forwarding pat

[DMM] 3GPP CSIPTO

[Alper Yegin]

Dear DMMers,

Here's an update on 3GPP SA1 CSIPTO work…

Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting SA1 has 
completed the CSIPTO normative work.
As you might remember, SA1 is in charge of defining service requirements.

The next step for CSIPTO is to initiate a work item in SA2.


And here's a copy-paste of the normative requirements (accepted doc is 
S1-143607.zip):


Some types of services (e.g. streaming services, VOIP, VPN, HTTPS-Based 
Services) cannot tolerate a change of IP address of the UE without disruption 
of the service.

SIPTO can be performed with or without coordination between the UE and the 
network. The following requirements apply to coordinated SIPTO:

- The 3GPP system shall be able to support multiple connections that are 
associated with the same defined IP network where each connection may or may 
not support IP address preservation.

- The 3GPP system shall be able to determine if an IP flow requires IP 
address preservation or not. Based on this determination, the 3GPP network 
shall be able to offload selected IP traffic in coordinated manner between UE 
and the network, in order to minimize service disruption.

-  The 3GPP system shall be able to detect when a connection becomes 
suboptimal and decide when to establish a new optimal connection to the same 
defined IP network or use an existing connection.

Note 1: The definition of optimal and suboptimal can be based on a number of 
implementation criteria like geography, topology and load balancing etc.

- The 3GPP system shall minimize the number of connections of a UE without 
disrupting the UE’s services, e.g. to ensure economical use of network 
resources.

- The 3GPP system shall be able to ensure that the actual average aggregate 
bit rate for IP flows of packet data network connections associated with the 
same packet data network does not significantly exceed the subscribed aggregate 
maximum bit rate for this packet data network when two connections are used 
with the same defined IP network.

Note 2:  Requirements for Coordinated SIPTO do not apply to IMS.___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] regarding the re-chartering..

[Alper Yegin]

> Okay, we are not going to define how the existing 3FPP system works - that 
> knowledge is assumed. What I thought goes into the document, for example, in 
> the case of 3GPP system would be identifying the architecture changes or 
> modifications needed. If the deployment model assumes all network functions 
> are virtualized, the document states that and lays out the architecture based 
> on that. Satoru's & Ryuji's vEPC deployment model (based on their solution) 
> is IMHO a good example of what could be documented. The similar applies for 
> other system architectures such as SP Wi-Fi etc.
> 

Jouni,

The "architecture changes" would be based on the a "specific solution". So, as 
part of describing a solution one can be talking about what you are suggesting 
above. But I don't understand how we can be talking about "deployment models 
and scenarios" before we agree on the solutions.

Alper




> o Enhanced mobility anchoring: define protocol solutions for a
>   gateway and mobility anchor assignment and mid-session mobility
>   anchor switching that go beyond what has been specified, for
>   example, in RFC 6097, 6463, and 5142. Traffic steering
>   associated with the anchor switch is also in-scope if deemed
>   appropriate.
> 
> o Forwarding path and signaling management: the function
>   that handles mobility management signaling interacts with the
>   DMM network elements for managing the forwarding state
>   associated with a mobile node's IP traffic. These two functions
>   may or may not be collocated. Furthermore, the forwarding state
>   may also be distributed into multiple network elements instead
>   of a single network element (e.g., anchor). Protocol extensions
>   or new protocols will be specified to allow the above mentioned
>   forwarding path and signalling management.
> 
 
 I cannot separate "mobility anchoring" from "fwding path and
 signaling management".
 Wherever you want to set your anchor or move your anchor to, you'd
 need signaling
>>> > and setting up data path. The two are inseparable.
 Having said that, I'm OK to keep the current work item descriptions
 and finalize
>>> > rechartering. Once we have detailed discussions about the breakdown
>>> of the work, we
>>> > can come back and refine the goals and milestones (as already stated
>>> below [*]).
>>> 
>>> The enhanced mobility anchoring above is/was rather MIP type solutions
>>> influenced with "anchors" like we understand today, while the
>>> "forwarding path and signaling management" was meant for more future
>>> oriented solutions where the forwarding path does not necessarily have
>>> anything mobility specific etc.
>>> 
>> 
>> (Just FYI: It's not possible to gather what you are saying from reading
>> the charter. Different people reading the charter may not have the same
>> understanding. But like I said, this is just FYI, I can live with this
>> text until we come back and refine it later).
> 
> Ok. I'll try to clarify the point the text tries to make.
> 
> - Jouni
> 
>> 
>> Thanks.
>> 
>> Alper
>> 
>> 
>> 
>> 
>>> Any other opinions on collapsing these two?
>>> 
>>> - Jouni
>>> 
> o Exposing mobility state to mobile nodes and network nodes:
>   define solutions that allow, for example, mobile nodes to select
>   either a care-of address or a home address depending on an
>   application' mobility needs. In order to enable this
>   functionality, the network-side control functions and other
>   networking nodes must also be able to exchange appropriate
>   control information, as well as to the mobile nodes and their
>   applications.
> 
> The working group may decide to extend the current milestones based on
> the new information and knowledge gained during working on other
> documents listed in the initial milestones. [*]
 
 
 Cheers,
 
 Alper
 
 
 
 
> Possible new documents and
> milestones must still fit into the overall DMM charter scope as outlined
> above.
> 
> Goals and Milestones:
> 
> Feb 2015 - Submit 'The deployment models and scenarios' as a working
>group document(s). To be Informational RFC.
> 
> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group
>document. To be Proposed Standard.
> 
> Feb 2015 - Submit 'Forwarding path and signaling management' as a
>working group document. To be Proposed Standard.
> 
> May 2015 - Submit 'Exposing mobility state to mobile nodes and network
>nodes' as a working group document(s). To be Proposed
>Standard.
> 
> 
> May 2015 - Submit 'The deployment models and scenarios' submitted to
>the IESG. To be Informational RFC.
> 
>