# T-Move: A Light-Weight Protocol for Improved QoS in Content-Centric Networks with Producer Mobility
## 4 T-Move
### Mobility Support in T-Move
#### 4.2.3 Behavior of Upstream Routers
Else, it updates the FIB entry by deleting the face and drops the FIB update (R3 in Figures 3 and 4 for _x/y/z/a_). * If it receives a FIB update only to _add_ the FIB entry, it adds the face on which the FIB update is received to the longest prefix-matching the string in the update message and drops the update (R4 in Figures 3 and 4 for _x/y/z/a_). * _Case 2--Uptstream router receives FIB update for addition or deletion of a data object_: In Case 2, upstream routers are not connected to both the old and new location of the data object by any face, such as R3 and R4 in Figures 3 and 4. These figures depict the state of the FIBs after the FIB updates are sent from R1, R2 and after the FIB updates are sent from R3, R4, respectively. * If a router receives a FIB update only to _delete_ the FIB entry, it checks if the face on which the update is received is the only face listed in the FIB for this data object. If yes, it deletes the entry and forwards the update to its upstream router (R3 in Figures 3 and 4 for _x/y/z/b_). Else, it updates the FIB entry by deleting the face and drops the FIB update (R3 in Figures 3 and 4 for _x/y/z/a_). * If it receives a FIB update only to _add_ the FIB entry, it adds the face on which the FIB update is received to the longest prefix-matching the string in the update message and drops the update (R4 in Figures 3 and 4 for _x/y/z/a_). * _Case 2--Uptstream router receives FIB update for addition or deletion of a data object_: In Case 2, upstream routers are not connected to both the old and new location of the data object by any face, such as R3 and R4 in Figures 3 and 4. These figures depict the state of the FIBs after the FIB updates are sent from R1, R2 and after the FIB updates are sent from R3, R4, respectively. * If a router receives a FIB update only to _delete_ the FIB entry, it checks if the face on which the update is received is received is the only face listed in the FIB for this data object. If yes, it deletes the entry and forwards the update to its upstream router (R3 in Figures 3 and 4 for _x/y/z/b_). Else, it updates the FIB entry by deleting the face and drops the FIB update (R3 in Figures 3 and 4 for _x/y/z/a_). * If it receives a FIB update only to _add_ the FIB entry, it adds the face on which the FIB update is received to the longest prefix-matching the string in the update message and drops the update (R4 in Figures 3 and 4 for _x/y/z/a_). * _Case 2--Uptstream router receives FIB update for addition or deletion of a data object_: In Case 2, upstream routers are not connected to both the old and new location of the data object by any face, such as R3 and R4 in Figures 3 and 4. These figures depict the state of the
The above scheme reduces the number of FIB updates by dropping the update messages wherever possible. At the same time, interests can still be routed to the new location of data. The new location of data is based on trendiness which is in turn based on prefix-matching. Since prefix-matching is also the basis for interest forwarding, new interests will eventually be routed by upstream routers to reach the caching router, from where the data object can be sent. Since data is cached at a place where it is most likely to be accessed from, the cache hit ratio is better than naive proactive pushing of data, even if it requires some FIB updates. The overall number of messages (and traffic in bytes) exchanged is still less than plain NDN or MAP-Me, which is also an anchorless producer mobility scheme.