>> I have been told that the Radio Access Network (RAN) tends to be sensitive >> to overlay solutions due to large headers. I have also heard that there >> seems >> to be queuing behavior for the base-stations that send to UEs (i.e. phones). >> The >> fact that queuing is happening while waiting for a handoffs to occur can be >> a good >> opportunity to pack IP packets into super-frames to send over the RAN. > > So what you propose is to take the packets waiting in the queue, and to > aggregate them into bigger ones, before sending them to the mobile node right?
To do any type of packet aggregation, you need a queue of packets. I don’t want to explicit create a queue just to get super-framing/packet-aggregation. But if it is happening for other reasons, the opportunity does present itself. But I’m not sure yet if there is huge benefits. Because large packets have their own set of problems. > Could this fit with other use case? In > http://research.cisco.com/pdfs/LISP-MN%20mobile%20networking%20through%20LISP.pdf > > (page 9), a LISP-based mobility scheme is explained in detail: > > In this section we describe the handover process in LISP-MN. When a MN > changes its attachment it regains connectivity in a new subnetwork. It > first > obtains a new RLOC and, as described in section 2.3.1, it notifies the > new > EID-to-RLOC binding to its Map-Server. The MN has to update also all the > bindings stored in the Map-Cache of the peers, either routers or nodes, > with > which it is communicating. In order to do it uses the special > signalling message > called Solicit-Map-Request (SMR). The reception of such message > triggers a > Map-Request to refresh the binding (...). > > Would it make sense to also multiplex packets waiting before the EID-to-RLOC > binding is updated? Today, it is hard for hardware to queue packets on the input side. And on the output side, most hardware that performs lookups then packet rewrites, queues packets and forgets them. They typically don’t pull them out to do processing later. Dino > >> Using this solution means the eNodeB (base-station) and the UE (phone) would >> have to run LISP. I would like to hear comments from the WG. I have copied >> 5gangip to see if they have opinions. >> >> Dino >> > > Thanks! > > Jose > PS: If you could detail a bit more the use case you are talking about, it > would be fine. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
