[DMM] APIs
Folks, There was discussion about necessity of APIs for DMM yesterday. Let's continue that discussion here. It is true that IETF's primary focus is protocol design. But when it's necessary, IETF also defines APIs. See, IPv6 basic socket API, for example. And, as a very relevant item, see RFC 5014, source address selection API. In RFC 5014, there's even consideration to mobility, in terms of apps selecting home address vs care-of address as their source address. I think by now it's clear to everyone that we can no longer treat all IP flows equally when it comes to providing IP mobility treatment to them. This is already recognized in the charter. The way to take apps' mobility need into account is to give them an API. RFC 5014 already made an attempt at that, but fell short. Now that we have a better understanding of the issues, we should extend that API. Once we define that API, other APIs (OS specific ones that are not under the control of IETF) can follow the same path. Discussion welcome. Alper ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] 3GPP CSIPTO
9/3/2014 9:54 AM, Alper Yegin kirjoitti: Sri, On Sep 2, 2014, at 6:32 PM, Sri Gundavelli (sgundave) wrote: Alper - The idea is to make sure the simultaneous PDN connections do not keep adding up each time the UE encounters a new GW. Is that not truly a deployment consideration ? Supporting #N simultaneous PDN connections per UE has implications on the systems. So, it's not really only about deployment considerations. The 3GPP system is able to support up to 11 PDN Connections (or any bearers to be precise). This limit is on both UE and network side. What I cannot now remember on top of my head is whether the limitation is just per UE-PGW pair. Need to check that. So, it also means the maximum number of prefixes per UE in 11.. unless prefix delegation is used (but in that case the prefixes are not for the UE but the LAN side nodes). If the approach is gateway selection based on application/CN basis, can the network control this ? Not sure how to answer that. Probably this can be discussed in the context of a specific solution…. Network should be able to control this. If not, it will be added most probably. - JOuni Alper Regards Sri From: Alper Yegin alper.ye...@yegin.org mailto:alper.ye...@yegin.org Date: Monday, September 1, 2014 7:39 AM To: Marco Liebsch marco.lieb...@neclab.eu mailto:marco.lieb...@neclab.eu Cc: dmm@ietf.org mailto:dmm@ietf.org dmm@ietf.org mailto:dmm@ietf.org Subject: Re: [DMM] 3GPP CSIPTO 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 mailto: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 http://www.3gpp.org/ftp/tsg_sa/WG1_Serv/TSGS1_67_SophiaAntipolis/docs/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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
On Wed, Sep 3, 2014 at 12:07 AM, Jouni Korhonen jouni.nos...@gmail.com wrote: We were on this in yesterday's interim call. We have a proposal text now. You were also on the call but I did not record you commenting anything during the discussion we had on this particular topic. I had leave early due to doctor's appointment. Are you now saying the resolution we have now in the charter text is not adequate? Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions would apply. Behcet: the above text does not reflect my comments. I am against any deployment work before we decide on a solution (and there is currently no draft on this). This is strongly supported by IETF work on deployment as well as 3GPP. I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. He also emphasized importance of running code. It is not that we don't have solutions and it is claimed that two of them have been implemented. Regards, behcet - JOuni 9/2/2014 11:39 PM, Behcet Sarikaya kirjoitti: On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: 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. I hope you read previous mails on this issue. I think it clear that 3GPP agrees with IETF on the interpretation of deployment. How can we close our eyes on this and try to put the horse before the cart? Why not simply remove it? Regards, Behcet - Jouni 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti: On Mon, Sep 1, 2014 at 3:25 AM, Jouni jouni.nos...@gmail.com 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
Re: [DMM] regarding the re-chartering..
Just for clarification... On 9/3/14 12:22 PM, Behcet Sarikaya wrote: I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. Not should, but rather could. Not all WGs need to have requirements, frameworks, architecture, etc. That is why this type of discussion during charter development is important. He also emphasized importance of running code. Running code is good thing. So is an understanding of customer needs (in this case, other SDOs). Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Hi Brian, On Wed, Sep 3, 2014 at 11:30 AM, Brian Haberman br...@innovationslab.net wrote: Just for clarification... On 9/3/14 12:22 PM, Behcet Sarikaya wrote: I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. Not should, but rather could. Not all WGs need to have requirements, frameworks, architecture, etc. That is why this type of discussion during charter development is important. Here is the quote: WGs should have solution work from day 1 from page 22 of Jari's slides at: http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf BTW we already did the requirements and gap analysis, etc. The architecture in our case is defined elsewhere, like 3GPP and everybody in this group is familiar with 3GPP architecture. He also emphasized importance of running code. Running code is good thing. So is an understanding of customer needs (in this case, other SDOs). Absolutely. Regards, Behcet Regards, Brian ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
On 9/3/14 12:50 PM, Behcet Sarikaya wrote: Hi Brian, On Wed, Sep 3, 2014 at 11:30 AM, Brian Haberman br...@innovationslab.net wrote: Just for clarification... On 9/3/14 12:22 PM, Behcet Sarikaya wrote: I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. Not should, but rather could. Not all WGs need to have requirements, frameworks, architecture, etc. That is why this type of discussion during charter development is important. Here is the quote: WGs should have solution work from day 1 from page 22 of Jari's slides at: http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf Yes, that is what the slide says. The IESG discussed the contents of this presentation and the overwhelming consensus (and what was verbalized in the plenary) is that WGs should not be formed where the *only* output is architecture, frameworks, and/or requirements documents. The charter should have protocol/solution work on the charter from day one. It does not mean that non-solution documents should be skipped if they are needed or provide useful background. The charter text that Jouni sent to the mailing has four (4) work items. By my read, three (3) of them are solutions to identified problem areas. So, I believe the charter is following the spirit of Jari's plenary slides. Your only complaint is about the first work item. I have seen people asking about clarifications on that work item, but you are the only one who wants it removed. I believe others are in favor of providing a document of the high-level models being targeted for the solutions work. At this point, the WG chairs need to determine if there is consensus for the latest charter text. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
