Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Behcet, thanks for clarifying more clearly. :) On Fri, May 23, 2014 at 4:15 AM, Behcet Sarikaya sarikaya2...@gmail.comwrote: -- snip -- Ah, I see what you mean. Yes, I'm sure that RR/RS just only know about routes, nor whole mobility information exists. When I see a node which plays MME role, the node could also be a BGP speaker to export the mobility info transformed to the routes. So MME should be BGP speaker? If not then what would happen? Precisely, say MME, which 3GPP defined mobility management entity, doesn't have the BGP function. IMO, If the entity can be coexist with BGP in a single node, an interface for exposing/retrieving mobility information would be required between them. What do you mean by topologically incorrect? Is that the assigned prefixes are disordered to be aggregated? Yes. UE moves to another EPC-E which supports a different prefix than UE has? You need to keep host-based prefixes as routes, is there another way? In the draft, as long as an UE keeps same prefix during hand-over among EPC-E routers, those routers belong to a same group that is expected to preserve same prefix for the UE. It should be initial attach when the UE is attached to different EPC-E and assigned different prefix from previous one. Please read section 3.3 and 3.4 of the draft. cheers, --satoru ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Hi Behcet, Yes, EPC-E routers should be default router for UEs. If I understand the background of your question correctly, you think an UE session is moved from an EPC-E router from another while moving around. It should be true because the UE sending packets are routed most closest node of the anycast tunnel. The assumption here is the c-plane will guide the UE session to connect an appropriate EPC-E routers set which preserve the UE route and shares the anycast address. That sounds like UEs are always in the area where it wouldn't require eNB to changing remote end-point of the tunnel. cheers, --satoru On Fri, Apr 18, 2014 at 6:57 AM, Behcet Sarikaya sarikaya2...@gmail.comwrote: Hi Satoru, I have a question about vEPC. As the UE moves around its default router changes. Which node is the default router? EPC-E? Regards, Behcet On Tue, Apr 1, 2014 at 10:07 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Peter, On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann peter.mcc...@huawei.comwrote: --snip-- No, it isn't meant that specific routes to indicate each UEs prefix are advertised into the core. I'll try to improve that text in next revision of the draft. Yes please clarify because the current text seems to say that UE prefixes are advertised into the core. Yes, thanks. I agree with you if a EPC-E has whole UE specific routes that exceed its capacity, it doesn't scale, yes. In the recent presentation through the webex, Ryuji were trying to explain that it's not intended to do. Routes contained in EPC-E will be limited/partitioned by operators policy, such as region, service, population scale, etc., I was a bit confused by the suggestion to partition by region, because there would be no mobility across regions if you partitioned in this way. That's because different regions would use different PDN prefixes. But, I suppose it would be ok to do this if you didn't need to support UE mobility across regions (or if you used OTT mobility such as client MIP for those cases). Partitioned by region sounds like that each regional network is isolated so that they has no connectivity between them. But it is not what I meant. Although a PDN prefix would be partitioned by region, the networks doesn't really need to be isolated. For example, when all EPC-E routers have connectivity to reach all RAN nodes, it makes easy to provide mobility across regions. Do you think that describing in the draft this kind of networking concept would be helpful to make things clear? You seem to attempt to address this issue in Section 4.1 when you talk about multiple sets of EPC-E devices, each one dedicated to a given geographic region. Ah, no. Sec 4.1 is intended to explain just scalability issue, and how to deal that issues with routing techniques in operation. Ok, I guess in the most common case you would have several slices of EPC-E, each set serving a different PDN prefix and a different set of UEs. There would be one EPC-E from each slice, each representing a partition of the PDN prefixes, at each EPC-E deployment site between eNBs and core. A given UE's current location would need to be BGP UPDATEd to each of the EPC-E in the slice that covered that UE's PDN prefix. In my mind, that sounds like when an operator assign a prefix to a PDN, the operator can divide the prefix into several longer prefixes. Each divided prefix, let's say sub-PDN prefix, may be allocated to a region, or any other operator's partition policy. It doesn't need to be assign a whole PDN prefix to a partition, or slice you said. It seems to me that each set of EPC-E could cover no more than the scope covered by a singleSGW today, because they each have the same amount of state as an SGW. Essentially you have described how to build a replicated SGW with failover to different nodesbased on the re-convergence of BGP after a failure (presumably you could get the core network to react to the closure of a BGP TCP session). So I think this addresses the problem of fault-tolerance that has been identified with the tunnel-based solutions, but not really the scalability bottleneck problem. The nature of BGP makes easy to do that. I think Sec 3.4 would be right place to explain that. But I couldn't see that flavor of text in sec 4.1. Would you point which text in Sec 4.1 makes you confuse? It was the text in the penultimate paragraph that talked about partitioning by region. If you do that, there is no mobility across regions, right? As I mentioned before, mobility across regions is available. But if you partition by PDN prefix (sets of UEs) then you can have a whole stack of EPC-E at each deployment site, covering the entire population of UEs. In fact, if you consider mobility from one set to another, if you want to keep the UE's IP address
Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Hi Peter, On Sat, Mar 29, 2014 at 3:32 AM, Peter McCann peter.mcc...@huawei.comwrote: Ryuji, After viewing your slides from the presentation you did overnight (sorry I couldn't be on the call) I went back and re-read the draft-matushima-stateless-uplane-vepc-02 draft. I am still confused about a number of things: Thanks. Let me try to answer your questions. You show in Figure 4, step 15 a Route Update (is this a BGP UPDATE?) going from the EPC-E to the core network RTR, containing a Destination of UE-prefix and a Next-Hop of EPC-E address. However, in Section 3.4, you describe the RTR as knowing only the PDN prefix, which is the same for all EPC-E, and the use of hot-potato routing to deliver the packets to the nearest EPC-E no matter the UE destination IP address. Which one is it? Are the UE prefixes advertised into the core or not? No, it isn't meant that specific routes to indicate each UEs prefix are advertised into the core. I'll try to improve that text in next revision of the draft. Assuming for now that the UE prefixes are not advertised into the core, but only the PDN prefixes are advertised, then that means that every EPC-E must know about every UE session, including the eNB F-TEID for every UE in the network, correct? Yes, it's correct. That's because any one of them at any time could receive a packet for the UE from the core. This doesn't seem scalable to me. I agree with you if a EPC-E has whole UE specific routes that exceed its capacity, it doesn't scale, yes. In the recent presentation through the webex, Ryuji were trying to explain that it's not intended to do. Routes contained in EPC-E will be limited/partitioned by operators policy, such as region, service, population scale, etc., You seem to attempt to address this issue in Section 4.1 when you talk about multiple sets of EPC-E devices, each one dedicated to a given geographic region. Ah, no. Sec 4.1 is intended to explain just scalability issue, and how to deal that issues with routing techniques in operation. It seems to me that each set of EPC-E could cover no more than the scope covered by a single SGW today, because they each have the same amount of state as an SGW. Essentially you have described how to build a replicated SGW with failover to different nodes based on the re-convergence of BGP after a failure (presumably you could get the core network to react to the closure of a BGP TCP session). So I think this addresses the problem of fault-tolerance that has been identified with the tunnel-based solutions, but not really the scalability bottleneck problem. The nature of BGP makes easy to do that. I think Sec 3.4 would be right place to explain that. But I couldn't see that flavor of text in sec 4.1. Would you point which text in Sec 4.1 makes you confuse? In fact, if you consider mobility from one set to another, if you want to keep the UE's IP address, you would need to broadcast the same set of PDN prefixes from all sets of EPC-E. In fact this would mean that all EPC-E throughout the network, even if they are in different sets, need to be prepared to handle packets for any UE and so they ALL would need the eNB F-TEIDs for ALL UEs. Please tell me where I have made a mistake. No, an EPC-E just only receives packets from v6 core network toward UEs that routes installed into EPC-E. Because of that an EPC-E should advertise aggregated routes only for that includes its downstream UEs. When the EPC-E advertises whole routes to the core as you explained, yes I agree with you that won't be scalable. But it would depend on EPC-E capacity and size of UE population in the network. cheers, --satoru ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt
Liu, MN's prefixes could be converged into an aggregated route. It is routing. So MN are always expected within the area where it covers as long as the aggregated route existed in the core network. cheers, --satoru On Fri, Jul 12, 2013 at 10:59 AM, Liu Dapeng maxpass...@gmail.com wrote: 2013/7/12 Satoru Matsushima satoru.matsush...@gmail.com: Hi Liu, Thanks for your good question. We, bgp operator are struggle fast convergence for bgp that most of the issues come from best path recalculation on bgp speaker. In the proposed architecture we expect no such kind of recalc but just simple update to epc-e from vepc. BGP is an incremental routing protocol so that bgp should be capable to continuously update route to mobile nodes as they moving. Please noted that it is happened only on RAN facing side on epc-e, not on ipv6 core network side. [Dapeng] You mean the MN's prefix can be converged in the core network? You can do this when the MN moves in a small area, but if the MN moves out from that area, it is difficult to converge. Thanks, Dapeng Liu So routing in ipv6 core can be much stable. cheers, --satoru On Fri, Jul 12, 2013 at 12:24 AM, Ryuji Wakikawa ryuji.wakik...@gmail.com wrote: Hi Liu For routing update matter, I will let my colleague to answer this. The routing update is happened just within an operator's network. The route for UE is just overwritten with the new information. I believe BGP can easily handle these updates. We haven't discussed billing and roaming. but what we are thinking now is following. If special treatment is needed (like roaming), we keep using the original EPC functions available at NFV. Packets are routed to EPC U-/C-planes on NFV. For billing, we need some mechanism between U-/C- plane and didn't identify a solution yet. We will try to identify it at the next revision. thanks ryuji On Jul 11, 2013, at 1:12 AM, Liu Dapeng maxpass...@gmail.com wrote: Hi Ryuji, Thanks for posting an very interesting draft. Build distributed mobility using BGP has been discussed in DMM before. For example: http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. My comments: 1. How to deal with routing fluctuation problem? Using BGP in Boeing on-board system is quite different from mobile network. Boeing on-board system normally does not have too much mobile node (the flight is only one mobile node), but for the mobile network, there could be hundreds of millions of mobile nodes keep moving and will result in lots of routing updates. 2. Billing and policy enforcement is not discussed in the draft. Do you have any thoughts on this? Thanks, Dapeng Liu 2013/7/11 Ryuji Wakikawa ryuji.wakik...@gmail.com: Hi We submit a new document. Your comments are appreciated! thanks, ryuji Begin forwarded message: From: internet-dra...@ietf.org Subject: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt Date: July 10, 2013 9:09:44 AM PDT To: Ryuji Wakikawa ryuji.wakik...@gmail.com, Satoru Matsushima satoru.matsush...@g.softbank.co.jp A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt has been successfully submitted by Satoru Matsushima and posted to the IETF repository. Filename: draft-matsushima-stateless-uplane-vepc Revision: 00 Title: Stateless user-plane architecture for virtualized EPC (vEPC) Creation date: 2013-07-10 Group: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt Status: http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc Htmlized: http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 Abstract: We envision a new mobile architecture for the future Evolved Packet Core (EPC). The new architecture is designed to support the virtualization scheme called NFV (Network Function Virtualization). In our architecture, the user plane of EPC is decoupled from the control-plane and uses routing information to forward packets of mobile nodes. Although the EPC control plane will run on hypervisor, our proposal does not modify the signaling of the EPC control plane. The benefits of our architecture are 1) scalability, 2) flexibility and 3) Manageability. How to run the EPC control plane on NFV is out of our focus in this document. The IETF Secretariat ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- -- Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ dmm mailing list dmm@ietf.org https
