Wendy Roome | 17 Apr 19:58 2015

Restrictions on cost-type names?

Does RFC 7285 define any restrictions on cost-type names? Eg, length or character set?

I am referring to the names in the IRD meta for a combination of cost-metric & cost-mode. Eg, "num-routing" in

 "meta" : {
     "cost-types": {
         "num-routing": {
             "cost-mode" : "numerical",
             "cost-metric": "routingcost",
             "description": "My default"
       },

As near as I can tell, while we rigorously defined cost metric names, resource ids, and everything else, we missed cost-type names.

- Wendy Roome

<div>
<div>Does RFC 7285 define any restrictions on cost-type names? Eg, length or character set?</div>
<div><br></div>
<div>I am referring to the names in the IRD meta for a combination of cost-metric &amp; cost-mode. Eg, "num-routing" in</div>
<div><br></div>
<div>
<div>&nbsp;"meta" : {</div>
<div>&nbsp; &nbsp; &nbsp;"cost-types": {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"num-routing": {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"cost-mode" : "numerical",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"cost-metric": "routingcost",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"description": "My default"</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp;},</div>
<div><br></div>
<div>As near as I can tell, while we rigorously defined cost metric names, resource ids, and everything else, we missed cost-type names.</div>
<div><br></div>
<div>
<span class="Apple-tab-span">	</span>- Wendy Roome</div>
<div><br></div>
</div>
</div>
Y. Richard Yang | 9 Apr 20:15 2015
Picon

Re: ALTO extension for representing SDN policies

Dear Huaming, Guohai,

Thanks for sharing the on the ALTO list. 

I infer that the bigger picture you are thinking is to use ALTO maps to convey end-to-end policies such as group based policies (GBP). The idea of an endpoint group (EPG) in GBP is the same as the PID in ALTO. In fact, initially PID was named as EPG.

Regardless of which one of the two approaches mentioned in your email, one gap (of encoding GBP using an ALTO map) I see is that eventually the ALTO WG has decided that there must be a mechanism to map each endpoint into a single PID, and the longest prefix matching mechanism is the chosen mechanism. I assume that you require the same?

Between the two approaches,  the first one maps more naturally into the current ALTO usage model. But my understanding is that you will then have multiple correlated cost maps, and there needs to be an ordering in searching the maps. For example, one map has port=*, while the next has port=80. I assume that you need to define some kind of priority/maximum matching to define precisely the semantics. I do not understand why you need QoS as a multiplex selector. 

Thanks!
Richard

On Thu, Apr 9, 2015 at 10:49 AM, 郭华明 <guohuaming <at> caict.ac> wrote:
Hi Guohai,

I think your example is good, it's my opinion that more meaningful policies are helpful for traffic optimization.

-----原始邮件-----
发件人:ChenGuohai <chenguohai67 <at> outlook.com>
发送时间:2015-04-08 21:18:44 (星期三)
收件人: "郭华明" <guohuaming <at> caict.ac>, "Richard Yang Y." <yry <at> cs.yale.edu>
抄送: "alto <at> ietf.org" <alto <at> ietf.org>
主题: RE: [alto] Alto extension for representing SDN policies


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
Date: Tue, 31 Mar 2015 04:23:49 +0800
From: guohuaming <at> caict.ac
To: yry <at> cs.yale.edu
CC: alto <at> ietf.org
Subject: [alto] Ato extension for representing SDN policies

Hi Richard, All

In SDN, each pair of source and destination network could have multiple policy rules. These rules maybe include source/destination address, protocols, ports, QoS, actions and so on. This information is
also important attributes of the path.     

I am thinking that if some policy information could be provided for applications in Alto, this is also helpful for traffic optimization.

I think there are two methods to do that in Alto.

1, Use a multiple cost types in Cost Maps (similar ideas in  draft-randriamasy-alto-multi-cost-10), add a new Cost Mode: policy, the Cost Metric use multiple fields, like <Protocol, Port, QoS>,  to represent a policy.

2, Add a new map service, like Policy Maps Service. In Policy Maps, applications can get the policy rule information.


Thanks.   

--
----------------
Best!


Huaming Guo

China Academy of Information and Communications Technology (CAICT)

_______________________________________________ alto mailing list alto <at> ietf.org https://www.ietf.org/mailman/listinfo/alto

--
----------------
Best!


Huaming Guo

China Academy of Information and Communications Technology (CAICT)



--
-- 
 =====================================
| Y. Richard Yang <yry <at> cs.yale.edu>   |
| Professor of Computer Science       |
 =====================================
<div><div dir="ltr">Dear Huaming, Guohai,<div><br></div>
<div>Thanks for sharing the on the ALTO list.&nbsp;</div>
<div><br></div>
<div>I infer that the bigger picture you are thinking is to use ALTO maps to convey end-to-end policies such as group based policies (GBP). The idea of an endpoint group (EPG) in GBP is the same as the PID in ALTO. In fact, initially PID was named as EPG.<br><div class="gmail_extra"><br></div>
<div class="gmail_extra">Regardless of which one of the two approaches mentioned in your email, one gap (of encoding GBP using an ALTO map) I see is that eventually the ALTO WG has decided that there must be a mechanism to map each endpoint into a single PID, and the longest prefix matching mechanism is the chosen mechanism. I assume that you require the same?</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">Between the two approaches, &nbsp;the first one maps more naturally into the current ALTO usage model. But my understanding is that you will then have multiple correlated cost maps, and there needs to be an ordering in searching the maps. For example, one map has port=*, while the next has port=80. I assume that you need to define some kind of priority/maximum matching to define precisely the semantics. I do not understand why you need QoS as a multiplex selector.&nbsp;</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">Thanks!</div>
<div class="gmail_extra">Richard</div>
<div class="gmail_extra">
<br><div class="gmail_quote">On Thu, Apr 9, 2015 at 10:49 AM, &#37101;&#21326;&#26126; <span dir="ltr">&lt;<a href="mailto:guohuaming <at> caict.ac" target="_blank">guohuaming <at> caict.ac</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">Hi Guohai,<div><br></div>
<div>I think your example is good, it's my opinion that more meaningful policies are helpful for traffic optimization.<br><br><blockquote name="replyContent">-----&#21407;&#22987;&#37038;&#20214;-----<br>&#21457;&#20214;&#20154;:<span>ChenGuohai &lt;<a href="mailto:chenguohai67 <at> outlook.com" target="_blank">chenguohai67 <at> outlook.com</a>&gt;</span><br>&#21457;&#36865;&#26102;&#38388;:<span>2015-04-08 21:18:44 (&#26143;&#26399;&#19977;)</span><br>&#25910;&#20214;&#20154;: "&#37101;&#21326;&#26126;" &lt;<a href="mailto:guohuaming <at> caict.ac" target="_blank">guohuaming <at> caict.ac</a>&gt;, "Richard Yang Y." &lt;<a href="mailto:yry <at> cs.yale.edu" target="_blank">yry <at> cs.yale.edu</a>&gt;<br>&#25220;&#36865;: "<a href="mailto:alto <at> ietf.org" target="_blank">alto <at> ietf.org</a>" &lt;<a href="mailto:alto <at> ietf.org" target="_blank">alto <at> ietf.org</a>&gt;<br>&#20027;&#39064;: RE: [alto] Alto extension for representing SDN policies<div><div class="h5">
<br><br><div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">Hi Huaming,All<div>
<br><div>Getting policy rules does benefit to traffic optimization. In addition to that it can reduce ALTO request and response.&nbsp;</div>
<div><br></div>
<div>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.&nbsp;<span>The ALTO client can use this policy in selecting more optimal peers without sending ATLO cost map request to ALTO server now and then.&nbsp;</span>
</div>
<div><span><br></span></div>
<div>ALTO client select src(A) as the peer between 11:00 to 14:00 and one of src(B,C,D....) at other time.</div>
<div><br></div>
<div>Make sense?</div>
<div><br></div>
<div><br></div>
<div>BR<br>Guohai<br><div>Date: Tue, 31 Mar 2015 04:23:49 +0800<br>From: <a href="mailto:guohuaming <at> caict.ac" target="_blank">guohuaming <at> caict.ac</a><br>To: <a href="mailto:yry <at> cs.yale.edu" target="_blank">yry <at> cs.yale.edu</a><br>CC: <a href="mailto:alto <at> ietf.org" target="_blank">alto <at> ietf.org</a><br>Subject: [alto] Ato extension for representing SDN policies<br><br>Hi Richard, All<div><br></div>
<div>In SDN, each pair of source and destination network could have multiple policy rules. These rules maybe include source/destination address, protocols, ports, QoS, actions and so on. This information is</div>
<div>
<span>also&nbsp;</span>important attributes of the path.&nbsp;<span>&nbsp; &nbsp;&nbsp;</span>
</div>
<div>
<br>I am thinking that if some policy information could be provided for applications in Alto, this is also helpful for traffic optimization.</div>
<div><br></div>
<div>I think there are two methods to do that in Alto.</div>
<div><br></div>
<div>1, Use a m<span>ultiple</span><span>&nbsp;cost types in Cost Maps (similar ideas in&nbsp; draft-randriamasy-alto-multi-cost-10), add a new Cost Mode: policy, the Cost Metric use multiple fields, like &lt;</span><span>Protocol</span><span>, Port, QoS&gt;, &nbsp;to&nbsp;</span><span>represent</span><span>&nbsp;a policy.</span>
</div>
<div><br></div>
<div><span>2, Add a new map service, like Policy Maps Service. In Policy Maps, applications can get the policy rule information.</span></div>
<div><span><br></span></div>
<div><span><br></span></div>
<div>
<span>Thanks.&nbsp;</span><span>&nbsp;</span><span>&nbsp;</span>
</div>
<div>
<br><span>--<br><div>----------------</div>
<div>Best!</div>
<div><br></div>
<div><br></div>Huaming Guo<div><br></div>
<div>China Academy of Information and Communications Technology (CAICT)</div></span>
</div>
<br>_______________________________________________
alto mailing list
<a href="mailto:alto <at> ietf.org" target="_blank">alto <at> ietf.org</a>
<a href="https://www.ietf.org/mailman/listinfo/alto" target="_blank">https://www.ietf.org/mailman/listinfo/alto</a>
</div>
</div>
</div>
</div>
</div>
</div>
 		 	   		  </div>
</div></div>
</blockquote>
<div><div class="h5">
<br><span>--<br><div>----------------</div>
<div>Best!</div>
<div><br></div>
<div><br></div>Huaming Guo<div><br></div>
<div>China Academy of Information and Communications Technology (CAICT)</div></span>
</div></div>
</div>
</blockquote>
</div>
<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">
<div>--&nbsp;</div>
<div>&nbsp;=====================================</div>
<div>| Y. Richard Yang &lt;<a href="mailto:yry <at> cs.yale.edu" target="_blank">yry <at> cs.yale.edu</a>&gt; &nbsp; |</div>
<div>| Professor of Computer Science &nbsp; &nbsp; &nbsp; |</div>
<div>| <a href="http://www.cs.yale.edu/~yry/" target="_blank">http://www.cs.yale.edu/~yry/</a> &nbsp; &nbsp; &nbsp; &nbsp;|</div>
<div>&nbsp;=====================================</div>
</div></div>
</div>
</div>
</div></div>
Vijay K. Gurbani | 9 Apr 00:01 2015

Latest ALTO papers on SDNs

1) Application-layer traffic optimization in software-defined mobile
  networks: A proof-of-concept implementation by Z. Faigl, Z. Szabo
  and R. Schulcz, IEEE 16th International Telecommunications Network
  Strategy and Planning Symposium, Sept. 2014.
  DOI: 10.1109/NETWKS.2014.6959200

2) New Technique to Improve BitTorrent Performance Based on Application
  Layer Traffic Optimization by Nattee Pinthong1 and Woraphon
  Lilakiatsakun, International Journal of Computing and Network
  Technology Jan, 2015.
  Google for the PDF.

Enjoy.

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

郭华明 | 30 Mar 22:23 2015

Ato extension for representing SDN policies

Hi Richard, All


In SDN, each pair of source and destination network could have multiple policy rules. These rules maybe include source/destination address, protocols, ports, QoS, actions and so on. These information is
also important attributes of the path.     

I am thinking that if some policy information could be provided for applications in Alto, this is also helpful for traffic optimization.

I think there are two methods to do that in Alto.

1, Use a multiple cost types in Cost Maps (similar ideas in  draft-randriamasy-alto-multi-cost-10), add a new Cost Mode: policy, the Cost Metric use multiple fields, like <Protocol, Port, QoS>,  to represent a policy.

2, Add a new map service, like Policy Maps Service. In Policy Maps, applications can get the policy rule information.


Thanks.   

--
----------------
Best!


Huaming Guo

China Academy of Information and Communications Technology (CAICT)
<div>
<p>Hi Richard, All</p>
<div><br></div>
<div>In SDN, each pair of source and destination network could have multiple policy rules. These rules maybe include source/destination address, protocols, ports, QoS, actions and so on. These information is</div>
<div>
<span>also&nbsp;</span>important attributes of the path.&nbsp;<span>&nbsp; &nbsp;&nbsp;</span>
</div>
<div>
<br>I am thinking that if some policy information could be provided for applications in Alto, this is also helpful for traffic optimization.</div>
<div><br></div>
<div>I think there are two methods to do that in Alto.</div>
<div><br></div>
<div>1, Use a m<span>ultiple</span><span>&nbsp;cost types in Cost Maps (similar ideas in&nbsp; draft-randriamasy-alto-multi-cost-10), add a new Cost Mode: policy, the Cost Metric use multiple fields, like &lt;</span><span>Protocol</span><span>, Port, QoS&gt;, &nbsp;to&nbsp;</span><span>represent</span><span>&nbsp;a policy.</span>
</div>
<div><br></div>
<div><span>2, Add a new map service, like Policy Maps Service. In Policy Maps, applications can get the policy rule information.</span></div>
<div><span><br></span></div>
<div><span><br></span></div>
<div>
<span>Thanks.&nbsp;</span><span>&nbsp;</span><span>&nbsp;</span>
</div>
<div>
<br><span>--<br><div>----------------</div>
<div>Best!</div>
<div><br></div>
<div><br></div>Huaming Guo<div><br></div>
<div>China Academy of Information and Communications Technology (CAICT)</div></span>
</div>
</div>
Picon

Re: ALTO implementation interoperability

Hi all,

we at University of Campinas are developing an ALTO server
implementation (for IXP-related use cases) based on Neo4j graph DB and
Open Daylight for a subset of ALTO services and would like to know
about related open source mplementation work, both at the server side
but mostly interested in the client side for interop testing and
further use case developments.

Looking forward to hear more about the Prague IETF opportunities for
ALTO interop (Raphael, please add to your agenda).

Thx,
Christian

From: Jan Seedorf <Jan.Seedorf at neclab.eu>
To: "Y. Richard Yang" <yry at cs.yale.edu>, Hans Seidel <hseidel at benocs.com>
Cc: IETF ALTO <alto at ietf.org>
Date: Fri, 20 Mar 2015 14:41:12 +0000
In-reply-to: <CANUuoLo-uVXoJuoHDpaZjEOEfihxMc0G6oYZOvrpPhCP_8G1mw <at> mail.gmail.com>
References: <5507EDC7.8060607 <at> benocs.com>
<55081EFD.3040004 <at> bell-labs.com>
<CANUuoLrAq2652MywG43iDWtzP4QikrYBw7N_-wg4MXOefd0Upw <at> mail.gmail.com>
<550AA9D6.908 <at> benocs.com>
<CANUuoLo-uVXoJuoHDpaZjEOEfihxMc0G6oYZOvrpPhCP_8G1mw <at> mail.gmail.com>

________________________________

We have also put this topic on the chair slides for the session in
Dallas to get feedback from the room, but please also continue raising
your opinion on this here on the ML.

-          Jan

From: alto [mailto:alto-bounces at ietf.org] On Behalf Of Y. Richard Yang
Sent: Donnerstag, 19. März 2015 22:26
To: Hans Seidel
Cc: IETF ALTO
Subject: Re: [alto] ALTO implementation interoperability

Hi Hans,

On Thu, Mar 19, 2015 at 6:49 AM, Hans Seidel <hseidel at benocs.com> wrote:

It will be cool to have an interop for the summer IETF. For those who
are interested, some of us are working on having an open-source ALTO
server running in ODL. We are slightly behind schedule, but should be
able to catch up in Apr., after IETF. If there is anyone who is
interested in collaboration, you are more than welcome.

I also like the idea of an interop for the summer IETF in Prague.
Since I am rather new to the IETF community, I am not very familiar
with the procedures but if I can be of any help, let me know.

Wonderful! Some of us here will want to engage in the development of
an interop in Prague as well. It will be nice to coordinate and get
started soon, say after this IETF.

Thanks!

Richard

Hans

Richard

Cheers,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani at alcatel-lucent.com
Web: https://urldefense.proofpoint.com/v2/url?u=http-3A__ect.bell-2Dlabs.com_who_vkg_&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IFXVSS1Ngo0C7z51Gunp5gTAVG7hdQAOfiXLLRkPLi4&s=RUjSP5rpFsp8V2Y0xuG9_3pFcAAsDEjzi2YQNNaMKfY&e=
  | Calendar:https://urldefense.proofpoint.com/v2/url?u=http-3A__goo.gl_x3Ogq&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IFXVSS1Ngo0C7z51Gunp5gTAVG7hdQAOfiXLLRkPLi4&s=wY56fXByx0Kd3boQqPHpBjX7uzem5fDJHZAW1FIv_Mc&e=
_______________________________________________
alto mailing list
alto at ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=IFXVSS1Ngo0C7z51Gunp5gTAVG7hdQAOfiXLLRkPLi4&s=JAiHH7palOiAkB3m6zdiENhShLMINWuIhPrijAeT0iQ&e=

-- 

BENOCS GmbH

Dipl.-Ing. Hans Seidel

Winterfeldtstr. 21

10781 Berlin

Germany

Phone: +49 - 30 / 577 0004-0

Email: hans.seidel at benocs.com

www.benocs.com

Board of Management:

  Michael Wolz, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese

Commercial Register: Amtsgericht Bonn HRB 19378

_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto
ChenGuohai | 31 Mar 09:16 2015

another use case should be considered in designing inter-ALTO communication.

 Piotr, Sebastian, Wendy, Richard and all
 
Piotr mentioned the topic of inter-ALTO communication on 22 Mar.
I think that is a practical problem should be resolved in ALTO deployment and am writing to offer another usecase that should be considered in designing inter-ALTO communication.
For scalability there should be multiple ALTO servers in one carrier domain and an ALTO server is responsible for a part of network. For a long route calculation such as from one PID in San Diego to other PIDs in Atlanta, an ALTO client has to get all the topology information from all ALTO servers and Traverse the huge topology information. The procedure is a big burden for ALTO client because that the information is huge and  transporting and processing of this information is time-consuming.
So I think there should be multi-level ALTO servers, which are child ALTO servers and parent ALTO servers. Child ALTO servers are responsible for the request that source PID and destination PID are local. Parent ALTO servers are responsible for request that source PID is in one child and the destination PID is in a different child. This is some similar to hierarchical PCE (https://tools.ietf.org/html/draft-lopez-pce-hpce-ted-02
---------------------------
                                                                                                           Parent ALTO server
                                                                                                                          |
                                                                                                                          |
                                                             -------------------------------------------------------------------
                                                             |                                                                                                          |       
                                                             |                                                                                                          |       
                                              Child ALTO server   A                                                                          Child ALTO server B
                                                (PIDA1 ,….PIDAm)                                                                       (PIDB1,……..PIDBn)
 -------------------------------
If the source PID is PIDAi and destination PID is PIDBj then this request should be processed by parent ALTO server. And there should be some communication between child ALTO server and parent ALTO server.
BR
Guohai
<div><div dir="ltr">&nbsp;Piotr, Sebastian, Wendy, Richard and all<br>&nbsp;<br>Piotr mentioned the topic of inter-ALTO communication on 22 Mar. <br>I think that is a practical problem should be resolved in ALTO deployment and am writing to offer another usecase that should be considered in designing inter-ALTO communication.<br>For scalability there should be multiple ALTO servers in one carrier domain and an ALTO server is responsible for a part of network. For a long route calculation such as from one PID in San Diego to other PIDs in Atlanta, an ALTO client has to get all the topology information from all ALTO servers and Traverse the huge topology information. The procedure is a big burden for ALTO client because that the information is huge and&nbsp; transporting and processing of this information is time-consuming.<br>So I think there should be multi-level ALTO servers, which are child ALTO servers and parent ALTO servers. Child ALTO servers are responsible for the request that source PID and destination PID are local. Parent ALTO servers are responsible for request that source PID is in one child and the destination PID is in a different child. This is some similar to hierarchical PCE &#65288;<a href="https://tools.ietf.org/html/draft-lopez-pce-hpce-ted-02">https://tools.ietf.org/html/draft-lopez-pce-hpce-ted-02</a>&#65289;<br>---------------------------<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Parent ALTO server<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -------------------------------------------------------------------<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Child ALTO server&nbsp;&nbsp; A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Child ALTO server B<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#65288;PIDA1 &#65292;&hellip;.PIDAm&#65289;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#65288;PIDB1,&hellip;&hellip;..PIDBn&#65289;<br>&nbsp;-------------------------------<br>If the source PID is PIDAi and destination PID is PIDBj then this request should be processed by parent ALTO server. And there should be some communication between child ALTO server and parent ALTO server.<br>BR<br>Guohai<br>
</div></div>
郭华明 | 31 Mar 00:00 2015

Ato extension for representing SDN policies

Hi All

In SDN, each pair of source and destination network could have multiple policy rules. These rules maybe include source/destination address, protocols, ports, QoS, actions and so on. These information is
also important attributes of the path.     

I am thinking that if some policy information could be provided for applications in Alto, this is also helpful for traffic optimization.

I think there are two methods to do that in Alto.

1, Use a multiple cost types in Cost Maps (similar ideas in  draft-randriamasy-alto-multi-cost-10), add a new Cost Mode: policy, the Cost Metric use multiple fields, like <Protocol, Port, QoS>,  to represent a policy.

2, Add a new map service, like Policy Maps Service. In Policy Maps, applications can get the policy rule information.


Thanks.   


--
----------------
Best!


Huaming Guo

China Academy of Information and Communications Technology (CAICT)
<div>
<span>Hi All</span><div><br></div>
<div>In SDN, each pair of source and destination network could have multiple policy rules. These rules maybe include source/destination address, protocols, ports, QoS, actions and so on. These information is</div>
<div>
<span>also&nbsp;</span>important attributes of the path.&nbsp;<span>&nbsp; &nbsp;&nbsp;</span>
</div>
<div>
<br>I am thinking that if some policy information could be provided for applications in Alto, this is also helpful for traffic optimization.</div>
<div><br></div>
<div>I think there are two methods to do that in Alto.</div>
<div><br></div>
<div>1, Use a m<span>ultiple</span><span>&nbsp;cost types in Cost Maps (similar ideas in&nbsp; draft-randriamasy-alto-multi-cost-10), add a new Cost Mode: policy, the Cost Metric use multiple fields, like &lt;</span><span>Protocol</span><span>, Port, QoS&gt;, &nbsp;to&nbsp;</span><span>represent</span><span>&nbsp;a policy.</span>
</div>
<div><br></div>
<div><span>2, Add a new map service, like Policy Maps Service. In Policy Maps, applications can get the policy rule information.</span></div>
<div><span><br></span></div>
<div><span><br></span></div>
<div>
<span>Thanks.&nbsp;</span><span>&nbsp;</span><span>&nbsp;</span>
</div>
<br><br><span>--<br><div>----------------</div>
<div>Best!</div>
<div><br></div>
<div><br></div>Huaming Guo<div><br></div>
<div>China Academy of Information and Communications Technology (CAICT)</div></span>
</div>
Scharf, Michael (Michael | 27 Mar 00:50 2015

Background on IANA registry for ALTO Endpoint Property Type?

Hi,

Does somebody with a memory better than mine recall why RFC 7285 mandates that endpoint properties are
assigned by IETF review (other than "priv:")? This results in a rather high bar and possibly in a large
number of RFCs as new use cases of ALTO emerge.

Why does RFC 7285 not use some simpler registration procedure, such as expert review?

At first sight, we could perhaps have avoided some of today's discussion if ALTO would not need IETF review
for each endpoint type that could possibly be useful in some ALTO deployments.

Thanks

Michael

Vijay K. Gurbani | 26 Mar 16:40 2015

Slide update and missing slides

Folks: We have updated the slides that were sent to us in the
last couple of days.

We still need slides for a couple of items.  Please get these to
us as soon as you can, preferably before noon.

Also, please take a look at the meeting material to make sure
your slide is the latest version that you sent us.

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

Piotr Wydrych | 23 Mar 04:02 2015
Picon

Inter-ALTO

Hi All,

As some of you may remember, few years ago, long time before the 
protocol has been standardized, an idea of inter-ALTO communication has 
been proposed. As the protocol is now ready and extensions are beeing 
developed, I'd like to raise your attention to this communication scheme 
again :-)

Since it's not possible to discuss the proposal within 5', I'll raise 
some issues on the list.

1. The rationale
Some (maybe out-of-date) rationale can be found in 
draft-dulinski-alto-inter-problem-statement-01 from July 2011. For me, 
the two most important use-cases in which operators significantly may 
benefit from map exchange are (a) route assymmetry and (b) remote isp's 
preference.
Regarding (a), the core ALTO protocol focuses on comparing traffic 
destination endpoints (thanks to, e.g., data from BGP tables). If an 
ALTO server is aware of routes towards the AS it belongs to, it may 
compare traffic sources between each other. In (b), I assume that 
information form remote ASes may make endpoints from the same AS (e.g., 
assigned to the same PID due the same AS-PATH) distinguishable.

Since YMMV, I'd be glad to hear your voice to come out with a set of 
really important issues to be solved by inter-ALTO. I don't want to 
start an academic discussion and think of a lot of generic and specific 
use-cases.

2. General requirements
Base on the use-cases, a question may be raised: is there any set of 
information that has to be provided every time an ALTO server says it 
implements inter-ALTO? Some other requirements that have to be 
investigated include authentication, information confidentiality, 
incremental updatest etc.

3. Does any IETF RFC/draft address all the reqs?
I do not know of any.

4. Extension spec
E.g., should it be contained within one draft or split into problem 
statment / reqs / definition?

Best regards,
Piotr
--

-- 
Piotr 'GhosT' Wydrych .. xmpp:wydrych//agh.edu.pl .. http://wydrych.net/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Huseyin ABACI | 22 Mar 11:31 2015
Picon

Final Extension - Call for Chapters: "Sustainable Computing"


FINAL EXTENSION - CALL FOR EBOOK CHAPTERS: "SUSTAINABLE COMPUTING"

-----------------------------------------------------------------
DEADLINES
Proposal Submission Deadline: 20 April 2015 (Extended)
Notification of Acceptance: 27 April 2015
Full Chapter Submission: 1 July 2015
Review Results Returned: 1 October 2015
Final Chapter Submission: 9 November 2015
-----------------------------------------------------------------

We apologise if you get multiple copies of this message. 

Please forward this message to anyone who might be interested in our call.
-----------------------------------------------------------------

EBOOK CHAPTERS FOR 
Sustainable Computing

PROPOSAL SUBMISSION 
1-2 pages including abstract, chapter objectives, chapter outlines and institutional affiliation with
Microsoft Word format. Submit to huseyin.abaci <at> adu.edu.tr or c.peoples <at> ulster.ac.uk with the
subject title "Sustainable Computing - Chapter Proposal" until 20 April 2015.

EDITORS
Editor-in-Chief 
Huseyin Abaci Ph.D., Assistant Professor in Department of Computer Engineering at Adnan Menderes
University, Aydin, Turkey
Email: huseyin.abaci <at> adu.edu.tr 

Co-Editor
Cathryn Peoples Ph.D., Teaching Fellow in Faculty of Computing and Engineering at University of Ulster,
Coleraine, Northern Ireland, United Kingdom.  
Email: c.peoples <at> ulster.ac.uk

DESCRIPTION
The associated improvement of Information and Communication Technology (ICT) allows and encourages the
developers deploying the ICT services to offer better facilities and services.  Examples of the types of
services provided include bandwidth intensive Video-on-Demand (VoD), Voice over Internet Protocol
(VoIP), cloud computing, online multi-player gaming and file sharing. This comes at the cost of higher
energy consumption. However, global warming and energy dependence are major concerns not just for
government agencies but also utilities that provide critical infrastructure for our digital economy.
This eBook will concentrate on establishing energy efficient computing and investigate possible energy
efficient technologies/technics at datacentre, cloud, wired/wireless networks alongside with the
data collection methods, test bed setup, algorithm and optimisation techniques which are provide
energy reduction.  

  
TOPICS
Suggested topics of interests include but are not limited to the following:

•	Energy-efficiency methods on sustainable ICT
•	Energy-efficiency in datacentre
•	Energy efficiency in cloud computing
•	Energy-efficiency in wired metro-core networks
•	Energy-efficiency in wireless
•	Energy-efficiency in customer premises equipment 
•	Energy-efficiency in network devices
•	Energy-efficiency in optical networks 
•	Energy-efficient topology / protocols / applications
•	Energy-efficiency in integrated circuits and other computer components.

CHAPTER SUBMISSION PROCEDURE
Researchers are invited to submit a 1-2 page chapter proposal until 20 April 2015. Authors of accepted
proposals will be notified 27 April 2015 about the status of their proposals. Authors of accepted
proposals will be sent guidelines to prepare the full chapter with 8,000 – 12,000 words length. Full
chapters are expected to be submitted by 1 July 2015 and submitted chapters will be reviewed on a
double-blind review basis. Contributors may also be requested to serve as a reviewer for this eBook.

PUBLISHER
This book is scheduled to be published by Bentham Science Publisher and it is expected to be released in the
first quarter of 2016.

INQUIRIES
If you have any inquiries about this call, please contact us at huseyin.abaci <at> adu.edu.tr or c.peoples <at> ulster.ac.uk.

_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto

Gmane