Clarifying Cost Map Dependencies on a Network Map
Richard Alimi <rich <at> velvetsea.net>
2013-06-20 07:45:21 GMT
[ We would like to hear feedback on this. We are planning to revise and submit a new version ASAP, so please voice opinions on this within the next few days, by Monday, June 24th. ]
Background:
Today, the ALTO protocol as a 'version tag' to indicate which version of a network map is used by a particular cost map.
In a particularly simple case, a single ALTO server is served by a single hostname (or IP address, whatever), and it exposes a single network map and one or more cost maps. There is no ambiguity here - a client automatically knows that any version tag refers to the single network map that is hosted by the server.
There are two alternate scenarios where ambiguities arrive:
(Scenario 2) A single ALTO server (single hostname) wishes to provide two different network maps (say, different levels of aggregation) and wants to provide cost maps for each of them. Currently, the version tag accompanying a cost map is not sufficient for a client to determine which network map a particular cost map is based on.
Proposal:
To resolve these problems, we'd like to propose a simple change to the version tag accompanying the cost map - it would now include the URI to the network map in addition to an opaque ID.
OLD (what we have now):
{
"meta" : {},
"data" : {
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"},
"map-vtag" : "1266506139",
"map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}
}
NEW PROPOSAL:
{
"meta" : {},
"data" : {
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"},
"network-map" : { "uri": "
http://alto.example.com/networkmap1"
"vtag": "1266506139"
} "map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}
}
Compared to the current approach we have in draft -16 (which is for a version tag to be consistent within resources served by the same hostname), this has the following advantages:
- It provides a more flexible solution to Scenario 1
- It allows us to handle Scenario 2
An possible addition to this approach would be explicitly declare the dependency between the cost map and the network map in the IRD.
Feedback would be great. The editors believe this would be a strong improvement to the draft.
Thanks,
Rich
<div><div dir="ltr">
<div><div>[ We would like to hear feedback on this. We are planning to revise and submit a new version ASAP, so please voice opinions on this within the next few days, by Monday, June 24th. ]</div></div>
<div>
<br>
</div>
<div>Background:</div>
<div><br></div>Today, the ALTO protocol as a 'version tag' to indicate which version of a network map is used by a particular cost map.<div><br></div>
<div>In a particularly simple case, a single ALTO server is served by a single hostname (or IP address, whatever), and it exposes a single network map and one or more cost maps. There is no ambiguity here - a client automatically knows that any version tag refers to the single network map that is hosted by the server.</div>
<div><br></div>
<div>There are two alternate scenarios where ambiguities arrive:</div>
<div><br></div>
<div>(Scenario 1) An IRD hosted by <a href="http://alto.isp1.example.com">alto.isp1.example.com</a> refers cost maps provided by some third-party, say <a href="http://alto.third-party.example.com">alto.third-party.example.com</a>. In this scenario, do version tags exposed by <a href="http://alto.third-party.example.com">alto.third-party.example.com</a> correspond to the network map provided by <a href="http://alto.isp1.example.com">alto.isp1.example.com</a>?</div>
<div><br></div>
<div>(Scenario 2) A single ALTO server (single hostname) wishes to provide two different network maps (say, different levels of aggregation) and wants to provide cost maps for each of them. Currently, the version tag accompanying a cost map is not sufficient for a client to determine which network map a particular cost map is based on.</div>
<div><br></div>
<div>Proposal:</div>
<div><br></div>
<div>To resolve these problems, we'd like to propose a simple change to the version tag accompanying the cost map - it would now include the URI to the network map in addition to an opaque ID.</div>
<div><br></div>
<div>OLD (what we have now):</div>
<div><br></div>
<div>{
"meta" : {},
"data" : {
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"},
"map-vtag" : "1266506139",
"map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}
}</div>
<div><br></div>
<div>NEW PROPOSAL:</div>
<div><br></div>
<div>
<div>{
"meta" : {},
"data" : {
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"},
"network-map" : { "uri": "<a href="http://alto.example.com/networkmap1">http://alto.example.com/networkmap1</a>"
<span> "vtag":</span><span> "1266506139"</span>
<span> }</span> "map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}
}</div>
<div><br></div>
<div>Compared to the current approach we have in draft -16 (which is for a version tag to be consistent within resources served by the same hostname), this has the following advantages:<br>
- It provides a more flexible solution to Scenario 1</div>
<div>- It allows us to handle Scenario 2</div>
<div><br></div>
<div>An possible addition to this approach would be explicitly declare the dependency between the cost map and the network map in the IRD.</div>
<div><br></div>
<div>Feedback would be great. The editors believe this would be a strong improvement to the draft.</div>
<div><br></div>
<div>Thanks,</div>
<div>Rich</div>
</div>
</div></div>
RSS Feed