Xiao SHI | 23 Oct 11:34 2014
Picon

Incremental Update/SSE Key Design Issue 1: Event subscription name in SSE

Hi all,

Wendy, Richard, and I are considering the incremental updates subscription model for ALTO using Server-Sent Event (SSE) streams. In this model, the client subscribes to an event stream, and the server push updates as events via the stream.

We use an "event" field to encode the unique identifier of the resource that the event should update, which should be a subset of {resource-id, resource-parameters, input-parameters}. (The client also has the IRD in its possession so that it can do certain look-ups).

We would like a __minimal__ unique identifier of each resource and each resource object. One resource could have multiple objects, e.g. when the "accepts" field is non-empty (i.e. they have input params), or they could have filters etc. Below are the proposal solutions:

For full network/cost map objects, resource-id is sufficient.
object {
  ResourceID resource-id;
} NetworkMapEventName;

object {
  ResourceID resource-id;
} CostMapEventName;

For resource objects that have non-empty "accepts" field or filters (i.e. input params) in the IRD, there are multiple solutions:

Solution 1. put the the input params in the events field
For  filtered network map objects, resource-id coupled with the pids for the filter:
object {
  ResourceID resource-id;
  PIDName pids<0..*>;
  [AddressType address-types<0..*>;]
} FilteredNetworkMapEventName;

For filtered cost map objects, we need to identify the costmap objects and the filter:
object {
  ResourceID resource-id;
  CostType cost-type;
  [JSONString constraints<0..*>;]
  [PIDFilter  pids;]
} CostMapEventName;

e.g. the event for a filtered network map would start with:
event: {"resource-id":"my-default-network-map", "pids":["PID2", "PID4"]}\n

Solution 2. add the input params information as meta information for an update.
We put the merge-patch object with the meta information together to form the update object:
object {
  ResponseMeta update-meta;
  JSONObject merge-patch;
} ALTOUpdate;

What do people think?

Best,
Xiao
<div><div dir="ltr">Hi all,<div><br></div>
<div>Wendy, Richard, and I are considering the incremental updates subscription model for ALTO using Server-Sent Event (SSE) streams. In this model, the client subscribes to an event stream, and the server push updates as events via the stream.</div>
<div><br></div>
<div>We use an "event" field to encode the unique identifier of the resource that the event should update, which should be a subset of {resource-id, resource-parameters, input-parameters}. (The client also has the IRD in its possession so that it can do certain look-ups).</div>
<div><br></div>
<div>We would like a __minimal__ unique identifier of each resource and each resource object. One resource could have multiple objects, e.g. when the "accepts" field is non-empty (i.e. they have input params), or they could have filters etc. Below are the proposal solutions:</div>
<div><br></div>
<div>For full network/cost map objects, resource-id is sufficient.<br>
</div>
<div>object {</div>
<div>&nbsp; ResourceID resource-id;</div>
<div>} NetworkMapEventName;</div>
<div><br></div>
<div>object {</div>
<div>&nbsp; ResourceID resource-id;</div>
<div>} CostMapEventName;</div>
<div><br></div>
<div>For resource objects that have non-empty "accepts" field or filters (i.e. input params) in the IRD, there are multiple solutions:</div>
<div><br></div>
<div>Solution 1. put the the input params in the events field</div>
<div>For &nbsp;filtered network map objects, resource-id coupled with the pids for the filter:</div>
<div>
<div>object {</div>
<div>&nbsp; ResourceID resource-id;</div>
<div>
<div>&nbsp; PIDName pids&lt;0..*&gt;;</div>
<div>&nbsp; [AddressType address-types&lt;0..*&gt;;]</div>
</div>
<div>} FilteredNetworkMapEventName;</div>
</div>
<div><br></div>
<div>For filtered cost map objects, we need to identify the costmap objects and the filter:</div>
<div>
<div>object {</div>
<div>&nbsp; ResourceID resource-id;</div>
<div>&nbsp; CostType cost-type;</div>
<div>
<div>&nbsp; [JSONString constraints&lt;0..*&gt;;]</div>
<div>&nbsp; [PIDFilter &nbsp;pids;]</div>
</div>
<div>} CostMapEventName;</div>
</div>
<div><br></div>
<div>e.g. the event for a filtered network map would start with:</div>
<div>event: {"resource-id":"my-default-network-map", "pids":["PID2", "PID4"]}\n</div>
<div><br></div>
<div>Solution 2. add the input params information as meta information for an update.</div>
<div>We put the merge-patch object with the meta information together to form the update object:</div>
<div>object {</div>
<div>&nbsp; ResponseMeta update-meta;</div>
<div>&nbsp; JSONObject merge-patch;</div>
<div>} ALTOUpdate;</div>
<div><br></div>
<div>What do people think?</div>
<div><br></div>
<div>Best,</div>
<div>Xiao</div>
</div></div>
Vijay K. Gurbani | 20 Oct 15:10 2014

Agenda requests for IETF 91

Folks: Please send me, Enrico and Jan the agenda requests for the
upcoming meeting in HI.

We have a 2.5 hour session on Thu, Nov 13 2014 1640-1910 local time.

As usual, agenda time will be prioritized according to item discussion
on the mailing list.

When sending a request, please indicate title, relevant drafts,
presenter, and time requested.

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

Xiao SHI | 20 Oct 08:05 2014
Picon

Modeling JSON based protocols using YANG

Hi folks,


As a few of us were working on modeling the ALTO protocol using YANG, we were pondering on a more general question: can YANG model all JSON based protocols? What is the condition for a JSON based protocol (at least the message format) to have an syntactically equivalent, hence interoperable, YANG model with JSON encoding? Alternatively, in order to interoperate, semantic equivalence might be sufficient, is there any condition for semantic equivalence?


tl;dr: A JSON based protocol carried by HTTP can have syntactically equivalent YANG model, if and only if all the keys in the key-value pairs in the JSON message are pre-defined keywords in the protocol.


We've come up with a few ideas, and a few things below are work in progress, but we would love your feedback!


Thank you!

Xiao


======================

1. Introduction.

JavaScript Object Notation (JSON) has been a popular choice as the message encoding for many network protocols such as the Application Layer Traffic Optimization (ALTO) protocol, the Content Delivery Networks Interconnection (CDNi) protocol, etc.


Meanwhile, there are broad interests in the networking community to use YANG to define data model so that one can use YANG related tools such as OpenDayLight controller. Although YANG itself is XML based, there have been efforts to model JSON content using YANG [draft-ietf-netmod-yang-json-01].


A natural question rises: can YANG model all JSON based protocols? What is the condition for a JSON based protocol (at least the message format) to have an syntactically equivalent, hence interoperable, YANG model with JSON encoding? Alternatively, in order to interoperate, semantic equivalence might be sufficient, is there any condition for semantic equivalence?


2. Claim

A JSON based protocol carried by HTTP can have syntactically equivalent YANG model, if and only if:

(1) the message encoding condition is met;

(2) the uri condition is met.


2.1. The message encoding condition

The JSON message encoding MUST not contain a variable as a key in a JSON object key-value pair. In other words, the keys in the JSON message must be an already defined constant (or keyword) in the message format of the protocol.


For example, if I have a protocol where “network-map”, “src”, and “dsts” are defined keywords, JSON text A meets the condition whereas B does not because “PID1” and “PID2” are not protocol keywords (they are resource IDs).

A:

{

 “network-map”: [

   {

     “src”: “PID1”,

     “dsts”: [“PID2”, “PID3”]

   },

   {

     “src”: “PID2”,

     “dsts”: [“PID3”, “PID4”]

   }

 ]

}

B:



{

 “network-map”: [

   “PID1: [“PID2”, “PID3”],

   “PID2”: [“PID3”, “PID4”]

 ]

}


