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.com>wrote: > 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.com>wrote: >> --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 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? >>> >>> 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, 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. >>> >>> Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE >>> population, right? There is no need to put all UEs on all EPC-Es. >>> >> >> Right. >> >> cheers, >> --satoru >> >> _______________________________________________ >> 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
