draft-ietf-alto-unified-props-new-04.txt   draft-ietf-alto-unified-props-new-05.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: December 31, 2018 Tongji University Expires: June 13, 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
June 29, 2018 December 10, 2018
Unified Properties for the ALTO Protocol Unified Properties for the ALTO Protocol
draft-ietf-alto-unified-props-new-04 draft-ietf-alto-unified-props-new-05
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 December 31, 2018. This Internet-Draft will expire on June 13, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 Name . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 6 2.6. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 6
2.7. Relationship with Other ALTO Resources . . . . . . . . . 6 2.7. Relationship with Other ALTO Resources . . . . . . . . . 6
3. Entity Domains . . . . . . . . . . . . . . . . . . . . . . . 7 3. Entity Domains . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Internet Address Domains . . . . . . . . . . . . . . . . 7 3.1. Internet Address Domains . . . . . . . . . . . . . . . . 7
3.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 7
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.1.4. Relationship to Network Maps . . . . . . . . . . . . 9 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 Resource . . . . . . . . . . . . . . . . . . . . 11 4. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Filtered Property Map Resource . . . . . . . . . . . . . . . 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 . . . . . . . 14 6. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 16
6.1. Impact on Endpoint Property Service . . . . . . . . . . . 15 6.1. Impact on Endpoint Property Service . . . . . . . . . . . 16
6.2. Impact on Resource-Specific Properties . . . . . . . . . 15 6.2. Impact on Resource-Specific Properties . . . . . . . . . 16
6.3. Impact on the pid Property . . . . . . . . . . . . . . . 15 6.3. Impact on the pid Property . . . . . . . . . . . . . . . 16
6.4. Impact on Other Properties . . . . . . . . . . . . . . . 16 6.4. Impact on Other Properties . . . . . . . . . . . . . . . 17
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Property Definitions . . . . . . . . . . . . . . . . . . 16 7.2. Property Definitions . . . . . . . . . . . . . . . . . . 17
7.3. Information Resource Directory (IRD) . . . . . . . . . . 16 7.3. Information Resource Directory (IRD) . . . . . . . . . . 18
7.4. Property Map Example . . . . . . . . . . . . . . . . . . 18 7.4. Property Map Example . . . . . . . . . . . . . . . . . . 20
7.5. Filtered Property Map Example #1 . . . . . . . . . . . . 19 7.5. Filtered Property Map Example #1 . . . . . . . . . . . . 21
7.6. Filtered Property Map Example #2 . . . . . . . . . . . . 20 7.6. Filtered Property Map Example #2 . . . . . . . . . . . . 21
7.7. Filtered Property Map Example #3 . . . . . . . . . . . . 21 7.7. Filtered Property Map Example #3 . . . . . . . . . . . . 22
7.8. Filtered Property Map Example #4 . . . . . . . . . . . . 22 7.8. Filtered Property Map Example #4 . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. application/alto-* Media Types . . . . . . . . . . . . . 24 9.1. application/alto-* Media Types . . . . . . . . . . . . . 25
9.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 25 9.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 26
9.2.1. Consistency Procedure between ALTO Address Type 9.2.1. Consistency Procedure between ALTO Address Type
Registry and ALTO Entity Domain Registry . . . . . . 26 Registry and ALTO Entity Domain Registry . . . . . . 27
9.2.2. ALTO Entity Domain Registration Process . . . . . . . 27 9.2.2. ALTO Entity Domain Registration Process . . . . . . . 28
9.3. ALTO Endpoint Property Type Registry . . . . . . . . . . 28 9.3. ALTO Entity Property Type Registry . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Normative References . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The ALTO protocol [RFC7285] introduced the concept of "properties" The ALTO protocol [RFC7285] introduces the concept of "properties"
attached to "endpoint addresses", and defined the Endpoint Property attached to "endpoint addresses", and defines the Endpoint Property
Service (EPS) to allow clients to retrieve those properties. While Service (EPS) to allow ALTO clients to retrieve those properties.
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
domain of entities, namely individual IP addresses. It is reasonable domain of entities, namely individual IP addresses. It is reasonable
to think that collections of endpoints, as defined by CIDRs [RFC4632] to think that collections of endpoints, as defined by CIDRs [RFC4632]
or PIDs, may also have properties. The EPS cannot be extended to new or PIDs, may also have properties. Since the EPS cannot be extended
entity domains. Instead, new services, with new request and response to new entity domains, new services, with new request and response
messages, would have to be defined for each new entity domain. messages, would have to be defined for new entity domains.
Second, the EPS is only defined as a POST-mode service. Clients must Second, the EPS is only defined as a POST-mode service. Clients must
request the properties for an explicit set of 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 lookup 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 an equivalent service for endpoint
properties. At first a map might seem impractical, because it could properties. At first a map of endpoint properties might seem
require enumerating the property value for every possible endpoint. impractical, because it could require enumerating the property value
But in practice, it is highly unlikely that properties will be for every possible endpoint. But in practice, it is highly unlikely
defined for every address. It is much more likely that properties that properties will be defined for every endpoint address. It is
will only be defined for a subset of addresses, and that subset would much more likely that properties will only be defined for a subset of
be small enough to enumerate. This is particularly true if blocks of endpoint addresses, and that subset would be small enough to be
enumerated. This is particularly true if blocks of endpoint
addresses with a common prefix (e.g., a CIDR) have the same value for addresses with a common prefix (e.g., a CIDR) have the same value for
a property. Furthermore, entities in other domains may very well be a property. Furthermore, entities in other domains may very well be
enumerable. enumerable.
This document proposes a new approach to retrieve ALTO properties. This document proposes a new approach to retrieve ALTO properties.
Specifically, it defines two new resource types, namely Property Maps Specifically, it defines two new types of resources, namely Property
(see Section 4) and Filtered Property Maps (see Section 5). The Map (see Section 4) and Filtered Property Map (see Section 5). The
former are GET-mode resources which return the property values for former is a GET-mode resource which returns the property values for
all entities in a domain, and are analogous to the ALTO's Network all entities in a domain, and is analogous to a network map or a cost
Maps and Cost Maps. The latter are POST-mode resources which return map in [RFC7285]. The latter is a POST-mode resource which returns
the values for a set of properties and entities requested by the the values for a set of properties and entities requested by the
client, and are analogous to the ALTO's Filtered Network Maps and client, and is analogous to a filtered network map or a filtered cost
Filtered Cost Maps. map.
Additionally, this document introduces ALTO Entity Domains, where Additionally, this document introduces ALTO Entity Domains, where an
entities extend the concept of endpoints to objects that may be entity is a generalization of an endpoint to also represent, a PID, a
endpoints as defined in [RFC7285] but also, for example, PIDs, network element, or a cell in a cellular network, etc. As a
Abstract Network Elements as defined in [I-D.ietf-alto-path-vector] consequence, ALTO Entity Domains defined in this document are a
or cells. As a consequence, ALTO Entity Domains are a super-set of super-set of ALTO Address Types defined in [RFC7285]. Their exact
ALTO Address Types and their relation is specified in Section 9.2.1. relationship is specified in Section 9.2.1.
Entity domains and property names are extensible. New entity domains Entity domains and property names are extensible. New entity domains
can be defined without revising the messages defined in this can be defined without revising the messages defined in this
document, in the same way that new cost metrics and new endpoint document, in the same way that new cost metrics and new endpoint
properties can be defined without revising the messages defined by properties can be defined without revising the messages defined in
the ALTO protocol. [RFC7285].
This proposal would subsume the Endpoint Property Service defined in This proposal would subsume 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 6). (see Section 6).
2. Definitions and Concepts 2. Definitions and Concepts
2.1. Entity 2.1. Entity
The entity is an extended concept of the endpoint defined in The entity is a generalized concept of the endpoint defined in
Section 2.1 of [RFC7285]. An entity is an object with a (possibly Section 2.1 of [RFC7285]. An entity is an object with a (possibly
empty) set of properties. Every entity is in a domain, such as the empty) set of properties. Each entity MUST be in one and only one
IPv4 and IPv6 domains, and has a unique address. domain, such as the IPv4 domain or the IPv6 domain, and has a unique
address.
2.2. Entity Domain 2.2. Entity Domain
An entity domain is a family of entities. Two examples are the An entity domain is a set of entities. Examples of domains are the
Internet address and PID domain (see Section 3.1 and Section 3.2) Internet address domains (see Section 3.1 and the PID domain (see
that this document will define. Section 3.2). This document will define the domains precisely below.
2.3. Domain Name 2.3. Domain Name
Each entity domain has a unique name. A domain name MUST be no more Each entity domain has a unique name. A domain name MUST be no more
than 32 characters, and MUST NOT contain characters other than US- than 32 characters, and MUST NOT contain characters other than US-
ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and
U+0061-U+007A), hyphen ("-", U+002D), and low line ("_", U+005F). U+0061-U+007A), hyphen ("-", U+002D), and low line ("_", U+005F).
For example, the names "ipv4" and "ipv6" identify objects in the For example, the names "ipv4" and "ipv6" identify entities in the
Internet address domain (see Section 3.1). Internet address domains (see Section 3.1).
The type DomainName is used in this document to denote a JSON string The type DomainName is used in this document to denote a JSON string
with a domain name in this format. with a domain name in this format.
Domain names MUST be registered with the IANA, and the format of the Domain names MUST be registered with the IANA, and the format of the
entity addresses in that entity domain, as well as any hierarchical entity addresses (see Section 2.4) in that entity domain, as well as
or inheritance rules for those entities, MUST be specified at the any hierarchical or inheritance rules (see Section 2.6) for those
same time. entities, MUST be specified at the same time.
2.4. Entity Address 2.4. Entity Address
Each entity has a unique address of the format: Each entity has a unique address of the format:
domain-name : domain-specific-entity-address EntityAddr ::= DomainName : DomainSpecificEntityAddr
Examples from the IP domain include individual addresses such as Examples from the IP domains include individual addresses such as
"ipv4:192.0.2.14" and "ipv6:2001:db8::12", as well as address blocks "ipv4:192.0.2.14" and "ipv6:2001:db8::12", as well as address blocks
such as "ipv4:192.0.2.0/26" and "ipv6:2001:db8::1/48". such as "ipv4:192.0.2.0/26" and "ipv6:2001:db8::1/48".
The type EntityAddr is used in this document to denote a JSON string The type EntityAddr is used in this document to denote a JSON string
with an entity address in this format. with an entity address in this format.
The format of the second part of an entity address depends on the The format of the second part of an entity address depends on the
entity domain, and MUST be specified when registering a new entity entity domain, and MUST be specified when registering a new entity
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 Name
The space of property names associated with entities defined by this The space of entity property names associated with entities defined
document is the same as, and is shared with, the endpoint property by this document is a superset of the endpoint property names defined
names defined by [RFC7285]. Thus entity property names are as by [RFC7285]. Thus endpoint property names registered with the "ALTO
defined in Section 10.8.2 of that document, and must be registered Endpoint Property Type Registry" MUST be defined in Section 9.3 of
with the "ALTO Endpoint Property Type Registry" defined in this document. The type PropertyName denotes a JSON string with a
Section 9.3 of that document. The type PropertyName denotes a JSON property name in this format.
string with a property name in this format.
This document defines uniform property names specified in a single This document defines property names in the domain-specific context.
property name space rather than being scoped by a specific entity This design is to enforce that each property name MUST be registered
domain, although some properties may only be applicable for for every applicable entity domains individually. This design
particular entity domains. This design decision is to enforce a decision is adopted because of the following considerations:
design so that similar properties are named similarly. The
interpretation of the value of a property, however, may depend on the o Some properties may only be applicable for particular entity
entity domain. For example, suppose the "geo-location" property is domains, not all. For example, the "pid" property is not
defined as the coordinates of a point, encoded as (say) "latitude applicable for entities in the "pid" domain.
longitude [altitude]." When applied to an entity that represents a
specific host computer, such as an Internet address, the property o The interpretation of the value of a property may depend on the
defines the host's location. When applied to an entity that entity domain. For different entity domains, not only the
represents a set of computers, such as a CIDR, the property would be intended semantics but also the dependent resource types may be
the location of the center of that set. If it is necessary to totally different. For example, suppose that the "geo-location"
represent the bounding box of a set of hosts, another property, such property is defined as the coordinates of a point, encoded as
as "geo-region", should be defined. (say) "latitude longitude [altitude]." When applied to an entity
that represents a specific host computer, such as an Internet
address, the property defines the host's location and has no
required dependency. However, when applied to an entity in the
"pid" domain, the property would indicate the location of the
center of all hosts in this "pid" entity and depend on a Network
Map defining this "pid" entity.
2.6. Hierarchy and Inheritance 2.6. Hierarchy and Inheritance
Entities in a given domain MAY form hierarchy based on entity Entities in a given domain MAY form a hierarchy based on entity
address. Each entity domain MUST define its own hierarchy and addresses, and introducing hierarchy allows the introduction of
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. If and only if the property of an another entity in the same domain.
entity is undefined, the hierarchy and inheritance rules are applied.
2.7. Relationship with Other ALTO Resources 2.7. Relationship with Other ALTO Resources
[RFC7285] recognizes that some properties MAY be specific to another [RFC7285] recognizes that some properties for some entity domains MAY
ALTO resource, such as a network map. Accordingly [RFC7285] defines be specific to an ALTO resource, such as a network map. Accordingly
the concept of "resource-specific endpoint properties" (see Section 10.8.1 of [RFC7285] defines the concept of "resource-specific
Section 10.8.1), and indicates that dependency by prefixing the endpoint properties", and indicates that dependency by prefixing the
property name with the ID of the resource on which it depends. That property name with the ID of the resource on which it depends. That
document defines one resource-specific property, namely the "pid" document defines one resource-specific property, namely the "pid"
property, whose value is the name of the PID containing that endpoint property, whose value is the name of the PID containing that endpoint
in the associated network map. in the associated network map.
This document takes a different approach. Instead of defining the This document takes a different approach. Instead of defining the
dependency by qualifying the property name, this document attaches dependency by qualifying the property name, this document attaches
the dependency to the entity domains. Thus all properties of a the dependency to the entity domains. Thus each resource-specific
specific entity domain depend on the same resource, the properties of property of all entities in a specific domain depends on the same
another entity domain may depend on another resource. For example, resources; the properties of entities in another domain may depend on
entities in the PID domain depend on a network map. another resource. For example, in a single property map, the "pid"
property of all entities in an Internet address domain MUST depend on
The "uses" field in an IRD entry defines the dependencies of a the same network map. Each property of all entities in the PID
property map resource, and the "dependent-vtags" field in a property domain MUST also depend on a network map; but different properties
map response defines the dependencies of that map. These fields are may depend on different network maps.
defined in Sections 9.1.5 and 11.1 of [RFC7285], respectively.
The "uses" field in an IRD entry MUST NOT include two dependent
resources with the same media type. This is similar to how [RFC7285]
handles dependencies between cost maps and network maps. Recall that
cost maps present the costs between PIDs, and PID names depend on a
network map. If an ALTO server provides the "routingcost" metric for
the network maps "net1" and "net2", then the server defines two
separate cost maps, one for "net1" and the other for "net2".
According to [RFC7285], a legacy ALTO server with two network maps, Specifically, this document uses the "uses" and "dependent-vtags"
with resource IDs "net1" and "net2", could offer a single Endpoint fields defined in Sections 9.1.5 and 11.1 of [RFC7285], respectively,
Property Service for the two properties "net1.pid" and "net2.pid". to specify the preceding dependency: the "uses" field of an IRD entry
An ALTO server which supports the extensions defined in this providing entity domain related resources (see Property Map and
document, would, instead, offer two different Property Maps for the Filtered Property Map resources below) specifies the dependent
"pid" property, one depending on "net1", the other on "net2". resources, and the "dependent-vtags" field specifies dependency in
message responses.
3. Entity Domains 3. Entity Domains
This document defines the following entity domains. For the This document defines three entity domains. The definition of each
definition of each entity domain, it includes the following template: entity domain below includes the following: (1) domain name, (2)
domain name, domain-specific addresses, and hierarchy and inheritance domain-specific addresses, and (3) hierarchy and inheritance
semantics. semantics.
3.1. Internet Address Domains 3.1. Internet Address Domains
The document defines two entity domains (IPv4 and IPv6) for Internet The document defines two entity domains (IPv4 and IPv6) for Internet
addresses. Both entity domains include individual addresses and addresses. Both entity domains include individual addresses and
blocks of addresses. blocks of addresses. Since the two domains use the same hierarchy
and inheritance semantics, we define the semantics together, instead
of repeating for each.
3.1.1. IPv4 Domain 3.1.1. IPv4 Domain
3.1.1.1. Domain Name 3.1.1.1. Domain Name
ipv4 ipv4
3.1.1.2. Domain-Specific Entity Addresses 3.1.1.2. Domain-Specific Entity Addresses
Individual addresses are strings as specified by the IPv4Addresses Individual addresses are strings as specified by the IPv4Addresses
rule of Section 3.2.2 of [RFC3986]. Blocks of addresses are prefix- rule of Section 3.2.2 of [RFC3986]; blocks of addresses are prefix-
match strings as specified in Section 3.1 of [RFC4632]. For the match strings as specified in Section 3.1 of [RFC4632]. For the
purpose of defining properties, an individual Internet address and purpose of defining properties, an individual Internet address and
the corresponding full-length prefix are considered aliases for the the corresponding full-length prefix are considered aliases for the
same entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are same entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are
equivalent. equivalent.
3.1.2. IPv6 Domain 3.1.2. IPv6 Domain
3.1.2.1. Domain Name 3.1.2.1. Domain Name
ipv6 ipv6
3.1.2.2. Domain-Specific Entity Addresses 3.1.2.2. Domain-Specific Entity Addresses
Individual addresses are strings as specified by Section 4 of Individual addresses are strings as specified by Section 4 of
[RFC5952]. Blocks of addresses are prefix-match strings as specified [RFC5952]; blocks of addresses are prefix-match strings as specified
in Section 7 of [RFC5952]. For the purpose of defining properties, in Section 7 of [RFC5952]. For the purpose of defining properties,
an individual Internet address and the corresponding 128-bit prefix an individual Internet address and the corresponding 128-bit prefix
are considered aliases for the same entity. That is, are considered aliases for the same entity. That is,
"ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent, and "ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent, and
have the same set of properties. have the same set of properties.
3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains
Both entity domains allow property values to be inherited. Both Internet address domains allow property values to be inherited.
Specifically, if a property P is not defined for a specific Internet Specifically, if a property P is not defined for a specific Internet
address I, but P is defined for some block C which prefix-matches I, address I, but P is defined for some block C which prefix-matches I,
then the address I inherits the value of P defined for block C. If then the address I inherits the value of P defined for block C. If
more than one such block defines a value for P, I inherits the value more than one such block defines a value for P, I inherits the value
of P in the block with the longest prefix. It is important to notice of P in the block with the longest prefix. It is important to notice
that this longest prefix rule will ensure no multiple inheritance, that this longest prefix rule will ensure no multiple inheritance,
and hence no ambiguity. and hence no ambiguity.
Address blocks can also inherit properties: if property P is not Address blocks can also inherit properties: if a property P is not
defined for a block C, but is defined for some block C' which prefix- defined for a block C, but is defined for some block C' which covers
matches C, and C' has a shorter mask than C, then block C inherits all IP addresses in C, and C' has a shorter mask than C, then block C
the property from C'. If there are several such blocks C', C inherits the property from C'. If there are several such blocks C',
inherits from the block with the longest prefix. C inherits from the block with the longest prefix.
As an example, suppose that a server defines the property P for the As an example, suppose that a server defines a property P for the
following entities: following entities:
ipv4:192.0.2.0/26: P=v1 ipv4:192.0.2.0/26: P=v1
ipv4:192.0.2.0/28: P=v2 ipv4:192.0.2.0/28: P=v2
ipv4:192.0.2.0/30: P=v3 ipv4:192.0.2.0/30: P=v3
ipv4:192.0.2.0: P=v4 ipv4:192.0.2.0: P=v4
Figure 1: Defined Property Values. Figure 1: Defined Property Values.
Then the following entities have the indicated values: Then the following entities have the indicated values:
skipping to change at page 9, line 27 skipping to change at page 9, line 20
ipv4:192.0.2.32: P=v1 ipv4:192.0.2.32: P=v1
ipv4:192.0.2.64: (not defined) ipv4:192.0.2.64: (not defined)
ipv4:192.0.2.0/32: P=v4 ipv4:192.0.2.0/32: P=v4
ipv4:192.0.2.0/31: P=v3 ipv4:192.0.2.0/31: P=v3
ipv4:192.0.2.0/29: P=v2 ipv4:192.0.2.0/29: P=v2
ipv4:192.0.2.0/27: P=v1 ipv4:192.0.2.0/27: P=v1
ipv4:192.0.2.0/25: (not defined) ipv4:192.0.2.0/25: (not defined)
Figure 2: Inherited Property Values. Figure 2: Inherited Property Values.
An ALTO Server MAY explicitly indicate a property as not having a An ALTO server MAY explicitly indicate a property as not having a
value for a particular entity. That is, a server MAY say that value for a particular entity. That is, a server MAY say that
property A of entity X is "defined to have no value", instead of property P of entity X is "defined to have no value", instead of
"undefined". To indicate "no value", a server MAY perform different "undefined". To indicate "no value", a server MAY perform different
behaviours: behaviours:
o If that entity would inherit a value for that property, then the o If that entity would inherit a value for that property, then the
ALTO server MUST return a "null" value for that property. In this ALTO server MUST return a "null" value for that property. In this
case, the ALTO client MUST recognize a "null" value as "no value" case, the ALTO client MUST recognize a "null" value as "no value"
and "do not apply the inheritance rules for this property." and "do not apply the inheritance rules for this property."
o If the entity would not inherit a value, then the ALTO server MAY o If the entity would not inherit a value, then the ALTO server MAY
return "null" or just omit the property. In this case, the ALTO return "null" or just omit the property. In this case, the ALTO
client cannot infer the value for this property of this entity client cannot infer the value for this property of this entity
from the Inheritance rules. So the client MUST interpret this from the Inheritance rules. So the client MUST interpret that
property has no value. this property has no value.
If the ALTO Server does not define any properties for an entity, then If the ALTO server does not define any properties for an entity, then
the server MAY omit that entity from the response. the server MAY omit that entity from the response.
3.1.4. Relationship to Network Maps
An Internet address domain MAY be associated with an ALTO network map
resource. Logically, there is a map of Internet address entities to
property values for each network map defined by the ALTO server, plus
an additional property map for Internet address entities which are
not associated with a network map. So, if there are n network maps,
the server can provide n+1 maps of Internet address entities to
property values. These maps are separate from each other. The
prefixes in the property map do not have to correspond to the
prefixes defining the network map's PIDs. For example, the property
map for a network map MAY assign properties to "ipv4:192.0.2.0/24"
even if that prefix is not associated with any PID in the network
map.
3.2. PID Domain 3.2. PID Domain
The PID domain associates property values with the PIDs in a network The PID domain associates property values with the PIDs in a network
map. Accordingly, this entity domain always depends on a network map. Accordingly, this entity domain always depends on a network
map. map.
3.2.1. Domain Name 3.2.1. Domain Name
pid pid
skipping to change at page 10, line 50 skipping to change at page 10, line 32
For example, suppose "PID1" consists of the prefix For example, suppose "PID1" consists of the prefix
"ipv4:192.0.2.0/24", and has the property "P" with value "v1". The "ipv4:192.0.2.0/24", and has the property "P" with value "v1". The
Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24", Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24",
in the IPv4 domain MAY have a value for the property "P", and if they in the IPv4 domain MAY have a value for the property "P", and if they
do, it is not necessarily "v1". do, it is not necessarily "v1".
3.3. Internet Address Properties vs. PID Properties 3.3. Internet Address Properties vs. PID Properties
Because the Internet address and PID domains are completely separate, Because the Internet address and PID domains are completely separate,
the question may arise as to which entity domain is the best for a the question may arise as to which entity domain is the best for a
property. In general, the Internet address domain is RECOMMENDED for property. In general, the Internet address domains are RECOMMENDED
properties that are closely related to the Internet address, or are for properties that are closely related to the Internet address, or
associated with, and inherited through, blocks of addresses. are associated with, and inherited through, blocks of addresses.
The PID domain is RECOMMENDED for properties that arise from the The PID domain is RECOMMENDED for properties that arise from the
definition of the PID, rather than from the Internet address prefixes definition of the PID, rather than from the Internet address prefixes
in that PID. in that PID.
For example, because Internet addresses are allocated to service For example, because Internet addresses are allocated to service
providers by blocks of prefixes, an "ISP" property would be best providers by blocks of prefixes, an "ISP" property would be best
associated with the Internet address domain. On the other hand, a associated with the Internet address domain. On the other hand, a
property that explains why a PID was formed, or how it relates a property that explains why a PID was formed, or how it relates a
provider's network, would best be associated with the PID domain. provider's network, would best be associated with the PID domain.
4. Property Map Resource 4. Property Map
A Property Map returns the properties defined for all entities in one A property map returns the properties defined for all entities in one
or more domains. or more domains, e.g., the "location" property of entities in "pid"
domain, and the "ASN" property of entities in "ipv4" and "ipv6"
domains.
Section 7.4 gives an example of a property map request and its Section 7.4 gives an example of a property map request and its
response. response.
4.1. Media Type 4.1. Media Type
The media type of an ALTO Property Map resource is "application/alto- The media type of a property map is "application/alto-propmap+json".
propmap+json".
4.2. HTTP Method 4.2. HTTP Method
An ALTO Property Map resource is requested using the HTTP GET method. The property map is requested using the HTTP GET method.
4.3. Accept Input Parameters 4.3. Accept Input Parameters
None. None.
4.4. Capabilities 4.4. Capabilities
The capabilities are defined by an object of type The capabilities are defined by an object of type
PropertyMapCapabilities: PropertyMapCapabilities:
object { object {
DomainName entity-domain-types<1..*>; DomainName entity-domains<1..*>;
PropertyName prop-types<1..*>; PropertyName properties<1..*>;
} PropertyMapCapabilities; } PropertyMapCapabilities;
where "entity-domain-types" is an array with the domains of the where "entity-domains" is an array specifying the entity domains, and
entities in this property map, and "prop-types" is an array with the "properties" is an array specifying the names of the properties
names of the properties returned for entities in those domains. returned for entities in those domains. The semantics is that each
domain in "entity-domains" provides all properties defined in
"properties". If a property in "properties" is NOT supported by a
domain in "entity-domains", the server can declare different property
maps to conform to the semantics.
4.5. Uses 4.5. Uses
An array with the resource ID(s) of resource(s) with which the entity The "uses" field of a property map resource in an IRD entry specifies
domains in this map are associated. In most cases, this array will dependencies as discussed in Section 2.7. It is an array of the
have at most one ID, for example, for a network map resource. resource ID(s) of the resource(s) that properties of entities in
However, the "uses" field MUST NOT contain two resources of the same domains specified in "entity-domains" depend on.
resource type. For example, if a property map depends on network map
resource, the "uses" field MUST include exactly one network map In a single property map, every property value of every entity
resource. depends on the same array of resources. Thus, if properties depend
on different resources arrays would be provided, they MUST be split
into different property maps.
Note that according to [RFC7285], a legacy ALTO server with two
network maps, with resource IDs "net1" and "net2", could offer a
single Endpoint Property Service for the two properties "net1.pid"
and "net2.pid". An ALTO server which supports the property map
resource defined in this document, would, instead, offer two
different property maps for the "pid" property, one depending on
"net1", and the other on "net2".
4.6. Response 4.6. Response
If the entity domains in this property map depend on other resources, If the entity domains in this property map depend on other resources,
the "dependent-vtags" field in the "meta" field of the response MUST the "dependent-vtags" field in the "meta" field of the response MUST
be an array that includes the version tags of those resources. The be an array that includes the version tags of those resources, and
data component of a Property Map response is named "property-map", the order MUST be consistent with the "uses" field of this property
which is a JSON object of type PropertyMapData, where: map resource. The data component of a property map response is named
"property-map", which is a JSON object of type PropertyMapData,
where:
object { object {
PropertyMapData property-map; PropertyMapData property-map;
} InfoResourceProperties : ResponseEntityBase; } InfoResourceProperties : ResponseEntityBase;
object-map { object-map {
EntityAddr -> EntityProps; EntityAddr -> EntityProps;
} PropertyMapData; } PropertyMapData;
object { object {
PropertyName -> JSONValue; PropertyName -> JSONValue;
} EntityProps; } EntityProps;
The ResponseEntityBase type is defined in Section 8.4 of [RFC7285]. The ResponseEntityBase type is defined in Section 8.4 of [RFC7285].
Specifically, a PropertyMapData object has one member for each entity Specifically, a PropertyMapData object has one member for each entity
in the Property Map. The entity's properties are encoded in the in the property map. The entity's properties are encoded in the
corresponding EntityProps object. EntityProps encodes one name/value corresponding EntityProps object. EntityProps encodes one name/value
pair for each property, where the property names are encoded as pair for each property, where the property names are encoded as
strings of type PropertyName. A protocol implementation SHOULD strings of type PropertyName. A protocol implementation SHOULD
assume that the property value is either a JSONString or a JSON assume that the property value is either a JSONString or a JSON
"null" value, and fail to parse if it is not, unless the "null" value, and fail to parse if it is not, unless the
implementation is using an extension to this document that indicates implementation is using an extension to this document that indicates
when and how property values of other data types are signaled. when and how property values of other data types are signaled.
For each entity in the Property Map, the ALTO Server returns the For each entity in the Property Map, the ALTO server returns the
value defined for each of the properties specified in this resource's value defined for each of the properties specified in this resource's
"capabilities" list. For efficiency, the ALTO Server SHOULD omit "capabilities" list. For efficiency, the ALTO server SHOULD omit
property values that are inherited rather than explicitly defined; if property values that are inherited rather than explicitly defined; if
a client needs inherited values, the client SHOULD use the entity a client needs inherited values, the client SHOULD use the entity
domain's inheritance rules to deduce those values. domain's inheritance rules to deduce those values.
5. Filtered Property Map Resource 5. Filtered Property Map
A Filtered Property Map returns the values of a set of properties for A filtered property map returns the values of a set of properties for
a set of entities selected by the client. a set of entities selected by the client.
Section 7.5, Section 7.6 and Section 7.7 give examples of filtered Section 7.5, Section 7.6, Section 7.7 and Section 7.8 give examples
property map requests and responses. of filtered property map requests and responses.
5.1. Media Type 5.1. Media Type
The media type of an ALTO Property Map resource is "application/alto- The media type of a property map resource is "application/alto-
propmap+json". propmap+json".
5.2. HTTP Method 5.2. HTTP Method
An ALTO Filtered Property Map resource is requested using the HTTP The filtered property map is requested using the HTTP POST method.
POST method.
5.3. Accept Input Parameters 5.3. Accept Input Parameters
The input parameters for a Filtered Property Map request are supplied The input parameters for a filtered property map request are supplied
in the entity body of the POST request. This document specifies the in the entity body of the POST request. This document specifies the
input parameters with a data format indicated by the media type input parameters with a data format indicated by the media type
"application/alto-propmapparams+json", which is a JSON object of type "application/alto-propmapparams+json", which is a JSON object of type
ReqFilteredPropertyMap: ReqFilteredPropertyMap:
object { object {
EntityAddr entities<1..*>; EntityAddr entities<1..*>;
PropertyName properties<1..*>; PropertyName properties<1..*>;
} ReqFilteredPropertyMap; } ReqFilteredPropertyMap;
skipping to change at page 14, line 12 skipping to change at page 14, line 12
Note that the "entities" and "properties" fields MUST have at Note that the "entities" and "properties" fields MUST have at
least one entry each. least one entry each.
5.4. Capabilities 5.4. Capabilities
The capabilities are defined by an object of type The capabilities are defined by an object of type
PropertyMapCapabilities, as defined in Section 4.4. PropertyMapCapabilities, as defined in Section 4.4.
5.5. Uses 5.5. Uses
An array with the resource ID(s) of resource(s) with which the entity The "uses" field of a filtered property map is an array with the
domains in this map are associated. In most cases, this array will resource ID(s) of resource(s) that each domain in "entity-domains"
have at most one ID, and it will be for a network map resource. depends on, in order to provide the properties specified in the
"properties" capability. The same "uses" rule as defined by the
property map resource applies (see Section 4.5).
5.6. Response 5.6. Response
The response is the same as for the property map (see Section 4.6), The response MUST indicate an error, using ALTO protocol error
except that it only includes the entities and properties requested by handling, as defined in Section 8.5 of [RFC7285], if the request is
the client. invalid.
Also, the Filtered Property Map response MUST include all inherited Specifically, a filtered property map request can be invalid as
property values for the specified entities (unlike the Full Property follows:
Map, the Filtered Property Map response does not include enough
information for the client to calculate the inherited values).
If an entity in "entities" in the request is invalid, the ALTO server o An entity address in "entities" in the request is invalid if:
MUST return an "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2
of [RFC7285]. An entity can be invalid if the domain of the entity
is not defined in the IRD for this service or the entity address is
an invalid address of the entity domain. On the other hand, a valid
entity address is not an error, even if the server does not define a
value for a requested property. In this case, the server MUST omit
that property from the response for only that entity. If a request
contains a property in "properties" and the property is not specified
in the IRD for the service, the ALTO server MUST return an
"E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of [RFC7285].
The "value" of the error message SHOULD indicate the wrong property.
If the ALTO server does not define a requested property's value for a * The domain of this entity is not defined in the "entity-domain-
particular entity, then it MUST omit that property from the response types" capability of this resource in the IRD;
for only that endpoint.
If the ALTO server does not support a requested entity's domain, then * The entity address is an invalid address in the entity domain.
it MUST return an E_INVALID_FIELD_VALUE error defined in
Section 8.5.2 of [RFC7285]. A valid entity address is never an error, even if this filtered
property map resource does not define any properties for it.
If an entity address in "entities" in the request is invalid, the
ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
in Section 8.5.2 of [RFC7285], and the "value" field of the error
message SHOULD indicate this entity address.
o A property name in "properties" in the request is invalid if this
property name is not defined in the "property-types" capability of
this resource in the IRD.
It is not an error that a filtered property map resource does not
define a requested property's value for a particular entity. In
this case, the ALTO server MUST omit that property from the
response for that endpoint.
If a property name in "properties" in the request is invalid, the
ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
in Section 8.5.2 of [RFC7285]. The "value" field of the error
message SHOULD indicate the property name.
The response to a valid request is the same as for the Property Map
(see Section 4.6), except that:
o The "dependent-vtags" field in its "meta" field only includes the
version tags of resources on which the requested properties of the
entity domains depend, and the order MUST be consistent with the
"uses" field of this filtered property map resource.
o It only includes the entities and properties requested by the
client. If an entity in the request is an address block (e.g., an
"ipv4" or "ipv6" entity), the response MUST cover properties for
all addresses in this block.
It is important that the filtered property map response MUST include
all inherited property values for the requested entities and all the
entities which are able to inherit property values from them. To
achieve this goal, the ALTO server MAY follow three rules:
o If a property for a requested entity is inherited from another
entity not included in the request, the response SHOULD include
this property for the requested entity. For example, A full
property map may skip a property P for an entity A (e.g.,
ipv4:192.0.2.0/31) if P can be derived using inheritance from
another entity B (e.g., ipv4:192.0.2.0/30). A filtered property
map request may include only A but not B. In such a case, the
property P SHOULD be included in the response for A.
o If there are entities covered by a requested entity but having
different values for the requested properties, the response SHOULD
include all those entities and the different property values for
them. For example, considering a request for property P of entity
A (e.g., ipv4:192.0.2.0/31), if P has value v1 for
A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the
response SHOULD include A1 and A2.
o If an entity in the response is already covered by some other
entities in the same response, it SHOULD be removed from the
response for compactness. For example, in the previous example,
the entity A=ipv4:192.0.2.0/31 SHOULD be removed because A1 and A2
cover all the addresses in A.
An ALTO client should be aware that the entities in the response MAY
be different from the entities in its request.
6. Impact on Legacy ALTO Servers and ALTO Clients 6. Impact on Legacy ALTO Servers and ALTO Clients
6.1. Impact on Endpoint Property Service 6.1. Impact on Endpoint Property Service
The Property Maps defined in this document provide the same Since the property map and the filtered property map defined in this
functionality as the Endpoint Property Service (EPS) defined in document provide the functionality of the Endpoint Property Service
Section 11.4 of [RFC7285]. Accordingly, it is RECOMMENDED that the (EPS) defined in Section 11.4 of [RFC7285], it is RECOMMENDED that
EPS be deprecated in favor of Property Maps. However, ALTO servers the EPS be deprecated in favor of Property Map and Filtered Property
MAY provide an EPS for the benefit of legacy clients. Map. However, ALTO servers MAY provide an EPS for the benefit of
legacy clients.
6.2. Impact on Resource-Specific Properties 6.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 resources defined in this document do not distinguish between map and the filtered property map defined in this document do not
those two types of properties. Instead, if there is a dependency, it distinguish between those two types of properties. Instead, if there
is indicated by the "uses" capability of a property map, and is is a dependency, it is indicated by the "uses" capability of a
shared by all properties and entity domains in that map. property map, and is shared by all properties and entity domains in
Accordingly, it is RECOMMENDED that resource-specific endpoint that map. Accordingly, it is RECOMMENDED that resource-specific
properties be deprecated, and no new resource-specific endpoint endpoint properties be deprecated, and no new resource-specific
properties be defined. endpoint properties be defined.
6.3. Impact on the pid Property 6.3. Impact on the pid Property
Section 7.1.1 of [RFC7285] defines the resource-specific endpoint Section 7.1.1 of [RFC7285] defines the resource-specific endpoint
property name "pid", whose value is the name of the PID containing property name "pid", whose value is the name of the PID containing
that endpoint. For compatibility with legacy clients, an ALTO server that endpoint. For compatibility with legacy clients, an ALTO server
which provides the "pid" property via the Endpoint Property Service which provides the "pid" property via the EPS MUST use that
MUST use that definition, and that syntax, in the EPS resource. definition, and that syntax.
However, when used with Property Maps, this document amends the However, when used with property maps, this document amends the
definition of the "pid" property as follows. definition of the "pid" property as follows.
First, the name of the property is simply "pid"; the name is not First, the name of the property is simply "pid"; the name is not
prefixed with the resource ID of a network map. The "uses" prefixed with the resource ID of a network map. The "uses"
capability of the property map resource indicates the associated capability of the property map indicates the associated network map.
network map. This implies that a property map can only return the This implies that a property map can only return the "pid" property
"pid" property for one network map; if an ALTO server provides for one network map; if an ALTO server provides several network maps,
several network maps, it MUST provide a property map resource for it MUST provide a Property Map for each of the network maps.
each one.
Second, a client MAY request the "pid" property for a block of Second, a client MAY request the "pid" property for a block of
addresses. An ALTO server determines the value of "pid" for an addresses. An ALTO server determines the value of "pid" for an
address block C as follows. Let CS be the set of all address blocks address block C as the rules defined in Section 5.6.
in the network map. If C is in CS, then the value of "pid" is the
name of the PID associated with C. Otherwise, find the longest block
C' in CS such that C' prefix-matches C, but is shorter than C. If
there is such a block C', the value of "pid" is the name of the PID
associated with C'. If not, then "pid" has no value for block C.
Note that although an ALTO server MAY provide a GET-mode property map Note that although an ALTO server MAY provide a GET-mode property map
resource which returns the entire map for the "pid" property, there which returns the entire map for the "pid" property, there is no need
is no need to do so, because that map is simply the inverse of the to do so, because that map is simply the inverse of the network map.
network map.
6.4. Impact on Other Properties 6.4. 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 addresses, rather than just individual now be defined on blocks of addresses, rather than just individual
addresses, which might change the semantics of a property. addresses, which might change the semantics of a property.
7. Examples 7. Examples
7.1. Network Map 7.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
pid3: ipv4:192.0.3.0/28
pid4: ipv4:192.0.3.16/28
Figure 3: Example Network Map Figure 3: Example Network Map
7.2. Property Definitions 7.2. Property Definitions
The examples in this section use four additional properties, "ISP", Beyond "pid", the examples in this section use four additional
"ASN", "country" and "state", with the following values: properties for Internet address domains, "ISP", "ASN", "country" and
"state", with the following values:
ISP ASN country state ISP ASN country state
ipv4:192.0.2.0/24: BitsRus - us - ipv4:192.0.2.0/23: BitsRus - us -
ipv4:192.0.2.0/28: - 12345 - NJ ipv4:192.0.2.0/28: - 12345 - NJ
ipv4:192.0.2.16/28: - 12345 - CT ipv4:192.0.2.16/28: - 12345 - CT
ipv4:192.0.2.0: - - - PA ipv4:192.0.2.0: - - - PA
ipv4:192.0.3.0/28: - 12346 - TX
ipv4:192.0.3.16/28: - 12346 - MN
Figure 4: Example Property Values Figure 4: Example Property Values for Internet Address Domains
And the examples in this section use the property "region" for PID
domain with the following values:
region
pid:defaultpid: -
pid:pid1: west
pid:pid2: east
pid:pid3: south
pid:pid4: north
Figure 5: Example Property Values for PID Domain
Note that "-" means the value of the property for the entity is
"undefined". So the entity would inherit a value for this property
by the inheritance rule if possible. For example, the value of the
"ISP" property for "ipv4:192.0.2.0" is "BitsRus" because of
"ipv4:192.0.2.0/24". But the "region" property for "pid:defaultpid"
has no value because no entity from which it can inherit.
7.3. Information Resource Directory (IRD) 7.3. Information Resource Directory (IRD)
The following IRD defines the relevant resources of the ALTO server. The following IRD defines the relevant resources of the ALTO server.
It provides two Property Map resources, one for the "ISP" and "ASN" It provides two property maps, one for the "ISP" and "ASN"
properties, and another for the "country" and "state" properties. properties, and another for the "country" and "state" properties.
The server could have provided a Property Map resource for all four The server could have provided a single property map for all four
properties, but did not, presumably because the organization that properties, but did not, presumably because the organization that
runs the ALTO server believes any given client is not interested in runs the ALTO server believes any given client is not interested in
all four properties. all four properties.
The server provides two Filtered Property Maps. The first returns The server provides two filtered property maps. The first returns
all four properties, and the second just returns the "pid" property all four properties, and the second just returns the "pid" property
for the default network map. for the default network map.
The Filtered Property Maps for the "ISP", "ASN", "country" and The filtered property maps for the "ISP", "ASN", "country" and
"state" properties do not depend on the default network map (it does "state" properties do not depend on the default network map (it does
not have a "uses" capability), because the definitions of those not have a "uses" capability), because the definitions of those
properties do not depend on the default network map. The Filtered properties do not depend on the default network map. The Filtered
Property Map for the "pid" property does have a "uses" capability for Property Map for the "pid" property does have a "uses" capability for
the default network map, because that defines the values of the "pid" the default network map, because that defines the values of the "pid"
property. property.
Note that for legacy clients, the ALTO server provides an Endpoint Note that for legacy clients, the ALTO server provides an Endpoint
Property Service for the "pid" property for the default network map. Property Service for the "pid" property for the default network map.
"meta": { ... }, "meta" : {
...
"default-alto-network-map" : "default-network-map"
},
"resources" : { "resources" : {
"default-network-map" : { "default-network-map" : {
"uri" : "http://alto.example.com/networkmap", "uri" : "http://alto.example.com/networkmap",
"media-type" : "application/alto-networkmap+json" "media-type" : "application/alto-networkmap+json"
}, },
.... property map resources .... .... property map resources ....
"country-state-property-map" : { "country-state-property-map" : {
"uri" : "http://alto.example.com/propmap/full/inet-cs", "uri" : "http://alto.example.com/propmap/full/inet-cs",
"media-type" : "application/alto-propmap+json", "media-type" : "application/alto-propmap+json",
"capabilities" : { "capabilities" : {
"entity-domain-types": [ "ipv4", "ipv6" ], "entity-domains": [ "ipv4", "ipv6" ],
"prop-types" : [ "country", "state" ] "properties" : [ "country", "state" ]
} }
}, },
"isp-asn-property-map" : { "isp-asn-property-map" : {
"uri" : "http://alto.example.com/propmap/full/inet-ia", "uri" : "http://alto.example.com/propmap/full/inet-ia",
"media-type" : "application/alto-propmap+json", "media-type" : "application/alto-propmap+json",
"capabilities" : { "capabilities" : {
"entity-domain-types": [ "ipv4", "ipv6" ], "entity-domains": [ "ipv4", "ipv6" ],
"prop-types" : [ "ISP", "ASN" ] "properties" : [ "ISP", "ASN" ]
} }
}, },
"iacs-property-map" : { "iacs-property-map" : {
"uri" : "http://alto.example.com/propmap/lookup/inet-iacs", "uri" : "http://alto.example.com/propmap/lookup/inet-iacs",
"media-type" : "application/alto-propmap+json", "media-type" : "application/alto-propmap+json",
"accepts" : "application/alto-propmapparams+json", "accepts" : "application/alto-propmapparams+json",
"capabilities" : { "capabilities" : {
"entity-domain-types": [ "ipv4", "ipv6" ], "entity-domains": [ "ipv4", "ipv6" ],
"prop-types" : [ "ISP", "ASN", "country", "state" ] "properties" : [ "ISP", "ASN", "country", "state" ]
} }
}, },
"pid-property-map" : { "pid-property-map" : {
"uri" : "http://alto.example.com/propmap/lookup/pid", "uri" : "http://alto.example.com/propmap/lookup/pid",
"media-type" : "application/alto-propmap+json", "media-type" : "application/alto-propmap+json",
"accepts" : "application/alto-propmapparams+json", "accepts" : "application/alto-propmapparams+json",
"uses" : [ "default-network-map" ] "uses" : [ "default-network-map" ]
"capabilities" : { "capabilities" : {
"entity-domain-types" : [ "ipv4", "ipv6" ], "entity-domains" : [ "ipv4", "ipv6" ],
"prop-types" : [ "pid" ] "properties" : [ "pid" ]
} }
}, },
"location-property-map": { "region-property-map": {
"uri": "http://alto.exmaple.com/propmap/location", "uri": "http://alto.exmaple.com/propmap/region",
"media-type": "application/alto-propmap+json", "media-type": "application/alto-propmap+json",
"accepts": "application/alto-propmapparams+json", "accepts": "application/alto-propmapparams+json",
"uses" : [ "default-network-map" ], "uses" : [ "default-network-map" ],
"capabilities": { "capabilities": {
"domain-types": [ "pid" ], "domain-types": [ "pid" ],
"prop-types": [ "country", "state" ] "properties": [ "region" ]
} }
}, },
"legacy-pid-property" : { "legacy-pid-property" : {
"uri" : "http://alto.example.com/legacy/eps-pid", "uri" : "http://alto.example.com/legacy/eps-pid",
"media-type" : "application/alto-endpointprop+json", "media-type" : "application/alto-endpointprop+json",
"accepts" : "application/alto-endpointpropparams+json", "accepts" : "application/alto-endpointpropparams+json",
"capabilities" : { "capabilities" : {
"prop-types" : [ "default-network-map.pid" ] "properties" : [ "default-network-map.pid" ]
} }
} }
} }
Figure 5: Example IRD Figure 6: Example IRD
7.4. Property Map Example 7.4. Property Map Example
The following example uses the properties and IRD defined above to The following example uses the properties and IRD defined above to
retrieve a property map for entities with the "ISP" and "ASN" retrieve a Property Map for entities with the "ISP" and "ASN"
properties. Note that the response does not include the entity properties.
"ipv4:192.0.2.0", because it does not have a value for either of
those properties. Also note that the entities "ipv4:192.0.2.0/28" Note that, to be compact, the response does not includes the entity
and "ipv4:192.0.2.16/28" are refinements of "ipv4:192.0.2.0/24", and "ipv4:192.0.2.0", because values of all those properties for this
hence inherit its value for "ISP" property. But because that value entity are inherited from other entities.
is inherited, it is not explicitly listed in the property map.
Also note that the entities "ipv4:192.0.2.0/28" and
"ipv4:192.0.2.16/28" are merged into "ipv4:192.0.2.0/27", because
they have the same value of the "ASN" property. The same rule
applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28".
Both of "ipv4:192.0.2.0/27" and "ipv4:192.0.3.0/27" omit the value
for the "ISP" property, because it is inherited from
"ipv4:192.0.2.0/23".
GET /propmap/full/inet-ia HTTP/1.1 GET /propmap/full/inet-ia HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json Accept: application/alto-propmap+json,application/alto-error+json
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: ### Content-Length: ###
Content-Type: application/alto-propmap+json Content-Type: application/alto-propmap+json
{ {
"property-map": { "property-map": {
"ipv4:192.0.2.0/24": {"ISP": "BitsRus"}, "ipv4:192.0.2.0/23": {"ISP": "BitsRus"},
"ipv4:192.0.2.0/28": {"ASN": "12345"}, "ipv4:192.0.2.0/27": {"ASN": "12345"},
"ipv4:192.0.2.16/28": {"ASN": "12345"} "ipv4:192.0.3.0/27": {"ASN": "12346"}
} }
} }
7.5. Filtered Property Map Example #1 7.5. Filtered Property Map Example #1
The following example uses the Filtered Property Map resource to The following example uses the filtered property map resource to
request the "ISP", "ASN" and "state" properties for several IPv4 request the "ISP", "ASN" and "state" properties for several IPv4
addresses. Note that the value of "state" for "ipv4:192.0.2.0" is addresses.
the only explicitly defined property; the other values are all
derived by the inheritance rules for Internet address entities. Note that the value of "state" for "ipv4:192.0.2.0" is the only
explicitly defined property; the other values are all derived by the
inheritance rules for Internet address entities.
POST /propmap/lookup/inet-iacs HTTP/1.1 POST /propmap/lookup/inet-iacs HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: ### Content-Length: ###
Content-Type: application/alto-propmapparams+json Content-Type: application/alto-propmapparams+json
{ {
"entities" : [ "ipv4:192.0.2.0", "entities" : [ "ipv4:192.0.2.0",
"ipv4:192.0.2.1", "ipv4:192.0.2.1",
skipping to change at page 20, line 35 skipping to change at page 21, line 45
{"ISP": "BitsRus", "ASN": "12345", "state": "PA"}, {"ISP": "BitsRus", "ASN": "12345", "state": "PA"},
"ipv4:192.0.2.1": "ipv4:192.0.2.1":
{"ISP": "BitsRus", "ASN": "12345", "state": "NJ"}, {"ISP": "BitsRus", "ASN": "12345", "state": "NJ"},
"ipv4:192.0.2.17": "ipv4:192.0.2.17":
{"ISP": "BitsRus", "ASN": "12345", "state": "CT"} {"ISP": "BitsRus", "ASN": "12345", "state": "CT"}
} }
} }
7.6. Filtered Property Map Example #2 7.6. Filtered Property Map Example #2
The following example uses the Filtered Property Map resource to The following example uses the filtered property map resource to
request the "ASN", "country" and "state" properties for several IPv4 request the "ASN", "country" and "state" properties for several IPv4
prefixes. Note that none of the returned property values is prefixes.
explicitly defined; all values are derived by the inheritance rules
for Internet address entities.
Also note the "ASN" property has the value "12345" for both the Note that the property values for both entities "ipv4:192.0.2.0/26"
blocks "ipv4:192.0.2.0/28" and "ipv4:192.0.2.16/28", so every address and "ipv4:192.0.3.0/26" are not explicitly defined. They are
in the block "ipv4:192.0.2.0/27" has that property value. However inherited from the entity "ipv4:192.0.2.0/23".
the block "ipv4:192.0.2.0/27" itself does not have a value for "ASN":
address blocks cannot inherit properties from blocks with longer Also note that some entities like "ipv4:192.0.2.0/28" and
prefixes, even if every such block has the same value. "ipv4:192.0.2.16/28" in the response are not listed in the request
explicitly. The response includes them because they are refinements
of the requested entities and have different values for the requested
properties.
The entity "ipv4:192.0.4.0/26" is not included in the response,
because there are neither entities which it is inherited from, nor
entities inherited from it.
POST /propmap/lookup/inet-iacs HTTP/1.1 POST /propmap/lookup/inet-iacs HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: ### Content-Length: ###
Content-Type: application/alto-propmapparams+json Content-Type: application/alto-propmapparams+json
{ {
"entities" : [ "ipv4:192.0.2.0/26", "entities" : [ "ipv4:192.0.2.0/26",
"ipv4:192.0.2.0/27", "ipv4:192.0.3.0/26",
"ipv4:192.0.2.0/28" ], "ipv4:192.0.4.0/26" ],
"properties" : [ "ASN", "country", "state" ] "properties" : [ "ASN", "country", "state" ]
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: ### Content-Length: ###
Content-Type: application/alto-propmap+json Content-Type: application/alto-propmap+json
{ {
"property-map": { "property-map": {
"ipv4:192.0.2.0/26": {"country": "us"}, "ipv4:192.0.2.0/26": {"country": "us"},
"ipv4:192.0.2.0/27": {"country": "us"},
"ipv4:192.0.2.0/28": {"ASN": "12345", "ipv4:192.0.2.0/28": {"ASN": "12345",
"country": "us", "state": "NJ"},
"state": "NJ"} "ipv4:192.0.2.16/28": {"ASN": "12345",
"state": "CT"},
"ipv4:192.0.2.0": {"state": "PA"},
"ipv4:192.0.3.0/26": {"country": "us"},
"ipv4:192.0.3.0/28": {"ASN": "12345",
"state": "TX"},
"ipv4:192.0.3.16/28": {"ASN": "12345",
"state": "MN"}
} }
} }
7.7. Filtered Property Map Example #3 7.7. Filtered Property Map Example #3
The following example uses the Filtered Property Map resource to The following example uses the filtered property map resource to
request the "pid" property for several IPv4 addresses and prefixes. request the "pid" property for several IPv4 addresses and prefixes.
Note that the value of "pid" for the prefix "ipv4:192.0.2.0/26" is Note that the entity "ipv4:192.0.3.0/27" is redundant in the
"pid1", even though all addresses in that block are in "pid2", response. Although it can inherit a value of "defaultpid" for the
because "ipv4:192.0.2.0/25" is the longest prefix in the network map "pid" property from the entity "ipv4:0.0.0.0/0", none of addresses in
which prefix-matches "ipv4:192.0.2.0/26", and that prefix is in it is in "defaultpid". Because blocks "ipv4:192.0.3.0/28" and
"pid1". "ipv4:192.0.3.16/28" have already cover all addresses in that block.
So an ALTO server who wants a compact response can omit this entity.
POST /propmap/lookup/pid HTTP/1.1 POST /propmap/lookup/pid HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: ### Content-Length: ###
Content-Type: application/alto-propmapparams+json Content-Type: application/alto-propmapparams+json
{ {
"entities" : [ "entities" : [
"ipv4:192.0.2.0",
"ipv4:192.0.2.16",
"ipv4:192.0.2.64",
"ipv4:192.0.2.128", "ipv4:192.0.2.128",
"ipv4:192.0.2.0/26", "ipv4:192.0.3.0/27" ],
"ipv4:192.0.2.0/30" ],
"properties" : [ "pid" ] "properties" : [ "pid" ]
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: ### Content-Length: ###
Content-Type: application/alto-propmap+json Content-Type: application/alto-propmap+json
{ {
"meta" : { "meta" : {
"dependent-vtags" : [ "dependent-vtags" : [
{"resource-id": "default-network-map", {"resource-id": "default-network-map",
"tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}
] ]
}, },
"property-map": { "property-map": {
"ipv4:192.0.2.0": {"pid": "pid2"},
"ipv4:192.0.2.16": {"pid": "pid2"},
"ipv4:192.0.2.64": {"pid": "pid1"},
"ipv4:192.0.2.128": {"pid": "defaultpid"}, "ipv4:192.0.2.128": {"pid": "defaultpid"},
"ipv4:192.0.2.0/26": {"pid": "pid1"}, "ipv4:192.0.2.0/27": {"pid": "defaultpid"},
"ipv4:192.0.2.0/30": {"pid": "pid2"} "ipv4:192.0.3.0/28": {"pid": "pid3"},
"ipv4:192.0.3.16/28": {"pid": "pid4"}
} }
} }
7.8. Filtered Property Map Example #4 7.8. Filtered Property Map Example #4
The following example uses the Filtered Property Map resource to The following example uses the filtered property map resource to
request the "country" and "state" property for several PIDs defined request the "region" property for several PIDs defined in "default-
in "default-network-map". network-map". The value of the "region" property for each PID is not
defined by "default-network-map", but the reason why the PID is
defined by the network operator.
POST /propmap/lookup/location HTTP/1.1 POST /propmap/lookup/region HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: ### Content-Length: ###
Content-Type: application/alto-propmapparams+json Content-Type: application/alto-propmapparams+json
{ {
"entities" : ["pid:pid3", "entities" : ["pid:pid1",
"pid:pid4", "pid:pid2"],
"pid:pid5", "properties" : [ "region" ]
"pid:pid6",
"pid:pid7"],
"properties" : [ "country", "state" ]
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: ### Content-Length: ###
Content-Type: application/alto-propmap+json Content-Type: application/alto-propmap+json
{ {
"meta" : { "meta" : {
"dependent-vtags" : [ "dependent-vtags" : [
{"resource-id": "default-network-map", {"resource-id": "default-network-map",
"tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}
] ]
}, },
"property-map": { "property-map": {
"pid:pid3": { "pid:pid1": {
"country": "us", "region": "west"
"state": "CA"
},
"pid:pid4": {
"country": "us",
"state": "CT"
},
"pid:pid5": {
"country": "ca",
"state": "QC"
},
"pid:pid6": {
"country": "ca",
"state": "NT"
}, },
"pid:pid7": { "pid:pid2": {
"country": "fr" "region": "east"
} }
} }
} }
8. Security Considerations 8. Security Considerations
As discussed in Section 15 of [RFC7285], properties MAY have Both Property Map and Filtered Property Map defined in this document
sensitive customer-specific information. If this is the case, an fit into the architecture of the ALTO base protocol, and hence the
ALTO Server MAY limit access to those properties by providing several Security Considerations (Section 15 of [RFC7285]) of the base
different Property Maps. For non-sensitive properties, the ALTO protocol fully apply: authenticity and integrity of ALTO information
Server would provide a URI which accepts requests from any client. (i.e., authenticity and integrity of Property Maps), potential
Sensitive properties, on the other hand, would only be available via undesirable guidance from authenticated ALTO information (e.g.,
a secure URI which would require client authentication. potentially imprecise or even wrong value of a property such as geo-
location), confidentiality of ALTO information (e.g., exposure of a
potentially sensitive entity property such as geo-location), privacy
for ALTO users, and availability of ALTO services should all be
considered.
Also, while technically this document does not introduce any security A particular fundamental security consideration when an ALTO server
risks not inherent in the Endpoint Property Service defined by provides a Property Map is to define precisely the policies on who
[RFC7285], the GET-mode property map resource defined in this can access what properties for which entities. Security mechanisms
document does make it easier for a client to download large numbers such as authentication and confidentiality mechanisms then should be
of property values. Accordingly, an ALTO Server SHOULD limit GET- applied to enforce the policy. For example, a policy can be that a
mode Property Maps to properties which do not contain sensitive data. property P can be accessed only by its owner (e.g., the customer who
is allocated a given IP address). Then, the ALTO server will need to
deploy corresponding mechanisms to realize the policy. The policy
may allow non-owners to access a coarse-grained value of the property
P. In such a case, the ALTO server may provide a different URI to
provide the information.
9. IANA Considerations 9. IANA Considerations
This document defines additional application/alto-* media types, and This document defines additional application/alto-* media types, and
extends the ALTO endpoint property registry. extends the ALTO endpoint property registry.
9.1. application/alto-* Media Types 9.1. application/alto-* Media Types
This document registers two additional ALTO media types, listed in This document registers two additional ALTO media types, listed in
Table 1. Table 1.
skipping to change at page 26, line 5 skipping to change at page 27, line 5
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: Internet Engineering Task Force Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org). (mailto:iesg@ietf.org).
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 Encoding | Hierarchy & Inheritance | | Identifier | Entity Address | Hierarchy & | Mapping to ALTO |
+-------------+--------------------------+--------------------------+ | | Encoding | Inheritance | Address Type |
| ipv4 | See Section 3.1.1 | See Section 3.1.3 | +------------+----------------+------------------+------------------+
| ipv6 | See Section 3.1.2 | See Section 3.1.3 | | ipv4 | See Section | See Section | Yes |
| pid | See Section 3.2 | None | | | 3.1.1 | 3.1.3 | |
+-------------+--------------------------+--------------------------+ | ipv6 | See Section | See Section | Yes |
| | 3.1.2 | 3.1.3 | |
| pid | See Section | None | No |
| | 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 27, line 9 skipping to change at page 28, line 13
"ipv6" in Table 2. "ipv6" in Table 2.
o Whether the candidate entity address of the entity domain is able o Whether the candidate entity address of the entity domain is able
to be an endpoint address, as defined in Sections 2.1 and 2.2 of to be an endpoint address, as defined in Sections 2.1 and 2.2 of
[RFC7285]. [RFC7285].
When a new ALTO entity domain is registered, the consistency with the When a new ALTO entity domain is registered, the consistency with the
ALTO Address Type Registry MUST be ensured by the following ALTO Address Type Registry MUST be ensured by the following
procedure: procedure:
o test: Do corresponding entity addresses match a known "network" o Test: Do corresponding entity addresses 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 identifier to be
the found ALTO address type identifier. 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 identifier and use
it to register a new address type in the ALTO Address it to register a new address type in the ALTO Address
Type Registry following Section 14.4 of [RFC7285]. 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 identifier to register a new
ALTO entity domain in the ALTO Entity Domain Registry ALTO entity domain in the ALTO Entity Domain Registry
following Section 9.2.2 of this document. following Section 9.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 registration as described in
Section 9.2.2. Section 9.2.2.
9.2.2. ALTO Entity Domain Registration Process 9.2.2. ALTO Entity Domain Registration Process
New ALTO entity domains are assigned after IETF Review [RFC5226] to New ALTO entity domains are assigned after IETF Review [RFC5226] to
ensure that proper documentation regarding the new ALTO entity ensure that proper documentation regarding the new ALTO entity
domains and their security considerations has been provided. RFCs domains and their security considerations has been provided. RFCs
defining new entity domains SHOULD indicate how an entity in a defining new entity domains SHOULD indicate how an entity in a
registered domain is encoded as an EntityAddr, and, if applicable, registered domain is encoded as an EntityAddr, and, if applicable,
skipping to change at page 28, line 22 skipping to change at page 29, line 24
defining properties, an individual entity address and the defining properties, an individual entity address 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
entity domain can be mapped to the ALTO address type with the same
identifier.
o Security Considerations: In some usage scenarios, entity addresses o Security Considerations: In some usage scenarios, entity addresses
carried in ALTO Protocol messages MAY reveal information about an carried in ALTO Protocol messages may reveal information about an
ALTO client or an ALTO service provider. Applications and ALTO ALTO client or an ALTO service provider. Applications and ALTO
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 Endpoint Property Type Registry 9.3. ALTO Entity Property Type Registry
The ALTO Endpoint Property Type Registry was created by [RFC7285]. This document requests IANA to create and maintain the "ALTO Entity
If possible, the name of that registry SHOULD be changed to "ALTO Property Type Registry".
Entity Property Type Registry", to indicate that it is not restricted
to Endpoint Properties. If it is not feasible to change the name,
the description MUST be amended to indicate that it registers
properties in all entity domains, rather than just the Internet
address domain.
10. References To distinguish with the "ALTO Endpoint Property Type Registry", this
new registry is for properties in all possible entity domains, rather
than just the Internet address domain. So it is necessary to define
and process the consistency between the two registries.
10.1. Normative References In the meanwhile, because every entity property is owned by some
entity domains, for each registered entity property, the ALTO Entity
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
dependent resources and how the ALTO client uses them in order.
TODO: The registry format and the initial content
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,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 29, line 35 skipping to change at page 30, line 48
[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>.
10.2. Informative References
[I-D.ietf-alto-path-vector]
Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W.,
Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path
Vector Cost Type", draft-ietf-alto-path-vector-03 (work in
progress), March 2018.
Authors' Addresses Authors' Addresses
Wendy Roome Wendy Roome
Nokia Bell Labs (Retired) Nokia Bell Labs (Retired)
124 Burlington Rd 124 Burlington Rd
Murray Hill, NJ 07974 Murray Hill, NJ 07974
USA USA
Phone: +1-908-464-6975 Phone: +1-908-464-6975
Email: wendy@wdroome.com Email: wendy@wdroome.com
Shiwei Dawn Chen Shiwei Dawn Chen
Tongji University Tongji University
4800 Caoan Road 4800 Caoan Road
Shanghai 201804 Shanghai 201804
China China
Email: dawn_chen_f@hotmail.com Email: dawn_chen_f@hotmail.com
Sabine Randriamasy Sabine Randriamasy
Nokia Bell Labs Nokia Bell Labs
 End of changes. 136 change blocks. 
398 lines changed or deleted 489 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/