Subject: [geonet/its] A possible geonet use-case

From: Dino Farinacci <[email-masked]>
Date: Sat, 14 Dec 2013 10:59:18 -0800

Folks, the chair of the 'its' BOF asked me to repost this use-case. I will try to describe it in a solution agnostic way. So apologize in advance for the slide that reads LISP on it.

The use-case described in the slide is a control-plane use-case only. There is no packet routing involved.

It is a way to use your existing network infrastructure investment and get more functionality out of it. Here is the basic idea:

(1) What you want to track has an IP address. It can be an opaque IP address and certainly not a Provider-Assigned IP address.

(2) The routers are configured with geo-coordinates (they are not required to have GPS receivers) of their physical location.

(3) When the tracked device appears to these routers, the IP address of the tracked device is associated with one more geo-coordinates of the routers.

(4) The routers can put this information in various types of databases.

One could see how a data-plane application could also extend this use-case.

Thanks,
Dino

---

From: sofiane Imadali <[email-masked]>
Date: Tue, 17 Dec 2013 12:11:16 +0100

Hi Dino, All,
The use case is interesting and, I think, could bring an added value to the
Geonet scenarios as a concrete perspective. I have some questions and
comments, if you don't mind, about some specific details of the use case
(also to confirm my comprehension of this topic):

1-> You are mentioning a provider-independent addressing for the packages,
is this addressing the responsibility of Fedex /UPS/Postal-service for
example ? that is, the one who delivers (Postal services) or the one who
sends (eMarket online, the such of amazon)? Both are
"providers-independent" but imply a different placement for the RLOC-to-EID
databases (see 3)...

