Folks: Here is the first draft of the ALTO interoperability test
we are scheduling in Quebec City.
Please go through this and suggest any fine-tuning we need to do
on the test suite. Some of the test cases are more fleshed out
than others (complete with request and response), others need some
more work, and if anyone will like to pick some of the test
cases that need some more work and complete them, please let
the chairs know.
Similarly, if we need to add any additional test cases or you feel
that we need to remove some of the existing ones, please feel
free to indicate so on the list.
If there is anything egregiously wrong with the IP address blocks
or costs, please indicate so.
I suspect that we will go through a couple of iterations to fully
finish the test cases, but the this should give you a good idea
of what to interoperate.
---- BEGIN ALTO INTEROPERABILITY DOCUMENT (Version 0.1)
For the ALTO interoperability, we will consider the following topology
from the view point of a service provider:
PID IP Address Block
-------------------------------
mypid1 10.0.0.0/8
mypid2 192.168.0.0/16
mypid3 192.168.10.0/24
peeringpid1 128.0.0.0/16
peeringpid2 130.0.0.0/16
transitpid1 132.0.0.0/16
transitpid2 135.0.0.0/16
defaultpid 0.0.0.0/0
And here is the cost map for the above topology:
Source PID Destination PID Cost (mode: numerical)
--------------------------------------------------------------------
mypid1 mypid1 0
" mypid2 0
" mypid3 0
" peeringpid1 0
" peeringpid2 0
" transitpid1 5
" transitpid2 10
" defaultpid 4
mypid2 mypid1 0
" mypid2 0
" mypid3 0
" peeringpid1 0
" peeringpid2 0
" transitpid1 7
" transitpid2 8
" defaultpid 4
mypid3 mypid1 0
" mypid2 0
" mypid3 0
" peeringpid1 0
" peeringpid2 0
" transitpid1 8
" transitpid2 8
" defaultpid 5.1
Test Cases
1) Retrieving the Information Resource Directory (IRD, Section 7.6)
- Client retrieve IRD through a well known URI:
http://alto.ietf.org/directory
- Server returns the following directory:
(TBD)
2) Longest prefix match (c.f. Section 4.2.1)
- Client retrieves a PID for IP address 192.168.1.23
Use the following request:
POST /endpointprop/lookup HTTP/1.1
Host: alto.ietf.org
Content-Length: ...
Accept: application/alto-endpointprop+json
{
"properties" : [ "pid" ],
"endpoints" : [ "ipv4:192.168.1.23" ]
}
- Server returns mypid2 using the following response:
HTTP/1.1 200 OK
Content-Length: ...
Content-Type: application/alto-endpointprop+json
{
"meta" : {},
"data": {
"ipv4:192.168.1.23" : { "pid": "mypid2" }
}
}
3) Longest prefix match (c.f. Section 4.2.1)
- Client retrieves a PID for IP address 192.168.10.23
Use the following request:
POST /endpointprop/lookup HTTP/1.1
Host: alto.ietf.org
Content-Length: ...
Accept: application/alto-endpointprop+json
{
"properties" : [ "pid" ],
"endpoints" : [ "ipv4:192.168.10.23" ]
}
- Server returns mypid3 using the following response:
HTTP/1.1 200 OK
Content-Length: ...
Content-Type: application/alto-endpointprop+json
{
"meta" : {},
"data": {
"ipv4:192.168.10.23" : { "pid": "mypid3" }
}
}
4) Returning default PID:
- Client retrieves a PID for IP address 201.1.13.12
Use the following request:
POST /endpointprop/lookup HTTP/1.1
Host: alto.ietf.org
Content-Length: ...
Accept: application/alto-endpointprop+json
{
"properties" : [ "pid" ],
"endpoints" : [ "ipv4:201.1.13.12" ]
}
- Server returns defaultpid using the following response:
HTTP/1.1 200 OK
Content-Length: ...
Content-Type: application/alto-endpointprop+json
{
"meta" : {},
"data": {
"ipv4:201.1.13.12" : { "pid": "defaultpid" }
}
}
5) Retrieving a network map (Section 4)
- Client uses information from IRD to retrieve a network map.
- Server returns the following:
(TBD)
6) Retrieving a cost map (Section 5)
- Client uses information from IRD to retrieve a cost map.
- Server returns the following:
(TBD)
NOTE: Make sure that the vtag in the response for the cost
map is the same as the vtag in the response for Test case
5.
7) Error: JSON parsing error (Section 7)
- Client sends a malformed JSON body in the request (details TBD)
- Server returns HTTP response code of 400 with ALTO error code
of E_JSON_SYNTAX (c.f., Table 1).
8) Error: Required field missing (Section 7)
- Client sends a request with a missing field (details TBD)
- Server returns HTTP response code of 400 with ALTO error code
of E_JSON_FIELD_MISSING (c.f., Table 1).
9) Error: Unexpected JSON value (Section 7)
- Client sends a request with a JSON value of unexpected type
(details TBD)
- Server returns HTTP response code of 400 with ALTO error code
of E_JSON_VALUE_TYPE (c.f., Table 1).
10) Error: Invalid JSON cost mode (Section 7)
- Client sends a request with a cost mode of 'foo'
- Server returns HTTP response code of 400 with ALTO error code
of E_JSON_COST_MODE (c.f., Table 1).
11) Error: Invalid JSON cost type (Section 7)
- Client sends a request with a cost type of 'foo'
- Server returns HTTP response code of 400 with ALTO error code
of E_JSON_COST_TYPE (c.f., Table 1).
12) Error: Invalid JSON property type (Section 7)
- Client sends a request with an invalid property type (details TBD)
- Server returns HTTP response code of 400 with ALTO error code
of E_JSON_PROPERTY_TYPE (c.f., Table 1).
13) Error: multiple errors in request (Section 7)
- Client sends a request with a missing required field and an
invalid cost mode ('foo')
- Server should detect at least one error and return that in a
response. The server chooses which error to report.
Question: If the server is capable of detecting and reporting
multiple errors, then what? How does it let the client know?
14) Error: send a request with a bad URI
- Client sends the following request:
GET /foo/bar HTTP/1.1
...
- Server responds with:
(TBD)
15) Change in network map (Section 5.3)
- Add a new network, changing the map. For example, add the
following subnet 201.1.2.0/24 to peeringpid2 giving the new
network map entry for peeringpid2 as follows:
peeringpid2 130.0.0.0/16, 201.1.2.0/24
- Have a client retrieve the new network map.
- The Version tag on the network map should be different than the
one retrieved in Test Case 5.
16) Filtered network map (Section 7.7.3)
TBD
17) Filtered cost map (Section 7.7.3.2, Section 7.7.2.2)
TBD
18) Endpoint cost service (Section 7.7.5)
TBD
19) IPv6 test cases
(TBD)
Miscellaneous notes
1) Section 4.2.1 says that "Each endpoint MUST map into exactly one
PID."
What happens if a client finds out that the above is not true?
---- END ALTO INTEROPERABILITY DOCUMENT (Version 0.1)
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
