[alto] Path vector to support application traffic capacity region design

["Y. Richard Yang" <[e-mail]>]

Dear all,

We have made an initial design of the path vector design to support the key
application capacity region use case.

Below is a list of key design reasoning:
- Current cost map and endpoint cost service is designed for the setting of
alternative flows, in that it asks for the cost of each flow alone, but the
capacity region is for concurrent flows. Hence, we need a new request
parameter to denote the new semantics---we could use a new cost mode, but
using a new design can be cleaner.

- We want to support both endpoints and network maps (PIDs), when querying
capacity regions. Hence, the query, as an example possibility, is:

  POST /capacityregion/lookup HTTP/1.1
  Host: alto.example.com
  Content-Length: TBD
  Content-Type: application/alto-flowparams+json
  Accept: application/alto-costmap+json,application/alto-error+json

  {
    "cost-type" : {"cost-mode": "path-vector",
                         "cost-metric": "bandwidth"
    },
    "flows" : [
      {"src": "ipv4:192.0.2.2", "dst": "ipv4:192.0.2.89"},
      {"src": "ipv4:192.0.2.2", "dst": "ipv4:198.51.100.34"},
      {"src": "ipv4:192.0.2.2", "dst": "ipv4:203.0.113.45"},
      {"src": "ipv4:192.0.2.3", "dst": "ipv4:203.0.113.45"}
    ]
  }

A possible encoding of response is:

  HTTP/1.1 200 OK
  Content-Length: TBA
  Content-Type: application/alto-costmap+json

  {
      "dependent-vtags" : [    // defines the resource id providing nep
        { "resource-id": "my-nep-map",
          "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
        }
      ],

      "meta" : {
       "vtag" : {
           "resource-id": "my-costmap",
           "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
        }
      "cost-type" : {"cost-mode": "path-vector",
                     "cost-metric": "bandwidth"
    },

    "cost-map" : {
      "ipv4:192.0.2.2": {
                "ipv4:192.0.2.89":    ["ne56"],
                "ipv4:198.51.100.34": ["ne56", "ne57"],
                "ipv4:203.0.113.45":  ["ne57"]
      },
      "ipv4:192.0.2.3": {
                "ipv4:203.0.113.45":  ["ne57"]
      }
    }
  }

The remaining issue is how to obtain the properties of the abstract network
elements. For this, we propose to use the unified properties design:
https://tools.ietf.org/html/draft-roome-alto-unified-props-00

Any comments?

Cheers,
Richard