2-> On a higher level, do you intend to make use of the (fixed) GPS
coordinates to translate the Provider-independent address on a
topology-related address ? (topology here relates to the Geographic
coordinates and somehow the local provider's)

3-> Depending on the answer to 1, a truck hosting several packages (n) with
not necessarily the same prefixes, would make (n) updates using the local
infrastructure, right ? is it possible to imagine an embedded Mobile Router
(a key element in Geonet) doing the work on behalf of the packages,
especially if the topology inside the truck (connected to the MR) is
homogeneous (in the case of a Postal service assigned prefix) ? (I hope
it's clear)

I think that those points determine if the Geonet is compatible and how it
could enhance a LISP-related use case, do you think so ?

Thanks in advance for your answers!

Best regards
Sofiane Imadali

On Sat, Dec 14, 2013 at 7:59 PM, Dino Farinacci <[email-masked]> wrote:

> Folks, the chair of the 'its' BOF asked me to repost this use-case. I will
> try to describe it in a solution agnostic way. So apologize in advance for
> the slide that reads LISP on it.
>
> It is a way to use your existing network infrastructure investment and get
> more functionality out of it. Here is the basic idea:
>
> (1) What you want to track has an IP address. It can be an opaque IP
> address and certainly not a Provider-Assigned IP address.
>
> (2) The routers are configured with geo-coordinates (they are not required
> to have GPS receivers) of their physical location.
>
> (3) When the tracked device appears to these routers, the IP address of
> the tracked device is associated with one more geo-coordinates of the
> routers.
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 17 Dec 2013 07:48:26 -0800

> Hi Dino, All,
> The use case is interesting and, I think, could bring an added value to the Geonet scenarios as a concrete perspective. I have some questions and comments, if you don't mind, about some specific details of the use case (also to confirm my comprehension of this topic):
> 
> 1-> You are mentioning a provider-independent addressing for the packages, is this addressing the responsibility of Fedex /UPS/Postal-service for example ? that is, the one who delivers (Postal services) or the one who sends (eMarket online, the such of amazon)? Both are "providers-independent" but imply a different placement for the RLOC-to-EID databases (see 3)...

In this case, Fedex wanted to use their own tracking numbers and didn't want an application database to map from tracking number to say a PA or even PI IPv6 address. They wanted it one in the same.

> 2-> On a higher level, do you intend to make use of the (fixed) GPS coordinates to translate the Provider-independent address on a topology-related address ? (topology here relates to the Geographic coordinates and somehow the local provider's)

This is the way it works with LISP:

(1) The package appears to routers. The routers learn these EIDs dynamically. The EIDs have no topological signifance to the Internet topology or the physical Geo topololgy.
(2) The routers register the EIDs to the LISP mapping database system with a RLOC that is encoded with {lat, long, alt}.
(3) When a user (via an application) asks "where is my package", the mapping database returns the "geo coordinates" that have been registered.

So this is a typical LISP mapping database lookup where the EID is typically the lookup key (EIDs can be encoded in any form) which returns a RLOC-set (RLOCs can be encoded in any form as well).

> 3-> Depending on the answer to 1, a truck hosting several packages (n) with not necessarily the same prefixes, would make (n) updates using the local infrastructure, right ? is it possible to imagine an embedded Mobile Router (a key element in Geonet) doing the work on behalf of the packages, especially if the topology inside the truck (connected to the MR) is homogeneous (in the case of a Postal service assigned prefix) ? (I hope it's clear)

When we did this with LISP, we just recurse the idea. So if two packages, each with EIDs are basically opaque, are associated with a Truck. That association of the truck is another EID. So you have this:

(1) Package 1 has an iPhone in it. Assigned an EID from tracking number.
(2) Package 2 has my iPhone case in it. Assigned an EID from tracking number.
(3) Truck is assigned an EID and its RLOC maps to its physical location as it is moving.

When package 1 and package 2 have roughly the same geo-coordinates, I can tell they are together. But they may be sitting in the same building at a distribution center.

When the packages are loaded on the truck (same truck or different trucks), the package 1 and package 2 RLOCs are change do the EID of the truck (they can also keep their geo-coordiantes as well).

I can do a lookup on package 1 EID and find out it is in the same truck with package 2. Or I can find out they are in different trucks but at the moment, they are in the same city.

> I think that those points determine if the Geonet is compatible and how it could enhance a LISP-related use case, do you think so ?

The whole point so physical locality has lots of value. And decisions on where to send packets can be based on physical proximity/locality.

Using a level of indirection in routing allows more usage of geo-coorindates, where it would be much harder to do it in the underlying routing protocols and infrastructure.

Dino

> <Screen Shot 2013-12-14 at 10.41.25 AM.png>
>

---

From: Henry Ptasinski <[email-masked]>
Date: Tue, 17 Dec 2013 09:16:33 -0700

Dino

What network technology (PHY/MAC) is used in this scenario?  Is this
something that's been deployed, or just a concept at this point?

IEEE 802.11 added some location tracking functionality as part of
802.11v.  Similar to your scenario, it operates in the control plane
only.  Tracking can be done based on MAC address, but the frames also
allow for vendor-specific additional info so e.g. each delivery service
could include their own format tracking number and additional info.

(I assume some other MAC standards have their own version of this, but
don't know for certain.)

Putting the functionality at the MAC layer (presumably) allows for a
simpler implementation of the device on the package. Using IPv6
leverages makes the system MAC-agnostic, but I'm not sure what other
benefits it provides over a MAC-layer approach (in either case, the
distribution centers, trucks, etc. could still be using geonet).  Thoughts?

---
Henry Ptasinski
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 17 Dec 2013 08:33:25 -0800

> something that's been deployed, or just a concept at this point?

The underlying network is IP of course. Or do you mean the wireless network between packages and routers?

This was demoed and is not a production deployment.

> distribution centers, trucks, etc. could still be using geonet).  Thoughts?

We want packages to roam ANYWHERE. Therefore it must sit on top of layer-3 and not layer-2.

Dino

---

From: Henry Ptasinski <[email-masked]>
Date: Tue, 17 Dec 2013 10:54:55 -0700

> We want packages to roam ANYWHERE. Therefore it must sit on top of layer-3 and not layer-2.

In this specific use case, do you really mean "ANYWHERE" or rather
"anywhere within the control of the package delivery service"?  Under
what scenarios do you expect packages to show up on networks that are
not controlled by the carrier?  (Lost packages, perhaps?  Or maybe the
package checks in from my home wireless network to report that it's been
delivered?  But how does it get access to the network if spme form of
security/auth is enabled?)

Do you expect multiple layer-2 technologies to be integrated into a
single package tracking tag?  Are tags disposable or reusable?

Thanks,
---
Henry Ptasinski
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 17 Dec 2013 16:11:20 -0800

> "anywhere within the control of the package delivery service"?  Under

I meant anywhere on the global Internet.

> security/auth is enabled?)

I was generalizing mobility, not referring to anywhere as that is how a Fedex package should roam.

> single package tracking tag?  Are tags disposable or reusable?

That is work in progress. And the tough nut to crack at low cost points.

Dino