Hi Sabine,Many thanks for your effort.I must say that draft @ https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/ can solve the example problem. If the policy is time-varying ,there are may be some composite cost-type. Policy may be expressed in (time period, protocol,port, QOS).
BR,Guohai > From: [email protected] > To: [email protected]; [email protected] > Date: Thu, 23 Apr 2015 08:25:55 +0000 > Subject: Re: [alto] Ato extension for representing SDN policies > > 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
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
