Hi Huaming and Guohai,
Thanks for bringing this case. I've been looking at a way to support your
example policy settings with ALTO. Indeed, ALTO is also meant to convey
provider policy and preferences terms of values assigned to metrics and
properties on end to end paths. In your example "policy" is expressed in terms
of a triplet conveying (protocol, port, QoS).
One issue: QoS and policy as you mention ("These rules maybe include
source/destination address, protocols, ports, QoS, actions and so on") can be
specified with multiple metrics and properties. So defining it as a specific
set of metric is tricky as the set may vary among providers.
Instead, the ALTO protocol and its multi-cost extension allows you specifying
your policy in the way proposed below:
- The client requests and gets every metric of the set that "composes" this
policy. All the available metrics of the provider ALTO server are specified in
the IRD.
- If the composition of this set needs to be specified, the IRD may be used in
a way to be discussed among the WG.
If as Guohai suggests, one of the metrics is time sensitive, the ALTO Client
can get the corresponding calendar, specified in
https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/ as Wendy
proposes.
I'll get back on policy-based EPG overlapping several PIDs is a next mail.
Any thoughts on the proposal below?
Thanks,
Sabine
-------------------------------------------------------------
GUOHAI proposal
"multi-cost-types" : [
{"cost-mode": "policy", "cost-metric": "policy"},
{"cost-mode": "policy", "cost-metric": "policy"}
]
}
"cost-map" : {
"PID1": { "PID1":[null,null], "PID2":[<TCP,80,10M>,<UDP,120,20M>]},
"PID2": { "PID1":[<TCP,80,10M>,<UDP,120,20M>], "PID2":[null,null]}
}
New proposal
"multi-cost-types" : [
{"cost-mode": "string", "cost-metric": "transport-protocol-id"},
{"cost-mode": "string", "cost-metric": "port-number"}
{"cost-mode": "numerical", "cost-metric": "bandwidth"}
]
}
"cost-map" : {
"PID1": { "PID1":[null,null], "PID2":[<TCP,80,10M>,<UDP,120,20M>]},
"PID2": { "PID1":[<TCP,80,10M>,<UDP,120,20M>], "PID2":[null,null]}
}
This proposal puts the Port Nb in "string" mode as this is handled as an ID
rather than a quantity.
-------------------------------------------------------------
>>-----Message d'origine-----
>>De : alto [mailto:[email protected]] De la part de Wendy Roome
>>Envoyé : mardi 14 avril 2015 22:35
>>À : [email protected]
>>Objet : Re: [alto] Ato extension for representing SDN policies
>>
>>Guohai,
>>
>>https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/
>>presents an extension to add time-dependency to cost maps. Eg, the
>>extended cost map could say the cost from A->B is 20 from 9:00 to
>>12:00, and 10 from 12:00 to 17:00, etc.
>>
>>Would that solve your problem?
>>
>> - Wendy Roome
>>
>>On 04/08/2015, 15:00, "[email protected]" <[email protected]>
>>wrote:
>>
>>>Message: 1
>>>Date: Wed, 8 Apr 2015 13:18:44 +0000
>>>From: ChenGuohai <[email protected]>
>>>To: ??? <[email protected]>, Richard Yang Y. <[email protected]>
>>>Cc: "[email protected]" <[email protected]>
>>>Subject: Re: [alto] Ato extension for representing SDN policies
>>>Message-ID: <[email protected]>
>>>Content-Type: text/plain; charset="gb2312"
>>>
>>>Hi Huaming,All
>>>Getting policy rules does benefit to traffic optimization. In addition
>>>to that it can reduce ALTO request and response.
>>>For example, a policy is that band between a pair of src(A)and dst is
>>>20M between 11:00 to 14:00 and is 10M for other time. And band between
>>>other src(B,C,D ....) and this dst is 15M. The ALTO client can use
>>this
>>>policy in selecting more optimal peers without sending ATLO cost map
>>>request to ALTO server now and then.
>>>ALTO client select src(A) as the peer between 11:00 to 14:00 and one
>>of
>>>src(B,C,D....) at other time.
>>>Make sense?
>>>
>>>BR
>>>Guohai
>>>
>>
>>
>>_______________________________________________
>>alto mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