From this we know that since ALTO protocol uses encoding B, there cannot be a syntactically equivalent YANG model.


2.2 The URI condition

Some of the YANG-related protocols might have URI constraints, e.g. RESTCONF. For now, we assume either that the JSON-based protocol URI could be conformed to RESTCONF compliant uri, or that the server could have a routing mapping between the protocol compliant uri and the RESTCONF compliant uri, hence this condition would not be an issue, which allows us to focus on the message encoding condition.


3. Proof

3.1. The message encoding condition is necessary.

We first note that this condition is a necessary condition for a JSON based protocol to have a syntactically equivalent YANG model by proving its contrapositive.


If one of the keys in the key-value pair in the JSON document is not pre-defined, the corresponding XML tags will not be pre-defined keywords. Therefore, it would not possible to model it in YANG without using YANG’s anyxml statement (which allows arbitrary XML content).


However, using the anyxml statement would defeat our purpose of modeling the data as it allows arbitrary XML content, and will not be helpful in the subsequent parsing process.


3.2. The message encoding condition is sufficient.

We prove this by providing a translation procedure from a JSON message that is compliant with the protocol we are trying to model, to a custom java class that can be used for Jackson data binding, then to a YANG model.


We note that the middle step of translating to and from the custom parser class is not necessary, but it will be useful.


3.2.1. motivation

JSON data binding is the process of binding data structures (objects, arrays, etc.) in JSON to the appropriate data structures in the server (e.g. java classes, database tables, etc.) in parsing the JSON text. In order to process JSON messages in a meaningful manner, data binding is necessary. Even if the binding is not explicit, the server would need to do it eventually. For example, one can read JSON content in a stream without binding it to the java classes, but eventually in order to make sense of the data, the server would eventually have to organize it, which is roughly analogous to data binding upfront. Popular choices for JSON parsing and data binding include jackson and gson.


We use Jackson full data binding as our approach. Full data binding binds JSON content into plain old java objects (POJOs), i.e. this custom parser class can neither extend nor implement any other class. Jackson uses ObjectMapper with the custom parser class to parse JSON content into this class.


3.2.2. The message encoding condition

The message encoding condition is that all keys in each key-value pair in the JSON text must be pre-defined keywords. As the keys will become either class names and instance variable names, or be keys in the java maps, it is easy to see that the condition is equivalent to “there exists a full data binding in Jackson custom parser class without using any map structures (Map<String, ?>).”


3.2.3. Proof

We provide a recursive binding process from a JSON object to the Jackson custom parser class to be used by Jackson ObjectMapper.


Type determine_type(value) {

 if (value is of a primitive type, i.e. string, number, boolean, null) {

   return the corresponding java primitive type;

 }

 if (value is a JSON object) {

   return build_parser_class(value).class;

 }

 if (value is an array) {

   return ArrayList<T> where T=determine_type(value[0]);

 }

 // should not reach here.

}


Class build_parser_class(JSONObject obj) {

 create custom class C;

 for each key/value pair in the obj {

   add instance variable v in C;

   the name of variable v <- key; // (__known__ a/c to our assumption)

   the type of variable v <- determine_type(value);

 }

 return C.class;

}


Naming:

--change everything into CamelCase (i.e. remove dashes, etc.)

--for instance variables, use “my” prefix, (e.g. myVariable, myNetworkMap, etc.)

--for the custom class name, if the object is an element of the array, use “Element” suffix.


This is just one convention so that the next step proceeds smoothly. As long as this naming translation is consistent with the naming stage in the next step, it will work just fine.


Example (a modified ALTO protocol network map example):

JSON object:

{

 “meta”: {

   “resource-id”: “my-default-map”,

   “tag”: “aab875ef69c87d012”

 },

 “network-map”: [

   {

     “src”: “PID1”,

     “dsts”: [“PID1”, “PID2”, “PID3”]

   },

   {

     “src”: “PID2”,

     “dsts”: [“PID1”, “PID3”]

   },

   {

     “src”: “PID3”,

     “dsts”: [“PID2”, “PID3”]

   }

 ]

}


Result of build_parser_class(obj):

Class JSONObject {

 Meta myMeta;

 ArrayList<NetworkMapElement> myNetworkMap;

}

Class Meta {

 String myResourceId;

 String myTag;

}

Class NetworkMapElement {

 String mySrc;

 ArrayList<String> myDsts;

}


Now given the Jackson Parser Java Class, to get a syntactically equivalent YANG model:

YANGModel build_yang_model(Class C) {

 for each instance variable (Type, Name) {

   if (Type is primitive type: string, number, boolean, null) {

     add the following to the YANG module:

     “leaf Name { type <YANG equivalent of Type>; }”

   }

   if (Type is an ArrayList<TypeElement>) {

     if (TypeElement is primitive type) {

       add the following to the YANG module:

       “leaf-list Name { type <YANG equivalent of TypeElement>; }”

     } else {

       // TypeElement is a custom parser class

       add the following to the YANG module:

       “list Name { <result from build_yang_model<TypeElement.class>> }”

     }

   }

   if (Type is a custom parser class) {

     add the following to the YANG module:

     “container Name { <result from build_yang_model<Type.class>> }”        

   }

 }

}


Result from the previous example:

container meta {

 leaf resource-id {

   type string;

 }

 leaf tag {

   type string;

 }

}

list network-map {

 leaf src {

   type string;

 }

 leaf-list dsts {

   type string;

 }

}


This does validate the JSON document with XML-JSON encoding. For your reference, this is the XML document which validates:

<?xml version="1.0" encoding="UTF-8" ?>

<meta>

 <resource-id>my-default-map</resource-id>

 <tag>aab875ef69c87d012</tag>

</meta>

<network-map>

 <src>PID1</src>

 <dsts>PID1</dsts>

 <dsts>PID2</dsts>

 <dsts>PID3</dsts>

</network-map>

<network-map>

 <src>PID2</src>

 <dsts>PID1</dsts>

 <dsts>PID3</dsts>

</network-map>

<network-map>

 <src>PID3</src>

 <dsts>PID2</dsts>

 <dsts>PID3</dsts>

</network-map>


This proves that the message encoding condition is a sufficient condition for the JSON object to have a YANG model.


Note the model generated is very crude and lose almost all constraints and all inheritance features (if any), because it focuses on the syntax and is essentially converted from an JSON object compliant with a protocol instead of from the protocol itself. Hence this result is more useful in determining which JSON based protocols cannot have a syntactically equivalent YANG model, than in generating a good YANG model.


3.3. Conclusion

Our claim holds. A JSON based protocol carried by HTTP can have syntactically equivalent YANG model, if and only if all the keys in the key-value pairs in the JSON message are pre-defined keywords.


4. Semantic equivalence

For JSON based protocols that don’t satisfy the message encoding condition, it is still possible to have a semantically equivalent YANG model. All that is required for the protocol compliant clients and the YANG model compliant server to interoperate is an adapter which does the following:


1) translate FROM YANG server compliant response msg TO alto compliant response msg

2) translate FROM alto compliant request msg TO YANG server compliant request msg


4.1. Claim

This adapter needs to be protocol-aware.


Ideally, given any YANG model, we would like to be able to automatically (or at least mechanically) generate this message adapter, which means not looking at the protocol or its compliant msgs. However, without knowing the specific protocol that we are working with (i.e. human intervention, i.e. looking at the protocol compliant msgs), such an adapter cannot be auto-generated.


4.2. Proof by Indistinguishability

Suppose both the YANG server compliant msg m_y and the actually protocol compliant msg m_p are in JSON (or have been encoded into JSON). Looking at the differences between the two messages, call these differences {d1, d2, ..., dn}. The goal for the auto-generated adapter would be to identify and eliminate these differences. Construct a new JSON msg m' where all but one difference di is the same as m_p and di is the same as the m_y. Without looking at the protocol (or m_p), the auto-generated adapter would not be able to distinguish between m' and m_p in its translation process, which means, it won't be able to tell whether it should change di or not. Hence, such an adapter must be protocol-aware.


