Pascal,
            The relocation process from SF0 is meant
also to detect collisions after random allocation, among
other sources of packet loss, such as narrowband
interference or noise.
Regards,

                                 Diego

2016-11-02 12:06 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:

> Hello Tengfei;
>
>
>
> this looks very useful in the context of the minimal cell allocation
> (Xavi’s random appropriation and collision detection).
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Tengfei
> Chang
> *Sent:* mercredi 2 novembre 2016 15:47
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] [6TISCH] RELOCATE command in sixtop?
>
>
>
> All,
>
>
>
> I would like to propose an idea to add a new command called RELOCATE
> command in sixtop.
>
> This RELOCATE sixtop command will contains the cells to be added and
> removed in single packet.
>
>
>
> Without RELOCATE command, the relocation is done through adding one cell
> first then deleting one cell.
>
> With RELOCATE command, once the sixtop transaction for relocation
> successes, the relocation process is done.
>
>
>
> There are several benefit from RELOCATE:
>
>
>
> 1.save overhead of relocation process.
>
> 2. avoid the influence of relocation on SF0. It requires SF0 to take the
> relocation into consideration if the cell is added through relocation or
> not. SF0 may take different decision.
>
>
>
> What do you think?
>
>
>
> Tengfei
>
>
>
>
>
>
> --
>
> Chang Tengfei,
>
> Pre-Postdoctoral Research Engineer, Inria
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to