Hi Ben,

On Tuesday, July 9, 2013, Ben Niven-Jenkins wrote:

> Richard
>
> On 9 Jul 2013, at 22:48, "Y. Richard Yang" 
> <[email protected]<javascript:_e({}, 'cvml', '[email protected]');>>
> wrote:
>
>
>
>> Introducing an identifier for each resource may make the entries look
>> more "consistent" but it's not clear to me how (or whether) they'd be used.
>> If folks think it's worthwhile I won't object but keeping things simple
>> helps keep the usage clear.
>>
>
> One usage that I have in mind is that later, when we build up more
> services, for example, on top of cost map, then the application or
> higher-level service can use the costmap id to identify the costmap that
> serves as the base.
>
> More specifically, one item that I am working on is topology service and
> even make ALTO as a base for actions. For example, an app fetches a
> topology, and computes a route. When the app submits the request to
> instantiate the route, the app should identify the map used (by using both
> id and vtag) so that the network can retrieve the corresponding topology.
>
>
> The app may need to identify the map used but why does it need to identify
> the cost map separately to the network map?
>

Good question. Let me elaborate more. The use case is that the network
gives an app a topology to allow the app to choose paths according to
the app's policy. Different apps/users can be given different abstract
topologies, due to access control and simplification considerations. Assume
a base network G0. The service provider transforms the base network to
obtain an abstract network topology. One of the transformation primitives
is to add virtual links. For example, there is no link between A and B, but
the ALTO server adds a virtual link from A to B representing a path
A->C-E->B, which can be implemented using a tunnel. The server deletes the
physical links A->C, C->E, and E->B. Given its abstract topology, the app
chooses paths for its origin-destination pairs. As an example, the app
may chose a path that uses the A-B link in the topology that it is
given. Another app may also be given a virtual A->B link, but this virtual
link is for a different path. Hence, when the network gets a route request
that contains the A->B link, the network needs to know the cost map to map
back to physical links to implement the request. Each abstract topology can
have different nodes and different links. Given that the current
ALTO encodes the node (network) map used by the (link) cost map, the app
only needs to identify the topology (link map), which points to the
corresponding node map. To summarize, app identifies the cost (link) map is
enough, and no need for including the network (node) map, as you pointed
out. Does this clarify or become more confusing?

Richard
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to