draft-ietf-alto-unified-props-new-05.txt   draft-ietf-alto-unified-props-new-06.txt 
ALTO WG W. Roome ALTO WG W. Roome
Internet-Draft Nokia Bell Labs Internet-Draft Nokia Bell Labs
Intended status: Standards Track S. Chen Intended status: Standards Track S. Chen
Expires: June 13, 2019 Tongji University Expires: July 6, 2019 Tongji University
S. Randriamasy S. Randriamasy
Nokia Bell Labs Nokia Bell Labs
Y. Yang Y. Yang
Yale University Yale University
J. Zhang J. Zhang
Tongji University Tongji University
December 10, 2018 January 2, 2019
Unified Properties for the ALTO Protocol Unified Properties for the ALTO Protocol
draft-ietf-alto-unified-props-new-05 draft-ietf-alto-unified-props-new-06
Abstract Abstract
This document extends the Application-Layer Traffic Optimization This document extends the Application-Layer Traffic Optimization
(ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
properties" to domains of other entities, and by presenting those properties" to domains of other entities, and by presenting those
properties as maps, similar to the network and cost maps in ALTO. properties as maps, similar to the network and cost maps in ALTO.
Requirements Language Requirements Language
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2019. This Internet-Draft will expire on July 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Concepts . . . . . . . . . . . . . . . . . . 4 2. Definitions and Concepts . . . . . . . . . . . . . . . . . . 4
2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Entity Address . . . . . . . . . . . . . . . . . . . . . 5 2.4. Entity Address . . . . . . . . . . . . . . . . . . . . . 5
2.5. Property Name . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Property Type and Property Name . . . . . . . . . . . . . 6
2.6. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 6 2.6. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 7
2.7. Relationship with Other ALTO Resources . . . . . . . . . 6 2.7. Relationship with Other ALTO Resources . . . . . . . . . 7
3. Entity Domains . . . . . . . . . . . . . . . . . . . . . . . 7 3. Entity Domains . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Internet Address Domains . . . . . . . . . . . . . . . . 7 3.1. Internet Address Domains . . . . . . . . . . . . . . . . 8
3.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains . . . 8 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains . . . 8
3.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 10 3.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 10
3.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 10 3.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 10
3.2.4. Relationship To Internet Addresses Domains . . . . . 10 3.2.4. Relationship To Internet Addresses Domains . . . . . 10
3.3. Internet Address Properties vs. PID Properties . . . . . 10 3.3. Internet Address Properties vs. PID Properties . . . . . 10
4. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 11 4.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 11
4.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 13 5. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 13
5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 13 5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 13
5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14
5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 16 6. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 16
6.1. Impact on Endpoint Property Service . . . . . . . . . . . 16 6.1. Impact on Endpoint Property Service . . . . . . . . . . . 16
6.2. Impact on Resource-Specific Properties . . . . . . . . . 16 6.2. Impact on Resource-Specific Properties . . . . . . . . . 16
6.3. Impact on the pid Property . . . . . . . . . . . . . . . 16 6.3. Impact on the pid Property . . . . . . . . . . . . . . . 16
6.4. Impact on Other Properties . . . . . . . . . . . . . . . 17 6.4. Impact on Other Properties . . . . . . . . . . . . . . . 17
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Property Definitions . . . . . . . . . . . . . . . . . . 17 7.2. Property Definitions . . . . . . . . . . . . . . . . . . 17
7.3. Information Resource Directory (IRD) . . . . . . . . . . 18 7.3. Information Resource Directory (IRD) . . . . . . . . . . 18
7.4. Property Map Example . . . . . . . . . . . . . . . . . . 20 7.4. Property Map Example . . . . . . . . . . . . . . . . . . 20
7.5. Filtered Property Map Example #1 . . . . . . . . . . . . 21 7.5. Filtered Property Map Example #1 . . . . . . . . . . . . 21
7.6. Filtered Property Map Example #2 . . . . . . . . . . . . 21 7.6. Filtered Property Map Example #2 . . . . . . . . . . . . 22
7.7. Filtered Property Map Example #3 . . . . . . . . . . . . 22 7.7. Filtered Property Map Example #3 . . . . . . . . . . . . 23
7.8. Filtered Property Map Example #4 . . . . . . . . . . . . 23 7.8. Filtered Property Map Example #4 . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. application/alto-* Media Types . . . . . . . . . . . . . 25 9.1. application/alto-* Media Types . . . . . . . . . . . . . 26
9.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 26 9.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 27
9.2.1. Consistency Procedure between ALTO Address Type 9.2.1. Consistency Procedure between ALTO Address Type
Registry and ALTO Entity Domain Registry . . . . . . 27 Registry and ALTO Entity Domain Registry . . . . . . 27
9.2.2. ALTO Entity Domain Registration Process . . . . . . . 28 9.2.2. ALTO Entity Domain Registration Process . . . . . . . 29
9.3. ALTO Entity Property Type Registry . . . . . . . . . . . 29 9.3. ALTO Entity Property Type Registry . . . . . . . . . . . 30
10. Normative References . . . . . . . . . . . . . . . . . . . . 30 10. Normative References . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The ALTO protocol [RFC7285] introduces the concept of "properties" The ALTO protocol [RFC7285] introduces the concept of "properties"
attached to "endpoint addresses", and defines the Endpoint Property attached to "endpoint addresses", and defines the Endpoint Property
Service (EPS) to allow ALTO clients to retrieve those properties. Service (EPS) to allow ALTO clients to retrieve those properties.
While useful, the EPS, as defined in [RFC7285], has at least two While useful, the EPS, as defined in [RFC7285], has at least two
limitations. limitations.
First, it only allows properties to be associated with a particular First, it only allows properties to be associated with a particular
skipping to change at page 6, line 5 skipping to change at page 6, line 5
domain. Addresses MAY be hierarchical, and properties MAY be domain. Addresses MAY be hierarchical, and properties MAY be
inherited based on that hierarchy. Again, the rules defining any inherited based on that hierarchy. Again, the rules defining any
hierarchy or inheritance MUST be defined when the entity domain is hierarchy or inheritance MUST be defined when the entity domain is
registered. registered.
Note that an entity address MAY have different textual Note that an entity address MAY have different textual
representations, for a given entity domain. For example, the strings representations, for a given entity domain. For example, the strings
"ipv6:2001:db8::1" and "ipv6:2001:db8:0:0:0:0:0:1" refer to the same "ipv6:2001:db8::1" and "ipv6:2001:db8:0:0:0:0:0:1" refer to the same
entity. entity.
2.5. Property Name 2.5. Property Type and Property Name
The space of entity property names associated with entities defined Every entity in some domain MAY have one or more properties. Every
by this document is a superset of the endpoint property names defined property MUST have a unique Property Type.
by [RFC7285]. Thus endpoint property names registered with the "ALTO
Endpoint Property Type Registry" MUST be defined in Section 9.3 of
this document. The type PropertyName denotes a JSON string with a
property name in this format.
This document defines property names in the domain-specific context. This document defines property types in the domain-specific context.
This design is to enforce that each property name MUST be registered This design is to enforce that each property type MUST be registered
for every applicable entity domains individually. This design for a single specific entity domain. But multiple property types
decision is adopted because of the following considerations: with the similar semantics MAY share the same Property Name in
different entity domains. This design decision is adopted because of
the following considerations:
o Some properties may only be applicable for particular entity o Some properties may only be applicable for particular entity
domains, not all. For example, the "pid" property is not domains, not all. For example, the "pid" property is not
applicable for entities in the "pid" domain. applicable for entities in the "pid" domain.
o The interpretation of the value of a property may depend on the o The interpretation of the value of a property may depend on the
entity domain. For different entity domains, not only the entity domain. For different entity domains, not only the
intended semantics but also the dependent resource types may be intended semantics but also the dependent resource types may be
totally different. For example, suppose that the "geo-location" totally different. For example, suppose that the "geo-location"
property is defined as the coordinates of a point, encoded as property is defined as the coordinates of a point, encoded as
(say) "latitude longitude [altitude]." When applied to an entity (say) "latitude longitude [altitude]." When applied to an entity
that represents a specific host computer, such as an Internet that represents a specific host computer, such as an Internet
address, the property defines the host's location and has no address, the property defines the host's location and has no
required dependency. However, when applied to an entity in the required dependency. However, when applied to an entity in the
"pid" domain, the property would indicate the location of the "pid" domain, the property would indicate the location of the
center of all hosts in this "pid" entity and depend on a Network center of all hosts in this "pid" entity and depend on a Network
Map defining this "pid" entity. Map defining this "pid" entity.
To achieve this, each property type has a unique identifier encoded
as the following format:
PropertyType ::= DomainName : PropertyName
The "DomainName" indicates which entity domain the property type
applies to. The "PropertyName" SHOULD refer to the semantics of this
property type. It does not have to be global unique. In other
words, different property types could have the same property name
applied to different entity domains, if they have the similar
semantics. For example, the property types "ipv4:pid" and "ipv6:pid"
have the same property name "pid" applied to both "ipv4" and "ipv6"
domains.
Property types MUST be registered with the IANA, and the intended
semantics, as well as the media types of dependent resources and the
interpretation, MUST be specified at the same time.
2.6. Hierarchy and Inheritance 2.6. Hierarchy and Inheritance
Entities in a given domain MAY form a hierarchy based on entity Entities in a given domain MAY form a hierarchy based on entity
addresses, and introducing hierarchy allows the introduction of addresses, and introducing hierarchy allows the introduction of
inheritance. Each entity domain MUST define its own hierarchy and inheritance. Each entity domain MUST define its own hierarchy and
inheritance rules when registered. The hierarchy and inheritance inheritance rules when registered. The hierarchy and inheritance
rule makes it possible for an entity to inherit a property value from rule makes it possible for an entity to inherit a property value from
another entity in the same domain. another entity in the same domain.
2.7. Relationship with Other ALTO Resources 2.7. Relationship with Other ALTO Resources
skipping to change at page 11, line 31 skipping to change at page 11, line 48
The capabilities are defined by an object of type The capabilities are defined by an object of type
PropertyMapCapabilities: PropertyMapCapabilities:
object { object {
DomainName entity-domains<1..*>; DomainName entity-domains<1..*>;
PropertyName properties<1..*>; PropertyName properties<1..*>;
} PropertyMapCapabilities; } PropertyMapCapabilities;
where "entity-domains" is an array specifying the entity domains, and where "entity-domains" is an array specifying the entity domains, and
"properties" is an array specifying the names of the properties "properties" is an array specifying the property names returned for
returned for entities in those domains. The semantics is that each entities in those domains. The semantics is that each domain in
domain in "entity-domains" provides all properties defined in "entity-domains" provides all properties defined in "properties". If
"properties". If a property in "properties" is NOT supported by a a property in "properties" is NOT supported by a domain in "entity-
domain in "entity-domains", the server can declare different property domains", the server can declare different property maps to conform
maps to conform to the semantics. to the semantics.
4.5. Uses 4.5. Uses
The "uses" field of a property map resource in an IRD entry specifies The "uses" field of a property map resource in an IRD entry specifies
dependencies as discussed in Section 2.7. It is an array of the dependencies as discussed in Section 2.7. It is an array of the
resource ID(s) of the resource(s) that properties of entities in resource ID(s) of the resource(s) that properties of entities in
domains specified in "entity-domains" depend on. domains specified in "entity-domains" depend on.
In a single property map, every property value of every entity In a single property map, every property value of every entity
depends on the same array of resources. Thus, if properties depend depends on the same array of resources. Thus, if properties depend
skipping to change at page 27, line 9 skipping to change at page 27, line 33
9.2. ALTO Entity Domain Registry 9.2. ALTO Entity Domain Registry
This document requests IANA to create and maintain the "ALTO Entity This document requests IANA to create and maintain the "ALTO Entity
Domain Registry", listed in Table 2. Domain Registry", listed in Table 2.
+------------+----------------+------------------+------------------+ +------------+----------------+------------------+------------------+
| Identifier | Entity Address | Hierarchy & | Mapping to ALTO | | Identifier | Entity Address | Hierarchy & | Mapping to ALTO |
| | Encoding | Inheritance | Address Type | | | Encoding | Inheritance | Address Type |
+------------+----------------+------------------+------------------+ +------------+----------------+------------------+------------------+
| ipv4 | See Section | See Section | Yes | | ipv4 | See | See | Yes |
| | 3.1.1 | 3.1.3 | | | | Section 3.1.1 | Section 3.1.3 | |
| ipv6 | See Section | See Section | Yes | | ipv6 | See | See | Yes |
| | 3.1.2 | 3.1.3 | | | | Section 3.1.2 | Section 3.1.3 | |
| pid | See Section | None | No | | pid | See | None | No |
| | 3.2 | | | | | Section 3.2 | | |
+------------+----------------+------------------+------------------+ +------------+----------------+------------------+------------------+
Table 2: ALTO Entity Domains. Table 2: ALTO Entity Domains.
This registry serves two purposes. First, it ensures uniqueness of This registry serves two purposes. First, it ensures uniqueness of
identifiers referring to ALTO entity domains. Second, it states the identifiers referring to ALTO entity domains. Second, it states the
requirements for allocated entity domains. requirements for allocated entity domains.
9.2.1. Consistency Procedure between ALTO Address Type Registry and 9.2.1. Consistency Procedure between ALTO Address Type Registry and
ALTO Entity Domain Registry ALTO Entity Domain Registry
skipping to change at page 29, line 41 skipping to change at page 30, line 18
service providers using addresses of the registered type should be service providers using addresses of the registered type should be
made aware of how (or if) the addressing scheme relates to private made aware of how (or if) the addressing scheme relates to private
information and network proximity. information and network proximity.
This specification requests registration of the identifiers "ipv4", This specification requests registration of the identifiers "ipv4",
"ipv6" and "pid", as shown in Table 2. "ipv6" and "pid", as shown in Table 2.
9.3. ALTO Entity Property Type Registry 9.3. ALTO Entity Property Type Registry
This document requests IANA to create and maintain the "ALTO Entity This document requests IANA to create and maintain the "ALTO Entity
Property Type Registry". Property Type Registry", listed in Table 3.
To distinguish with the "ALTO Endpoint Property Type Registry", this To distinguish with the "ALTO Endpoint Property Type Registry", each
new registry is for properties in all possible entity domains, rather entry in this registry is an ALTO entity property type defined in
than just the Internet address domain. So it is necessary to define Section 2.5. Thus, registered ALTO entity property type identifier
and process the consistency between the two registries. MUST conform to the syntactical requirements specified in that
section.
In the meanwhile, because every entity property is owned by some The initial registered ALTO entity property types are listed in
entity domains, for each registered entity property, the ALTO Entity Table 3.
Property Registry MUST define its accepted entity domains and its
semantics in every different accepted entity domains.
Also, an entity property MAY depend on several other ALTO resources. +------------+------------------+-----------------------------------+
The ALTO Entity Property Registry MUST specify the media types of all | Identifier | Intended | Dependencies and Interpretation |
dependent resources and how the ALTO client uses them in order. | | Semantics | |
+------------+------------------+-----------------------------------+
| ipv4:pid | PID for the IPv4 | application/alto-networkmap+json, |
| | entity | where the PID names are defined |
| ipv6:pid | PID for the IPv6 | application/alto-networkmap+json, |
| | entity | where the PID names are defined |
+------------+------------------+-----------------------------------+
TODO: The registry format and the initial content Table 3: ALTO Entity Property Types.
Requests to the IANA to add a new value to the registry MUST include
the following information:
o Identifier: The unique id for the desired ALTO entity property
type. The format MUST be as defined in Section 2.5 of this
document. It includes the information of the applied ALTO entity
domain and the property name.
o Intended Semantics: ALTO entity properties carry with them
semantics to guide their usage by ALTO clients. Hence, a document
defining a new type SHOULD provide guidance to both ALTO service
providers and applications utilizing ALTO clients as to how values
of the registered ALTO entity property should be interpreted.
o Dependencies and Interpretation: Dependent ALTO resources MAY be
required by ALTO clients to interpret ALTO entity properties.
Hence, a document defining a new type SHOULD provide a sequence of
media types in which the dependent ALTO resources are and the
guidance how ALTO clients use them to interpret the property.
This specification requests registration of the identifiers
"ipv4:pid" and "ipv6:pid", as shown in Table 3.
10. Normative References 10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
 End of changes. 23 change blocks. 
61 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/