draft-ietf-alto-unified-props-new-08.txt   draft-ietf-alto-unified-props-new-09.txt 
ALTO WG W. Roome ALTO WG W. Roome
Internet-Draft S. Randriamasy Internet-Draft S. Randriamasy
Intended status: Standards Track Nokia Bell Labs Intended status: Standards Track Nokia Bell Labs
Expires: January 9, 2020 Y. Yang Expires: March 7, 2020 Y. Yang
Yale University Yale University
J. Zhang J. Zhang
Tongji University Tongji University
July 8, 2019 K. Gao
Sichuan University
September 4, 2019
Unified Properties for the ALTO Protocol Unified Properties for the ALTO Protocol
draft-ietf-alto-unified-props-new-08 draft-ietf-alto-unified-props-new-09
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 generic types of entities, and by presenting those
properties as maps, similar to the network and cost maps in properties as maps, similar to the network and cost maps in
[RFC7285]. [RFC7285].
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
skipping to change at page 1, line 44 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 January 9, 2020. This Internet-Draft will expire on March 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview: Basic Concepts . . . . . . . . . . . . . . . . . . 5 2. Overview: Basic Concepts . . . . . . . . . . . . . . . . . . 6
2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 6 2.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 6
2.3. Property Map . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Property Map . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Information Resource . . . . . . . . . . . . . . . . . . 6 2.4. Information Resource . . . . . . . . . . . . . . . . . . 7
2.5. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 7
2.5.1. Resource-Specific Entity Domain . . . . . . . . . . . 7 2.5.1. Resource-Specific Entity Domain . . . . . . . . . . . 7
2.5.2. Relationship between Entity and Entity Domain . . . . 7 2.5.2. Relationship between Entity and Entity Domain . . . . 8
2.5.3. Aggregated Entity Domain . . . . . . . . . . . . . . 7 2.5.3. Aggregated Entity Domain . . . . . . . . . . . . . . 8
2.5.4. Resource-Specific Entity Property . . . . . . . . . . 8 2.5.4. Resource-Specific Entity Property . . . . . . . . . . 9
2.6. Scope of Property Map . . . . . . . . . . . . . . . . . . 8 2.6. Scope of Property Map . . . . . . . . . . . . . . . . . . 9
2.7. Entity Hierarchy and Property Inheritance . . . . . . . . 9 2.7. Entity Hierarchy and Property Inheritance . . . . . . . . 10
3. Protocol Specification: Basic Data Type . . . . . . . . . . . 10 3. Protocol Specification: Basic Data Type . . . . . . . . . . . 10
3.1. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Entity Domain Type . . . . . . . . . . . . . . . . . 10 3.1.1. Entity Domain Type . . . . . . . . . . . . . . . . . 10
3.1.2. Entity Domain Name . . . . . . . . . . . . . . . . . 10 3.1.2. Entity Domain Name . . . . . . . . . . . . . . . . . 11
3.1.3. Entity Identifier . . . . . . . . . . . . . . . . . . 11 3.1.3. Entity Identifier . . . . . . . . . . . . . . . . . . 11
3.1.4. Hierarchy and Inheritance . . . . . . . . . . . . . . 12 3.1.4. Hierarchy and Inheritance . . . . . . . . . . . . . . 12
3.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 12 3.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Entity Property Type . . . . . . . . . . . . . . . . 12 3.2.1. Entity Property Type . . . . . . . . . . . . . . . . 12
3.2.2. Entity Property Name . . . . . . . . . . . . . . . . 13 3.2.2. Entity Property Name . . . . . . . . . . . . . . . . 13
3.3. Information Resource Export . . . . . . . . . . . . . . . 13 3.3. Information Resource Export . . . . . . . . . . . . . . . 14
3.3.1. Resource-Specific Entity Domain Export . . . . . . . 13 3.3.1. Resource-Specific Entity Domain Export . . . . . . . 14
3.3.2. Entity Property Mapping Export . . . . . . . . . . . 14 3.3.2. Entity Property Mapping Export . . . . . . . . . . . 14
4. Entity Domain Types . . . . . . . . . . . . . . . . . . . . . 14 4. Entity Domain Types . . . . . . . . . . . . . . . . . . . . . 14
4.1. Internet Address Domain Types . . . . . . . . . . . . . . 14 4.1. Internet Address Domain Types . . . . . . . . . . . . . . 15
4.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 15 4.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. Hierarchy and Inheritance of Internet Address Domains 15 4.1.3. Hierarchy and Inheritance of Internet Address Domains 15
4.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 16 4.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 17
4.2.2. Domain-Specific Entity Identifiers . . . . . . . . . 16 4.2.2. Domain-Specific Entity Identifiers . . . . . . . . . 17
4.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 17 4.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 17
4.2.4. Relationship To Internet Addresses Domains . . . . . 17 4.2.4. Relationship To Internet Addresses Domains . . . . . 17
4.3. Internet Address Properties vs. PID Properties . . . . . 17 4.3. Internet Address Properties vs. PID Properties . . . . . 17
5. Entity Domains and Property Mappings in Information Resources 17 5. Entity Domains and Property Mappings in Information Resources 18
5.1. Network Map Resource . . . . . . . . . . . . . . . . . . 17 5.1. Network Map Resource . . . . . . . . . . . . . . . . . . 18
5.1.1. Resource-Specific Entity Domain . . . . . . . . . . . 18 5.1.1. Resource-Specific Entity Domain . . . . . . . . . . . 18
5.1.2. Entity Property Mapping . . . . . . . . . . . . . . . 18 5.1.2. Entity Property Mapping . . . . . . . . . . . . . . . 18
5.2. Endpoint Property Resource . . . . . . . . . . . . . . . 18 5.2. Endpoint Property Resource . . . . . . . . . . . . . . . 19
5.2.1. Resource-Specific Entity Domain . . . . . . . . . . . 18 5.2.1. Resource-Specific Entity Domain . . . . . . . . . . . 19
5.2.2. Entity Property Mapping . . . . . . . . . . . . . . . 19 5.2.2. Entity Property Mapping . . . . . . . . . . . . . . . 19
5.3. Property Map Resource . . . . . . . . . . . . . . . . . . 19 5.3. Property Map Resource . . . . . . . . . . . . . . . . . . 19
6. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 19 6.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 20
6.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 19 6.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 20
6.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 20 6.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 21 7. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 22
7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 21 7.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 22
7.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 22 7.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 23
7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 22 7.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 24 8. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 25
8.1. Impact on Endpoint Property Service . . . . . . . . . . . 24 8.1. Impact on Endpoint Property Service . . . . . . . . . . . 25
8.2. Impact on Resource-Specific Properties . . . . . . . . . 24 8.2. Impact on Resource-Specific Properties . . . . . . . . . 25
8.3. Impact on the pid Property . . . . . . . . . . . . . . . 25 8.3. Impact on Other Properties . . . . . . . . . . . . . . . 25
8.4. Impact on Other Properties . . . . . . . . . . . . . . . 25
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 25
9.2. Property Definitions . . . . . . . . . . . . . . . . . . 26 9.2. Property Definitions . . . . . . . . . . . . . . . . . . 26
9.3. Information Resource Directory (IRD) . . . . . . . . . . 27 9.3. Information Resource Directory (IRD) . . . . . . . . . . 27
9.4. Property Map Example . . . . . . . . . . . . . . . . . . 29 9.4. Property Map Example . . . . . . . . . . . . . . . . . . 29
9.5. Filtered Property Map Example #1 . . . . . . . . . . . . 30 9.5. Filtered Property Map Example #1 . . . . . . . . . . . . 30
9.6. Filtered Property Map Example #2 . . . . . . . . . . . . 31 9.6. Filtered Property Map Example #2 . . . . . . . . . . . . 31
9.7. Filtered Property Map Example #3 . . . . . . . . . . . . 32 9.7. Filtered Property Map Example #3 . . . . . . . . . . . . 32
9.8. Filtered Property Map Example #4 . . . . . . . . . . . . 33 9.8. Filtered Property Map Example #4 . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11.1. application/alto-* Media Types . . . . . . . . . . . . . 35 11.1. application/alto-* Media Types . . . . . . . . . . . . . 35
11.2. ALTO Entity Domain Type Registry . . . . . . . . . . . . 36 11.2. ALTO Entity Domain Type Registry . . . . . . . . . . . . 36
11.2.1. Consistency Procedure between ALTO Address Type 11.2.1. Consistency Procedure between ALTO Address Type
Registry and ALTO Entity Domain Registry . . . . . . 37 Registry and ALTO Entity Domain Type Registry . . . 37
11.2.2. ALTO Entity Domain Registration Process . . . . . . 38 11.2.2. ALTO Entity Domain Type Registration Process . . . . 38
11.3. ALTO Entity Property Type Registry . . . . . . . . . . . 39 11.3. ALTO Entity Property Type Registry . . . . . . . . . . . 39
11.4. ALTO Resource-Specific Entity Domain Registries . . . . 40 11.4. ALTO Resource-Specific Entity Domain Registries . . . . 40
11.4.1. Network Map . . . . . . . . . . . . . . . . . . . . 40 11.4.1. Network Map . . . . . . . . . . . . . . . . . . . . 40
11.4.2. Endpoint Property . . . . . . . . . . . . . . . . . 40 11.4.2. Endpoint Property . . . . . . . . . . . . . . . . . 40
11.5. ALTO Resource Entity Property Mapping Registries . . . . 40 11.5. ALTO Resource Entity Property Mapping Registries . . . . 40
11.5.1. Network Map . . . . . . . . . . . . . . . . . . . . 40 11.5.1. Network Map . . . . . . . . . . . . . . . . . . . . 41
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
13. Normative References . . . . . . . . . . . . . . . . . . . . 41 13. Normative References . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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 three
limitations. limitations.
First, it allows properties to be associated with only a particular First, the EPS allows properties to be associated with only endpoints
domain of entities, namely individual IP addresses. It is reasonable which are identified by individual communication addresses like IPv4
to think that collections of endpoints, as defined by CIDRs [RFC4632] and IPv6 addresses. It is reasonable to think that collections of
or PIDs, may also have properties. Since the EPS cannot be extended endpoints, as defined by CIDRs [RFC4632] or PIDs, may also have
to new entity domains, new services, with new request and response properties. Furthermore, recent ALTO use cases show that properties
messages, would have to be defined for new entity domains. of network flows [RFC7011] and routing elements [RFC7921] are also
very useful. Since the EPS cannot be extended to those generic
entities, new services, with new request and response messages, would
have to be defined for them.
Second, the EPS is only defined as a POST-mode service. Clients must Second, the EPS only allows endpoints identified by global
communication addresses. However, many other generic entities like
PIDs may not have global identifiers. Even for Internet addresses,
there may be some local IP addresses and anycast IP addresses which
are also not global unique.
Third, the EPS is only defined as a POST-mode service. Clients must
request the properties for an explicit set of endpoint addresses. By request the properties for an explicit set of endpoint addresses. By
contrast, [RFC7285] defines a GET-mode cost map resource which contrast, [RFC7285] defines a GET-mode cost map resource which
returns all available costs, so a client can get a full set of costs returns all available costs, so a client can get a full set of costs
once, and then processes costs lookups without querying the ALTO once, and then processes costs lookups without querying the ALTO
server. [RFC7285] does not define an equivalent service for endpoint server. [RFC7285] does not define a similar service for endpoint
properties. At first a map of endpoint properties might seem properties. At first a map of endpoint properties might seem
impractical, because it could require enumerating the property value impractical, because it could require enumerating the property value
for every possible endpoint. But in practice, it is highly unlikely for every possible endpoint. But in practice, it is highly unlikely
that properties will be defined for every endpoint address. It is that properties will be defined for every endpoint address. It is
much more likely that properties may be defined for only a subset of much more likely that properties may be defined for only a subset of
endpoint addresses, and the specification of properties uses an endpoint addresses, and the specification of properties uses an
aggregation representation to allow enumeration. This is aggregation representation to allow enumeration. This is
particularly true if blocks of endpoint addresses with a common particularly true if blocks of endpoint addresses with a common
prefix (e.g., a CIDR) have the same value for a property. Entities prefix (e.g., a CIDR) have the same value for a property. Entities
in other domains may very well allow aggregated representation and in other domains may very well allow aggregated representation and
hence be enumerable as well. hence be enumerable as well.
This document specifies a new approach for defining and retrieving This document specifies a new approach for defining and retrieving
ALTO properties to address the two limitations. Specifically, this ALTO properties to address the three limitations:
document addresses the first limitation by introducing a generic
concept called ALTO Entity Domains, where an entity is a
generalization of an endpoint to also represent, a PID, a network
element, or a cell in a cellular network, etc. As a consequence,
ALTO Entity Domains defined in this document are a super-set of ALTO
Address Types defined in [RFC7285]. Their exact relationship is
specified in Section 11.2.1.
Entity domains and property names are extensible. New entity domains o This document addresses the first limitation by introducing a
can be defined without revising the messages defined in this generic concept called ALTO Entity which is a generalization of an
document, in the same way that new cost metrics and new endpoint endpoint to represent a PID, a network element, a cell in a
properties can be defined without revising the messages defined in cellular network, or other physical or logical objects used by
[RFC7285]. ALTO. Each entity is included by a collection called ALTO Entity
Domain. And each entity domain includes only one type of
entities. Thus, each entity domain also has a type to indicate
the type of entities in it.
Additional, this document addresses the second limitation by defining o Additionally, this document addresses the second limitation by
two new types of resources, namely Property Map (see Section 6) and using resource-specific entity domains. A resource-specific
Filtered Property Map (see Section 7). The former is a GET-mode entity domain is an entity domain exported by an existing ALTO
resource which returns the property values for all entities in a information resource. And a resource-specific entity domain is
domain, and is analogous to a network map or a cost map in [RFC7285]. named by its type and the resource id of the ALTO information
The latter is a POST-mode resource which returns the values for a set resource which exports it. As each resource-specific entity
of properties and entities requested by the client, and is analogous domain name is unique, an entity can be uniquely identified by the
to a filtered network map or a filtered cost map. name of a resource-specific entity domain and its domain-specific
identifier.
o Finally, this document addresses the third limitation by defining
two new types of ALTO information resources, namely Property Map
(see Section 6) and Filtered Property Map (see Section 7). The
former is a GET-mode resource which returns the property values
for all entities in some entity domains, and is analogous to a
network map or a cost map in [RFC7285]. The latter is a POST-mode
resource which returns the values for a set of properties and
entities requested by the client, and is analogous to a filtered
network map or a filtered cost map.
This approach is extensible, because new entity domain types can be
defined without revising the protocol specification defined in this
document, in the same way that new cost metrics and new endpoint
properties can be defined without revising the protocol specification
defined in [RFC7285].
This document subsumes the Endpoint Property Service defined in This document subsumes the Endpoint Property Service defined in
[RFC7285], although that service may be retained for legacy clients [RFC7285], although that service may be retained for legacy clients
(see Section 8). (see Section 8).
2. Overview: Basic Concepts 2. Overview: Basic Concepts
Before we define the specification of unified properties, there are Before we define the specification of unified properties, there are
several basic concepts which we need to introduce. several basic concepts which we need to introduce.
skipping to change at page 8, line 16 skipping to change at page 8, line 36
part of properties of its associated physical or logical object. For part of properties of its associated physical or logical object. For
example, the IPv4 entity in the IPv4 domain of the network map example, the IPv4 entity in the IPv4 domain of the network map
"netmap1" only has the PID property defined by "netmap1"; same to the "netmap1" only has the PID property defined by "netmap1"; same to the
IPv4 entity in the IPv4 domain of the network map "netmap2". If the IPv4 entity in the IPv4 domain of the network map "netmap2". If the
ALTO client wants to get the complete properties, using the resource- ALTO client wants to get the complete properties, using the resource-
specific entity domain, the ALTO client has to query the IPv4 entity specific entity domain, the ALTO client has to query the IPv4 entity
"192.0.2.34" twice. "192.0.2.34" twice.
To simplify the query process of the ALTO client, this document To simplify the query process of the ALTO client, this document
introduces the concept "Aggregated Entity Domain". An aggregated introduces the concept "Aggregated Entity Domain". An aggregated
entity domain defines an aggregated set of entities coming from entity domain defines a union set of entities coming from multiple
multiple resource-specific entity domains in the same type. An resource-specific entity domains in the same type. An entity in the
entity in the aggregated entity domain includes all properties aggregated entity domain inherits all properties defined for its
defined for the associated entity in each associated resource- associated entity in each associated resource-specific entity
specific entity domains. For example, the IPv4 entity "192.0.2.34" domains. For example, the IPv4 entity "192.0.2.34" in the aggregated
in the aggregated entity domain between the IPv4 domain of "netmap1" entity domain between the IPv4 domain of "netmap1" and the IPv4
and the IPv4 domain of "netmap2" has PID properties defined by both domain of "netmap2" has PID properties defined by both "netmap1" and
"netmap1" and "netmap2". "netmap2".
Note that some resource-specific entity domains may not be able to be
aggregated even if they are in the same type. For example, a
property map "propmap1" may define the "asn" property on both PID
domains "netmap1.pid" and "netmap2.pid". But the PID "pid1" in
"netmap1.pid" and the PID with the same name in "netmap2.pid" have
different "asn" property values. It does not make sense to define an
aggregated PID domain between "netmap1.pid" and "netmap2.pid" to
provide the "propmap1.asn" property because it is ambiguous.
2.5.4. Resource-Specific Entity Property 2.5.4. Resource-Specific Entity Property
According to the example of the aggregated entity domain, an entity According to the example of the aggregated entity domain, an entity
may have multiple properties in the same type but associated to may have multiple properties in the same type but associated to
different information resources. To distinguish them, this document different information resources. To distinguish them, this document
uses the same approach proposed by Section 10.8.1 of [RFC7285], which uses the same approach proposed by Section 10.8.1 of [RFC7285], which
is called "Resource-Specific Entity Property". is called "Resource-Specific Entity Property".
2.6. Scope of Property Map 2.6. Scope of Property Map
skipping to change at page 24, line 50 skipping to change at page 25, line 25
the EPS be deprecated in favor of Property Map and Filtered Property the EPS be deprecated in favor of Property Map and Filtered Property
Map. However, ALTO servers MAY provide an EPS for the benefit of Map. However, ALTO servers MAY provide an EPS for the benefit of
legacy clients. legacy clients.
8.2. Impact on Resource-Specific Properties 8.2. Impact on Resource-Specific Properties
Section 10.8 of [RFC7285] defines two categories of endpoint Section 10.8 of [RFC7285] defines two categories of endpoint
properties: "resource-specific" and "global". Resource-specific properties: "resource-specific" and "global". Resource-specific
property names are prefixed with the ID of the resource they depend property names are prefixed with the ID of the resource they depend
upon, while global property names have no such prefix. The property upon, while global property names have no such prefix. The property
map and the filtered property map defined in this document do not map and the filtered property map defined in this document defines
distinguish between those two types of properties. Instead, if there the similar categories for entity properties. The difference is that
is a dependency, it is indicated by the "uses" capability of a there is no "global" entity properties but the "self-defined" entity
property map, and is shared by all properties and entity domains in properties as the special case of the "resource-specific" entity
that map. Accordingly, it is RECOMMENDED that resource-specific properties instead.
endpoint properties be deprecated, and no new resource-specific
endpoint properties be defined.
8.3. Impact on the pid Property
Section 7.1.1 of [RFC7285] defines the resource-specific endpoint
property name "pid", whose value is the name of the PID containing
that endpoint. For compatibility with legacy clients, an ALTO server
which provides the "pid" property via the EPS MUST use that
definition, and that syntax.
However, when used with property maps, this document amends the
definition of the "pid" property as follows.
First, the name of the property is simply "pid"; the name is not
prefixed with the resource ID of a network map. The "uses"
capability of the property map indicates the associated network map.
This implies that a property map can only return the "pid" property
for one network map; if an ALTO server provides several network maps,
it MUST provide a Property Map for each of the network maps.
Second, a client MAY request the "pid" property for a block of
Internet addresses. An ALTO server determines the value of "pid" for
an address block C as the rules defined in Section 7.6.
Note that although an ALTO server MAY provide a GET-mode property map
which returns the entire map for the "pid" property, there is no need
to do so, because that map is simply the inverse of the network map.
8.4. Impact on Other Properties 8.3. Impact on Other Properties
In general, there should be little or no impact on other previously In general, there should be little or no impact on other previously
defined properties. The only consideration is that properties can defined properties. The only consideration is that properties can
now be defined on blocks of identifiers, rather than just individual now be defined on blocks of entity identifiers, rather than just
identifiers, which might change the semantics of a property. individual entity identifiers, which might change the semantics of a
property.
9. Examples 9. Examples
9.1. Network Map 9.1. Network Map
The examples in this section use a very simple default network map: The examples in this section use a very simple default network map:
defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0
pid1: ipv4:192.0.2.0/25 pid1: ipv4:192.0.2.0/25
pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28 pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28
skipping to change at page 37, line 10 skipping to change at page 37, line 10
| pid | See Section 4.2 | None | | pid | See Section 4.2 | None |
+-------------+---------------------------+-------------------------+ +-------------+---------------------------+-------------------------+
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.
11.2.1. Consistency Procedure between ALTO Address Type Registry and 11.2.1. Consistency Procedure between ALTO Address Type Registry and
ALTO Entity Domain Registry ALTO Entity Domain Type Registry
One potential issue of introducing the "ALTO Entity Domain Registry" One potential issue of introducing the "ALTO Entity Domain Type
is its relationship with the "ALTO Address Types Registry" already Registry" is its relationship with the "ALTO Address Types Registry"
defined in Section 14.4 of [RFC7285]. In particular, the entity already defined in Section 14.4 of [RFC7285]. In particular, the
identifier of an entity domain registered in the "ALTO Entity Domain entity identifier of a type of an entity domain registered in the
Registry" MAY match an address type defined in "ALTO Address Type "ALTO Entity Domain Type Registry" MAY match an address type defined
Registry". It is necessary to precisely define and guarantee the in "ALTO Address Type Registry". It is necessary to precisely define
consistency between "ALTO Address Type Registry" and "ALTO Entity and guarantee the consistency between "ALTO Address Type Registry"
Domain Registry". and "ALTO Entity Domain Registry".
We define that the ALTO Entity Domain Registry is consistent with We define that the ALTO Entity Domain Type Registry is consistent
ALTO Address Type Registry if two conditions are satisfied: with ALTO Address Type Registry if two conditions are satisfied:
o When an address type is already or able to be registered in the o When an address type is already or able to be registered in the
ALTO Address Type Registry [RFC7285], the same identifier MUST be ALTO Address Type Registry [RFC7285], the same identifier MUST be
used when a corresponding entity domain is registered in the ALTO used when a corresponding entity domain type is registered in the
Entity Domain Registry. ALTO Entity Domain Type Registry.
o If an ALTO entity domain has the same identifier as an ALTO o If an ALTO entity domain type has the same identifier as an ALTO
address type, their addresses encoding MUST be compatible. address type, their addresses encoding MUST be compatible.
To achieve this consistency, the following items MUST be checked To achieve this consistency, the following items MUST be checked
before registering a new ALTO entity domain in a future document: before registering a new ALTO entity domain type in a future
document:
o Whether the ALTO Address Type Registry contains an address type o Whether the ALTO Address Type Registry contains an address type
that can be used as an entity identifier for the candidate domain that can be used as an entity identifier for the candidate domain
identifier. This has been done for the identifiers "ipv4" and identifier. This has been done for the identifiers "ipv4" and
"ipv6" in Table 2. "ipv6" in Table 2.
o Whether the candidate entity identifier of the entity domain is o Whether the candidate entity identifier of the type of the entity
able to be an endpoint address, as defined in Sections 2.1 and 2.2 domain is able to be an endpoint address, as defined in Sections
of [RFC7285]. 2.1 and 2.2 of [RFC7285].
When a new ALTO entity domain is registered, the consistency with the When a new ALTO entity domain type is registered, the consistency
ALTO Address Type Registry MUST be ensured by the following with the ALTO Address Type Registry MUST be ensured by the following
procedure: procedure:
o Test: Do corresponding entity identifiers match a known "network" o Test: Do corresponding entity identifiers match a known "network"
address type? address type?
* If yes (e.g., cell, MAC or socket addresses): * If yes (e.g., cell, MAC or socket addresses):
+ Test: Is such an address type present in the ALTO Address + Test: Is such an address type present in the ALTO Address
Type Registry? Type Registry?
- If yes: Set the new ALTO entity domain identifier to be - If yes: Set the new ALTO entity domain type identifier to
the found ALTO address type identifier. be the found ALTO address type identifier.
- If no: Define a new ALTO entity domain identifier and use - If no: Define a new ALTO entity domain type identifier
it to register a new address type in the ALTO Address and use it to register a new address type in the ALTO
Type Registry following Section 14.4 of [RFC7285]. Address Type Registry following Section 14.4 of
[RFC7285].
+ Use the new ALTO entity domain identifier to register a new + Use the new ALTO entity domain type identifier to register a
ALTO entity domain in the ALTO Entity Domain Registry new ALTO entity domain type in the ALTO Entity Domain Type
following Section 11.2.2 of this document. Registry following Section 11.2.2 of this document.
* If no (e.g., pid name, ane name or country code): Proceed with * If no (e.g., pid name, ane name or country code): Proceed with
the ALTO Entity Domain registration as described in the ALTO Entity Domain Type registration as described in
Section 11.2.2. Section 11.2.2.
11.2.2. ALTO Entity Domain Registration Process 11.2.2. ALTO Entity Domain Type Registration Process
New ALTO entity domains are assigned after IETF Review [RFC5226] to New ALTO entity domain types are assigned after IETF Review [RFC5226]
ensure that proper documentation regarding the new ALTO entity to ensure that proper documentation regarding the new ALTO entity
domains and their security considerations has been provided. RFCs domain types and their security considerations has been provided.
defining new entity domains SHOULD indicate how an entity in a RFCs defining new entity domain types SHOULD indicate how an entity
registered domain is encoded as an EntityId, and, if applicable, the in a registered type of domain is encoded as an EntityID, and, if
rules defining the entity hierarchy and property inheritance. applicable, the rules defining the entity hierarchy and property
Updates and deletions of ALTO entity domains follow the same inheritance. Updates and deletions of ALTO entity domains follow the
procedure. same procedure.
Registered ALTO entity domain identifiers MUST conform to the Registered ALTO entity domain type identifiers MUST conform to the
syntactical requirements specified in Section 3.1.2. Identifiers are syntactical requirements specified in Section 3.1.2. Identifiers are
to be recorded and displayed as strings. to be recorded and displayed as strings.
Requests to the IANA to add a new value to the registry MUST include Requests to the IANA to add a new value to the registry MUST include
the following information: the following information:
o Identifier: The name of the desired ALTO entity domain. o Identifier: The name of the desired ALTO entity domain type.
o Entity Identifier Encoding: The procedure for encoding the o Entity Identifier Encoding: The procedure for encoding the
identifier of an entity of the registered type as an EntityId (see identifier of an entity of the registered type as an EntityID (see
Section 3.1.3). If corresponding entity identifiers of an entity Section 3.1.3). If corresponding entity identifiers of an entity
domain match a known "network" address type, the Entity Identifier domain match a known "network" address type, the Entity Identifier
Encoding of this domain identifier MUST include both Address Encoding of this domain identifier MUST include both Address
Encoding and Prefix Encoding of the same identifier registered in Encoding and Prefix Encoding of the same identifier registered in
the ALTO Address Type Registry [RFC7285]. For the purpose of the ALTO Address Type Registry [RFC7285]. For the purpose of
defining properties, an individual entity identifier and the defining properties, an individual entity identifier and the
corresponding full-length prefix MUST be considered aliases for corresponding full-length prefix MUST be considered aliases for
the same entity. the same entity.
o Hierarchy: If the entities form a hierarchy, the procedure for o Hierarchy: If the entities form a hierarchy, the procedure for
determining that hierarchy. determining that hierarchy.
o Inheritance: If entities can inherit property values from other o Inheritance: If entities can inherit property values from other
entities, the procedure for determining that inheritance. entities, the procedure for determining that inheritance.
o Mapping to ALTO Address Type: A boolean value to indicate if the o Mapping to ALTO Address Type: A boolean value to indicate if the
entity domain can be mapped to the ALTO address type with the same entity domain type can be mapped to the ALTO address type with the
identifier. same identifier.
o Security Considerations: In some usage scenarios, entity o Security Considerations: In some usage scenarios, entity
identifiers carried in ALTO Protocol messages may reveal identifiers carried in ALTO Protocol messages may reveal
information about an ALTO client or an ALTO service provider. information about an ALTO client or an ALTO service provider.
Applications and ALTO service providers using addresses of the Applications and ALTO service providers using addresses of the
registered type should be made aware of how (or if) the addressing registered type should be made aware of how (or if) the addressing
scheme relates to private information and network proximity. scheme relates to private 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.
skipping to change at page 42, line 5 skipping to change at page 42, line 10
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy, Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol", "Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014, RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>. <https://www.rfc-editor.org/info/rfc7285>.
skipping to change at page 42, line 38 skipping to change at page 43, line 4
Phone: +1-908-464-6975 Phone: +1-908-464-6975
Email: wendy@wdroome.com Email: wendy@wdroome.com
Sabine Randriamasy Sabine Randriamasy
Nokia Bell Labs Nokia Bell Labs
Route de Villejust Route de Villejust
NOZAY 91460 NOZAY 91460
FRANCE FRANCE
Email: Sabine.Randriamasy@nokia-bell-labs.com Email: Sabine.Randriamasy@nokia-bell-labs.com
Y. Richard Yang Y. Richard Yang
Yale University Yale University
51 Prospect Street 51 Prospect Street
New Haven, CT 06511 New Haven, CT 06511
USA USA
Phone: +1-203-432-6400 Phone: +1-203-432-6400
Email: yry@cs.yale.edu Email: yry@cs.yale.edu
Jingxuan Jensen Zhang Jingxuan Jensen Zhang
Tongji University Tongji University
4800 Caoan Road 4800 Caoan Road
Shanghai 201804 Shanghai 201804
China China
Email: jingxuan.n.zhang@gmail.com Email: jingxuan.n.zhang@gmail.com
Kai Gao
Sichuan University
Chengdu 610000
China
Email: kaigao@scu.edu.cn
 End of changes. 51 change blocks. 
163 lines changed or deleted 175 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/