[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

ALTO WG                                                         J. Zhang
Internet-Draft                                         Tongji University
Intended status: Standards Track                                  K. Gao
Expires: June 16, 2018                               Tsinghua University
                                                                 J. Wang
                                                       Tongji University
                                                                Q. Xiang
                                                  Tongji/Yale University
                                                                 Y. Yang
                                                         Yale University
                                                       December 13, 2017


                 ALTO Extension: Flow-based Cost Query
                       draft-gao-alto-fcs-04.txt

Abstract

   The ALTO cost query service maps a source-destination pair into a
   cost value, which provides a network view abstract based on a subset
   of the 2-dimension address space.  Given that the emergence of new
   networking optimization requirements, such a query space is not
   sufficient to uniquely identify a flow.  To address the limitations
   of the network information query space provided by the legacy ALTO
   protocol, this document introduces two extensions: extending the
   existing ALTO cost query services with fine-grained semantics, and
   enabling a new flow-based query service named Flow Cost Service.
   These extensions move ALTO to a more flexible and expressive network
   information query space.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Zhang, et al.             Expires June 16, 2018                 [Page 1]


Internet-Draft              Flow Cost Service              December 2017


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 16, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview of Approaches  . . . . . . . . . . . . . . . . . . .   5
     3.1.  Flexible Flow-based Filter  . . . . . . . . . . . . . . .   5
     3.2.  Extended Endpoint Address . . . . . . . . . . . . . . . .   5
     3.3.  Mapping Flow Attributes to Cost . . . . . . . . . . . . .   5
   4.  Changes Since Version -01 . . . . . . . . . . . . . . . . . .   6
   5.  ALTO Flow Cost Specification: Basic Flow-based Query  . . . .   6
     5.1.  Flow-based Filtered Cost Map  . . . . . . . . . . . . . .   7
       5.1.1.  Capabilities  . . . . . . . . . . . . . . . . . . . .   7
       5.1.2.  Accept Input Parameters . . . . . . . . . . . . . . .   7
       5.1.3.  Response  . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Extended Endpoint Address Encoding  . . . . . . . . . . .   8
       5.2.1.  Address Type  . . . . . . . . . . . . . . . . . . . .   8
       5.2.2.  Address Type Conflict . . . . . . . . . . . . . . . .   9
       5.2.3.  Endpoint Address  . . . . . . . . . . . . . . . . . .   9
       5.2.4.  Extended Endpoint Address Examples  . . . . . . . . .  10
     5.3.  Flow-based Endpoint Cost Service  . . . . . . . . . . . .  10
       5.3.1.  Capabilities  . . . . . . . . . . . . . . . . . . . .  10
       5.3.2.  Accept Input Parameters . . . . . . . . . . . . . . .  11
       5.3.3.  Response  . . . . . . . . . . . . . . . . . . . . . .  11
   6.  ALTO Flow Cost Specification: Advanced Flow-based Query . . .  11
     6.1.  Basic Data Types  . . . . . . . . . . . . . . . . . . . .  12
       6.1.1.  Flow ID . . . . . . . . . . . . . . . . . . . . . . .  12
       6.1.2.  Typed Header Field  . . . . . . . . . . . . . . . . .  12
     6.2.  Flow Cost Service . . . . . . . . . . . . . . . . . . . .  12



Zhang, et al.             Expires June 16, 2018                 [Page 2]


Internet-Draft              Flow Cost Service              December 2017


       6.2.1.  Media Type  . . . . . . . . . . . . . . . . . . . . .  12
       6.2.2.  HTTP Method . . . . . . . . . . . . . . . . . . . . .  12
       6.2.3.  Accept Input Parameters . . . . . . . . . . . . . . .  12
       6.2.4.  Capabilities  . . . . . . . . . . . . . . . . . . . .  13
       6.2.5.  Response  . . . . . . . . . . . . . . . . . . . . . .  14
       6.2.6.  Errors  . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  Information Resource Directory  . . . . . . . . . . . . .  16
     7.2.  Flow-based Filtered Cost Map Service Example  . . . . . .  17
     7.3.  Flow-based Endpoint Cost Service Example  . . . . . . . .  18
     7.4.  Flow Cost Service Example #1  . . . . . . . . . . . . . .  19
     7.5.  Flow Cost Service Example #2  . . . . . . . . . . . . . .  21
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
     9.1.  ALTO Address Type Registry  . . . . . . . . . . . . . . .  22
     9.2.  ALTO Address Type Conflict Registry . . . . . . . . . . .  23
     9.3.  Media Types . . . . . . . . . . . . . . . . . . . . . . .  24
     9.4.  Header Field  . . . . . . . . . . . . . . . . . . . . . .  25
   10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  25
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     11.2.  Informative References . . . . . . . . . . . . . . . . .  26
   Appendix A.  Tables . . . . . . . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

1.  Introduction

   An ALTO cost query service (Filtered Cost Map or Endpoint Cost
   Service) can be regarded as a function transforming a given subset of
   a specific query space into a network view abstract.  For the legacy
   ALTO protocol defined in [RFC7285], the query space is the
   2-dimension address space where each flow can be uniquely identified
   using a source-destination pair.  ALTO clients can send a query with
   source-destination pairs to an ALTO server and receive a view
   containing the end-to-end cost for each pair.

   Such a query schema might be sufficient for peer-to-peer (P2P)
   applications to determine the preferred peer selection in a
   traditional network.  However, as networks are becoming more and more
   flexible in the coming networking evolution, the limited 2-dimension
   address space is no longer sufficient as the query space to end-to-
   end connections.  To make ALTO servers provide more accurate and
   efficient network information, the following additional requirements
   must be considered:

   Req. FAR-1:  ALTO servers SHOULD provide a view for a more flexible
      flow set query space.




Zhang, et al.             Expires June 16, 2018                 [Page 3]


Internet-Draft              Flow Cost Service              December 2017


      New network architectures such as Software Defined Networking
      (SDN) collect a global network view that enables more complex
      control functions, e.g., access control list, flow-level traffic
      scheduling, etc.  In order to adapt to such architectures, ALTO
      servers need to support flow space queries.

   Req. FAR-2:  ALTO servers SHOULD provide a view for a more expressive
      flow attributes space.

      With the emerging data plane technologies, multiple header fields
      can be used to determine the forwarding path.  As a consequence,
      networks are moving to more flexible routing mechanisms beyond the
      simple destination-based routing.  Thus, the source-destination
      query space is no longer sufficient to provide accurate cost
      information.  ALTO servers need to support queries of network
      information in an extended packet header space.

   This document addresses the following issues in providing fine-
   grained flow-based cost query services in a more flexible query
   space: (1) the compatibility with the legacy ALTO services; (2) the
   support for fine-grained routing system; and (3) the redundancy
   trade-off between query and response.

   In this document, we describe two extensions of ALTO to provide the
   flow-based cost query.  The rest of this document is organized as
   follows.  Section 5 describes the extended schema on Filtered Cost
   Map (FCM) and Endpoint Cost Service (ECS) to support cost queries of
   arbitrary source-destination combinations.  For networks using a more
   generic flow concept such as Software-Defined Networks, Section 6
   defines a new ALTO service called Flow Cost Service (FCS), which
   supports the cost query of the flow-based routing.  Section 8 and
   Section 9 discuss security and IANA considerations.

2.  Terminology

   This document uses the same terms as defined in [RFC7285] and
   [RFC8189] with the following additional terms:

   o  Protocol: In this document, a protocol means a network protocol in
      the OSI model.

   o  Application-layer protocol: In this document, an application-layer
      protocol indicates a network protocol above layer 4 in the OSI
      model.

   o  Port: A port means a valid TCP or UDP port number in this
      document.




Zhang, et al.             Expires June 16, 2018                 [Page 4]


Internet-Draft              Flow Cost Service              December 2017


   o  Flow: A flow indicates a set of packets with similar attributes.
      A typical definition of a flow is by a 5-tuple (protocol, source/
      destination addresses and ports).  In this document, a flow MAY be
      a set of packets matching a given packet header pattern.

3.  Overview of Approaches

   This section presents a non-normative overview of flow-based cost
   query extensions.  It assumes the readers are familiar with Filtered
   Cost Map and Endpoint Cost Service defined in [RFC7285] and their
   extensions defined in [RFC8189].

3.1.  Flexible Flow-based Filter

   The legacy ALTO server based on [RFC7285] can provide two types of
   flow cost query services: Filtered Cost Map and Endpoint Cost
   Service.  But both of them only support the query space in the mesh
   shape.  It can not satisfy the requirement of providing the view for
   the flexible flow set query space.

   This document extends the filter schema of Filtered Cost Map and
   Endpoint Cost Service.  The extended filter allows ALTO clients to
   send multiple source-destination cross products in the same query.
   In this way, the ALTO client can query any combinations of flow sets.
   Also, the responses of such extended services are backward compatible
   with legacy ALTO services.

3.2.  Extended Endpoint Address

   In order to support the requirement of providing the view for the
   expressive packet header space, this document defines more types of
   endpoint addresses to represent a flow.  These extended address types
   indicate the protocol information of flows besides encoding formats
   of endpoint addresses.

   Since the address types of both the source and the destination
   specify a flow protocol, they MUST NOT conflict.  This document
   defines an address type dependency table to identify conflicts.  If
   the source and destination address types are different but do no
   conflict, ALTO servers MUST specify the more accurate one as the flow
   protocol.

3.3.  Mapping Flow Attributes to Cost

   In the emerging software-defined networks, the network control tends
   to be based on more fine-grained flow attributes.  Some advanced
   requirements, such as the cost query for flows with endpoint-
   independent attributes, are proposed by such use cases.  However,



Zhang, et al.             Expires June 16, 2018                 [Page 5]


Internet-Draft              Flow Cost Service              December 2017


   those requirements cannot be fulfilled by the extension above.  To
   support the flow-based cost query in more flexible network
   information space, this document defines Flow Cost Service, which
   enables ALTO clients to customize flows by specifying OpenFlow packet
   header match fields.

4.  Changes Since Version -01

   Note to Editor: Please remove this section prior to publication.

   This section records the change logs of the draft updates.

   o  Remove some irrelevant content from the draft.

   o  Improve the description of the new endpoint address type
      identifier registry.  And add a new registry to declare the
      conflicting address type identifiers.

   Changes since older versions:

   Since -03 revision:

   o  Change "EndpointURI" to "AddressType::EndpointAddr" for
      consistency.

   o  Replace Cost Confidence by Cost Statistics for compatibility.

   Since -02 revision:

   o  Define the basic flow-based query extensions for Filtered Cost Map
      and Endpoint Cost service.  The basic flow-based query is downward
      compatible with the legacy ALTO service.  It does not introduce
      any new media types.

   o  Move the service of media-type application/alto-flowcost+json to
      the advanced flow-based query extension.  It will ask ALTO server
      to support the new media type.

   Since -01 revision:

   o  Change the schema of pid-flows and endpoint-flows fields from pair
      list to pair mesh list.

5.  ALTO Flow Cost Specification: Basic Flow-based Query

   This section describes backward compatible extensions for Filtered
   Cost Map and Endpoint Cost Service to support flow-based query.




Zhang, et al.             Expires June 16, 2018                 [Page 6]


Internet-Draft              Flow Cost Service              December 2017


5.1.  Flow-based Filtered Cost Map

5.1.1.  Capabilities

   The Filtered Cost Map capabilities are extended with a new member:
   flow-based-filter.

   The capability flow-based-filter indicates whether this resource
   supports flow-based query.  The FilteredCostMapCapabilities object in
   Section 4.1.1 of [RFC8189] is extended as follows:

       object {
         JSONString cost-type-names<1..*>;
         [JSONBool cost-constraints;]
         [JSONNumber max-cost-types;]
         [JSONString testable-cost-type-names<1..*>;]
         [JSONBool flow-based-filter;]
       } FilteredCostMapCapabilities;

   cost-type-names and cost-constraints:  As defined in Section 11.3.2.4
      of [RFC7285].

   max-cost-types and testable-cost-type-names:  As defined in
      Section 4.1.1 of [RFC8189].

   flow-based-filter:  If true, a ALTO Server allows pid-flows to be
      included in the requests.  If not present, this field MUST be
      interpreted as if it is specified false.

5.1.2.  Accept Input Parameters

   The ReqFilteredCostMap object in Section 4.1.2 of [RFC8189] is
   extended as follows:

       object {
         [CostType cost-type;]
         [CostType multi-cost-types<1..*>;]
         [CostType testable-cost-types<1..*>;]
         [JSONString constraints<0..*>;]
         [JSONString or-constraints<1..*><1..*>;]
         [PIDFilter  pids;]
         [PIDFilter  pid-flows<1..*>;]
       } ReqFilteredCostMap;

   cost-type, multi-cost-types, testable-cost-types, constraints, or-
   constraints: As defined in Section 4.1.2 of <RFC8189>.

   pids:  As defined in Section 11.3.2.3 of [RFC7285].



Zhang, et al.             Expires June 16, 2018                 [Page 7]


Internet-Draft              Flow Cost Service              December 2017


   pid-flows:  Defined as a list of PIDFilter objects defined in
      Section 11.3.2.3 of [RFC7285].  The ALTO server MUST interpret PID
      pairs appearing in all objects multiple times as if they appeared
      only once.  An ALTO client MUST include either pids or pid-flows
      in a query but MUST NOT include them both at the same time.

5.1.3.  Response

   The response is the same as defined in Section 4.1.3 of [RFC8189].

5.2.  Extended Endpoint Address Encoding

   This section extends the encoding format of endpoint addresses,
   TypedEndpointAddr, which is defined in Section 10.4 of [RFC7285].
   The type TypedEndpointAddr is made up of two components: AddressType
   and EndpointAddr.  [RFC7285] only defines two address types, ipv4 and
   ipv6", which represent IPv4 and IPv6 addresses respectively.
   However, the flow-based ECS requires a more expressive endpoint
   address encoding, which means more address types are required.  This
   document registers new address types and defines new formats of
   endpoint addresses to support flow-based ECS query.

5.2.1.  Address Type

   This document defines new AddressType identifiers as follows:

   eth:  Indicates the ethernet interface of the host, which refers to
      the Media-Access-Control (MAC) address.

   domain:  Indicates the host located by the domain name, which refers
      to the the host name which can be translated to the IPv4 address.

   domain6:  Indicates the host located by the domain name, which refers
      to the the host name which can be translated to the IPv6 address.

   tcp:  Indicates the application working on TCP on IPv4, which refers
      to the IPv4 address or the host name which can be translated to
      the IPv4 address with the tcp port.

   tcp6:  Indicates the application working on TCP on IPv6, which refers
      to the IPv6 address or the host name which can be translated to
      the IPv6 address with the tcp port.

   udp:  Indicates the application working on UDP on IPv4, which refers
      to the IPv4 address or the host name which can be translated to
      the IPv4 address with the tcp port.





Zhang, et al.             Expires June 16, 2018                 [Page 8]


Internet-Draft              Flow Cost Service              December 2017


   udp6:  Indicates the application working on UDP on IPv4, which refers
      to the IPv4 address or the host name which can be translated to
      the IPv4 address with the tcp port.

   See Table 1 in Section 9.1 for a list of new AddressType identifiers
   to be registered in the ALTO Address Type Registry.

5.2.2.  Address Type Conflict

   Different AddressTypes MAY conflict with each others.  For example, a
   source endpoint of an "ipv4" address cannot establish a network
   connection with a destination endpoint of an "ipv6" address.  Neither
   the "tcp" typed source and the "udp" typed destination.  It means the
   conflicting AddressType identifiers MUST NOT appear in associated
   source and destination endpoint addresses.  So every new registered
   ALTO AddressType identifier MUST indicate its conflicts with existing
   address types in the ALTO Address Type Registry.

   The AddressType identifier conflicts defined in this document are
   listed in Section 9.2.

5.2.3.  Endpoint Address

   This document defines new formats of EndpointAddr as follows for the
   new AddressType registered in Section 9.1.

5.2.3.1.  MAC Address

   When AddressType is eth, the EndpointAddr MUST be a MAC address,
   which are encoded as specified by one of format EUI-48 in [EUI48] and
   EUI-64 in [EUI64].

5.2.3.2.  Host Name

   Host names are encoded as specified in Section 11 of [RFC2181].

5.2.3.3.  Address with Port

   When AddressType is a layer 4 or application-layer protocol, the
   EndpointAddr MUST be one of an IPv4/IPv6 address, a host name or an
   address with port.  An address with port is encoded as a string of
   the format Addr:Port, with the : character as a separator.  The Addr
   component of EndpointAddr MUST be an IPv4/IPv6 address or a host
   name.  The Port component of EndpointAddr MUST be an integer between
   1 and 65535.  If the Addr component of EndpontAddr is an IPv6
   address, the address MUST be enclosed in [" and "] characters, as
   recommended in [RFC2732].




Zhang, et al.             Expires June 16, 2018                 [Page 9]


Internet-Draft              Flow Cost Service              December 2017


   When AddressType is an application-layer protocol and the
   EndpointAddr is not an address with port, ALTO servers MUST use the
   default port.  The default ports of some well-known AddressType
   identifiers are defined in Table 1 in Section 9.1.

5.2.4.  Extended Endpoint Address Examples

   Some valid endpoint addresses based on the above extension look like
   follows:

       "eth:98-e0-d9-9c-df-81"
       "domain:www.example.com"
       "tcp:198.51.100.34:5123"
       "udp6:[2000::1:2345:6789:abcd]:8080"

5.3.  Flow-based Endpoint Cost Service

5.3.1.  Capabilities

   The extensions of EndpointCostCapabilities are based on
   FilteredCostMapCapabilities in Section 5.1.1 but with a new member:
   protocols.

   The capability address-types indicates which endpoint address types
   are supported to be queried by this resource.  For the capability
   flow-based-filter, the true value means the ALTO server allows
   requests to have endpoint-flows field.  If not present, this field
   MUST be interpreted as if it is specified false.

       object {
         [JSONString  address-types<0..*>;]
         [JSONBool    flow-based-filter;]
       } EndpointCostCapabilities : FilteredCostMapCapabilities;

   address-types:  Defines a list of JSONString indicating the supported
      AddressType identifiers of TypedEndpointAddr in the request.  All
      the AddressType identifiers MUST be registered in the ALTO Address
      Type Registry (see Section 14.4 of [RFC7285]).  The ALTO server
      SHOULD NOT claim ipv4 and ipv6 in this field explicitly, because
      they are supported by default.  If not present, this field MUST be
      interpreted as if it specifies the default supported AddressType
      ipv4 and ipv6.

   flow-based-filter:  If true, the ALTO Server allows endpoint-flows to
      be queried in the requests.  If not present, this field MUST be
      interpreted as if it is specified false.





Zhang, et al.             Expires June 16, 2018                [Page 10]


Internet-Draft              Flow Cost Service              December 2017


5.3.2.  Accept Input Parameters

   The ReqEndpointCostMap object in Section 4.2.2 of [RFC8189] is
   extended as follows:

       object {
         [CostType cost-type;]
         [CostType multi-cost-types<1..*>;]
         [CostType testable-cost-types<1..*>;]
         [JSONString constraints<0..*>;]
         [JSONString or-constraints<1..*><1..*>;]
         [EndpointFilter endpoints;]
         [EndpointFilter endpoint-flows<1..*>;]
       } ReqEndpointCostMap;

   cost-type, multi-cost-types, testable-cost-types, constraints, or-
   constraints:
      As defined in Section 4.1.2 of [RFC8189].

   endpoints:  As defined in Section 11.5.1.3 of [RFC7285].

   endpoint-flows:  Defined as a list of EndpointFilter objects in which
      each object is as defined in Section 11.5.1.3 of [RFC7285].  The
      ALTO server MUST interpret endpoint pairs appearing multiple times
      in all EndpointFilter objects as if they appeared only once.

   If the AddressType of the source and destination in the same
   EndpointFilter do not conform the dependencies defined in Table 1 of
   Section 9.1, the ALTO server MUST return an ALTO error response with
   the error code "E_INVALID_FIELD_VALUE".

   The additional requirement is that the ALTO client MUST specify
   either endpoints or endpoint-flows, but MUST NOT specify both.

5.3.3.  Response

   The response is the same as defined in Section 4.2.3 of [RFC8189].

6.  ALTO Flow Cost Specification: Advanced Flow-based Query

   The basic flow-based query extends the ECS service to support
   querying the cost of flows.  However, it only supports the cost query
   of flows defined by the 5-tuple of protocol, source/destination
   address (host name, IP address or MAC address) and ports.  In the
   emerging software-defined networking, the concept of flow is not
   confined by this 5-tuple anymore.  Instead, [OF15] has defined 38
   header match fields that could define a flow.  This document next
   introduces an advanced flow-based cost query service, which is called



Zhang, et al.             Expires June 16, 2018                [Page 11]


Internet-Draft              Flow Cost Service              December 2017


   Flow Cost Service, to support the flow-based cost queries for such a
   generic context of flows.

6.1.  Basic Data Types

   The Flow Cost Service introduces some new basic data types, as
   defined below.

6.1.1.  Flow ID

   A flow ID has the same format as a PIDName, as defined in
   Section 10.1 of [RFC7285].  It is used to uniquely identify a flow in
   a flow cost service request.

6.1.2.  Typed Header Field

   A typed header field represents a particular field in a network
   protocol that can be obtained at the application layer.  It is
   represented by the protocol name and the field name, concatenated by
   the colon (:, U+003A).  The typed header fields are case insensitive.
   For example, "ipv4:source" and "IPv4:source" both represent the
   source address field used in IPv4 and "tcp:destination" represents
   the destination port for a TCP connection.

   See Table 4 for a list of proposed typed header fields.

6.2.  Flow Cost Service

   The Flow Cost Service provides cost information for each individual
   flow specified in a request.

6.2.1.  Media Type

   The media type of the flow cost service is "application/alto-
   flowcost+json".

6.2.2.  HTTP Method

   The flow cost service is requested using the HTTP POST method.

6.2.3.  Accept Input Parameters

   The input parameters of the flow cost service MUST be encoded as a
   JSON object of type FlowCostRequest in the body of an HTTP POST
   request.  The media type of the request MUST be application/alto-
   flowcostparams+json.





Zhang, et al.             Expires June 16, 2018                [Page 12]


Internet-Draft              Flow Cost Service              December 2017


       object {
         FlowFilterMap     flows;
       } FlowCostRequest : MultiCostRequestBase;

       object {
         [CostType         cost-type;]
         [CostType         multi-cost-types<1..*>;]
         [CostType         testable-cost-types<1..*>;]
         [JSONString       constraints<0..*>;]
         [JSONString       or-constraints<0..*><0..*>;]
       } MultiCostRequestBase;

       object-map {
         FlowId -> FlowFilter;
       } FlowFilterMap;

       object-map {
         TypedHeaderField -> JSONValue;
       } FlowFilter;

   flows:  A map of flow filters for which path costs are to be
      returned.  Each flow filter is identified by a unique FlowId, as
      defined in Section 6.1.1.  The value type of a field is protocol-
      specific, see Table 5 for the value type associated with typed
      header fields in Table 4.

   cost-type:  The same as defined in Section 4.2.2 of [RFC8189].

   multi-cost-types:  The same as defined in Section 4.2.2 of [RFC8189].

   testable-cost-types, constraints, or-constraints:  The same as
      defined in Section 4.2.2 of [RFC8189].

6.2.4.  Capabilities

   The capabilities of the flow cost service is a JSON object of type
   FlowCostCapabilities:

       object {
         [TypedHeaderField  required<1..*>;]
         [TypedHeaderField  or-required<1..*><1..*>;]
         [TypedHeaderField optional<1..*>;]
       } FlowCostCapabilities :  FilteredCostMapCapabilities;

   with fields:

   required:  A list of required TypedHeaderFields.  These
      TypedHeaderFields are essential to find the path cost for a given



Zhang, et al.             Expires June 16, 2018                [Page 13]


Internet-Draft              Flow Cost Service              December 2017


      flow and MUST be provided in a flow filter.  The "required" field
      MUST be present if "or-required" field is not present.

   or-required:  A list of TypedHeaderField list, where each
      TypedHeaderField list defines a combination of required
      TypedHeaderFields.  The "or-required" field claims that at least
      one of the combination in this list MUST be provided in a flow
      filter.  As an example, a valid "or-requried" field value is
      [[ipv4:source, ipv4:destination], [ipv6:source,
      ipv6:destination]].  This is equivalent to the validation: For
      each flow, assert (ipv4:source in flow AND ipv4:destination in
      flow) OR (ipv6:soruce in flow AND ipv6:destination in flow).  This
      field MUST be present if "required" field is not present.

   optional:  A list of optional TypedHeaderFields.  The ALTO server MAY
      leverage the values of the optional TypedHeaderFields to find more
      accurate costs.

6.2.5.  Response

   The "meta" field of a flow cost response MUST contain the same cost
   type information as defined in Section 4.2.3 of [RFC8189].

   The data component of a flow cost service is named "flow-cost-map",
   which is a JSON object of type FlowCostMap:

       object {
         FlowCostMap     flow-cost-map;
       } FlowCostResponse : ResponseEntityBase;

       object-map {
         FlowId -> JSONValue;
       } FlowCostMap;

   flow-cost-map:  A dictionary map with each key (flow ID) representing
      a flow specified in the request.  For each flow, the cost MUST
      follow the format defined in Section 4.2.3 of [RFC8189].

6.2.6.  Errors

   The ALTO servers can provide more information to the clients when
   requests have errors.  The FlowCostErrorMap below can provide basic
   information about three most common errors for the flow cost service.
   The ALTO servers MAY include it as the data component of an ALTO
   error response.  If multiple errors are identified, the ALTO server
   MUST return exactly one error code according to Section 8.5.2 of
   [RFC7285] .




Zhang, et al.             Expires June 16, 2018                [Page 14]


Internet-Draft              Flow Cost Service              December 2017


       object-map {
         FlowId -> FlowCostError;
       } FlowCostErrorMap;

       object {
         [TypedHeaderField conflicts<2..*>;]
         [TypedHeaderField missing<1..*>;]
         [TypedHeaderField unsupported<1..*>;]
       } FlowFilterError;

   conflicts:  A list of conflicting typed header fields.  See
      Section 6.2.6.1 for details.

   missing:  A list of missing typed header fields.  See Section 6.2.6.2
      for details.

   unsupported:  A list of unsupported typed header fields.  See
      Section 6.2.6.3 for details.

6.2.6.1.  Conflicts

   Some header fields may have conflicts.  For example, IPv4 fields and
   IPv6 fields can never appear in the same packet, nor can TCP and UDP
   ports.  These header fields MUST not be included in the same flow
   filter.  Otherwise, the ALTO server MUST return an ALTO error
   response with the error code "E_INVALID_FIELD_VALUE".  As specified
   in Section 8.5.2 of [RFC7285], the ALTO server MAY include the
   "field" and the "value" in the "meta" field.  In this case, the ALTO
   server MUST use the flow ID as the "field" and the flow filter as the
   "value".  However, the RECOMMENDED approach is to use the
   FlowCostErrorMap, where the server can provide the conflicting typed
   header fields in the "conflicts" field of the FlowFilterError
   associated with the corresponding flow ID.

6.2.6.2.  Missing Fields

   The "E_MISSING_FIELD" error code is originally designed to report the
   absence of required JSON fields.  In the flow cost service, the
   required typed header fields are implementation-specific and the ALTO
   servers MUST declare the required fields in the capabilities.  If any
   required header field is missing, the ALTO server MUST return an ALTO
   error response, with the error code "E_MISSING_FIELD".  The ALTO
   server can follow the steps defined in Section 8.5.2 of [RFC7285] to
   indicate the location of the missing field.  An alternative approach
   which is also RECOMMENDED, is that the server provides the missing
   typed header fields in the "missing" field of the FlowFilterError
   associated with the corresponding flow ID.




Zhang, et al.             Expires June 16, 2018                [Page 15]


Internet-Draft              Flow Cost Service              December 2017


6.2.6.3.  Unsupported Fields

   If a query contains unsupported typed header fields, e.g., those not
   in the "required" nor the "optional" capabilities, the ALTO server
   MUST return an ALTO error response, with the error code
   "E_INVALID_FIELD_VALUE".  Like how the conflicting header fields are
   handled in Section 6.2.6.1, the ALTO servers can report unsupported
   typed header fields in the "unsupported" field associated with the
   corresponding flow ID.

7.  Examples

7.1.  Information Resource Directory

   GET /directory HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-directory+json,application/alto-error+json

   HTTP/1.1 200 OK
   Content-Length: [TODO]
   Content-Type: application/alto-directory+json
   {
     "meta" : {
      "default-alto-network-map" : "my-default-network-map",
      "cost-types" : {
        "num-routingcost" : {
          "cost-mode" : "numerial",
          "cost-metric" : "routingcost"},
        "ord-routingcost" : {
          "cost-mode" : "ordinal",
          "cost-metric" : "routingcost"}
      },
       .....
       Other ALTO cost types as described in RFC7285
       .....
     },
     "resources" : {
       "my-default-network-map" : {
         "uri" : "http://alto.example.com/networkmap",
         "media-type" : "application/alto-networkmap+json"
       },
       "basic-flow-based-cost-map" : {
         "uri" : "http://alto.example.com/costmap/multi/filtered",
         "media-type" : "application/alto-costmap+json",
         "accepts" : "application/alto-costmapfilter+json",
         "uses" : [ "my-default-network-map" ],
         "capabilities" : {
           "max-cost-types" : 2,



Zhang, et al.             Expires June 16, 2018                [Page 16]


Internet-Draft              Flow Cost Service              December 2017


           "flow-based-filter" : true,
           "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ]
         }
       },
       "basic-flow-based-endpoint-cost" : {
         "uri" : "http://alto.example.com/endpointcost/lookup",
         "media-type" : "application/alto-endpointcost+json",
         "accepts" : "application/alto-endpointcostparams+json",
         "capabilities" : {
           "protocols": ["tcp", "http"],
           "flow-based-filter" : true,
           "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ]
         }
       },
       "flow-cost-map": {
         "uri" : "http://alto.example.com/flowcost/lookup",
         "media-type" : "application/alto-flowcost+json",
         "accepts" : "application/alto-flowcostparams+json",
         "capabilities" : {
           "or-required" : [ [ "ethernet:destination" ],
                             [ "ipv4:destination" ] ],
           "optional" : [ "ethernet:source", "ethernet:destination",
                          "ipv4:source", "ipv4:destination",
                          "tcp:source", "tcp:destination"]
         }
       }
     }
   }

7.2.  Flow-based Filtered Cost Map Service Example





















Zhang, et al.             Expires June 16, 2018                [Page 17]


Internet-Draft              Flow Cost Service              December 2017


     POST /costmap/multi/filtered HTTP/1.1
     Host: alto.example.com
     Accept: application/alto-costmap+json,application/alto-error+json
     Content-Length: [TBD]
     Content-Type: application/alto-costmapfilter+json

     {
       "cost-type": {
         "cost-mode": "numerical",
         "cost-metric": "routingcost"
       },
       "pid-flows": [
         { "srcs": ["PID1"], "dsts": ["PID2", "PID3"] },
         { "srcs": ["PID3"], "dsts": ["PID4"] }
       ]
     }

     HTTP/1.1 200 OK
     Content-Length: [TBD]
     Content-Type: application/alto-costmap+json

     {
       "meta": {
         "dependent-vtags": [
           {
             "resource-id": "my-default-network-map",
             "tag": "75ed013b3cb58f896e839582504f622838ce670f"
           }
         ],
         "cost-type": {
           "cost-mode": "numerical",
           "cost-metric": "routingcost"
         }
       },
       "cost-map": {
         "PID1": { "PID2": 100 },
         "PID1": { "PID3": 20 },
         "PID3": { "PID4": 80 }
       }
     }

7.3.  Flow-based Endpoint Cost Service Example









Zhang, et al.             Expires June 16, 2018                [Page 18]


Internet-Draft              Flow Cost Service              December 2017


  POST /endpointcost/lookup HTTP/1.1
  Host: alto.example.com
  Accept: application/alto-endpointcost+json,application/alto-error+json
  Content-Length: [TBD]
  Content-Type: application/alto-endpointcostparams+json

  {
    "cost-type": {
      "cost-mode": "numerical",
      "cost-metric": "hopcount"
    },
    "endpoint-flows": [
      { "srcs": ["ipv4:192.0.2.2"],
        "dsts": ["ipv4:192.0.2.89", "http:cdn1.example.com"] },
      { "srcs": ["tcp:203.0.113.45:54321"],
        "dsts": ["http:cdn1.example.com"] }
    ]
  }


  HTTP/1.1 200 OK
  Content-Length: [TBD]
  Content-Type: application/alto-endpointcost+json

  {
    "meta": {
      "cost-type": {
        "cost-mode": "numerical",
        "cost-metric": "hopcount"
      }
    },
    "endpoint-cost-map": {
      "ipv4:192.0.2.2": {
        "ipv4:192.0.2.89": 3,
        "http:cdn1.example.com": 6
      },
      "tcp:203.0.113.45:54321": {
        "http:cdn1.example.com": 10
      }
    }
  }

7.4.  Flow Cost Service Example #1








Zhang, et al.             Expires June 16, 2018                [Page 19]


Internet-Draft              Flow Cost Service              December 2017


   POST /flowcost/lookup HTTP/1.1
   HOST: alto.example.com
   Content-Length: 521
   Content-Type: application/alto-flowcostparams+json
   Accept: application/alto-flowcost+json,application/alto-error+json

   {
     "cost-type": {
       "cost-mode": "numerical",
       "cost-metric": "routingcost"
     },
     "flows": {
       "l3-flow": {
         "ipv4:source": "192.168.1.1",
         "ipv4:destination": "192.168.1.2"
       },
       "optional-l2-flow": {
         "ethernet:source": "12:34:56:78:00:01",
         "ethernet:destination": "12:34:56:78:00:02"
       },
       "l3-flow-aggr": {
         "ipv4:source": "192.168.1.0/24",
         "ipv4:destination": "192.168.2.0/24"
       }
     }
   }

   HTTP/1.1 200 OK
   Content-Length: 312
   Content-Type: application/alto-flowcost+json

   {
     "meta": {
       "cost-type": {
         "cost-mode": "numerical",
         "cost-metric": "routingcost"
       }
     },
     "flow-cost-map": {
       "l3-flow": 10,
       "l3-flow-aggr": 50,
       "optional-l3-flow": 5
     }
   }







Zhang, et al.             Expires June 16, 2018                [Page 20]


Internet-Draft              Flow Cost Service              December 2017


7.5.  Flow Cost Service Example #2

   POST /flowcost/lookup HTTP/1.1
   HOST: alto.example.com
   Content-Length: 521
   Content-Type: application/alto-flowcostparams+json
   Accept: application/alto-flowcost+json,application/alto-error+json

   {
     "cost-type": {
       "cost-mode": "ordinal",
       "cost-metric": "hopcount"
     },
     "flows": {
       "missing-dest-flow": {
         "ipv4:source": "192.168.1.100"
       },
       "conflict-flow": {
         "ipv4:source": "192.168.1.101",
         "ipv6:destination": "2000::1:2345:6789:abcd"
       },
       "unsupported-flow": {
         "ipv4:source": "192.168.1.102",
         "ipv6:destination": "192.168.2.102",
         "ethernet:vlan-id": 1024
       }
     }
   }























Zhang, et al.             Expires June 16, 2018                [Page 21]


Internet-Draft              Flow Cost Service              December 2017


   HTTP/1.1 200 OK
   Content-Length: 312
   Content-Type: application/alto-error+json

   {
     "meta": {
       "code": "E_INVALID_FIELD_VALUE"
     }
     "flow-error-map": {
       "missing-dest-flow-flow": {
         "missing": ["ipv4:destination"]
       },
       "conflict-flow": {
         "conflicts": ["ipv4:source", "ipv6:destination"]
       },
       "unsupported-flow": {
         "unsupported": ["ethernet:vlan-id"]
       }
     }
   }

8.  Security Considerations

   An ALTO client can send flow-based queries to the Flow Cost Service.
   However, the ALTO server or a third party who is able to intercept
   such messages can store and process obtained information in order to
   analyze user behaviors and communication patterns, which has been
   discussed in Section 15.4 of [RFC7285].  Since the fine-grained flow-
   based query provides more information, an ALTO client should be
   cognizant about the trade-off between redundancy and privacy.

9.  IANA Considerations

   This document defines two new entries to be registered to
   application/alto-* media types.

9.1.  ALTO Address Type Registry

   This document defines several new address types to be registered to
   ALTO Address Type Registry, listed in Table 1.











Zhang, et al.             Expires June 16, 2018                [Page 22]


Internet-Draft              Flow Cost Service              December 2017


   +------------+--------------------+-------------+-------------------+
   | Identifier | Address Encoding   | Prefix      | Mapping to/from   |
   |            |                    | Encoding    | IPv4/v6           |
   +------------+--------------------+-------------+-------------------+
   | eth        | See                | None        | Mapping to/from   |
   |            | Section 5.2.3.1    |             | IPv4 by [RFC0903] |
   |            |                    |             | and [RFC0826];    |
   |            |                    |             | Mapping to/from   |
   |            |                    |             | IPv6 by [RFC3122] |
   |            |                    |             | and [RFC4861]     |
   | domain     | See                | None        | Mapping to/from   |
   |            | Section 5.2.3.2    |             | IPv4 by [RFC1034] |
   | domain6    | See                | None        | Mapping to/from   |
   |            | Section 5.2.3.2    |             | IPv6 by [RFC3596] |
   | tcp        | See                | None        | No mapping        |
   |            | Section 5.2.3.3    |             |                   |
   | tcp6       | See                | None        | No mapping        |
   |            | Section 5.2.3.3    |             |                   |
   | upd        | See                | None        | No mapping        |
   |            | Section 5.2.3.3    |             |                   |
   | udp6       | See                | None        | No mapping        |
   |            | Section 5.2.3.3    |             |                   |
   +------------+--------------------+-------------+-------------------+

                    Table 1: ALTO Address Type Registry

9.2.  ALTO Address Type Conflict Registry

   This document proposes to create a new registry called ALTO Address
   Type Conflict Registry.  The purpose of this registry is stated in
   Section 5.2.2.  The conflicts of all existing address type
   identifiers and new identifiers registered in this document are
   listed in Table 2.

                +-------------+--------------------------+
                | Identifier  | Conflicting Identifiers  |
                +-------------+--------------------------+
                | ipv6        | ipv4                     |
                | eth         | None                     |
                | domain      | ipv6                     |
                | domain6     | ipv4, domain             |
                | tcp         | ipv6, domain6            |
                | tcp6        | ipv4, domain, tcp        |
                | udp         | ipv6, domain6, tcp6      |
                | udp6        | ipv4, domain, tcp, udp   |
                +-------------+--------------------------+

               Table 2: ALTO Address Type Conflict Registry



Zhang, et al.             Expires June 16, 2018                [Page 23]


Internet-Draft              Flow Cost Service              December 2017


   Every address type identifier SHOULD only indicate its conflicts with
   the identifiers registered before it.  But the conflicts in this
   registry MUST be followed as the bidirectional.  For example,
   although "tcp" does not register "tcp6" as its conflicting
   identifier, the ALTO server MUST identify this conflict because of
   the registered conflicting identifiers of "tcp6".

   Any new ALTO address type identifier registered after this document
   MUST indicate their conflicting identifiers in this registry
   simultaneously.

9.3.  Media Types

   This document registers two media types listed in Table 3.

       +--------------+--------------------------+----------------+
       | Type         | Subtype                  | Specification  |
       +--------------+--------------------------+----------------+
       | application  | alto-flowcost+json       | Section 5.1.3  |
       | application  | alto-flowcostparam+json  | Section 5.3.2  |
       +--------------+--------------------------+----------------+

                       Table 3: ALTO FCS Media Types

   Type name:  application

   Subtype name:  This document registers two subtypes, as listed in
      Table 3.

   Required parameters:  n/a

   Optional parameters:  n/a

   Encoding considerations:  Encoding considerations are identical to
      those specified for the "applicatoin/json" media type.  See
      [RFC7159].

   Security considerations:  Security considerations are identical to
      those specified in Section 15 of [RFC7285].

   Interoperability considerations:  n/a

   Published specification:  This document is the specification for
      these media types.  See Table 3 for the section documenting each
      media type.






Zhang, et al.             Expires June 16, 2018                [Page 24]


Internet-Draft              Flow Cost Service              December 2017


   Applications that use this media type: ALTO servers and ALTO clients
   with the extension to support the flow cost service, either
   standalone or embedded within other applications.

   Additional information:  n/a

   Person & email address to contact for further information:  See
      Authors' Addresses.

   Intended usage:  COMMON

   Restrictions on usage:  n/a

   Author:  See Authors' Addresses.

9.4.  Header Field

   TBD: Create the "ALTO Header Field Name Registry".

10.  Acknowledgement

   The authors would like to thank Dawn Chen, Haizhou Du, Sabine
   Randriamasy and Wendy Roome for fruitful discussions and feedback on
   this document.  Shawn Lin provided substantial review feedback and
   suggestions to the protocol design.

11.  References

11.1.  Normative References

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              Converting Network Protocol Addresses to 48.bit Ethernet
              Address for Transmission on Ethernet Hardware", STD 37,
              RFC 826, DOI 10.17487/RFC0826, November 1982,
              <https://www.rfc-editor.org/info/rfc826>.

   [RFC0903]  Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
              Reverse Address Resolution Protocol", STD 38, RFC 903,
              DOI 10.17487/RFC0903, June 1984, <https://www.rfc-
              editor.org/info/rfc903>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.







Zhang, et al.             Expires June 16, 2018                [Page 25]


Internet-Draft              Flow Cost Service              December 2017


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
              <https://www.rfc-editor.org/info/rfc2181>.

   [RFC2732]  Hinden, R., Carpenter, B., and L. Masinter, "Format for
              Literal IPv6 Addresses in URL's", RFC 2732,
              DOI 10.17487/RFC2732, December 1999, <https://www.rfc-
              editor.org/info/rfc2732>.

   [RFC3122]  Conta, A., "Extensions to IPv6 Neighbor Discovery for
              Inverse Discovery Specification", RFC 3122,
              DOI 10.17487/RFC3122, June 2001, <https://www.rfc-
              editor.org/info/rfc3122>.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", STD 88,
              RFC 3596, DOI 10.17487/RFC3596, October 2003,
              <https://www.rfc-editor.org/info/rfc3596>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
              editor.org/info/rfc4861>.

11.2.  Informative References

   [EUI48]    IEEE, , "Guidelines for use of a 48-bit Extended Unique
              Identifier (EUI-48)", 2012,
              <http://standards.ieee.org/develop/regauth/tut/eui48.pdf>.

   [EUI64]    IEEE, , "Guidelines for use of a 64-bit Extended Unique
              Identifier (EUI-64)", November 2012,
              <http://standards.ieee.org/develop/regauth/tut/eui64.pdf>.








Zhang, et al.             Expires June 16, 2018                [Page 26]


Internet-Draft              Flow Cost Service              December 2017


   [OF15]     Foundation, O., "OpenFlow Switch Specification v1.5.0",
              2014,
              <https://www.opennetworking.org/images/stories/downloads/
              sdn-resources/onf-specifications/openflow/openflow-switch-
              v1.5.0.noipr.pdf>.

   [OPENFLOW]
              McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G.,
              Peterson, L., Rexford, J., Shenker, S., and J. Turner,
              "OpenFlow: enabling innovation in campus networks", 2008.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <https://www.rfc-editor.org/info/rfc7159>.

   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
              "Application-Layer Traffic Optimization (ALTO) Protocol",
              RFC 7285, DOI 10.17487/RFC7285, September 2014,
              <https://www.rfc-editor.org/info/rfc7285>.

   [RFC8189]  Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost
              Application-Layer Traffic Optimization (ALTO)", RFC 8189,
              DOI 10.17487/RFC8189, October 2017, <https://www.rfc-
              editor.org/info/rfc8189>.

Appendix A.  Tables

       +------------+--------------+------------------------------+
       | Protocol   | Field Name   | Description                  |
       +------------+--------------+------------------------------+
       | Ethernet   | source       | The source MAC address       |
       |            | destination  | The destination MAC address  |
       |            | vlan-id      | VLAN-ID from 802.1Q header   |
       | IPv4       | source       | IPv4 source address          |
       |            | destination  | IPv4 destination address     |
       | IPv6       | source       | IPv6 source address          |
       |            | destination  | IPv6 destination address     |
       | TCP        | source       | TCP source port              |
       |            | destination  | TCP destination port         |
       | UDP        | source       | UDP source port              |
       |            | destination  | UDP destination port         |
       +------------+--------------+------------------------------+

                    Table 4: Protocols and Field Names.






Zhang, et al.             Expires June 16, 2018                [Page 27]


Internet-Draft              Flow Cost Service              December 2017


   +-----------------------+-------------------------------------------+
   | Typed Header Field    | Acceptable Value Type                     |
   +-----------------------+-------------------------------------------+
   | ethernet:source       | JSONString as MAC address                 |
   | ethernet:destination  |                                           |
   | ethernet:vlan-id      | JSONNumber in the range of [1, 4094]      |
   | ipv4:source           | JSONString as IPv4 address or IPv4 prefix |
   | ipv4:destination      |                                           |
   | ipv6:source           | JSONString as IPv6 address or IPv6 prefix |
   | ipv6:destination      |                                           |
   | tcp:source            | JSONNumber in the range of [0, 65535]     |
   | tcp:destination       | 0 serves as a wildcard value              |
   | udp:source            |                                           |
   | udp:destination       |                                           |
   +-----------------------+-------------------------------------------+

               Table 5: Value Types for Typed Header Fields

Authors' Addresses

   Jingxuan Jensen Zhang
   Tongji University
   4800 Cao'an Hwy
   Shanghai  201804
   China

   Email: jingxuan.n.zhang@gmail.com


   Kai Gao
   Tsinghua University
   30 Shuangqinglu Street
   Beijing  100084
   China

   Email: gaok12@mails.tsinghua.edu.cn


   Junzhuo Austin Wang
   Tongji University
   4800 Cao'an Hwy, Jiading District
   Shanghai
   China

   Email: wangjunzhuo200@gmail.com






Zhang, et al.             Expires June 16, 2018                [Page 28]


Internet-Draft              Flow Cost Service              December 2017


   Qiao Xiang
   Tongji/Yale University
   51 Prospect Street
   New Haven, CT
   USA

   Email: qiao.xiang@cs.yale.edu


   Y. Richard Yang
   Yale University
   51 Prospect St
   New Haven  CT
   USA

   Email: yry@cs.yale.edu



































Zhang, et al.             Expires June 16, 2018                [Page 29]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/