Subject: [alto] Design issue on path vector

From: Chan Dawn <[email-masked]>
Date: Tue, 21 Mar 2017 17:02:54 +0000

Hi all,

I'd like to start a discussion for path-vector design and push it as an acceptable specification. Following is my thought:

We have agreed on delivering path-vector + abstract network elements design for net graph representation since IETF 96. This design specifies the cost value as a path vector which is a JSONArray of network elements and puts the network element properties into a nep-map. Considering to reference the nep-map from another resource (we propose to use unified-prop-map), below is a naive design:

An example of IRD:

“pv-endpoint-cost-map”: {

    “uri”: “http://alto.example.com/lookup/endpointcost”,

    “media-type”: “application/alto-endpointcostmap+json”,

    “capabilities” : {

      “cost-type-names”: [“pv"]

    },

    “uses”: [“default-nep-map"]

}

An example of ECS response:

“meta”: {

  “dependent-vtags”: [

    { “resource-id”: “default-nep-map”, “tag”: “<sha256>” }

  ],

  “cost-type”: {“cost-mode”: “path-vector”, “cost-metric”: “ane”}

},

“endpoint-cost-map”: ...

However, the problem is how to reference the filtered property map that we use for clients to retrieve the properties of the corresponding network elements. In the above example, the referenced network element property map is added in the “uses” field. However, here is the trouble:

Since the network elements are abstract, the network element property map is dynamically generated when the client sends a path-vector query. So, to add the refrenced network element property map in the “uses” field of a resource is not possible because the resource id in the “uses” field is somehow static, it already exists before queried.

To solve this problem, we proposed the following design in draft-yang-alto-path-vector-04:

An example of ECS response:

“meta”: {

  …

  "nep-map": {

           "uri": "http://alto.example.com/propmap/lookup/nep-map",

           "media-type": "application/alto-prompmap+json",

           "accepts": "application/alto-propmapparams+json",

           "capabilities": {

             "domain-types": [“ane"],

             "prop-types": ["availbw"]

           }

         }

},

“endpoint-cost-map”: ...

But we found two issues in this design:

1. How to present the supported properties of the network elements in the IRDResourceEntry of a resource? In this example, the nep-map can only provide the “availbw” property. If the client needs the “delay” property of the returned network elements, it cannot get this knowledge that the dependent nep-map of this ECS resource does not provide this property before it sends the query. So the client will send a useless query.

2. This design does not provide a resource-id for the nep-map, so the server cannot provide an incremental update service for the nep-map.

We found the fundamental problem is caused by the dynamic resource. In the previous ALTO extensions, all the resources can be defined by the static IRD Resource Entries. But in this case, we have to handle the dependency relationship between FCM/ECS and a dynamic property map resource. So we propose the following design to solve this problem:

1. Add a new attribute in the IRDResrouceEntry:

object {

    JSONString               uri;

    JSONString               media-type;

    [JSONString              accepts;]

    [Capabilities            capabilities;]

    [ResourceID              uses<0..*>;]

    [ImmediateResourceEntry  immediate-uses<0..*>;]

} IRDResourceEntry;

object {

    JSONString      media-type;

    [JSONString     accepts;]

    [Capabilities   capabilities;]

    [ResourceID     uses<0..*>;]

} ImmediateResourceEntry;

2. Add a new attribute in the meta of FCM/ECS response:

object {

    [JSONString               vtag;]

    [VersionTag               dependent-vtags<1..*>;]

    [ImmediateVersionTag      immediate-dependent-vtags<1..*>;]

} ResponseMeta;

object {

    ResourceID       resource-id;

    JSONString       vtag;

    [JSONNumber      time-out;]

} ImmediateVersionTag;

Here is an example:

IRD:

    "pv-endpoint-cost-map": {

      "uri": "http://alto.example.com/lookup/endpointcost",

      "media-type": "application/alto-endpointcost+json",

      "accepts": "application/alto-endpointcostparams+json",

      "immediate-uses": [

        {

          "media-type": "application/alto-propmap+json",

          "accepts": "application/alto-propmapparams+json",

          "capabilities": { "domain-types": ["ane"],

                            "prop-types": ["availbw", "delay"] }

      ],

      "capabilities": {

        "cost-type-names": ["pv-ane", "num-routingcost", "num-hopcount"],

        "cost-constraints": true

      }

    },

Response:

  {

    "meta": {

      "cost-type": {

        "cost-mode": "path-vector",

        "cost-metric": "ane",

      },

      "immediate-dependent-vtags": [

        {"resource-id": "nep-map-<sha256>",

         "vtag": "<sha256>",

         "time-out": 180}

      ]

    },

    "endpoint-cost-map": {

      ...

    }

  }

Shall we push this design into the pv draft? Any feedback from others?

Thanks a lot!

Dawn

---

From: xin wang <[email-masked]>
Date: Wed, 22 Mar 2017 04:32:46 +0000

Hi Dawn,

If I am wrong please correct me. For the second issue, the resource id could be reflected in the hash code of the uri field. I think you are missing that in your ECS example. For the first issue, in my understanding, since network elements are dynamically generated after the computation of path-vector, I think it is hard to determine element property types before the computation. This may depend on whether we support "unknown" in the response of network element property map, i.e.,

"property-map": {
         "ne:ne12": { "availbw": "90", "delay": "unknown" },
         "ne:ne23": { "availbw": "80", "delay": "15" },
         "ne:ne34": { "availbw": "70", "delay": "25" }
 }

Best,
Xin

________________________________
From: alto <[email-masked]> on behalf of Chan Dawn <[email-masked]>
Sent: Tuesday, March 21, 2017 13:02
To: [email-masked]; [email-masked]
Subject: [alto] Design issue on path vector

Hi all,

An example of IRD:

    “capabilities” : {

    },

}

“meta”: {

  “dependent-vtags”: [

  ],

},

“endpoint-cost-map”: ...

“meta”: {

  …

  "nep-map": {

           "capabilities": {

             "domain-types": [“ane"],

           }

         }

},

“endpoint-cost-map”: ...

object {

    JSONString               uri;

    JSONString               media-type;

    [JSONString              accepts;]

    [ResourceID              uses<0..*>;]

} IRDResourceEntry;

object {

    JSONString      media-type;

    [JSONString     accepts;]

    [ResourceID     uses<0..*>;]

object {

    [JSONString               vtag;]

} ResponseMeta;

object {

    ResourceID       resource-id;

    JSONString       vtag;

    [JSONNumber      time-out;]

} ImmediateVersionTag;

Here is an example:

IRD:

      "immediate-uses": [

        {

      ],

      "capabilities": {

        "cost-constraints": true

      }

    },

Response:

  {

    "meta": {

      "cost-type": {

        "cost-metric": "ane",

      },

         "vtag": "<sha256>",

         "time-out": 180}

      ]

    },

    "endpoint-cost-map": {

      ...

    }

  }

Thanks a lot!

Dawn

---

From: Jensen Zhang <[email-masked]>
Date: Wed, 22 Mar 2017 14:35:54 +0800

Hi Dawn,

Thanks for starting this discussion.

Hi Xin,

Thanks for your comments. See inline.

Jensen

On Wed, Mar 22, 2017 at 12:32 PM, xin wang <[email-masked]> wrote:
> Hi Dawn,
>
>
> If I am wrong please correct me. For the second issue, the resource id could
> be reflected in the hash code of the uri field. I think you are missing that
> in your ECS example.

I think "uri" and "resource-id" are very different. How can we reflect
the "resource-id" in the "uri"? Do you want to introduce the extra
semantics into the "uri"?

> For the first issue, in my understanding, since network
> elements are dynamically generated after the computation of path-vector, I
> think it is hard to determine element property types before the computation.
> This may depend on whether we support "unknown" in the response of network
> element property map, i.e.,
>
> "property-map": {

Please notice that "prop-types" is a capability of "prop-map". If this
"prop-map" does not support "delay", it will be determined before you
send any query. And you even cannot query "delay" to this "prop-map".
"unknown" does not solve this issue.

I think what we are discussing is that if the ALTO server provides a
"path-vector" FCM resource, it should inform the client which
"prop-types" will be supported by the generated "prop-map" at an
earlier stage. If you provide this information in the response of FCM
rather than the IRD entry of it, the client may have to send a useless
FCM query before it gets this information.

> I'd like to start a discussion for path-vector design and push it as an
> acceptable specification. Following is my thought:
>
>
> We have agreed on delivering path-vector + abstract network elements design
> for net graph representation since IETF 96. This design specifies the cost
> value as a path vector which is a JSONArray of network elements and puts the
> network element properties into a nep-map. Considering to reference the
> nep-map from another resource (we propose to use unified-prop-map), below is
> a naive design:
>
>
>
> An example of IRD:
>
>
> However, the problem is how to reference the filtered property map that we
> use for clients to retrieve the properties of the corresponding network
> elements. In the above example, the referenced network element property map
> is added in the “uses” field. However, here is the trouble:
>
>
> Since the network elements are abstract, the network element property map is
> dynamically generated when the client sends a path-vector query. So, to add
> the refrenced network element property map in the “uses” field of a resource
> is not possible because the resource id in the “uses” field is somehow
> static, it already exists before queried.
>
>
> 1. How to present the supported properties of the network elements in the
> IRDResourceEntry of a resource? In this example, the nep-map can only
> provide the “availbw” property. If the client needs the “delay” property of
> the returned network elements, it cannot get this knowledge that the
> dependent nep-map of this ECS resource does not provide this property before
> it sends the query. So the client will send a useless query.
>
> 2. This design does not provide a resource-id for the nep-map, so the server
> cannot provide an incremental update service for the nep-map.
>
>
> We found the fundamental problem is caused by the dynamic resource. In the
> previous ALTO extensions, all the resources can be defined by the static IRD
> Resource Entries. But in this case, we have to handle the dependency
> relationship between FCM/ECS and a dynamic property map resource. So we
> propose the following design to solve this problem:
>
>

---

From: Chan Dawn <[email-masked]>
Date: Wed, 22 Mar 2017 13:06:25 +0000

Hi Xin,

Thanks for your comments and I agree with Jensen.

Besides, I would like to point out that if the property map doesn't support some property types, all of its network elements is not able to have that property. So, in your example,

>          "ne:ne34": { "availbw": "70", "delay": "25" }

If property "delay" is not supported, all the network elements shall not have the "delay" property, not only the netwrok element "ne:ne12".

Another thing is that if the property for a specific network element is not available, the property map will return value "null" for that property.

Best Regards,

Dawn

________________________________
发件人: Jensen Zhang <[email-masked]>
发送时间: 2017年3月22日 14:35
收件人: xin wang
抄送: Chan Dawn; [email-masked]; [email-masked]
主题: Re: Design issue on path vector

Hi Dawn,

Hi Xin,

Jensen

---

From: Jensen Zhang <[email-masked]>
Date: Thu, 23 Mar 2017 00:16:43 +0800

I'm thinking about whether the design can be simpler. Here is another
design to solve the dynamic nep-map issue:

We do not extend any scheme but make every path-vector queries share
the same nep-map resource.

Here is an example nep-map resource in the IRD. It is a filtered
property map as the same define in [0].

This resource supports the "availbw" and "delay" property types.
Initially, this resource may be empty with no abstract network
elements.

  "default-nep-map": {
     "uri": "http://alto.example.com/propmap/nepmap/default",
     "media-type": "application/alto-propmap+json",
     "accepts": "application/alto-propmapfilter+json",
     "capabilities": {
       "domain-types": ["ane"],
       "prop-types": ["availbw", "delay"]
   }

The ECS resource uses "default-nep-map" as the dependent resource.
(Just like the naive design.)

    “capabilities”: { “cost-type-names”: [“pv"] },

Each query will share the same dependent resource. But the ane names
in different responses MUST be different. There are two different
queries for the same ECS resource.

ECS Response of Query1:

  {
    "meta": {
      "cost-type": {
        "cost-mode": "path-vector",
        "cost-metric": "ane",
      },
      "dependent-vtags": [
        {"resource-id": "default-nep-map",
         "vtag": "[TBD]",}
      ]
    },
    "endpoint-cost-map": {
      "ipv4:192.168.1.101": { "ipv4:192.168.1.201": ["ane:QabcdL0001",
"ane:QabcdL0002"] },
      ...
    }
  }

After the above query, "ane:QabcdL0001" and "ane:QabcdL0002" will be
added into the "default-nep-map".

ECS Response of Query2:

{
  "meta": //The same meta
  "endpoint-cost-map": {
    "ipv4:192.168.1.102": { "ipv4:192.168.1.202": ["ane:QabdeL0001",
"ane:QabdeL0002"] },
    ...
  }
}

And after this query, "ane:QabcdL0001" and "ane:QabcdL0002" will be
added into the "default-nep-map".

You may notice that they use different prefixes ("Qabcd" and "Qabde")
of ane names to ensure there is no same ane name in different
responses. The ALTO server can also adopt other ways to ensure the ane
names are query-specific (which means the ane names in responses of
different queries are not conflict).

Any thoughts?

[0] https://www.ietf.org/id/draft-roome-alto-unified-props-new-00.txt

Jensen

On Wed, Mar 22, 2017 at 9:06 PM, Chan Dawn <[email-masked]> wrote:
> Besides, I would like to point out that if the property map doesn't support
> some property types, all of its network elements is not able to have that
> property. So, in your example,
>
>>"property-map": {
> If property "delay" is not supported, all the network elements shall not
> have the "delay" property, not only the netwrok element "ne:ne12".
>
>
> Another thing is that if the property for a specific network element is not
> available, the property map will return value "null" for that property.
>
>
> Best Regards,
>
> Dawn
>
>
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 22 Mar 2017 15:38:01 -0400

Dear Dawn, Jensen,

Some comments. Please see below inline.

On Tue, Mar 21, 2017 at 1:02 PM, Chan Dawn <[email-masked]> wrote:

> We have agreed on delivering path-vector + abstract network elements
> design for net graph representation since IETF 96. This design specifies
> the cost value as a path vector which is a JSONArray of network elements
> and puts the network element properties into a nep-map. Considering to
> reference the nep-map from another resource (we propose to use
> unified-prop-map), below is a naive design:
>
> An example of IRD:
>

I assume that the same IRD will also have an entry for "default-nep-map"
and there is also a definition for "pv". You omitted them in this example,
correct?

> Since the network elements are abstract, the network element property map
> is dynamically generated when the client sends a path-vector query. So, to
> add the refrenced network element property map in the “uses” field of a
> resource is not possible because the resource id in the “uses” field is
> somehow static, it already exists before queried.
>
>
> A resource ID is a name to be used in the IRD to provide the needed query
information (e.g., uri) to obtain related information. If the pv resource
returns an property name (dynamic), and the property resource has an accept
of the dynamic property name, can this solve your problem?

> dependent nep-map of this ECS resource does not provide this property
> before it sends the query. So the client will send a useless query.
>

One possibility is that a pv resource also indicates the metrics that it
can provide, i.e.,

    “capabilities” : {

      // define metrics here??

    },

}

2. This design does not provide a resource-id for the nep-map, so the
> server cannot provide an incremental update service for the nep-map.
>
>
> This is a good point. We need to think a bit hard on incremental updates.
A reply will come shortly.

> previous ALTO extensions, all the resources can be defined by the static
> IRD Resource Entries. But in this case, we have to handle the dependency
> This "immediate-use" design reminds me of nameless inner class/object.
Does this require that the resource in the "immediate-use" to use the same
uri as the "parent" uri?

> Shall we push this design into the pv draft? Any feedback from others?
It is a quite interesting design. If we can modify the incremental updates
to include not only resource id but also some additional info, can the
problem be solved?

Richard

---

From: Jensen Zhang <[email-masked]>
Date: Thu, 23 Mar 2017 15:20:33 +0800

Hi Richard,

Thanks for your feedback! See my comments inline:

Jensen

On Thu, Mar 23, 2017 at 3:38 AM, Y. Richard Yang <[email-masked]> wrote:
>> design for net graph representation since IETF 96. This design specifies the
>> cost value as a path vector which is a JSONArray of network elements and
>> puts the network element properties into a nep-map. Considering to reference
>> the nep-map from another resource (we propose to use unified-prop-map),
>> below is a naive design:
>>
>> An example of IRD:
>>
> I assume that the same IRD will also have an entry for "default-nep-map" and
> there is also a definition for "pv". You omitted them in this example,
> correct?

Yes, they are also in the same IRD.

> of the dynamic property name, can this solve your problem?

Let me understand your proposal. Is it like the following?

ECS response meta:

"meta": {
  "dependent-vtags": [ { "resource-id": "default-nep-map":, "tag":
"<sha256>" } ],
  "cost-type": { "cost-mode": "path-vector", "cost-metric": "ane" },
  "query-id": "<A Query Specific ID>"
}

And nep-map request:

"query-id": "<The Same Query as the One in the Response>",
"entities": ...
"properties": ...

So every nep-map should be identified by <resource-id, tag, query-id>
rather than only <resource-id, tag>? It seems to be a solution. Let me
think about it.

> One possibility is that a pv resource also indicates the metrics that it can
> provide, i.e.,
>

Yes, it is a solution. And we tried to propose the same solution. But
it will introduce an extra capability. And only when the cost-mode is
"path-vector", this capability can be enabled. So it is too specific.
How do you think?

> This is a good point. We need to think a bit hard on incremental updates. A
> reply will come shortly.
>

Looking forward.

> This "immediate-use" design reminds me of nameless inner class/object. Does
> this require that the resource in the "immediate-use" to use the same uri as
> the "parent" uri?
>

What's the meaning of "parent" uri? A prefix of the uri? If so, I
think it is a good proposal.

> to include not only resource id but also some additional info, can the

Although we can extend incremental updates to include additional info,
I think the resource id is still a required attribute. Because we need
a unique id to identify the resource. A potential way is to use "uri"
instead of "resource-id"? But for incremental update service, resource
"uri“ cannot be used to index the resource attributes such as
"media-type" and "capabilities".

Thanks a lot!

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 23 Mar 2017 20:35:25 -0400

Jensen, Dawn,

Please see below.

> > returns a property name (dynamic), and the property resource has an
> accept

Yep. Essentially, since we have the freedom to design property map---it is
great that we are designing PV before the property, we can add needed info.

> before
> can

Agree with your thinking. The downside is that the domain of capabilities
will depend on the content, and hence static typing will not work. But I
feel that this is a small price.

> Does
Yep.

> Good point.

Richard

---

From: Dawn Chan <[email-masked]>
Date: Fri, 24 Mar 2017 12:01:52 +0000

Hi Richard, Jensen

Thanks for your new ideas, please see my comments inline.

On Mar 24, 2017, at 8:35 AM, Y. Richard Yang <[email-masked]<mailto:[email-masked]>> wrote:

Jensen, Dawn,

Please see below.

> returns a property name (dynamic), and the property resource has an accept

ECS response meta:

"meta": {

And nep-map request:

Yep. Essentially, since we have the freedom to design property map---it is great that we are designing PV before the property, we can add needed info.

I think this design idea is quite similar to what Jensen posted previously. That is, the “resource-id” of a nep-map is fixed but the nep-map itself is dynamic. To distinguish the network elements names between different queries, the names in the nep-map uses different prefixes
of ane names to ensure there is no same ane name in different responses, but this design idea doesn’t require new field name.

Also, since the nep-map will be enriched when new queries appear, the “tag” field in “dependent-vtags” is useless to reference the nep-map, right?

Agree with your thinking. The downside is that the domain of capabilities will depend on the content, and hence static typing will not work. But I feel that this is a small price.

I think no more capabilities are needed here. From the “uses” field, the client can get the information about what property types the nep-map resource support, so we don’t need to list the property types in the ECS’s capabilities, right?

Yep.

Good point.

Richard

---

From: Dawn Chan <[email-masked]>
Date: Fri, 24 Mar 2017 17:51:25 +0000

Hi Richard, Jensen and all,

Thanks for your discussion. I think I have a simple enough design now. Please see below.

The major argument seems to be how to provide the network element properties.

We have discussed both inline and separate (reference) design since IETF 96. I will recommend to use separate design. Let me explain the reason.

Although the inline design seems to be simpler, yet it cannot solve the following problem: How to inform the client which property types will be provided? The cost map resource has to provide such information in its IRD entry. Because of the semantics of cost-mode and cost-metric, it is nonsense to provide such information in the cost-type. So IRD has to provide a “cost-type-specific” attribute to provide such information. It is not a good idea.

How about the separate design? If we separate the graph information into pv-cost-map and ane-prop-map, the property types can be declared by the IRD entry of ane-prop-map. But we have to introduce some extra complexities:

Requirement 1: The dependent relationship has to be indicated explicitly.
Requirement 2: The response of ane-prop-map has to be query specific.

For requirement 1, I propose to declare the pv-cost-map as the dependent resource of the ane-prop-map. It is reasonable. Because the network elements are computed when the client queries the pv-cost-map. In other words, the generation of the ane-prop-map is caused by the query of the pv-cost-map. Another potential benefit is that the server can provide pv and other cost-types in the same cost-map.

For requirement 2, I think it can be proposed as a generic requirement: The responses of several resources can be associated with the same query.

Let’s see the general scheme of the ALTO service response:

object {
  [ResponseMeta meta;]
  ResponseData   network-map | cost-map | endpoint-cost-map | property-map;
} Response;

In our case, we can think pv-cost-map. ResponseData and ane-prop-map. ResponseData are generated at the same time when the server receives a request of pv-cost-map. So both ResponseDatas should be associated with the same query. Let’s specify the query as a “query-id” information. A reasonable workflow should be the following:

1. The client sends a request to the pv-cost-map.
2. The pv-cost-map returns the response with a “query-id” information.
3. The client sends a request with this “query-id” information to the ane-prop-map.
4. The ane-prop-map returns the response with the dependency of the pv-cost-map response with the same “query-id” information.

The following is an example of the IRD:

“pv-cost-map": {
      "uri": "http://alto.example.com/costmap/multi/filtered",
      "media-type": "application/alto-costmap+json",
      "accepts": "application/alto-costmapfilter+json",
      "uses": ["default-network-map"],
      "capabilities": {
        "cost-type-names": ["pv-ane", "num-routingcost", "num-hopcount"],
        "cost-constraints": true
      }
},
"default-nep-map": {
    "uri": "http://alto.example.com/propmap/nepmap/default",
    "media-type": "application/alto-propmap+json",
    "accepts": "application/alto-propmapfilter+json",
    "uses ": ["filtered-multi-cost-map”],
    "capabilities": {
        "domain-types": ["ane"],
        "prop-types": ["availbw"],
        "query-specific": true
    }
}

Below is an example of pv-cost-map request and response.

pv-cost-map request:
{
    "cost-type": {
        "cost-mode": "path-vector",
        "cost-metric": "ane",
    },
    "pids": {
      "srcs": ["PID1", "PID3"],
      "dsts": ["PID2", "PID4"]
    }
}

pv-cost-map response:
{
    "meta": {
        "vtag": [{"resource-id":"filtered-multi-cost-map",
                      "tag": "<sha256>",
                      "query-id": “query_0”}], // Means this response is associated with query_0.
      "dependent-vtags": [
        {"resource-id": "default-network-map",
         "tag": "<sha256>"},
      ],
      "cost-type": {
        "cost-mode": "path-vector",
        "cost-metric": "ane",
      },
    },
    "cost-map": {
      "PID1": {"PID2": ["ane:L01", "ane:L02"],
               "PID4": ["ane:L01", "ane:L03"]},
      "PID3": {"PID2": ["ane:L04", "ane:L02"],
               "PID4": ["ane:L05", "ane:L03"]}
    }
}

In the pv-cost-map response, “vtag” is extended. A new attribute “query-id” is added into VersionTag.

Next is an example of ane-prop-map request and response.

ane-prop-map Request:

{
    "query-id": “query_0”,
    "entities":["ane:L01","ane:L02","ane:L03","ane:L04","ane:L05"],
    "properties":["availbw”]
}

The query format of property map is extended, a new field “query-id” is to uniquely identify different network elements in different queries. Since one FCM or ECS query will update the ane-prop-map, so, the “query-id” in the request body of a ane-prop-map is the same as “query-id” in the response body of the corresponding FCM or ECS.

ane-prop-map Response:

{
    "meta": {
      "dependent-vtags": [
        {"resource-id": "default-nep-map",
         "tag":"<sha256>”,
         “query-id”:”query_0”
        },
      ],
    },
    "property-map": {
      "ane:L01": {"availbw": "30"},
      "ane:L02": {"availbw": "40"},
      "ane:L03": {"availbw": "50"},
      "ane:L04": {"availbw": "40"},
      "ane:L05": {"availbw": "70"}
    }
}

The “query-id” here is the same as the “query-id” in FCM response and nep-map resource mentioned above. And their value must be the same.

Any comments on this design?

Best Regards,
Dawn

---

From: Dawn Chan <[email-masked]>
Date: Fri, 24 Mar 2017 17:54:19 +0000

object {
  [ResponseMeta meta;]

“pv-cost-map": {

pv-cost-map request:
{
    "cost-type": {

pv-cost-map response:
{
    "meta": {

ane-prop-map Request:

{
    "query-id": “query_0”,

ane-prop-map Response:

{
    "meta": {
      "dependent-vtags": [

Best Regards,
Dawn