A good example is the dependent-vtag in the ALTO protocol:

"dependent-vtag" : [

 {

   "resource-id" : "my-network-map",

   "tag" : "abcd1234"

 }

]


It was specified this way in the alto protocol. However, it could conceivably be the case that it was originally the following map structure, and was converted into the above encoding because of the map->list+key issue. (This case is actually one of the few differences in the m_y and m_p where the adapter does not need to convert it back to a map structure.)

"dependent-vtag" : {

 "my-network-map" : {

   "tag" : "abcd1234"

 }

}


Without knowing the protocol, there is no way to tell.


5. Ramifications

We now understand the basic condition for a JSON based protocol to have a YANG Model. For the protocols that don’t meet this condition, there can be a semantic equivalent YANG model, but there won’t be a generic process of generating the adapter for all such protocols.


<div><div dir="ltr">
<span><p><span>Hi folks,</span></p>
<p dir="ltr"><span><br></span></p>
<p><span>As a few of us were working on modeling the ALTO protocol using YANG, we were pondering on a more general question: can YANG model all JSON based protocols? What is the condition for a JSON based protocol (at least the message format) to have an syntactically equivalent, hence interoperable, YANG model with JSON encoding? Alternatively, in order to interoperate, semantic equivalence might be sufficient, is there any condition for semantic equivalence?</span><br></p>
<p><br></p>
<p><span>tl;dr: </span><span>A JSON based protocol carried by HTTP can have syntactically equivalent YANG model, if and only if all the keys in the key-value pairs in the JSON message are pre-defined keywords in the protocol.</span></p>
<p><br></p>
<p><span>We've come up with a few ideas, and a few things below are work in progress, but we would love your feedback!</span><span><br></span></p>
<p><span><br></span></p>
<p><span>Thank you!</span></p>
<p><span>Xiao</span></p>
<p><span><br></span></p>======================</span><div><span><p dir="ltr"><span>1. Introduction.</span></p>
<p dir="ltr"><span>JavaScript Object Notation (JSON) has been a popular choice as the message encoding for many network protocols such as the Application Layer Traffic Optimization (ALTO) protocol, the Content Delivery Networks Interconnection (CDNi) protocol, etc.</span></p>
<br><p dir="ltr"><span>Meanwhile, there are broad interests in the networking community to use YANG to define data model so that one can use YANG related tools such as OpenDayLight controller. Although YANG itself is XML based, there have been efforts to model JSON content using YANG [draft-ietf-netmod-yang-json-01]. </span></p>
<br><p dir="ltr"><span>A natural question rises: can YANG model all JSON based protocols? What is the condition for a JSON based protocol (at least the message format) to have an syntactically equivalent, hence interoperable, YANG model with JSON encoding? Alternatively, in order to interoperate, semantic equivalence might be sufficient, is there any condition for semantic equivalence?</span></p></span></div>
<div><span><br><p dir="ltr"><span>2. Claim</span></p>
<p dir="ltr"><span>A JSON based protocol carried by HTTP can have syntactically equivalent YANG model, if and only if:</span></p>
<p dir="ltr"><span>(1) the message encoding condition is met;</span></p>
<p dir="ltr"><span>(2) the uri condition is met.</span></p>
<br><p dir="ltr"><span>2.1. The message encoding condition</span></p>
<p dir="ltr"><span>The JSON message encoding MUST not contain a variable as a key in a JSON object key-value pair. In other words, the keys in the JSON message must be an already defined constant (or keyword) in the message format of the protocol.</span></p>
<br><p dir="ltr"><span>For example, if I have a protocol where &ldquo;network-map&rdquo;, &ldquo;src&rdquo;, and &ldquo;dsts&rdquo; are defined keywords, JSON text A meets the condition whereas B does not because &ldquo;PID1&rdquo; and &ldquo;PID2&rdquo; are not protocol keywords (they are resource IDs).</span></p>
<p dir="ltr"><span>A:</span></p>
<p dir="ltr"><span>{</span></p>
<p dir="ltr"><span> &nbsp;&ldquo;network-map&rdquo;: [</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;{</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;src&rdquo;: &ldquo;PID1&rdquo;,</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;dsts&rdquo;: [&ldquo;PID2&rdquo;, &ldquo;PID3&rdquo;]</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;},</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;{</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;src&rdquo;: &ldquo;PID2&rdquo;,</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;dsts&rdquo;: [&ldquo;PID3&rdquo;, &ldquo;PID4&rdquo;]</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;]</span></p>
<p dir="ltr"><span>}</span></p>
<p dir="ltr"><span>B:</span></p>
<br><br><p dir="ltr"><span>{</span></p>
<p dir="ltr"><span> &nbsp;&ldquo;network-map&rdquo;: [</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&ldquo;PID1: [&ldquo;PID2&rdquo;, &ldquo;PID3&rdquo;],</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&ldquo;PID2&rdquo;: [&ldquo;PID3&rdquo;, &ldquo;PID4&rdquo;]</span></p>
<p dir="ltr"><span> &nbsp;]</span></p>
<p dir="ltr"><span>}</span></p>
<br><p dir="ltr"><span>From this we know that since ALTO protocol uses encoding B, there cannot be a syntactically equivalent YANG model.</span></p>
<br><p dir="ltr"><span>2.2 The URI condition</span></p>
<p dir="ltr"><span>Some of the YANG-related protocols might have URI constraints, e.g. RESTCONF. For now, we assume either that the JSON-based protocol URI could be conformed to RESTCONF compliant uri, or that the server could have a routing mapping between the protocol compliant uri and the RESTCONF compliant uri, hence this condition would not be an issue, which allows us to focus on the message encoding condition.</span></p>
<br><p dir="ltr"><span>3. Proof</span></p>
<p dir="ltr"><span>3.1. The message encoding condition is necessary.</span></p>
<p dir="ltr"><span>We first note that this condition is a necessary condition for a JSON based protocol to have a syntactically equivalent YANG model by proving its contrapositive.</span></p>
<br><p dir="ltr"><span>If one of the keys in the key-value pair in the JSON document is not pre-defined, the corresponding XML tags will not be pre-defined keywords. Therefore, it would not possible to model it in YANG without using YANG&rsquo;s </span><span>anyxml </span><span>statement (which allows arbitrary XML content).</span></p>
<br><p dir="ltr"><span>However, using the anyxml statement would defeat our purpose of modeling the data as it allows arbitrary XML content, and will not be helpful in the subsequent parsing process.</span></p>
<br><p dir="ltr"><span>3.2. The message encoding condition is sufficient.</span></p>
<p dir="ltr"><span>We prove this by providing a translation procedure from a JSON message that is compliant with the protocol we are trying to model, to a custom java class that can be used for Jackson data binding, then to a YANG model.</span></p>
<br><p dir="ltr"><span>We note that the middle step of translating to and from the custom parser class is not necessary, but it will be useful.</span></p>
<br><p dir="ltr"><span>3.2.1. motivation</span></p>
<p dir="ltr"><span>JSON data binding is the process of binding data structures (objects, arrays, etc.) in JSON to the appropriate data structures in the server (e.g. java classes, database tables, etc.) in parsing the JSON text. In order to process JSON messages in a meaningful manner, data binding is necessary. Even if the binding is not explicit, the server would need to do it eventually. For example, one can read JSON content in a stream without binding it to the java classes, but eventually in order to make sense of the data, the server would eventually have to organize it, which is roughly analogous to data binding upfront. Popular choices for JSON parsing and data binding include jackson and gson.</span></p>
<br><p dir="ltr"><span>We use Jackson full data binding as our approach. Full data binding binds JSON content into plain old java objects (POJOs), i.e. this custom parser class can neither extend nor implement any other class. Jackson uses ObjectMapper with the custom parser class to parse JSON content into this class.</span></p>
<br><p dir="ltr"><span>3.2.2. The message encoding condition</span></p>
<p dir="ltr"><span>The message encoding condition is that all keys in each key-value pair in the JSON text must be pre-defined keywords. As the keys will become either class names and instance variable names, or be keys in the java maps, it is easy to see that the condition is equivalent to &ldquo;there exists a full data binding in Jackson custom parser class without using any map structures (Map&lt;String, ?&gt;).&rdquo; </span></p>
<br><p dir="ltr"><span>3.2.3. Proof</span></p>
<p dir="ltr"><span>We provide a recursive binding process from a JSON object to the Jackson custom parser class to be used by Jackson ObjectMapper.</span></p>
<br><p dir="ltr"><span>Type determine_type(value) {</span></p>
<p dir="ltr"><span> &nbsp;if (value is of a primitive type, i.e. string, number, boolean, null) {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;return the corresponding java primitive type;</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;if (value is a JSON object) {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;return build_parser_class(value).class;</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;if (value is an array) {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;return ArrayList&lt;T&gt; where T=determine_type(value[0]);</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;// should not reach here.</span></p>
<p dir="ltr"><span>}</span></p>
<br><p dir="ltr"><span>Class build_parser_class(JSONObject obj) {</span></p>
<p dir="ltr"><span> &nbsp;create custom class C;</span></p>
<p dir="ltr"><span> &nbsp;for each key/value pair in the obj {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;add instance variable v in C; </span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;the name of variable v &lt;- key; // (__known__ a/c to our assumption)</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;the type of variable v &lt;- determine_type(value);</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;return C.class;</span></p>
<p dir="ltr"><span>}</span></p>
<br><p dir="ltr"><span>Naming:</span></p>
<p dir="ltr"><span>--change everything into CamelCase (i.e. remove dashes, etc.)</span></p>
<p dir="ltr"><span>--for instance variables, use &ldquo;my&rdquo; prefix, (e.g. myVariable, myNetworkMap, etc.)</span></p>
<p dir="ltr"><span>--for the custom class name, if the object is an element of the array, use &ldquo;Element&rdquo; suffix.</span></p>
<br><p dir="ltr"><span>This is just one convention so that the next step proceeds smoothly. As long as this naming translation is consistent with the naming stage in the next step, it will work just fine.</span></p>
<br><p dir="ltr"><span>Example (a </span><span>modified</span><span> ALTO protocol</span><span> </span><span>network map example):</span></p>
<p dir="ltr"><span>JSON object:</span></p>
<p dir="ltr"><span>{</span></p>
<p dir="ltr"><span> &nbsp;&ldquo;meta&rdquo;: {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&ldquo;resource-id&rdquo;: &ldquo;my-default-map&rdquo;,</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&ldquo;tag&rdquo;: &ldquo;aab875ef69c87d012&rdquo;</span></p>
<p dir="ltr"><span> &nbsp;},</span></p>
<p dir="ltr"><span> &nbsp;&ldquo;network-map&rdquo;: [</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;{</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;src&rdquo;: &ldquo;PID1&rdquo;,</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;dsts&rdquo;: [&ldquo;PID1&rdquo;, &ldquo;PID2&rdquo;, &ldquo;PID3&rdquo;]</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;},</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;{</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;src&rdquo;: &ldquo;PID2&rdquo;,</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;dsts&rdquo;: [&ldquo;PID1&rdquo;, &ldquo;PID3&rdquo;]</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;},</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;{</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;src&rdquo;: &ldquo;PID3&rdquo;,</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;dsts&rdquo;: [&ldquo;PID2&rdquo;, &ldquo;PID3&rdquo;]</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;]</span></p>
<p dir="ltr"><span>}</span></p>
<br><p dir="ltr"><span>Result of build_parser_class(obj):</span></p>
<p dir="ltr"><span>Class JSONObject {</span></p>
<p dir="ltr"><span> &nbsp;Meta myMeta;</span></p>
<p dir="ltr"><span> &nbsp;ArrayList&lt;NetworkMapElement&gt; myNetworkMap;</span></p>
<p dir="ltr"><span>}</span></p>
<p dir="ltr"><span>Class Meta {</span></p>
<p dir="ltr"><span> &nbsp;String myResourceId;</span></p>
<p dir="ltr"><span> &nbsp;String myTag;</span></p>
<p dir="ltr"><span>}</span></p>
<p dir="ltr"><span>Class NetworkMapElement {</span></p>
<p dir="ltr"><span> &nbsp;String mySrc;</span></p>
<p dir="ltr"><span> &nbsp;ArrayList&lt;String&gt; myDsts;</span></p>
<p dir="ltr"><span>}</span></p>
<br><p dir="ltr"><span>Now given the Jackson Parser Java Class, to get a syntactically equivalent YANG model:</span></p>
<p dir="ltr"><span>YANGModel build_yang_model(Class C) {</span></p>
<p dir="ltr"><span> &nbsp;for each instance variable (Type, Name) {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;if (Type is primitive type: string, number, boolean, null) {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;add the following to the YANG module:</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;leaf Name { type &lt;YANG equivalent of Type&gt;; }&rdquo;</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;if (Type is an ArrayList&lt;TypeElement&gt;) {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (TypeElement is primitive type) {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;add the following to the YANG module:</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;leaf-list Name { type &lt;YANG equivalent of TypeElement&gt;; }&rdquo;</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} else {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// TypeElement is a custom parser class</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;add the following to the YANG module:</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;list Name { &lt;result from build_yang_model&lt;TypeElement.class&gt;&gt; }&rdquo;</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;if (Type is a custom parser class) {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;add the following to the YANG module:</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;container Name { &lt;result from build_yang_model&lt;Type.class&gt;&gt; }&rdquo; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span>}</span></p>
<br><p dir="ltr"><span>Result from the previous example:</span></p>
<p dir="ltr"><span>container meta {</span></p>
<p dir="ltr"><span> &nbsp;leaf resource-id {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;type string;</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;leaf tag {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;type string;</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span>}</span></p>
<p dir="ltr"><span>list network-map {</span></p>
<p dir="ltr"><span> &nbsp;leaf src {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;type string;</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span> &nbsp;leaf-list dsts {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;type string;</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span>}</span></p>
<br><p dir="ltr"><span>This does validate the JSON document with XML-JSON encoding. For your reference, this is the XML document which validates:</span></p>
<p dir="ltr"><span>&lt;?xml version="1.0" encoding="UTF-8" ?&gt;</span></p>
<p dir="ltr"><span>&lt;meta&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;resource-id&gt;my-default-map&lt;/resource-id&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;tag&gt;aab875ef69c87d012&lt;/tag&gt;</span></p>
<p dir="ltr"><span>&lt;/meta&gt;</span></p>
<p dir="ltr"><span>&lt;network-map&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;src&gt;PID1&lt;/src&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;dsts&gt;PID1&lt;/dsts&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;dsts&gt;PID2&lt;/dsts&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;dsts&gt;PID3&lt;/dsts&gt;</span></p>
<p dir="ltr"><span>&lt;/network-map&gt;</span></p>
<p dir="ltr"><span>&lt;network-map&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;src&gt;PID2&lt;/src&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;dsts&gt;PID1&lt;/dsts&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;dsts&gt;PID3&lt;/dsts&gt;</span></p>
<p dir="ltr"><span>&lt;/network-map&gt;</span></p>
<p dir="ltr"><span>&lt;network-map&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;src&gt;PID3&lt;/src&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;dsts&gt;PID2&lt;/dsts&gt;</span></p>
<p dir="ltr"><span> &nbsp;&lt;dsts&gt;PID3&lt;/dsts&gt;</span></p>
<p dir="ltr"><span>&lt;/network-map&gt;</span></p>
<br><p dir="ltr"><span>This proves that the message encoding condition is a sufficient condition for the JSON object to have a YANG model.</span></p>
<br><p dir="ltr"><span>Note the model generated is very crude and lose almost all constraints and all inheritance features (if any), because it focuses on the syntax and is essentially converted from an JSON object compliant with a protocol instead of from the protocol itself. Hence this result is more useful in determining which JSON based protocols cannot have a syntactically equivalent YANG model, than in generating a good YANG model.</span></p>
<br><p dir="ltr"><span>3.3. Conclusion</span></p>
<p dir="ltr"><span>Our claim holds. A JSON based protocol carried by HTTP can have syntactically equivalent YANG model, if and only if all the keys in the key-value pairs in the JSON message are pre-defined keywords.</span></p>
<br><p dir="ltr"><span>4. Semantic equivalence</span></p>
<p dir="ltr"><span>For JSON based protocols that don&rsquo;t satisfy the message encoding condition, it is still possible to have a semantically equivalent YANG model. All that is required for the protocol compliant clients and the YANG model compliant server to interoperate is an adapter which does the following:</span></p>
<br><p dir="ltr"><span>1) translate FROM YANG server compliant response msg TO alto compliant response msg</span></p>
<p dir="ltr"><span>2) translate FROM alto compliant request msg TO YANG server compliant request msg</span></p>
<br><p dir="ltr"><span>4.1. Claim</span></p>
<p dir="ltr"><span>This adapter needs to be protocol-aware.</span></p>
<br><p dir="ltr"><span>Ideally, given any YANG model, we would like to be able to automatically (or at least mechanically) generate this message adapter, which means not looking at the protocol or its compliant msgs. However, without knowing the specific protocol that we are working with (i.e. human intervention, i.e. looking at the protocol compliant msgs), such an adapter cannot be auto-generated.</span></p>
<br><p dir="ltr"><span>4.2. Proof by Indistinguishability</span></p>
<p dir="ltr"><span>Suppose both the YANG server compliant msg m_y and the actually protocol compliant msg m_p are in JSON (or have been encoded into JSON). Looking at the differences between the two messages, call these differences {d1, d2, ..., dn}. The goal for the auto-generated adapter would be to identify and eliminate these differences. Construct a new JSON msg m' where all but one difference di is the same as m_p and di is the same as the m_y. Without looking at the protocol (or m_p), the auto-generated adapter would not be able to distinguish between m' and m_p in its translation process, which means, it won't be able to tell whether it should change di or not. Hence, such an adapter must be protocol-aware.</span></p>
<br><p dir="ltr"><span>A good example is the dependent-vtag in the ALTO protocol:</span></p>
<p dir="ltr"><span>"dependent-vtag" : [</span></p>
<p dir="ltr"><span> &nbsp;{</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;"resource-id" : "my-network-map",</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;"tag" : "abcd1234"</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span>]</span></p>
<br><p dir="ltr"><span>It was specified this way in the alto protocol. However, it could conceivably be the case that it was originally the following map structure, and was converted into the above encoding because of the map-&gt;list+key issue. (This case is actually one of the few differences in the m_y and m_p where the adapter does not need to convert it back to a map structure.)</span></p>
<p dir="ltr"><span>"dependent-vtag" : {</span></p>
<p dir="ltr"><span> &nbsp;"my-network-map" : {</span></p>
<p dir="ltr"><span> &nbsp;&nbsp;&nbsp;"tag" : "abcd1234"</span></p>
<p dir="ltr"><span> &nbsp;}</span></p>
<p dir="ltr"><span>}</span></p>
<br><p dir="ltr"><span>Without knowing the protocol, there is no way to tell. </span></p>
<br><p dir="ltr"><span>5. Ramifications</span></p>
<p dir="ltr"><span>We now understand the basic condition for a JSON based protocol to have a YANG Model. For the protocols that don&rsquo;t meet this condition, there can be a semantic equivalent YANG model, but there won&rsquo;t be a generic process of generating the adapter for all such protocols.</span></p>
<div><span><br></span></div></span></div>
</div></div>
Y. Richard Yang | 15 Oct 06:32 2014
Picon

Incremental updates transport using SSE?

Dear all,

Given the potential progress in incremental update messaging format (e.g., merge-patch or tree-replace), it is time to consider the next item: transport. In particular, we want decoupling of update message format from transport: the payload can be carried by not only HTTP Patch, but other methods, say client pull using HTTP POST, or SSE.

In particular, consider a design where an ALTO server pushes incremental updates to an ALTO client using SSE. How about the following straw-man mapping design, for client subscription and server push content indication:

event name: ALTO resource-id

id: 
  if initial resource (full content), tag as full alto resource
  if new-tag_old-tag

data: {
data: "Content-Type": "application/merge-patch+json" | rfc6902 patch
data: "Content": 
data: {
data: <op object here, need escape to avoid ambiguity, i.e., no extra \ndata:>
data: }
data: }\n\n

Make sense, by SSE experts?

Richard
<div><div dir="ltr">
<div>Dear all,</div>
<div><br></div>
<div>Given the potential progress in incremental update messaging format (e.g., merge-patch or tree-replace), it is time to consider the next item: transport. In particular, we want decoupling of update message format from transport: the payload can be carried by not only HTTP Patch, but other methods, say client pull using HTTP POST, or SSE.</div>
<div><br></div>
<div>In particular, consider a design where an ALTO server pushes incremental updates to an ALTO client using SSE. How about the following straw-man mapping design, for client subscription and server push content indication:</div>
<div><br></div>
<div>event name: ALTO resource-id</div>
<div><br></div>
<div>id:&nbsp;</div>
<div>&nbsp; if initial resource (full content), tag as full alto resource</div>
<div>&nbsp; if new-tag_old-tag</div>
<div><br></div>
<div>data: {</div>
<div>data: "Content-Type": "application/merge-patch+json" | rfc6902 patch</div>
<div>data: "Content":&nbsp;</div>
<div>data: {</div>
<div>data: &lt;op object here, need escape to avoid ambiguity, i.e., no extra \ndata:&gt;</div>
<div>data: }</div>
<div>data: }\n\n</div>
<div><br></div>
<div>Make sense, by SSE experts?</div>
<div><br></div>
<div>Richard</div>
</div></div>
Y. Richard Yang | 14 Oct 19:47 2014
Picon

ALTO incremental updates and JSON Patch extension

Dear all,

Some of us are having an extensive discussion on how to proceed regarding the ALTO incremental updates WG item. Here is a summary of what we are thinking. At a high level, we plan to propose an approach of using JSON Patch (RFC6902), but with some extensions. We want to get your comments and advice on if you see any problems, and how best to proceed.

Current state: 
==========
Both JSON Patch (RFC6902) and  http://tools.ietf.org/html/draft-roome-alto-incr-updates-01 are considered as candidates of the encoding update message format.

Design goal and problem: 
====================
Generality and efficiency. That is, we want an incremental update format that can handle not only current resources but also future resources. The recent trend in adopting YANG shows that general mechanisms, not per protocol patch, have value. Generic encoding of JSON Patch based on XPATH and a few operators is complete in this sense, but inefficient in key ALTO cases such as updating cost maps, as pointed out in http://tools.ietf.org/html/draft-roome-alto-incr-updates-01

Key idea: 
=======
A JSON object can be considered as an key-value tree, with each node being an object and each edge labeled by the key, and the value of the edge pointing to another object. For example, the ALTO cost map example:
{
            "meta" : {
                
              "dependent-vtags" : [
                {"resource-id": "my-default-network-map",
                 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
                }
              ],

              "vtag":
                 {"resource-id": "COST-MAP-ID", "tag": "CM-TAG"},

              "cost-type" : {"cost-mode"  : "numerical",
                             "cost-metric": "routingcost"
              }
            },
            "cost-map" : {
              "PID1": { "PID1": 1,  "PID2": 5,  "PID3": 10 },
              "PID2": { "PID1": 5,  "PID2": 1,  "PID3": 15 },
              "PID3": { "PID1": 20, "PID2": 15  }
            }

defines a data tree with 14 leaf nodes:

"meta/dependent-vtags/resource-id": "my-default-network-map",
"meta/dependent-vtags/tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e",
...
"cost-map/PID3/PID1": 20,
"cost-map/PID3/PID2": 15

RFC6902 focuses on encoding updating one node on the tree at a time. On the other hand, one can realize that the cost-map update encoding of http://tools.ietf.org/html/draft-roome-alto-incr-updates-01 updates a set of nodes. For example, an update example 
{
        "meta": {
             "vtag":
                 {"tag": "NEW-CM-TAG"},
             },
        "cost-map": {
             "PID1": {"PID2": 10, "PID99": null}
             }
   }
updates 3 nodes.

If one thinks about, one will realize that this is a general, interesting design: consider the data tree of the original object; the update object is a partial tree of the original, and updates a batch containing all matched nodes in the partial tree. We call this operator the tree-replace operator. How may one do this as an extension of RFC6902: 

{
 "op" : "tree-replace",
 "path" : "/",    // prefix of update object
 "value" :       // just a copy of the partial object in value
      { "meta": {
             "vtag":
                 {"tag": "NEW-CM-TAG"},
         },
        "cost-map": {
             "PID1": {"PID2": 10, "PID99": null}
          }
      }     
}

Hence, we have a simple operator that appears to be able to fix the cost-map efficiency issue and is still general, not ALTO only. 

Next step:
========
- One possibility is to start to work on an extension of RFC 6902 to introduce this operator, if there is no bug. After this is done, we specify ALTO incremental updates using the new op. An issue is that this is a sequential process and may take time.

- Another possibility is that we specify JSON Patch as incremental update encoding for now, losing efficiency. In parallel, we push for the new op, and when it is done, ALTO incremental updates implementation can use the new op.

- A third possibility is that we define the extension operator in ALTO incremental updates document itself, and proceed quickly.

Any bug in the design? Any comments or suggestions?

Thanks!

Richard, Wendy
<div><div dir="ltr">Dear all,
<div><br></div>
<div>Some of us are having an extensive discussion on how to proceed regarding the ALTO incremental updates WG item. Here is a summary of what we are thinking. At a high level, we plan to propose an approach of using JSON Patch (RFC6902), but with some extensions. We want to get your comments and advice on if you see any problems, and how best to proceed.</div>
<div><br></div>
<div>Current state:&nbsp;</div>
<div>==========</div>
<div>Both JSON Patch (RFC6902) and&nbsp;&nbsp;<a href="http://tools.ietf.org/html/draft-roome-alto-incr-updates-01">http://tools.ietf.org/html/draft-roome-alto-incr-updates-01</a> are considered as candidates of the encoding update message format.</div>
<div><br></div>
<div>Design goal and problem:&nbsp;</div>
<div><span>====================</span></div>
<div>
<span>Generality and efficiency. That is, we want an incremental update format that can handle not only current resources but also future resources.&nbsp;</span><span>The recent trend in adopting YANG shows that general mechanisms, not per protocol patch, have value.&nbsp;</span><span>Generic encoding of JSON Patch based on XPATH and a few operators is complete in this sense, but inefficient in key ALTO cases such as updating cost maps, as pointed out in&nbsp;</span><a href="http://tools.ietf.org/html/draft-roome-alto-incr-updates-01">http://tools.ietf.org/html/draft-roome-alto-incr-updates-01</a>
</div>
<div><span><br></span></div>
<div><span>Key idea:&nbsp;</span></div>
<div><span>=======</span></div>
<div><span>A JSON object can be considered as an key-value tree, with each node being an object and each edge labeled by the key, and the value of the edge pointing to another object. For example, the ALTO cost map example:</span></div>
<div>
<div>{</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "meta" : {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<span>&nbsp;</span><span>&nbsp;</span>
</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "dependent-vtags" : [</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {"resource-id": "my-default-network-map",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ],</div>
<div><br></div>
<div>
<div><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "vtag":</span></div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;{"resource-id": "COST-MAP-ID", "tag": "CM-TAG"},</div>
<div><br></div>
</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "cost-type" : {"cost-mode" &nbsp;: "numerical",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"cost-metric": "routingcost"</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; },</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "cost-map" : {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "PID1": { "PID1": 1, &nbsp;"PID2": 5, &nbsp;"PID3": 10 },</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "PID2": { "PID1": 5, &nbsp;"PID2": 1, &nbsp;"PID3": 15 },</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "PID3": { "PID1": 20, "PID2": 15 &nbsp;}</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</div>
</div>
<div><br></div>
<div>defines a data tree with 14 leaf nodes:<br><br>
</div>
<div>
<div>"meta/dependent-vtags/resource-id": "my-default-network-map",</div>
<div>"meta/dependent-vtags/tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e",</div>
<div>...</div>
<div>"cost-map/PID3/PID1": 20,</div>
<div>"cost-map/PID3/PID2": 15</div>
<div><br></div>
</div>
<div>
<span>RFC6902 focuses on encoding updating one node on the tree at a time. On the other hand, one can realize that the cost-map update encoding of&nbsp;</span><a href="http://tools.ietf.org/html/draft-roome-alto-incr-updates-01">http://tools.ietf.org/html/draft-roome-alto-incr-updates-01</a> updates a set of nodes. For example, an update example&nbsp;<br><div>{</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; "meta": {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"vtag":</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;{"tag": "NEW-CM-TAG"},</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;},<br>
</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; "cost-map": {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"PID1": {"PID2": 10, "PID99": null}</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</div>
<div>&nbsp; &nbsp;}</div>
</div>
<div>updates 3 nodes.</div>
<div><br></div>
<div>If one thinks about, one will realize that this is a general, interesting design: consider the data tree of the original object; the update object is a partial tree of the original, and updates a batch containing all matched nodes in the partial tree. We call this operator the tree-replace operator. How may one do this as an extension of RFC6902:&nbsp;</div>
<div>
<br><div>{</div>
<div>&nbsp;"op" : "tree-replace",</div>
<div>&nbsp;"path" : "/", &nbsp; &nbsp;// prefix of update object</div>
<div>&nbsp;"value" : &nbsp; &nbsp; &nbsp; // just a copy of the partial object in value</div>
<div>
<div>&nbsp; &nbsp; &nbsp; { "meta": {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"vtag":</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;{"tag": "NEW-CM-TAG"},</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;},<br>
</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; "cost-map": {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"PID1": {"PID2": 10, "PID99": null}</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</div>
<div>&nbsp; &nbsp; &nbsp; } &nbsp; &nbsp;&nbsp;</div>
</div>
<div>
<span>}</span><br>
</div>
</div>
<div><br></div>
<div>Hence, we have a&nbsp;<span>simple operator that appears to be able to fix the cost-map efficiency issue and is still general, not ALTO only.&nbsp;</span><br>
</div>
<div><span><br></span></div>
<div>
<div>Next step:</div>
<div>========</div>
</div>
<div>- One possibility is to start to work on an extension of RFC 6902 to introduce this operator, if there is no bug. After this is done, we specify ALTO incremental updates using the new op. An issue is that this is a sequential process and may take time.</div>
<div><br></div>
<div>- Another possibility is that we specify JSON Patch as incremental update encoding for now, losing efficiency. In parallel, we push for the new op, and when it is done, ALTO incremental updates implementation can use the new op.</div>
<div><br></div>
<div>- A third possibility is that we define the extension operator in ALTO incremental updates document itself, and proceed quickly.</div>
<div><br></div>
<div>Any bug in the design? Any comments or suggestions?</div>
<div><br></div>
<div>Thanks!</div>
<div><br></div>
<div>Richard, Wendy</div>
</div></div>
Xiao SHI | 10 Oct 07:33 2014
Picon

YANG Model for ALTO Protocol

Hi all,

Several of us (Michael, Jon, Richard, Wendy) are working on producing a YANG module specification for the ALTO base protocol (RFC 7285). Some of our goals include:

(1) What a semantically equivalent YANG module of the ALTO protocol looks like;

(2) What issues we may encounter;

(3) How we may generate running code based on either YANG or direct JSON tools.

Our current YANG model can be found at https://github.com/alto-ietf/ALTO/blob/master/alto-service.yang. It is still a work-in-progress.

We would like to post the code early to get some feedback from you, and will submit an internet-draft to document the YANG spec, our experiences using YANG (and the related tools), and comparisons related to the goals above.

Your comments will be much appreciated! Thank you so much!

Best,
Xiao
<div><div dir="ltr">
<div>Hi all,</div>
<div><br></div>
<div>Several of us (Michael, Jon, Richard, Wendy) are working on producing a YANG module specification for the ALTO base protocol (RFC 7285). Some of our goals include:</div>
<div><br></div>
<div>(1) What a semantically equivalent YANG module of the ALTO protocol looks like;</div>
<div><br></div>
<div>(2) What issues we may encounter;</div>
<div><br></div>
<div>(3) How we may generate running code based on either YANG or direct JSON tools.</div>
<div><br></div>
<div>Our current YANG model can be found at <a href="https://github.com/alto-ietf/ALTO/blob/master/alto-service.yang">https://github.com/alto-ietf/ALTO/blob/master/alto-service.yang</a>. It is still a work-in-progress.</div>
<div><br></div>
<div>We would like to post the code early to get some feedback from you, and will submit an internet-draft to document the YANG spec, our experiences using YANG (and the related tools), and comparisons related to the goals above.</div>
<div><br></div>
<div>Your comments will be much appreciated! Thank you so much!</div>
<div><br></div>
<div>Best,</div>
<div>Xiao</div>
</div></div>
Wendy Roome | 8 Oct 21:32 2014

Resource Attributes -- new draft

I just submitted a draft proposal
(https://datatracker.ietf.org/doc/draft-roome-alto-resource-attr/) for
providing additional descriptive information for ALTO services. The draft
defines both the mechanism and an initial set of attributes. While
capabilities tell you want kind of resource this is, and what optional
features it supports, attributes tell you how this resource differs from
other resources of the same type.

Hopefully we can discuss this in November.

	- Wendy Roome

Y. Richard Yang | 30 Sep 22:31 2014
Picon

Key-value data structures in YANG/JSON encoding

Hi all,

A few of us are doing an exercise of defining a YANG module to express the ALTO protocol (RFC7285). Multiple problems come up and here is one problem we encounter. 

First, the context. A design decision of the ALTO protocol is to use key-value stores (maps), which are different from lists or containers. Many large-scale systems are designed based on key-value stores, and many programming frameworks provide hash maps.

A particular example of using key-value map is the network-map, which is defined as a key-value store to enforce that each named endpoint address group has a unique name. A specific example is in Section 11.2.1.7 of RFC 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt):

         "network-map" : {
           "PID1" : {
             "ipv4" : [
               "192.0.2.0/24",
               "198.51.100.0/25"
             ]
           },
           "PID2" : {
             "ipv4" : [
               "198.51.100.128/25"
             ]
           },
           "PID3" : {
             "ipv4" : [
               "0.0.0.0/0"
             ],
             "ipv6" : [
               "::/0"
             ]
           }

One way to express this in YANG is the following:
===example YANG===
list network-map {
  key "pid";
  leaf pid {
    type string;
  }
  leaf endpoint-address-group ... {
    // ...
  }
}
==================

Following the currently defined json encoding, the output will be:
{
  "network-map" : [
    {
      "pid" : "PID1",
       // ...
    },
    {
      "pid" : "PID2",
      // ...
    },
    {
      "pid" : "PID3",
      // ...
    }
  ]
} 

But this not what we want, because it is using an array, not a map. One does not have to use an array to store the map.

We see two possibilities, if to produce the output. One is in the encoding process: define such outputs on matching a template:

list MyList {
  key x;
  leaf x {
    type string;
  }
  leaf y { 
   ...
  }
}

The second is that maybe this should be resolved in YANG; i.e., introducing a new data type (beyond list, container), but something like key-value store, say named map:

map MyMap {
  key my-key {
    ...
  };
  value my-value {
  }
}

Note that the second mapping involves work if the key type is not a simple type (say string or numbers). A typical approach in some software framework is to define a hash function on key. 

We have discussed the issue with Lada, and now take the issue to the mailing list. If anyone else has encountered similar problems, please let us know. We also want to get a sense of any interest in introducing the data type in YANG. Any comments will be appreciated.

Thanks!

Richard
<div><div dir="ltr">Hi all,<div><br></div>
<div>A few of us are doing an exercise of defining a YANG module to express the ALTO protocol (RFC7285). Multiple problems come up and here is one problem we encounter.&nbsp;</div>
<div><br></div>
<div>
<span>First, the context. A design decision of the ALTO protocol is to use key-value stores (maps), which are different from lists or containers. Many large-scale systems are designed based on key-value stores, and many programming frameworks provide hash maps.</span><br>
</div>
<div><span><br></span></div>
<div>
<span>A particular example of using key-value map is the network-map, which is defined as a key-value store to enforce that each named endpoint address group has a unique name. A specific example is&nbsp;</span>in Section 11.2.1.7 of RFC 7285 (<a href="http://www.rfc-editor.org/rfc/rfc7285.txt">http://www.rfc-editor.org/rfc/rfc7285.txt</a>):</div>
<div><br></div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"network-map" : {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"PID1" : {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"ipv4" : [</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"<a href="http://192.0.2.0/24">192.0.2.0/24</a>",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"<a href="http://198.51.100.0/25">198.51.100.0/25</a>"</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;]</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;},</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"PID2" : {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"ipv4" : [</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"<a href="http://198.51.100.128/25">198.51.100.128/25</a>"</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;]</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;},</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"PID3" : {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"ipv4" : [</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"<a href="http://0.0.0.0/0">0.0.0.0/0</a>"</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;],</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"ipv6" : [</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;"::/0"</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;]</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</div>
<div><br></div>
<div>One way to express this in YANG is the following:</div>
<div>
<div>===example YANG===</div>
<div>list network-map {</div>
<div>&nbsp; key "pid";</div>
<div>&nbsp; leaf pid {</div>
<div>&nbsp; &nbsp; type string;</div>
<div>&nbsp; }</div>
<div>&nbsp; leaf endpoint-address-group ... {</div>
<div>&nbsp; &nbsp; // ...</div>
<div>&nbsp; }</div>
<div>}</div>
<div>==================</div>
</div>
<div><br></div>
<div>Following the currently defined json encoding, the output will be:</div>
<div>{</div>
<div>&nbsp; "network-map" : [</div>
<div>&nbsp; &nbsp; {</div>
<div>&nbsp; &nbsp; &nbsp; "pid" : "PID1",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp;// ...</div>
<div>&nbsp; &nbsp; },</div>
<div>&nbsp; &nbsp; {</div>
<div>&nbsp; &nbsp; &nbsp; "pid" : "PID2",</div>
<div>&nbsp; &nbsp; &nbsp; // ...</div>
<div>&nbsp; &nbsp; },</div>
<div>&nbsp; &nbsp; {</div>
<div>&nbsp; &nbsp; &nbsp; "pid" : "PID3",</div>
<div>&nbsp; &nbsp; &nbsp; // ...</div>
<div>&nbsp; &nbsp; }</div>
<div>&nbsp; ]</div>
<div>
<span>}</span>&nbsp;</div>
<div><br></div>
<div>But this not what we want, because it is using an array, not a map. One does not have to use an array to store the map.</div>
<div><br></div>
<div>
<div>
<span>We see two possibilities, if to produce the output. One is in the encoding process:</span><span>&nbsp;define such outputs on matching a template:</span>
</div>
<div>
<div><br></div>
<div>list MyList {</div>
<div>&nbsp; key x;</div>
<div>&nbsp; leaf x {</div>
<div>&nbsp; &nbsp; type string;</div>
<div>&nbsp; }</div>
<div>&nbsp; leaf y {&nbsp;</div>
<div>&nbsp; &nbsp;...</div>
<div>&nbsp; }</div>
<div>}</div>
</div>
<div><br></div>
<div>The second is that maybe this should be resolved in YANG; i.e., introducing a new data type (beyond list, container), but something like key-value store, say named map:</div>
<div><br></div>
<div>map MyMap {</div>
<div>&nbsp; key my-key {</div>
<div>&nbsp; &nbsp; ...</div>
<div>&nbsp; };</div>
<div>&nbsp; value my-value {</div>
<div>&nbsp; }</div>
<div>}</div>
<div><br></div>
<div>Note that the second mapping involves work if the key type is not a simple type (say string or numbers). A typical approach in some software framework is to define a hash function on key.&nbsp;</div>
</div>
<div><br></div>
<div>We have discussed the issue with Lada, and now take the issue to the mailing list. If anyone else has encountered similar problems, please let us know. We also want to get a sense of any interest in introducing the data type in YANG. Any comments will be appreciated.</div>
<div><br></div>
<div>Thanks!</div>
<div><br></div>
<div>Richard</div>
<div>
</div>
</div></div>
Vijay K. Gurbani | 5 Sep 22:18 2014

Building ALTO maps from public data

Folks: Some of you may be interested in the following paper on how to
build ALTO maps from public data:

Making historical connections: Building Application Layer Traffic
Optimization (ALTO) network and cost maps from public broadband data
    Vijay K. Gurbani, David Goergen, Radu State and Thomas Engel

Abstract: The Application Traffic Layer Optimization (ALTO) protocol
allows network service providers (NSP) to make available a pair of maps
to applications such that the applications can intelligently (compared
to randomly) connect to a desired resource. The network map aggregates
the service provider network into provider defined identifiers (PID)
and the cost map provides a pair-wise link cost between each PID.
Clearly, a NSP has an authoritative view of its network and is able to
provide an ALTO server that distributes such maps. However, ALTO also
envisions third-parties as being able to provide such maps. In this
paper, we demonstrate how a third-party ALTO server can provide maps
by mining public information. Specifically, we build our maps from the
United States Federal Communications Commission public broadband data
set, which contains an expressive (multi-tier wireline broadband
measurements) and rich (measurements for specific application uses)
dataset. In all, we examined over 1 billion records spread over 90
GBytes as part of our analysis. We borrow concepts from financial
engineering and social network analysis to show how network topology
and cost maps can be created, and furthermore, how peer-to-peer systems
can insulate themselves from going dark by choosing supernodes
effectively from mining historical data.

Until the paper is available in the IEEE archives, email me if you'd
like a copy.

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: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

Y. Richard Yang | 5 Sep 21:44 2014
Picon

ALTO Protocol (RFC7285) published!

Dear ALTOnians,

The base ALTO protocol has been published !! 


The link to the published RFC: https://www.rfc-editor.org/rfc/rfc7285.txt

RFC7285 is the hard work of a lot of people, including the authors, the WG chairs (Enrico, Vijay), the ADs (Spencer, Martin), the RFC editor (Megan), the IESG, multiple people that deserve a lot more recognition that currently (Jan, Ben, Michael, Sabine, Young, Greg, Haibin, ...)

The editors and authors learned much and will apply the learned when working on the extensions (e.g., more streamlined).

Cheers,

Richard
<div><div dir="ltr">Dear ALTOnians,<div><br></div>
<div>The base ALTO protocol has been published !!&nbsp;</div>
<div><br></div>
<div>The RFC announcement link:&nbsp;<a href="http://www.rfc-editor.org/pipermail/rfc-dist/2014-September/004110.html">http://www.rfc-editor.org/pipermail/rfc-dist/2014-September/004110.html</a>
</div>
<div><br></div>
<div>The link to the published RFC:&nbsp;<a href="https://www.rfc-editor.org/rfc/rfc7285.txt">https://www.rfc-editor.org/rfc/rfc7285.txt</a>
</div>
<div><br></div>
<div>RFC7285 is the hard work of a lot of people, including the authors, the WG chairs (Enrico, Vijay), the ADs (Spencer, Martin), the RFC editor (Megan), the IESG, multiple people that deserve a lot more recognition that currently (Jan, Ben, Michael, Sabine, Young, Greg, Haibin, ...)<br><div><br></div>
</div>
<div>The editors and authors learned much and will apply the learned when working on the extensions (e.g., more streamlined).</div>
<div><br></div>
<div>Cheers,</div>
<div><br></div>
<div>Richard</div>
</div></div>
rfc-editor | 5 Sep 21:28 2014

RFC 7285 on Application-Layer Traffic Optimization (ALTO) Protocol

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7285

        Title:      Application-Layer Traffic Optimization (ALTO) Protocol 
        Author:     R. Alimi, Ed.,
                    R. Penno, Ed.,
                    Y. Yang, Ed.,
                    S. Kiesel, 
                    S. Previdi,
                    W. Roome, 
                    S. Shalunov, 
                    R. Woundy
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2014
        Mailbox:    ralimi <at> google.com, 
                    repenno <at> cisco.com, 
                    yry <at> cs.yale.edu,  
                    ietf-alto <at> skiesel.de, 
                    sprevidi <at> cisco.com,  
                    w.roome <at> alcatel-lucent.com, 
                    shalunov <at> shlang.com,  
                    Richard_Woundy <at> cable.comcast.com
        Pages:      91
        Characters: 194499
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-alto-protocol-27.txt

        URL:        https://www.rfc-editor.org/rfc/rfc7285.txt

Applications using the Internet already have access to some topology
information of Internet Service Provider (ISP) networks.  For
example, views to Internet routing tables at Looking Glass servers
are available and can be practically downloaded to many network
application clients.  What is missing is knowledge of the underlying
network topologies from the point of view of ISPs.  In other words,
what an ISP prefers in terms of traffic optimization -- and a way to
distribute it.

The Application-Layer Traffic Optimization (ALTO) services defined in
this document provide network information (e.g., basic network
location structure and preferences of network paths) with the goal of
modifying network resource consumption patterns while maintaining or
improving application performance.  The basic information of ALTO is
based on abstract maps of a network.  These maps provide a simplified
view, yet enough information about a network for applications to
effectively utilize them.  Additional services are built on top of
the maps.

This document describes a protocol implementing the ALTO services.
Although the ALTO services would primarily be provided by ISPs, other
entities, such as content service providers, could also provide ALTO
services.  Applications that could use the ALTO services are those
that have a choice to which end points to connect.  Examples of such
applications are peer-to-peer (P2P) and content delivery networks.

This document is a product of the Application-Layer Traffic Optimization Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC


Gmane