interop, doc: add interop test descrption for api_listener, metadata_filter, forwarding_rule_port_match, forwarding_rule_default_port (#26289)

doc/xds-test-descriptions.md

@@ -621,3 +621,110 @@ There are four sub-tests:
       `rpc-behavior: sleep-4`.
    1. Test driver asserts client recieves ~100% status `OK` for EmptyCall
       and ~100% status `DEADLINE_EXCEEDED` for UnaryCall.
+
+### api_listener
+The test case verifies a specific use case where it creates a second TD API 
+listener using the same name as the existing one and then delete the old one. 
+The test driver verifies this is a safe way to update the API listener 
+configuration while keep using the existing name.
+
+Client parameters:
+
+1.  --num_channels=1
+1.  --qps=100
+
+Load balancer configuration:
+
+1.  One MIG with two backends.
+
+Assert:
+
+The test driver configuration steps:
+1. The test driver creates the first set of forwarding rule + target proxy + 
+URL map with a test host name.
+1. Then the test driver creates a second set of forwarding rule + target proxy + 
+URL map with the same test host name.
+1. The test driver deletes the first set of configurations in step 1.
+
+The test driver verifies, at each configuration step, the traffic is always able 
+to reach the designated hosts.
+
+### metadata_filter
+This test case verifies that metadata filter configurations in URL map match 
+rule are effective at Traffic Director for routing selection against downstream
+node metadata.
+
+Client parameters:
+
+1.  --num_channels=1
+1.  --qps=100
+
+Load balancer configuration:
+
+1.  Two MIGs in the same zone, each having two backends.
+
+There are four test sub-cases:
+1. Test `MATCH_ALL` metadata filter criteria.
+1. Test `MATCH_ANY` metadata filter criteria.
+1. Test mixed `MATCH_ALL` and `MATCH_ANY` metadata filter criteria.
+1. Test when multiple match rules with metadata filter all match.
+
+Assert:
+
+At each test sub-case described above, the test driver configures
+and verifies:
+
+1. Set default URL map, and verify traffic goes to the original backend hosts. 
+1. Then patch URL map to update the match rule with metadata filter 
+configuration under test added.
+1. Then it verifies traffic switches to alternate backend service hosts. 
+
+This way, we test that TD correctly evaluates both matching and non-matching 
+configuration scenario.
+
+### forwarding_rule_port_match
+This test verifies that request server uri port should match with the GCP 
+forwarding rule configuration port.
+
+Client parameters:
+
+1.  --num_channels=1
+1.  --qps=100
+
+Load balancer configuration:
+
+1.  One MIG with two backends.
+
+Assert:
+1. The test driver configures matching port in the forwarding rule and in the
+request server uri, then verifies traffic reaches backend service instances.
+1. The test driver updates the forwarding rule to use a different port, then 
+verifies that the traffic stops going to those backend service instances.
+
+### forwarding_rule_default_port
+This test verifies that omitting port in the request server uri should only 
+match with the default port(80) configuration in the forwarding rule. 
+In addition, request server uri port should exactly match that in the URL map 
+host rule, as described in 
+[public doc](https://cloud.google.com/traffic-director/docs/proxyless-overview#proxyless-url-map).
+
+Client parameters:
+
+1.  --num_channels=1
+1.  --qps=100
+
+Load balancer configuration:
+
+1.  One MIG with two backends.
+
+Assert:
+
+Test driver configures and verifies:
+1. No traffic goes to backends when configuring the target URI 
+`xds:///myservice`, the forwarding rule with port *x != 80*, the URL map 
+host rule `myservice::x`.
+1. Traffic goes to backends when configuring the target URI `xds:///myservice`, 
+the forwarding rule port `80` and the URL map host rule `myservice`.
+1. No traffic goes to backends when configuring the target URI
+`xds:///myservice`, the forwarding rule port `80` and the host rule 
+`myservice::80`.