draft-ietf-alto-unified-props-new-11.txt   draft-ietf-alto-unified-props-new-12.txt 
ALTO WG W. Roome ALTO WG W. Roome
Internet-Draft S. Randriamasy Internet-Draft S. Randriamasy
Intended status: Standards Track Nokia Bell Labs Intended status: Standards Track Nokia Bell Labs
Expires: September 10, 2020 Y. Yang Expires: January 14, 2021 Y. Yang
Yale University Yale University
J. Zhang J. Zhang
Tongji University Tongji University
K. Gao K. Gao
Sichuan University Sichuan University
March 9, 2020 July 13, 2020
Unified Properties for the ALTO Protocol Unified properties for the ALTO protocol
draft-ietf-alto-unified-props-new-11 draft-ietf-alto-unified-props-new-12
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 generic types of entities, and by presenting those properties" to generic types of entities, and by presenting those
properties as maps, similar to the network and cost maps in properties as maps, similar to the network and cost maps in
[RFC7285]. [RFC7285].
Requirements Language Requirements Language
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 September 10, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Basic Features of the Unified Property Extension . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
2.2. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 7 3. Basic Features of the Unified Property Extension . . . . . . 6
2.3. Entity Property . . . . . . . . . . . . . . . . . . . . . 7 3.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. New information resource and media type: ALTO Property 3.2. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 7
Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 8
3. Advanced Features of the Unified Property Extension . . . . . 8 3.2.2. Entity Domain Name . . . . . . . . . . . . . . . . . 8
3.1. Entity Identifier and Entity Domain . . . . . . . . . . . 8 3.3. Entity Property Type . . . . . . . . . . . . . . . . . . 8
3.2. Resource-Specific Entity Domain Name . . . . . . . . . . 8 3.4. New information resource and media type: ALTO Property
3.3. Resource-Specific Entity Property . . . . . . . . . . . . 9 Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Entity Hierarchy and Property Inheritance . . . . . . . . 10 4. Advanced Features of the Unified Property Extension . . . . . 10
3.5. Applicable Entity Domains and Properties in the Property 4.1. Entity Identifier and Entity Domain Name . . . . . . . . 10
Map Capabilities . . . . . . . . . . . . . . . . . . . . 11 4.2. Resource-Specific Entity Domain Name . . . . . . . . . . 10
3.6. Connection between Resource-Specific Entity Domain/Entity 4.3. Resource-Specific Entity Property Value . . . . . . . . . 11
Property Mapping and Information Resources . . . . . . . 11 4.4. Entity Hierarchy and Property Inheritance . . . . . . . . 12
4. Protocol Specification: Basic Data Type . . . . . . . . . . . 12 4.4.1. Entity Hierarchy . . . . . . . . . . . . . . . . . . 12
4.1. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 12 4.4.2. Property Inheritance . . . . . . . . . . . . . . . . 13
4.1.1. Entity Domain Type . . . . . . . . . . . . . . . . . 12 4.4.3. Property Value Unicity . . . . . . . . . . . . . . . 13
4.1.2. Entity Domain Name . . . . . . . . . . . . . . . . . 12 4.5. Supported Properties on Entity Domains in Property Map
4.1.3. Entity Identifier . . . . . . . . . . . . . . . . . . 13 Capabilities . . . . . . . . . . . . . . . . . . . . . . 14
4.1.4. Hierarchy and Inheritance . . . . . . . . . . . . . . 14 4.6. Defining Information Resource . . . . . . . . . . . . . . 14
4.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 14 4.6.1. Defining Information Resource and Media Type . . . . 15
4.2.1. Entity Property Type . . . . . . . . . . . . . . . . 14 4.6.2. Examples of specific resources media-types . . . . . 16
4.2.2. Entity Property Name . . . . . . . . . . . . . . . . 15 4.7. Defining Information Resource for Resource-Specific
5. Entity Domain Types . . . . . . . . . . . . . . . . . . . . . 15 Property Values . . . . . . . . . . . . . . . . . . . . . 17
5.1. Internet Address Domain Types . . . . . . . . . . . . . . 16 4.7.1. Examples of defining resources media-types for
5.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 16 properties . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 16 5. Protocol Specification: Basic Data Type . . . . . . . . . . . 17
5.1.3. Hierarchy and Inheritance of Internet Address Domains 17 5.1. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 17
5.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.1. Entity Domain Type . . . . . . . . . . . . . . . . . 18
5.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 18 5.1.2. Entity Domain Name . . . . . . . . . . . . . . . . . 18
5.2.2. Domain-Specific Entity Identifiers . . . . . . . . . 18 5.1.3. Entity Identifier . . . . . . . . . . . . . . . . . . 20
5.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 18 5.1.4. Hierarchy and Inheritance . . . . . . . . . . . . . . 20
5.2.4. Relationship To Internet Addresses Domains . . . . . 18 5.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 21
5.3. Internet Address Properties vs. PID Properties . . . . . 19 5.2.1. Entity Property Type . . . . . . . . . . . . . . . . 21
6. Entity Domains and Property Mappings in Information Resources 19 5.2.2. Entity Property Name . . . . . . . . . . . . . . . . 22
6.1. Information Resource Export . . . . . . . . . . . . . . . 19 5.2.3. Format for Entity Property Value . . . . . . . . . . 22
6.1.1. Resource-Specific Entity Domain Export . . . . . . . 19 6. Entity Domain Types Defined in this Document . . . . . . . . 22
6.1.2. Entity Property Mapping Export . . . . . . . . . . . 20 6.1. Internet Address Domain Types . . . . . . . . . . . . . . 23
6.2. Network Map Resource . . . . . . . . . . . . . . . . . . 20 6.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 23
6.2.1. Resource-Specific Entity Domain . . . . . . . . . . . 20 6.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 23
6.2.2. Entity Property Mapping . . . . . . . . . . . . . . . 20 6.1.3. Hierarchy and Inheritance of Internet Address Domains 23
6.3. Endpoint Property Resource . . . . . . . . . . . . . . . 21 6.1.4. Defining Information Resource Media Type for domain
6.3.1. Resource-Specific Entity Domain . . . . . . . . . . . 21 types IPv4 and IPv6 . . . . . . . . . . . . . . . . . 25
6.3.2. Entity Property Mapping . . . . . . . . . . . . . . . 21 6.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 25
6.4. Property Map Resource . . . . . . . . . . . . . . . . . . 21 6.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 25
7. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2.2. Domain-Specific Entity Identifiers . . . . . . . . . 25
7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 22 6.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 25
7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 22 6.2.4. Defining Information Resource Media Type for Domain
7.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 22 Type PID . . . . . . . . . . . . . . . . . . . . . . 25
7.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 22 6.2.5. Relationship To Internet Addresses Domains . . . . . 26
7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.3. Internet Address Properties vs. PID Properties . . . . . 26
7.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 24 7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 27
8.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 24 7.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 27
8.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 25 7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 27
8.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 29
9. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 27 8.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Impact on Endpoint Property Service . . . . . . . . . . . 27 8.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Impact on Resource-Specific Properties . . . . . . . . . 27 8.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 29
9.3. Impact on Other Properties . . . . . . . . . . . . . . . 27 8.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 30
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Network Map . . . . . . . . . . . . . . . . . . . . . . 27 8.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2. Property Definitions . . . . . . . . . . . . . . . . . . 28 8.7. Entity property type defined in this document . . . . . . 32
10.3. Properties for Abstract Network Elements . . . . . . . . 29 9. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 32
10.4. Information Resource Directory (IRD) . . . . . . . . . . 29 9.1. Impact on Endpoint Property Service . . . . . . . . . . . 32
10.5. Property Map Example . . . . . . . . . . . . . . . . . . 32 9.2. Impact on Resource-Specific Properties . . . . . . . . . 32
10.6. Filtered Property Map Example #1 . . . . . . . . . . . . 33 9.3. Impact on Other Properties . . . . . . . . . . . . . . . 32
10.7. Filtered Property Map Example #2 . . . . . . . . . . . . 34 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.8. Filtered Property Map Example #3 . . . . . . . . . . . . 35 10.1. Network Map . . . . . . . . . . . . . . . . . . . . . . 33
10.9. Filtered Property Map Example #4 . . . . . . . . . . . . 37 10.2. Property Definitions . . . . . . . . . . . . . . . . . . 33
10.10. Property Map in Path Vector Example #1 . . . . . . . . . 37 10.3. Properties for Abstract Network Elements . . . . . . . . 34
11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 10.4. Information Resource Directory (IRD) . . . . . . . . . . 35
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 10.5. Full Property Map Example . . . . . . . . . . . . . . . 37
12.1. application/alto-* Media Types . . . . . . . . . . . . . 40 10.6. Filtered Property Map Example #1 . . . . . . . . . . . . 38
12.2. ALTO Entity Domain Type Registry . . . . . . . . . . . . 41 10.7. Filtered Property Map Example #2 . . . . . . . . . . . . 39
10.8. Filtered Property Map Example #3 . . . . . . . . . . . . 41
10.9. Filtered Property Map Example #4 . . . . . . . . . . . . 42
10.10. Filtered Property Map for ANEs Example #5 . . . . . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
12.1. application/alto-* Media Types . . . . . . . . . . . . . 45
12.2. ALTO Entity Domain Type Registry . . . . . . . . . . . . 46
12.2.1. Consistency Procedure between ALTO Address Type 12.2.1. Consistency Procedure between ALTO Address Type
Registry and ALTO Entity Domain Type Registry . . . 42 Registry and ALTO Entity Domain Type Registry . . . 46
12.2.2. ALTO Entity Domain Type Registration Process . . . . 43 12.2.2. ALTO Entity Domain Type Registration Process . . . . 48
12.3. ALTO Entity Property Type Registry . . . . . . . . . . . 44 12.3. ALTO Entity Property Type Registry . . . . . . . . . . . 49
12.4. ALTO Resource-Specific Entity Domain Registries . . . . 45 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
12.4.1. Network Map . . . . . . . . . . . . . . . . . . . . 45 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.4.2. Endpoint Property . . . . . . . . . . . . . . . . . 45 14.1. Normative References . . . . . . . . . . . . . . . . . . 51
12.5. ALTO Resource Entity Property Mapping Registries . . . . 46 14.2. Informative References . . . . . . . . . . . . . . . . . 52
12.5.1. Network Map . . . . . . . . . . . . . . . . . . . . 46 Appendix A. Scope of Property Map . . . . . . . . . . . . . . . 52
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 A.1. Example Property Map . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . 46
14.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Scope of Property Map . . . . . . . . . . . . . . . 48
A.1. Example Property Map . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
The ALTO protocol [RFC7285] introduces the concept of "properties" The ALTO protocol [RFC7285] introduces the concept of "properties"
attached to "endpoint addresses", and defines the Endpoint Property attached to "endpoint addresses", and defines the Endpoint Property
Service (EPS) to allow ALTO clients to retrieve those properties. Service (EPS) to allow ALTO clients to retrieve those properties.
While useful, the EPS, as defined in [RFC7285], has at least three While useful, the EPS, as defined in [RFC7285], has at least three
limitations. limitations.
First, the EPS allows properties to be associated with only endpoints First, the EPS allows properties to be associated with only endpoints
skipping to change at page 6, line 12 skipping to change at page 6, line 15
The protocol extension defined in this document is extensible. New The protocol extension defined in this document is extensible. New
entity domain types can be defined without revising the specification entity domain types can be defined without revising the specification
defined in this document. Similarly, new cost metrics and new defined in this document. Similarly, new cost metrics and new
endpoint properties can be defined in other documents without endpoint properties can be defined in other documents without
revising the protocol specification defined in [RFC7285]. revising the protocol specification defined in [RFC7285].
This document subsumes the Endpoint Property Service defined in This document subsumes the Endpoint Property Service defined in
[RFC7285], although that service may be retained for legacy clients [RFC7285], although that service may be retained for legacy clients
(see Section 9). (see Section 9).
2. Basic Features of the Unified Property Extension This document assumes the reader is familiar with the base ALTO
protocol defined in [RFC7285].
The purpose of this extension is to convey properties on objects that 1.1. Terminology
extend ALTO Endpoints and are called ALTO Entities, entities for
short. This section introduces the basic features involved in ALTO
Property Maps.
2.1. Entity TODO: TBC
o Client: When starting with a capital "C", this term refers to an
ALTO client.
o Server: When starting with a capital "S", this term refers to an
ALTO server.
o TBC
2. Requirements Language
TODO: REAL RFC xrefs The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only
when, they appear in all capitals, as shown here. When the words
appear in lower case, they are to be interpreted with their natural
language meanings.
3. Basic Features of the Unified Property Extension
This section gives a high-level overview of the the basic features
involved in ALTO Entity Property Maps. It assumes the reader is
familiar with the ALTO protocol [RFC7285]. The purpose of this
extension is to convey properties on objects that extend ALTO
Endpoints and are called ALTO Entities, entities for short.
3.1. Entity
The concept of an ALTO Entity generalizes the concept of an ALTO The concept of an ALTO Entity generalizes the concept of an ALTO
Endpoint defined in Section 2.1 of [RFC7285]. An entity is an object Endpoint defined in Section 2.1 of [RFC7285]. An entity is an object
that can be an endpoint that is defined by its network address, but that can be an endpoint that is defined by its network address, but
can also be an object that has a defined mapping to a set of one or can also be an object that has a defined mapping to a set of one or
more network addresses or an object that is not even related to any more network addresses or an object that is not even related to any
network address. Thus, where as all endpoints are entities, not all network address. Thus, where as all endpoints are entities, not all
entities are endpoints. entities are endpoints.
Examples of entities are: Examples of entities are:
o an ALTO endpoint, defined in [RFC7285], that represents an o an ALTO endpoint, defined in [RFC7285], that represents an
application or a host identified by a communication address (e.g., application or a host identified by a communication address (e.g.,
an IPv4 or IPv6 address) in a network. an IPv4 or IPv6 address) in a network,
o a PID, defined in [RFC7285], that has a provider defined human- o a PID, defined in [RFC7285], that has a provider defined human-
readable abstract identifier specified by an ALTO network map, readable identifier specified by an ALTO network map, which maps a
which maps a PID to a set of ipv4 and ipv6 addresses; PID to a set of ipv4 and ipv6 addresses,
o an autonomous system (AS), that has an AS number (ASN) as its o an autonomous system (AS), that has an AS number (ASN) as its
identifier and maps to a set of ipv4 and ipv6 addresses; identifier and maps to a set of ipv4 and ipv6 addresses,
o a country, identified by its country code defined by ISO 3166, to o a country with a code as specified in [ISO3166-1], to which
which applications such as CDN providers associate properties and applications such as CDN providers associate properties and
capabilities; capabilities,
o a TCP/IP network flow, that is identified by a TCP/IP 5-Tuple o a TCP/IP network flow, that is identified by a TCP/IP 5-Tuple
specifying its source and destination addresses and port numbers specifying its source and destination addresses and port numbers
and the utilized protocol; and the utilized protocol,
o a routing element, that is specified in [RFC7921] and is o a routing element, that is specified in [RFC7921] and is
associated with routing capabilities information; associated with routing capabilities information,
o an abstract network element, that represents an abstraction of a o an abstract network element, that represents an abstraction of a
network part such as a routable network node, one or more link, a network part such as a routable network node, one or more links, a
network domain or their aggregation. network domain or their aggregation.
2.2. Entity Domain 3.2. Entity Domain
An entity domain defines a set of entities of the same type. This An entity domain defines a set of entities of the same semantic type.
type, also called entity domain type, defines the semantics of a type An entity domain is characterized by its type and identified by its
of entity. Entity domain types could be defined in different name.
documents. For example: the present document defines entity domain
types "ipv4", "ipv6" and "pid" in sections Section 5.1 and
Section 5.2; the entity domain type "ane", that defines Abstract
Network Elements (ANEs), is introduced in
[I-D.ietf-alto-path-vector].
An entity domain also has a name. The name and type of an entity In this document, an entity must be owned by exactly one entity
domain can be the same. This is the case for the abovementionned domain name. An entity identifier must point to exactly one entity.
types "ipv4", "ipv6" and "pid". The name of an entity domain may If two entities in two different entity domains refer to the same
however be different from its type, in particular when the identifier physical or logical object, they are treated as different entities.
of its entities cannot be recognized outside this domain. For For example, if an object has both an IPv4 and an IPv6 address, these
example: an entity "mypid10" of domain type "pid" is only recognized two addresses will be treated as two entities, defined respectively
with respect to a given network map resource and may be undefined in in the "ipv4" and "ipv6" entity domains.
other network maps, or may even map to a different set of addresses.
This document addresses this case in Section 3.2 and related.
2.3. Entity Property 3.2.1. Entity Domain Type
An entity property defines a property of an entity. It is similar to The type of an entity domain type defines the semantics of a type of
the endpoint property defined by Section 7.1 of [RFC7285]. It can entity. Entity domain types can be defined in different documents.
convey either network-aware or network-agnostic information. For example: the present document defines entity domain types "ipv4",
"ipv6" and "pid" in sections Section 6.1 and Section 6.2. The entity
domain type "ane", that defines Abstract Network Elements (ANEs), is
introduced in [I-D.ietf-alto-path-vector]. The entity domain type
that defines country codes is introduced in
[draft-ietf-alto-cdni-request-routing-alto]. An entity domain type
is expected to be registered at the IANA, as specified in section
Section 12.2.2 and similarly to an ALTO address type.
3.2.2. Entity Domain Name
The name of an entity domain is defined in the scope of an ALTO
server. An entity domain name can be identical to its relevant
entity domain type in the following case: when the entities of an
entity domain have an identifier that points to the same object
throughout all the information resources of the Server that provide
entity properties for this domain. For example, a domain of type
"ipv4" that contains entities identified by a public IPv4 address can
be named "ipv4" because its entities are uniquely identified by all
the resources of the Server.
In some cases, a domain type and domain name must be different.
Indeed, for some domain types, entities are defined relatively to a
given information resource. As a consequence, entities in such
domains may be defined in a resource handling this domain type but
not in other resources handling this same domain type. Moreover,
across different ALTO information resources handling a domain type,
an entity identifier may point to different objects. This is the
case for entities of domain type "pid". A PID is defined relatively
to a network map. For example: an entity "mypid10" of domain type
"pid" may be defined in a given network map resource and be undefined
in other network maps, or may even map to a different set of endpoint
addresses. In this case, naming an entity domain only by its type
"pid" does not guarantee that its entities are owned by exactly one
entity domain name. Section 4.2 and related of this document
describe how a domain is uniquely identified by a name that
associates the domain type and the related information resource.
3.3. Entity Property Type
An entity property defines a property of an entity. This is similar
to the endpoint property defined in Section 7.1 of [RFC7285]. An
entity property can convey either network-aware or network-agnostic
information. Simularly to an entity domain, an entity property is
characterized by its type and identified by its name. An entity
property type is expected to be registered at the IANA, as specified
in section Section 12.3.
For example: For example:
o an entity in the "ipv4" domain may have a property whose value is o an entity in the "ipv4" domain may have a property whose value is
an Autonomous System (AS) number indicating the AS that owns this an Autonomous System (AS) number indicating the AS that owns this
IPv4 address, IPv4 address and another property named "countrycode" indicating a
country code mapping to this address,
o an entity in the "pid" domain may have a property that indicates o an entity identified by its country code in the "countrycode"
the central geographical location of endpoints it includes. domain, defined in [draft-ietf-alto-cdni-request-routing-alto] may
have a property indicating what delivery protocol is used by a
CDN,
It should be noted that some objects may be both entities and o an entity in the "netmap1.pid" domain may have a property that
properties. For example, a PID may be both a property of an "ipv4" indicates the central geographical location of the endpoints it
entity and an entity on which a Client may query properties such as includes.
geographical location.
2.4. New information resource and media type: ALTO Property Map It should be noted that some identifiers may be used for both an
entity domain type and a property type. For example:
o the identifier "countrycode" may point to both the entity domain
type "countrycode" and the property type "countrycode".
o the identifier "pid" may point to both the entity domain type
"pid" and the property type "pid".
Likewise, a same identifier may point to both a domain name and a
property name.
3.4. New information resource and media type: ALTO Property Map
This document introduces a new ALTO information resource named This document introduces a new ALTO information resource named
Property Map. An ALTO property map provides a set of properties on a Property Map. An ALTO property map provides a set of properties on
set of entities. These entities may be of different types. For one or more sets of entities. A property may apply to different
example, an ALTO property map may define the ASN property for both entity domain types and names. For example, an ALTO property map may
"ipv4" and "ipv6" type of entities. define the "ASN" property for both "ipv4" and "ipv6" entity domains.
The present extension also introduces a new media type. The present extension also introduces a new media type.
This document uses the same definition of the information resource as This document uses the same definition of an information resource as
defined by [RFC7285]. Each information resource usually has a JSON Section 9.1 of [RFC7285]. ALTO uses media types to uniquely indicate
format representation following a specific schema defined by its the data format used to encode the content to be transmitted between
media type. In the present case, an ALTO property map resource is an ALTO server and an ALTO client in the HTTP entity body. In the
represented by a JSON object of type InfoResourcePropertyMap and present case, an ALTO property map resource is defined by the media
defined by the media type "application/alto-propmap+json". type "application/alto-propmap+json".
A Property Map can be queried as a GET-mode resource, thus conveying A Property Map can be queried as a GET-mode resource, thus conveying
values of all properties on all entities indicated in its values of all properties on all entities indicated in its
capabilities. It can also be queried as a POST-mode resource, thus capabilities. It can also be queried as a POST-mode resource, thus
conveying a selection of properties on a selection of entities. conveying a selection of properties on a selection of entities.
3. Advanced Features of the Unified Property Extension 4. Advanced Features of the Unified Property Extension
3.1. Entity Identifier and Entity Domain 4.1. Entity Identifier and Entity Domain Name
In [RFC7285], an endpoint has an identifier explicitly associated In [RFC7285], an endpoint has an identifier which is explicitly
with the "ipv4" or "ipv6" address domain. Examples are associated with the "ipv4" or "ipv6" address domain. Examples are
"ipv4:192.0.2.14" and "ipv6:2001:db8::12". In this extension, an "ipv4:192.0.2.14" and "ipv6:2001:db8::12".
entity domain characterizes the type semantics and identifier format
of its entities. And the identifier of an entity is explicitly
associated with its entity domain. For instance: an entity that is
an endpoint with an IPv4 address will have an identifier associated
with the "ipv4" domain, like "ipv4:192.0.2.14"; an entity which is a
PID will have an identifier associated with a "pid" domain, like
"pid:mypid10".
In this document, an entity must be owned by exactly one entity In this document, an entity must be owned by exactly one entity
domain. And an entity identifier must point to exactly one entity. domain name and an entity identifier must point to exactly one
Even if two entities in two different entity domains refer to the entity. To ensure this, an entity identifier is explicitly attached
same physical or logical object, they are treated as different to the name of its entity domain and an entity domain type
entities. For example, an IPv4 and IPv6 address. characterizes the semantics and identifier format of its entities.
3.2. Resource-Specific Entity Domain Name The encoding format of an entity identifier is further specified in
Section 5.1.3 of this document.
For instance:
o if an entity is an endpoint with example routable IPv4 address
"192.0.2.14", its identifier is associated with domain name "ipv4"
and is "ipv4:192.0.2.14",
o if an entity is a PID named "mypid10" in network map resource
"netmap2", its identifier is associated with domain name
"netmap2.pid" and is "netmap2.pid:mypid10".
4.2. Resource-Specific Entity Domain Name
Some entities are defined and identified in a unique and global way. Some entities are defined and identified in a unique and global way.
This is the case for instance for entities that are endpoints This is the case for instance for entities that are endpoints
identified by a routable IPv4 or IPv6 address. The entity domain for identified by a routable IPv4 or IPv6 address. The entity domain for
such entities can be globally defined and named "ipv4" or "ipv6". such entities can be globally defined and named "ipv4" or "ipv6".
Those entity domains are also called resource-agnostic entity domains Those entity domains are called resource-agnostic entity domains in
in this document, as they are not associated to any specific ALTO this document, as they are not associated to any specific ALTO
information resources. information resources.
Some other entities and entity types are only defined relatively to a Some other entities and entity types are only defined relatively to a
given information resource. This is the case for entities of domain given information resource. This is the case for entities of domain
"pid", that can only be understood with respect to the network map type "pid", that can only be understood with respect to the network
where they are defined. For example, a PID named "mypid10" may be map where they are defined. For example, a PID named "mypid10" may
defined to represent a set S1 of IP addresses in an information be defined to represent a set S1 of IP addresses in a network map
resource of type Network Map and named "netmap1". Another Network resource named "netmap1". Another network map "netmap2" may use the
Map "netmap2" may use the same name "mypid10" and define it to same name "mypid10" and define it to represent another set S2 of IP
represent another set S2 of IP addresses. The identifier addresses. The identifier "pid:mypid10" may thus point to different
"pid:mypid10" may thus point to different objects because the objects because the information on the originating information
information on the originating information resource is lost. The resource is lost.
reason is that "pid" denotes an entity domain type rather than an
unambiguous identifier.
To solve this ambiguity, the present extension introduces the concept To solve this ambiguity, the present extension introduces the concept
of resources-specific entity domain. This concept applies to domains of resources-specific entity domain. This concept applies to domain
where entities are defined relatively to a given information types where entities are defined relatively to a given information
resource. It can also apply to domains of entities that are defined resource. It can also apply to entity domains that are defined
locally, such as local networks of objects identified with a local locally, such as local networks of objects identified with a local
IPv4 address. IPv4 address.
In such cases, an entity domain name is explicitly associated with an In such cases, an entity domain type is explicitly associated with an
identifier of the information resource where these entities are identifier of the information resource where these entities are
defined. Using a resource-specific entity domain name, an ALTO defined. Such an information resource is referred to as the
Property Map may unambiguously indicate entity domains of the same "specific information resource". Using a resource-aware entity
type, on which entity properties may be queried. Example resource- domain name, an ALTO property map can unambiguously identify distinct
specific entity domain names may look like: "netmap1.pid" or entity domains of the same type, on which entity properties may be
"netmap2.pid". This allows to identify two distinct PID entities queried. Example resource-specific entity domain names may look
such as "netmap1.pid:mypid10" or "netmap2.pid:mypid10". Resource- like: "netmap1.pid" or "netmap2.pid". Thus, a name association such
specific entity domain name will be specified in Section 4.1.2. as "netmap1.pid:mypid10" and "netmap2.pid:mypid10" allows to
distinguish the two abovementioned PIDs that are both named "mypid10"
but in two different resources, "netmap1" and "netmap2".
3.3. Resource-Specific Entity Property An information resource is defined in the scope of an ALTO Server and
so is an entity domain name. The format of a resource-specific
entity domain name is further specified in Section 5.1.2.
An entity may have properties of same type, whose values are 4.3. Resource-Specific Entity Property Value
associated to different information resources. For instance, entity
"192.0.2.34" defined in the "ipv4" domain may have two "pid" Like entity domains, some types of properties are defined relatively
properties defined in two different network maps "netmap1" and to an information resource. That is, an entity may have a property
"netmap2". These properties will likely have different values in of a given type, whose values are associated to different information
"netmap1" and "netmap2". To distinguish between them, this document resources.
uses the same approach proposed as in Section 10.8.1 of [RFC7285],
which is called "Resource-Specific Entity Property". When a property For example, suppose entity "192.0.2.34" defined in the "ipv4" domain
value depends on a given information resource, the identifier of the has a property of type "pid", whose value is the PID to which address
"192.0.2.34" is attached in a network map. The mapping of network
addresses to PIDs is specific to a network map and probably different
from one network map resource to another one. So that if a property
"pid" is defined for entity "192.0.2.34" in two different network
maps "netmap1" and "netmap2", the value for this property will likely
be different value in "netmap1" and "netmap2".
To support information resource dependent property values, this
document uses the same approach as in Section 10.8.1 of [RFC7285]
entitled "Resource-Specific Endpoint Properties". When a property
value depends on a given information resource, the name of this
property must be explicitly associated with the information resource property must be explicitly associated with the information resource
that defines it. that defines it.
For example, the property "pid" queried on entity "ipv4:192.0.2.34" For example, the property "pid" queried on entity "ipv4:192.0.2.34"
and defined in both "netmap1" and "netmap2", may be named and defined in both "netmap1" and "netmap2", can be named
"netmap1.pid" and "netmap2.pid". This allows a Client to get a "netmap1.pid" and "netmap2.pid". This allows a Client to get a
property of the same type but defined in different information property of the same type but defined in different information
resources in a single query. Specifications are provided in resources with a single query. Specifications on the property name
Section 4.2. format are provided in Section 5.2.
3.4. Entity Hierarchy and Property Inheritance 4.4. Entity Hierarchy and Property Inheritance
Enumerating all individual entities is inefficient for both the For some domain types, entities can be grouped in a set and be
Client and the Server. defined by the identifier of this set. This is the case for domain
types "ipv4" and "ipv6", where individual Internet addresses can be
grouped in blocks. When a same property value applies to a whole
set, a Server can define a property for the identifier of this set
instead of enumerating all the entities and their properties. This
allows substantial reduction of transmission payload both for the
Server and the Client. For example, all the entities included in the
set defined by the address block "ipv6:2001:db8::1/64" share the same
properties and values defined for this block.
o For the Client, even if it only wants to request properties for a Additionally, entity sets sometimes are related by inclusion,
"/24" ipv4 subnet, using the individual ipv4 entity, it has to hierarchy or other relations. This allows defining inheritance rules
enumerate all 256 entities. for entity properties that propagate properties among related entity
sets. The Server and the Client can use these inheritance rules for
further payload savings. Entity hierarchy and property inheritance
rules are specified in the documents that define the applicable
domain types. The present document defines these rules for the
"ipv4" and "ipv6" domain types.
o For the Server, in some cases, most of the entities may have the This document introduces, for applicable domain types, "Entity
same properties. Simply enumerating all of them may introduce a Property Inheritance rules", with the following concepts: Entity
lot of reduncency in the payload. For example, all the individual Hierarchy, Property Inheritance and Property Value Unicity. A
ipv4 entities in a "/24" ipv4 subnet is usually owned by the same detailed specification of entity hierarchy and property inheritance
AS. When a Client requests the ASN property for this ipv4 subnet, rules is provided in Section 5.1.4.
using the individual ipv4 address, the Server has to repeat the
same ASN property for 256 times in the worst case.
To reduce the size of the property map request and response payloads, 4.4.1. Entity Hierarchy
this document introduces, when appicable, an approach called
"Property Inheritance". This approach consists of two parts: Entity
Hierarchy and Property Inheritance.
o Entity Hierarchy: This approach allows an entity domain to support An entity domain may allow using a single identifier to identify a
using a single identifier to identify a set of indivudial set of individual entities. For example, a CIDR block can be used to
entities. For example, a CIDR can be used to identify a set of identify a set of IPv4 or IPv6 entities. A CIDR block is called a
ipv4 or ipv6 entities. Such an identifier is called a hierarchical entity identifier, as it can reflect inclusion relations
hierarchical entity identifier, as the set identified by it can be among entity sets. For example, the CIDR "ipv4:192.0.1.0/24"
hierarachical. For example, the CIDR "ipv4:192.0.1.0/24" covers includes all the individual ipv4 entities identified by the CIDR
all the individual ipv4 entities identified the CIDR "ipv4:192.0.1.0/26".
"ipv4:192.0.1.0/26".
o Property Inheritance: This approach allows a property map to 4.4.2. Property Inheritance
define a property for a hierarchical entity identifier. An
undefined property of an entity may inherit the value of the
property defined for a hierarchical entity identifier. For
example, a property map only defines the ASN property for a
hierarchical ipv4 entity identifier "ipv4:192.0.1.0/24". When
receiving this property map, a Client could infer that the ipv4
entity "ipv4:192.0.1.1" inherits the same ASN property even if it
does not appear in the property map.
The detailed specification will be specified in Section 4.1.4. A property may be defined for a hierarchical entity identifier while
it may be undefined for individual entities covered by this
identifier. In this case these individual entities inherit the
property value defined for the identifier that covers them. For
example, suppose a property map defines the ASN property only for the
hierarchical entity identifier "ipv4:192.0.1.0/24" but not for
individual entities in this block. Suppose also that inheritance
rules are specified for CIDR blocks in the "ipv4" domain type. When
receiving this property map, a Client can infer that entity
"ipv4:192.0.1.1" inherits the "ASN" property value of block
"ipv4:192.0.1.0/24" because the address "ipv4:192.0.1.1" is included
by the CIDR block "ipv4:192.0.1.0/24".
3.5. Applicable Entity Domains and Properties in the Property Map Property value inheritance rules also apply among entity sets. A
property map may define values for an entity set belonging to a
hierarchy but not for "sub" sets that are covered by this set
identifier. In this case, inheritance rules must specify how
entities in "sub" sets inherit property values from their "super"
set. For instance, if the "ASN" property is defined only for the
entity set identified by block "ipv4:192.0.1.0/24", the entity set
identified by "ipv4:192.0.1.0/30" and thus included in the former
set, may inherit the "ASN" property values from set
"ipv4:192.0.1.0/24".
4.4.3. Property Value Unicity
The inheritance rules must ensure that an entity belonging to a
hierarchical set of entities inherits no more than one property
value. Indeed, a property map may define a property on a hierarchy
of entity sets that inherit property values from one or more
including sets in the upper levels. On the other hand, a property
value, defined at a lower level of the hierarchy may be different
from the value defined at an upper level. In such a case, a set in
the lower level of the hierarchy may potentially end up with
different values. This may be the case for address blocs with
increasing prefix length, on which a property value gets increasingly
accurate and thus may differ. For example, a fictitious property
such as "geo-location" or "average transfer volume" may be defined at
a progressively finer grain for entity sets defined with
progressively longer CIDR prefixes. It seems more interesting to
have property values of progressively higher accuracy. A unicity
rule, applied to the entity domain type must specify an arbitration
rule among the different property values for an entity.
4.5. Supported Properties on Entity Domains in Property Map
Capabilities Capabilities
A property is not necessarily applicable to any domain, or an ALTO A property type is not necessarily applicable to any domain type, or
Server may just not support it for all applicable domains. For an ALTO Server may just not provide a property on all applicable
instance, a property reflecting link bandwidth is likely not defined domains. For instance, a property type reflecting link bandwidth is
on entities of a domain of type "country-code". Therefore an ALTO likely not defined on entities of a domain of type "country-code".
server supporting Property Maps specifies the properties that can be Therefore an ALTO server providing Property Maps specifies the
queried on the different domains defined in this server. properties that can be queried on the different entity domains it
supports.
In Section 6 and related, this document explains how the IRD This document explains how the IRD capabilities of a Property Map
capabilities of a Property Map unambiguously expose what type of resource unambiguously expose what properties a Client can query on a
properties on what entity domains a Client can query. For short, a given entity domain.
field called "mapping" enumerates the entity domains supported by the
Property Map; For each entity domain, a list of applicable properties
is provided. An example can be found in Section 10.4. Using
resource-agnostic or resource-specific entity domains and properties
allows to formulate compact and unambiguous entity property queries
relating to one or more information resources, in particular:
o avoid a Client to query a property on entity domains on which P is o a field named "mappings" lists the names of the entity domains
not defined, supported by the Property Map,
o query for en entity E property values defined in different o for each listed entity domain, a list of the names of the
information resources, applicable properties is provided.
o query a property P on entities E defined in different information An example is provided in Section 10.4. The "mappings" field
resources. associates entity domains and properties that can be resource-
agnostic or resource-specific. This allows a Client to formulate
compact and unambiguous entity property queries, possibly relating to
one or more information resources. In particular:
Specifications will be provided in Section 7.4. o it avoids a Client to query a property on entity domains on which
it is not defined,
3.6. Connection between Resource-Specific Entity Domain/Entity Property o it allows a Client to query, for an entity E, values for a
Mapping and Information Resources property P that are defined in different information resources,
Although the IRD capabilities of a Property Map can expose the o it allows a Client to query a property P on entities that are
supported mappings in this property map, it may still not be clear to defined in different information resources.
a Client what a resource-specific entity domain is, and what an
applicable resource-specific entity property means, as those concepts
are not defined in other ALTO information resources. For example, a
Client should understand that:
o a local IPv4 entity domain "netmap1.ipv4" includes the IPv4 Further specifications are provided in Section 7.4.
addresses appearing in the "ipv4" field of the endpoint address
group of each PID in the network map "netmap1";
o a "netmap1.pid" property of an IPv4 entity "ipv4:192.0.1.1" 4.6. Defining Information Resource
indicates the PID defined by the network map "netmap1" and
including the IPv4 address "ipv4:192.0.1.1" in its endpoint
address group.
To help the client understanding these connections, this document A Client willing to query properties on entities belonging to a
requests two new IANA registries for each information resource to domain needs to know how to retrieve these entities. To this end, he
define the connection to each supported resource-specific entity Client can look up the "mappings" field exposed in IRD capabilities
domain and entity property mapping respectively. Such a connection of a property map, see Section 4.5. This field, in its keys, exposes
is called "Information Resource Export", to explain what is an all the entity domains supported by the property map. The syntax of
resource-specific entity domain or an entity property mapping the entity domain identifier specified in Section 5.1.2 allows the
exported by an information resource. Examples of "Information client to infer whether the entity domain is resource-specific or
Resource Exports" of existing ALTO information resources are provided not. The Client can extract, if applicable, the identifier of the
in Section 6. Specifications are provided in Section 6.1. The specific resource, query the resource and retrieve the entities. For
details of these new IANA registries are provided in Section 12.4 and example:
Section 12.5.
4. Protocol Specification: Basic Data Type o an entity domain named "netmap1.ipv4" includes the IPv4 addresses
that appear in the "ipv4" field of the endpoint address group of
each PID in the network map "netmap1", and that cannot be
recognized outside "netmap1", for instance because these are local
non routable addresses,
4.1. Entity Domain o an entity domain named "netmap1.pid" includes the PIDs listed in
network map "netmap1".
4.1.1. Entity Domain Type o an entity domain named "ipv4" is resource-agnostic and covers all
the routable IPv4 addresses.
Besides, it is also necessary to inform a Client about which
associations of specific resources and entity domain types are
allowed, because it is not possible to prevent a Server from exposing
inappropriate associations. An informed Client will just ignore
inappropriate associations exposed by a Server and avoid error-prone
transactions with the Server.
For example, the association "costmap3.pid" is not allowed for the
following reason: although a cost map exposes PID identifiers, it
does not define them, that is, the set of addresses included in this
PID. Neither does a cost map list all the PIDs on which properties
can be queried, because a cost map only exposes PID pairs on which a
queried cost type is defined. The resource "costmap3" therefore does
not enable a Client to extract information on the existing PID
entities or on the addresses they contain.
Instead, the cost map uses a network map, that lists all the PIDs
used in a cost map, together with the addresses contained by the
PIDs. This network map is qualified in this document as the Defining
Information Resource for the entity domain "pid" and this concept is
explained in Section 4.6.1.
4.6.1. Defining Information Resource and Media Type
For the reasons explained in the previous section, this document
indroduces the concept of defining information resource and media
type.
A defining information resource for an entity domain D is the
information resource where entities of D are defined. That is, all
the information on the entities of D can be retrieved in this
resource. This concept applies to resource specific domains. This
is useful for entity domain types that are by essence domain-
specific, such as "pid" and "ane" domain types. It is also useful
for resource-specific entity domains constructed from resource-
agnostic domain types, such as for example, network map specific
domains of local IPv4 addresses.
The defining information resource of an entity domain D has the
following specificities:
o it has an entry in the IRD,
o it defines the entities of D,
o it does not use another information resource that defines these
entities,
o it defines and exposes entity identifiers that are all persistent.
o its media type is unique and equal to the one that is specified
for the defining information resource of an entity domain type.
A fundamental attribute of a defining information resource is its
media type. There is a unique association of an entity domain type
with the media type of its defining information resources. If an
entity domain type allows defining information resources, their media
type is specified in the document that defines this entity domain
type and in the document that requests the registration of this
domain type at the IANA.
When the Client wants to use a resource-specific entity domain, it
needs to be cognizant of the media-type of its defining information
resource. If the Server exposes resources a resource specific entity
domain with a non compliant media type for the domain type, the
Client can avoid transaction errors by ignoring them.
4.6.2. Examples of specific resources media-types
Here are some examples of specific information resources types
associated to entity domain types and their media type.
o For entity domain type "pid": the media type of the specific
resource is "application/alto-networkmap+json", because PIDs are
defined in network map resources.
o For entity domain types "ipv4" and "ipv6": the media type of the
specific resource is "application/alto-networkmap+json", because
IPv4 and IPv6 addresses covered by the Server are defined in
network map resources.
o For entity domain type "ane", defined in
[I-D.ietf-alto-path-vector]: a specific property map resource can
be associated to ANEs that have a persistent identifier and have
an entry in the IRD. ANEs that have a persistent identifier are
defined in a property map that is indicated in the IRD, therefore
the media type associated with entity domain type "ane" is
"application/alto-propmap+json".
4.7. Defining Information Resource for Resource-Specific Property
Values
As explained in Section 4.3, a property type may take values that are
resource specific. This is the case for example for property type
"pid", whose values are by essence defined relatively to a specific
network map. The PID value for an IPv4 address differ in different
network maps or not be defined for some of them. Property values may
be specific to different types of information resources. For
example: the value for property "pid" is specific to a network map.
The value for property type "cdnifci-capab" is specific to the
information resource "cdnifci-map", defined in [draft-ietf-alto-cdni-
request-routing-alto], while network maps do not define property
"fci-capability" for ipv4 addresses and a cdnifci-map does not define
"pid" values for IPv4 addresses.
Thus, similarly to resource specific entity domains, the Client needs
to be aware of aware of appropriate associations of information
resource and property types.
4.7.1. Examples of defining resources media-types for properties
Here are some examples of specific information resources types
associated to entity property types and their media type.
o For property type "pid": the media type of the specific resource
is "application/alto-networkmap+json", because PIDs are defined in
network map resources.
o For property type "cdni-fci-capability": the media type of the
specific resource is "application/alto-cdnifci+json"
5. Protocol Specification: Basic Data Type
5.1. Entity Domain
5.1.1. Entity Domain Type
An entity domain has a type, which is uniquely identified by a string
that MUST be no more than 64 characters, and MUST NOT contain
characters other than US-ASCII alphanumeric characters
(U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), hyphen ("-",
U+002D), and low line ("_", U+005F). The ?.? separator MUST NOT be
used unless specifically indicated in a further extension document.
An entity domain has a type, which is defined by a string that MUST
be no more than 64 characters, and MUST NOT contain characters other
than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A,
and U+0061-U+007A), hyphen ("-", U+002D), and low line ("_", U+005F).
For example, the strings "ipv4", "ipv6", and "pid" are valid entity For example, the strings "ipv4", "ipv6", and "pid" are valid entity
domain types. domain types. "ipv4.anycast" and "pid.local" are invalid.
The type EntityDomainType is used in this document to denote a JSON The type EntityDomainType is used in this document to denote a JSON
string confirming to the preceding requirement. string meeting the preceding requirement.
An entity domain type defines the semantics of a type of entity An entity domain type defines the semantics of a type of entity,
domains. Each entity domain type MUST be registered with the IANA. indenpendently of any specifying resource. Each entity domain type
The format of the entity identifiers (see Section 4.1.3) in that type MUST be registered with the IANA. The format of the entity
of entity domains, as well as any hierarchical or inheritance rules identifiers (see Section 5.1.3) in that type of entity domains, as
(see Section 4.1.4) for those entities, MUST be specified at the same well as any hierarchical or inheritance rules (see Section 5.1.4) for
time. those entities, MUST be specified at the same time.
4.1.2. Entity Domain Name 5.1.2. Entity Domain Name
Each entity domain is identified by an entity domain name, a string This document distinguishes three categories of entity domains:
of the following format: resource-specific entity domains, resource-agnostic entity domains
and self-defined entity domains. Their entity domain names are
constructed as specified in the following sub-sections.
EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType Each entity domain is identified by a unique entity domain name which
This document distinguishes three types of entity domains: resource- is a string of the following format:
specific entity domains, self-defined entity domains, and resource-
agnostic entity domains. Their entity domain names are derived as
follows.
Each ALTO information resource MAY define a resource-specific entity EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType
domain (which could be empty) in a given entity domain type. A
resource-specific entity domain is identified by an entity domain
name derived as follows. It MUST start with a resource ID using the
ResourceID type defined in [RFC7285], followed by the "." separator
(U+002E), followed by an EntityDomainType typed string. For example,
if an ALTO server provides two network maps "netmap-1" and "netmap-
2", they can define two different "pid" domains identified by
"netmap-1.pid" and "netmap-2.pid" respectively. To be simplified, in
the scope of a specific information resource, the resource-specific
entity domain defined by itself can be identified by the "."
EntityDomainTyep without the ResourceID.
When the associated information resource of a resource-specific Where the presence and construction of component:
entity domain is the current information resource itself, this
resource-specific entity domain is a self-defined entity domain, and
its ResourceID SHOULD be ignored from its entity domain name.
Given a set of ALTO information resources, there MAY be a resource- "[ [ ResourceID ] '.' ]"
agnostic entity domain in a given entity domain type amongst them. A
resource-agnostic entity domain is simply identified by its entity
domain type. For example, given two network maps "net-map-1" and
"net-map-2", "ipv4" and "ipv6" identify two resource-agnostic
Internet address entity domains (see Section 5.1) between them.
Note that the "." separator is not allowed in EntityDomainType and depends on the category of entity domain.
Note that the '.' separator is not allowed in EntityDomainType and
hence there is no ambiguity on whether an entity domain name refers hence there is no ambiguity on whether an entity domain name refers
to a resource-agnostic entity domain or a resource-specific entity to a resource-agnostic entity domain or a resource-specific entity
domain. domain.
4.1.3. Entity Identifier Note also that the resource ID format definition in Section 10.1 of
[RFC7285] specifies that: "the '.' separator is reserved for future
use and MUST NOT be used unless specifically indicated in this
document, or an extension document". The present extension keeps the
format specification of [RFC7285], hence the '.' separator MUST NOT
be used in an information resources ID.
5.1.2.1. Resource-specific Entity Domain
A resource-specific entity domain is identified by an entity domain
name constructed as follows. It MUST start with a resource ID using
the ResourceID type defined in Section 10.2 of [RFC7285], followed by
the '.' separator (U+002E), followed by an string of the type
EntityDomainType specified in Section 5.1.1.
For example, if an ALTO server provides two network maps "netmap-1"
and "netmap-2", these network maps can define two resource-specific
domains of type "pid", respectively identified by "netmap-1.pid" and
"netmap-2.pid".
5.1.2.2. Resource-agnostic Entity Domain
A resource-agnostic entity domain contains entities that are
identified independently of any information resource. Hence, the
identifier of a resource-agnostic entity domain is simply the
identifier of its entity domain type. For example, "ipv4" and "ipv6"
identify the two resource-agnostic Internet address entity domains
defined in Section 6.1.
5.1.2.3. Self-defined Entity Domain
A property map can define properties on entities that are neither
resource-specific nor resource-agnostic but are instead defined
within the property map itself. This may be the case when an ALTO
Server provides information on a set of entities that is specific to
this property map would not be relevant for another one and that does
not depend on a specific resource.
For example: a specialised property map may define a domain of type
"ane", defined in [I-D.ietf-alto-path-vector], that contains a set of
ANEs with a persistent identifier that are relevant only for this
property map.
In this case, the entity domain is qualified as "self-defined". The
identifier of a self-defined entity domain can be of the format:
EntityDomainName ::= .EntityDomainType
where '.' indicates that the entity domain only exists within the
property map resource using it.
A self-defined entity domain can be viewed as a particular case of
resource-specific entity domain, where the specific resource is the
current resource that uses this entity domain. In that case, for the
sake of simplification, the component "ResourceID" SHOULD be omitted
in its entity domain name.
5.1.3. Entity Identifier
Entities in an entity domain are identified by entity identifiers Entities in an entity domain are identified by entity identifiers
(EntityID) of the following format: (EntityID) of the following format:
EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID
Examples from the Internet address entity domains include individual Examples from the Internet address entity domains include individual
IP addresses such as "net1.ipv4:192.0.2.14" and IP addresses such as "net1.ipv4:192.0.2.14" and
"net1.ipv6:2001:db8::12", as well as address blocks such as "net1.ipv6:2001:db8::12", as well as address blocks such as
"net1.ipv4:192.0.2.0/26" and "net1.ipv6:2001:db8::1/48". "net1.ipv4:192.0.2.0/26" and "net1.ipv6:2001:db8::1/48".
The format of the second part of an entity identifier depends on the The format of the second part of an entity identifier depends on the
entity domain type, and MUST be specified when registering a new entity domain type, and MUST be specified when defining a new entity
entity domain type. Identifiers MAY be hierarchical, and properties domain type and registering it with the IANA. Identifiers MAY be
MAY be inherited based on that hierarchy. Again, the rules defining hierarchical, and properties MAY be inherited based on that
any hierarchy or inheritance MUST be defined when the entity domain hierarchy. The rules defining any hierarchy or inheritance MUST be
type is registered. defined when the entity domain type is registered.
The type EntityID is used in this document to denote a JSON string The type EntityID is used in this document to denote a JSON string
representing an entity identifier in this format. representing an entity identifier in this format.
Note that two entity identifiers with different textual Note that two entity identifiers with different valid textual
representations may refer to the same entity, for a given entity representations may refer to the same entity, for a given entity
domain. For example, the strings "net1.ipv6:2001:db8::1" and domain. For example, the strings "net1.ipv6:2001:db8::1" and
"net1.ipv6:2001:db8:0:0:0:0:0:1" refer to the same entity in the "net1.ipv6:2001:db8:0:0:0:0:0:1" refer to the same entity in the
"ipv6" entity domain. "ipv6" entity domain.
4.1.4. Hierarchy and Inheritance 5.1.4. Hierarchy and Inheritance
To make the representation efficient, some types of entity domains To simplify the representation, some types of entity domains allow
MAY allow the ALTO client/server to use a hierarchical format entity the ALTO Client and Server to use a hierarchical entity identifier
identifier to represent a block of individual entities. e.g., In an format to represent a block of individual entities. For instance, in
IPv4 domain "net1.ipv4", a cidr "net1.ipv4:192.0.2.0/26" represents an IPv4 domain "net1.ipv4", a CIDR "net1.ipv4:192.0.2.0/26" covers 64
64 individual IPv4 entities. In this case, the corresponding individual IPv4 entities. In this case, the corresponding property
property inheritance rule MUST be defined for the entity domain type. inheritance rule MUST be defined for the entity domain type. The
The hierarchy and inheritance rule MUST have no ambiguity. hierarchy and inheritance rule MUST have no ambiguity.
4.2. Entity Property 5.2. Entity Property
Each entity property has a type to indicate the encoding and the Each entity property has a type to indicate the encoding and the
semantics of the value of this entity property, and has a name to be semantics of the value of this entity property, and has a name to
identified. One entity MAY have multiple properties in the same identify it.
type.
4.2.1. Entity Property Type 5.2.1. Entity Property Type
The type EntityPropertyType is used in this document to indicate a The type EntityPropertyType is used in this document to indicate a
string denoting an entity property type. The string MUST be no more string denoting an entity property type. The string MUST be no more
than 32 characters, and it MUST NOT contain characters other than US- than 32 characters, and it 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), the hyphen ("-", U+002D), the colon (":", U+003A), or U+0061-U+007A), the hyphen ("-", U+002D), the colon (":", U+003A), or
the low line ('_', U+005F). the low line ('_', U+005F). Note that the ?.? separator is not
allowed because it is reserved to separate an entity property type
and an information resource identifier when an entity property is
resource-specific.
Each entity property type MUST be registered with the IANA. The Each entity property type MUST be registered with the IANA. The
intended semantics of the entity property type MUST be specified at intended semantics of the entity property type MUST be specified at
the same time. the same time.
Identifiers prefixed with "priv:" are reserved for Private Use
[RFC5226] without a need to register with IANA. All other
identifiers for entity property types appearing in an HTTP request or
response with an "application/alto-*" media type MUST be registered
in the "ALTO Entity Property Type Registry", defined in Section 12.3.
For an entity property identifier with the "priv:" prefix, an
additional string (e.g., company identifier or random string) MUST
follow (i.e., "priv:" only is not a valid endpoint property
identifier) to reduce potential collisions.
To distinguish with the endpoint property type, the entity property To distinguish with the endpoint property type, the entity property
type has the following features. type has the following features.
o Some entity property types may be applicable to entities in only o Some entity property types may be applicable to entities in only
particular types of entity domains, not all. For example, the particular types of entity domains, not all. For example, the
"pid" property is not applicable to entities in a "pid" typed "pid" property is not applicable to entities in a "pid" typed
entity domain, but is applicable to entities in the "ipv4" or entity domain, but is applicable to entities in the "ipv4" or
"ipv6" domains. "ipv6" domains.
o The intended semantics of the value of an entity property may also o The intended semantics of the value of an entity property may also
depend on the entity domain type of this entity. For example, depend on the entity domain type of this entity. For example,
suppose that the "geo-location" property is defined as the suppose that the "geo-location" property is defined as the
coordinates of a point, encoded as (say) "latitude longitude coordinates of a point, encoded as (say) "latitude longitude
[altitude]." When applied to an entity that represents a specific [altitude]." When applied to an entity that represents a specific
host computer, identified by an address in the "ipv4" or "ipv6" host computer, identified by an address in the "ipv4" or "ipv6"
entity domain, the property defines the host's location. However, entity domain, the property defines the host's location. However,
when applied to an entity in a "pid" domain, the property would when applied to an entity in a "pid" domain, the property would
indicate the location of the center of all hosts in this "pid" indicate the location of the center of all hosts in this "pid"
entity. entity.
4.2.2. Entity Property Name 5.2.2. Entity Property Name
Each entity property is identified by an entity property name, which Each entity property is identified by an entity property name, which
is a string of the following format: is a string of the following format:
EntityPropertyName ::= [ ResourceID ] '.' EntityPropertyType EntityPropertyName ::= [ ResourceID ] '.' EntityPropertyType
Similar to the endpoint property type defined in Section 10.8 of Similar to the endpoint property type defined in Section 10.8 of
[RFC7285], each entity property may be defined by either the property [RFC7285], each entity property may be defined by either the property
map itself (self-defined) or some other specific information resource map itself (self-defined) or some other specific information resource
(resource-specific). (resource-specific).
skipping to change at page 15, line 47 skipping to change at page 22, line 33
string. For example, the "pid" properties of an "ipv4" entity string. For example, the "pid" properties of an "ipv4" entity
defined by two different maps "net-map-1" and "net-map-2" are defined by two different maps "net-map-1" and "net-map-2" are
identified by "net-map-1.pid" and "net-map-2.pid" respectively. identified by "net-map-1.pid" and "net-map-2.pid" respectively.
When the associated information resource of the entity property is When the associated information resource of the entity property is
the current information resource itself, the ResourceID in the the current information resource itself, the ResourceID in the
property name SHOULD be ignored. For example, the ".asn" property of property name SHOULD be ignored. For example, the ".asn" property of
an "ipv4" entity indicates the AS number of the AS which this IPv4 an "ipv4" entity indicates the AS number of the AS which this IPv4
address is owned by. address is owned by.
5. Entity Domain Types 5.2.3. Format for Entity Property Value
[RFC7285] in Section 11.4.1.6, specifies that an implementation of
the Endpoint Property Service specified in [RFC7285] SHOULD assume
that the property value is a JSONString and fail to parse if it is
not. The present document first, extends the property service to
Entities. Second it extends the format of a property value by
allowing it to be a JSONValue instead of just a JSONString.
6. Entity Domain Types Defined in this Document
This document requires the definition of each entity domain type MUST This document requires the definition of each entity domain type MUST
include (1) the entity domain type name and (2) domain-specific include (1) the entity domain type name and (2) domain-specific
entity identifiers, and MAY include (3) hierarchy and inheritance entity identifiers, and MAY include (3) hierarchy and inheritance
semantics optionally. This document defines three initial entity semantics optionally. This document defines three initial entity
domain types as follows. domain types as follows.
5.1. Internet Address Domain Types 6.1. Internet Address Domain Types
The document defines two entity domain types (IPv4 and IPv6) for The document defines two entity domain types (IPv4 and IPv6) for
Internet addresses. Both types are resource-agnostic entity domain Internet addresses. Both types are resource-agnostic entity domain
types and hence define corresponding resource-agnostic entity domains types and hence define corresponding resource-agnostic entity domains
as well. Since the two domains use the same hierarchy and as well. Since the two domains use the same hierarchy and
inheritance semantics, we define the semantics together, instead of inheritance semantics, we define the semantics together, instead of
repeating for each. repeating for each.
5.1.1. IPv4 Domain 6.1.1. IPv4 Domain
5.1.1.1. Entity Domain Type 6.1.1.1. Entity Domain Type
ipv4 ipv4
5.1.1.2. Domain-Specific Entity Identifiers 6.1.1.2. Domain-Specific Entity Identifiers
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]; Hierarchical addresses are rule of Section 3.2.2 of [RFC3986]; Hierarchical addresses are
prefix-match strings as specified in Section 3.1 of [RFC4632]. To prefix-match strings as specified in Section 3.1 of [RFC4632]. To
define properties, an individual Internet address and the define properties, an individual Internet address and the
corresponding full-length prefix are considered aliases for the same 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 entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are
equivalent. equivalent.
5.1.2. IPv6 Domain 6.1.2. IPv6 Domain
5.1.2.1. Entity Domain Type 6.1.2.1. Entity Domain Type
ipv6 ipv6
5.1.2.2. Domain-Specific Entity Identifiers 6.1.2.2. Domain-Specific Entity Identifiers
Individual addresses are strings as specified by Section 4 of Individual addresses are strings as specified by Section 4 of
[RFC5952]; Hierarchical addresses are prefix-match strings as [RFC5952]; Hierarchical addresses are prefix-match strings as
specified in Section 7 of [RFC5952]. To define properties, an specified in Section 7 of [RFC5952]. To define properties, an
individual Internet address and the corresponding 128-bit prefix are individual Internet address and the corresponding 128-bit prefix are
considered aliases for the same entity. That is, "ipv6:2001:db8::1" considered aliases for the same entity. That is, "ipv6:2001:db8::1"
and "ipv6:2001:db8::1/128" are equivalent, and have the same set of and "ipv6:2001:db8::1/128" are equivalent, and have the same set of
properties. properties.
5.1.3. Hierarchy and Inheritance of Internet Address Domains 6.1.3. Hierarchy and Inheritance of Internet Address Domains
Both Internet address 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 a a hierarchical Internet address C address I, but P is defined for a a hierarchical Internet address C
which prefix-matches I, then the address I inherits the value of P which prefix-matches I, then the address I inherits the value of P
defined for the hierarchical address C. If more than one such defined for the hierarchical address C. If more than one such
hierarchical addresses define a value for P, I inherits the value of hierarchical addresses define a value for P, I inherits the value of
P in the hierarchical address with the longest prefix. Note that P in the hierarchical address with the longest prefix. Note that
this longest prefix rule ensures no multiple inheritances, and hence this longest prefix rule ensures no multiple inheritances, and hence
no ambiguity. no ambiguity.
skipping to change at page 18, line 21 skipping to change at page 25, line 14
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 that from the Inheritance rules. So the client MUST interpret that
this 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.
5.2. PID Domain 6.1.4. Defining Information Resource Media Type for domain types IPv4
and IPv6
Entity domain types "ipv4" and "ipv6" both allow to define resource
specific entity domains. When resource specific domains are defined
with entities of domain type "ipv4" or "ipv6", the defining
information resource for an entity domain of type "ipv4" or "ipv6"
MUST be a Network Map. The media type of a defining information
resource is therefore:
application/alto-networkmap+json
6.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.
5.2.1. Entity Domain Type 6.2.1. Entity Domain Type
pid pid
5.2.2. Domain-Specific Entity Identifiers 6.2.2. Domain-Specific Entity Identifiers
The entity identifiers are the PID names of the associated network The entity identifiers are the PID names of the associated network
map. map.
5.2.3. Hierarchy and Inheritance 6.2.3. Hierarchy and Inheritance
There is no hierarchy or inheritance for properties associated with There is no hierarchy or inheritance for properties associated with
PIDs. PIDs.
5.2.4. Relationship To Internet Addresses Domains 6.2.4. Defining Information Resource Media Type for Domain Type PID
The entity domain type "pid" allows to define resource specific
entity domains. When resource specific domains are defined with
entities of domain type "pid", the defining information resource for
entity domain type "pid" MUST be a Network Map. The media type of a
defining information resource is therefore:
application/alto-networkmap+json
6.2.5. Relationship To Internet Addresses Domains
The PID domain and the Internet address domains are completely The PID domain and the Internet address domains are completely
independent; the properties associated with a PID have no relation to independent; the properties associated with a PID have no relation to
the properties associated with the prefixes or endpoint addresses in the properties associated with the prefixes or endpoint addresses in
that PID. An ALTO server MAY choose to assign some or all properties that PID. An ALTO server MAY choose to assign some or all properties
of a PID to the prefixes in that PID. of a PID to the prefixes in that PID.
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" in 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 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".
5.3. Internet Address Properties vs. PID Properties 6.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 domains are RECOMMENDED property. In general, the Internet address domains are RECOMMENDED
for properties that are closely related to the Internet address, or for properties that are closely related to the Internet address, or
are associated with, and inherited through, hierarchical addresses. are associated with, and inherited through, hierarchical 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 to a property that explains why a PID was formed, or how it relates to a
provider's network, would best be associated with the PID domain. provider's network, would best be associated with the PID domain.
6. Entity Domains and Property Mappings in Information Resources
6.1. Information Resource Export
Each information resource MUST export a set of entity domains and
entity property mappings (which can be empty).
6.1.1. Resource-Specific Entity Domain Export
Each type of information resource MAY export different types of
entity domains. For example, a network map resource MUST export a
"pid" domain, an "ipv4" domain and an "ipv6" domain (which may be
empty); if a facilitated endpoint type "ecgi" and its corresponding
entity domain type defined for cellular network addresses are
supported in a future ALTO extension, a network map supporting the
"ecgi" endpoint type MUST also export an "ecgi" domain.
When a new ALTO information resource type is registered, if this type
of information resource MAY export an existing type of entity domain,
the corresponding document MUST define how to export such type of
entity domain from such type of information resource.
When a new entity domain type is registered, if an existing type of
information resource MAY export an entity domain in this entity
domain type, the corresponding document MUST define how to export
such type of entity domain from such type of information resource.
6.1.2. Entity Property Mapping Export
For each entity domain which MAY be exported by an information
resource, this information resource MAY also export mappings from
this entity domain to some entity property. For example, a network
map resource MUST map an "ipv4" entity to its "pid" property; if a
facilitated ALTO CDNI FCI information resource including
"capabilities with footprint restrictions" [RFC8008] supporting ALTO
PIDs as a new footprint type, this information ressource MUST map a
"pid" entity to its corresponding "cdni-fci-capabilities" property.
When a new ALTO information resource type is registered, if this type
of information resource MAY export an entity domain in an existing
entity domain type, and map entities in this entity domain to an
existing type of entity property, the corresponding document MUST
define how to export such type of an entity property.
When a new ALTO entity domain type or a new entity property type is
defined, if an existing type of resource MAY export an entity domain
in this entity domain type, and map entities in this entity domain to
this type of entity property, the corresponding document MUST define
how to export such type of an entity property.
6.2. Network Map Resource
The ALTO network map resource defined by the media type "application/
alto-networkmap+json" exports the following types of entity domains
and entity property mappings.
6.2.1. Resource-Specific Entity Domain
An ALTO network map resource defines a "pid" domain, an "ipv4" domain
and an "ipv6" domain by follows:
o The defined "pid" domain includes all PIDs in keys of the
"network-map" object.
o The defined "ipv4" domain includes all IPv4 addresses appearing in
the "ipv4" field of the endpoint address group of each PID.
o The defined "ipv6" domain includes all IPv6 addresses appearing in
the "ipv6" field of the endpoint address group of each PID.
6.2.2. Entity Property Mapping
For each of the preceding entity domains, an ALTO network map
resource provides the properties mapping as follows:
ipv4 -> pid: An "networkmap" typed resource can map an "ipv4" entity
to a "pid" property whose value is a PID defined by this
"networkmap" resource and including the IPv4 address of this
entity.
ipv6 -> pid: An "networkmap" typed resource can map an "ipv6" entity
to a "pid" property whose value is a PID defined by this
"networkmap" resource and including the IPv6 address of this
entity.
6.3. Endpoint Property Resource
The ALTO endpoint property resource defined by the media type
"application/alto-endpointprop+json" exports the following types of
entity domains and entity property mappings.
6.3.1. Resource-Specific Entity Domain
An ALTO endpoint property resource defined an "ipv4" domain and an
"ipv6" domain by follows:
o The defined "ipv4" domain includes all IPv4 addresses appearing in
keys of the "endpoint-properties" object.
o The defined "ipv6" domain includes all IPv6 addresses appearing in
keys of the "endpoint-properties" object.
6.3.2. Entity Property Mapping
For each of the preceding entity domains, an ALTO endpoint property
resource exports the properties mapping from it to each supported
global endpoint property. The property value is the corresponding
global endpoint property value in the "endpiont-properties" object.
6.4. Property Map Resource
To avoid the nested reference and its potential complexity, this
document does not specify the export rule of resource-specific entity
domain and entity property mapping for the ALTO property map resource
defined by the media type "application/alto-propmap+json" (see
Section 7.1).
7. Property Map 7. 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, e.g., the "location" property of entities in "pid" or more domains, e.g., the "location" property of entities in "pid"
domain, and the "ASN" property of entities in "ipv4" and "ipv6" domain, and the "ASN" property of entities in "ipv4" and "ipv6"
domains. domains.
Section 10.5 gives an example of a property map request and its Section 10.5 gives an example of a property map request and its
response. response.
skipping to change at page 27, line 8 skipping to change at page 32, line 8
o If an entity in the response is already covered by some other o If an entity in the response is already covered by some other
entities in the same response, it SHOULD be removed from the entities in the same response, it SHOULD be removed from the
response for compactness. For example, in the previous example, 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 the entity A=ipv4:192.0.2.0/31 SHOULD be removed because A1 and A2
cover all the addresses in A. cover all the addresses in A.
An ALTO client should be aware that the entities in the response MAY An ALTO client should be aware that the entities in the response MAY
be different from the entities in its request. be different from the entities in its request.
8.7. Entity property type defined in this document
This document defines the entity property type "pid"
The intended semantics are the same as in [RFC7285]
The defining information resource for property type MUST be a network
map.
The media type of a defining information resource is therefore:
application/alto-networkmap+json
This document requests a IANA registration for this property
9. Impact on Legacy ALTO Servers and ALTO Clients 9. Impact on Legacy ALTO Servers and ALTO Clients
9.1. Impact on Endpoint Property Service 9.1. Impact on Endpoint Property Service
Since the property map and the filtered property map defined in this Since the property map and the filtered property map defined in this
document provide the functionality of the Endpoint Property Service document provide the functionality of the Endpoint Property Service
(EPS) defined in Section 11.4 of [RFC7285], it is RECOMMENDED that (EPS) defined in Section 11.4 of [RFC7285], it is RECOMMENDED that
the EPS be deprecated in favor of Property Map and Filtered Property the EPS be deprecated in favor of Property Map and Filtered Property
Map. However, ALTO servers MAY provide an EPS for the benefit of Map. However, ALTO servers MAY provide an EPS for the benefit of
legacy clients. legacy clients.
skipping to change at page 30, line 27 skipping to change at page 35, line 48
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.
The server also provides a facilitated ALTO resource which accepts The server also provides a facilitated ALTO resource which accepts
the filtered cost map request but returns a multipart message the filtered cost map request but returns a multipart message
including a cost map and an associated property map for "ane" including a cost map and an associated property map for "ane"
entities. entities.
"meta" : { "meta" : {
... ...
"default-alto-network-map" : "default-network-map" "default-alto-network-map" : "default-network-map"
}, },
"resources" : { "resources" : {
"default-network-map" : { "default-network-map" : {
"uri" : "http://alto.example.com/networkmap/default", "uri" : "http://alto.example.com/networkmap/default",
"media-type" : "application/alto-networkmap+json" "media-type" : "application/alto-networkmap+json"
}, },
"alt-network-map" : { "alt-network-map" : {
"uri" : "http://alto.example.com/networkmap/alt", "uri" : "http://alto.example.com/networkmap/alt",
"media-type" : "application/alto-networkmap+json" "media-type" : "application/alto-networkmap+json"
}, },
.... property map resources .... .... property map resources ....
"ia-property-map" : { "ia-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",
"uses": [ "default-network-map", "alt-network-map" ], "uses": [ "default-network-map", "alt-network-map" ],
"capabilities" : { "capabilities" : {
"mappings": { "mappings": {
"ipv4": [ ".ISP", ".ASN" ], "ipv4": [ ".ISP", ".ASN" ],
"ipv6": [ ".ISP", ".ASN" ] "ipv6": [ ".ISP", ".ASN" ]
} }
} }
}, },
"iacs-property-map" : { "iacs-property-map" : {
"uri" : "http://alto.example.com/propmap/full/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",
"uses": [ "default-network-map", "alt-network-map" ], "uses": [ "default-network-map", "alt-network-map" ],
"capabilities" : { "capabilities" : {
"mappings": { "mappings": {
"ipv4": [ ".ISP", ".ASN", ".country", ".state" ], "ipv4": [ ".ISP", ".ASN", ".country", ".state" ],
"ipv6": [ ".ISP", ".ASN", ".country", ".state" ] "ipv6": [ ".ISP", ".ASN", ".country", ".state" ]
} }
} }
}, },
"region-property-map": { "region-property-map": {
"uri": "http://alto.exmaple.com/propmap/region", "uri": "http://alto.example.com/propmap/lookup/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", "alt-network-map" ], "uses" : [ "default-network-map", "alt-network-map" ],
"capabilities": { "capabilities": {
"mappings": { "mappings": {
"default-network-map.pid": [ ".region" ], "default-network-map.pid": [ ".region" ],
"alt-network-map.pid": [ ".ASN" ], "alt-network-map.pid": [ ".ASN" ],
} }
} }
}, },
"ip-pid-property-map" : { "ip-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", "alt-network-map" ], "uses" : [ "default-network-map", "alt-network-map" ],
"capabilities" : { "capabilities" : {
"mappings": { "mappings": {
"ipv4": [ "default-network-map.pid", "ipv4": [ "default-network-map.pid",
"alt-network-map.pid" ], "alt-network-map.pid" ],
"ipv6": [ "default-network-map.pid", "ipv6": [ "default-network-map.pid",
"alt-network-map.pid" ] "alt-network-map.pid" ]
} }
} }
}, },
"legacy-endpoint-property" : { "legacy-endpoint-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" : {
"properties" : [ "default-network-map.pid", "properties" : [ "default-network-map.pid",
"alt-network-map.pid" ] "alt-network-map.pid" ]
} }
}, },
"path-vector-map": { "ane-dc-property-map": {
"uri": "http://alto.example.com/costmap/pv", "uri" : "http://alto.example.com/propmap/lookup/ane-dc",
"media-type": "media-type" : "application/alto-propmap+json",
"multipart/related;type=applicatoin/alto-costmap+json", "accepts": "application/alto-propmapparams+json",
"accepts": "applicatoin/alto-costmapfilter+json", "capabilities": {
"capabilities": { "mappings": {
"cost-type-names": ["path-vector"], ".ane" : [ "storage-capacity", "ram", "cpu" ]
"ane-properties": ["maxresbw", "persistent-entities", }
"mec-flavors"] },
}, }
"uses": [ "default-network-map" ] }
}
}
Figure 8: Example IRD Figure 8: Example IRD
10.5. Property Map Example 10.5. Full Property Map Example
The following example uses the properties and IRD defined above to The following example uses the properties and IRD defined above in
retrieve a Property Map for entities with the "ISP" and "ASN" Section 10.4 to retrieve a Property Map for entities with the "ISP"
properties. and "ASN" properties.
Note that, to be compact, the response does not include the entity Note that, to be compact, the response does not include the entity
"ipv4:192.0.2.0", because values of all those properties for this "ipv4:192.0.2.0", because values of all those properties for this
entity are inherited from other entities. entity are inherited from other entities.
Also note that the entities "ipv4:192.0.2.0/28" and 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 "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 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". 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 Both of "ipv4:192.0.2.0/27" and "ipv4:192.0.3.0/27" omit the value
skipping to change at page 37, line 46 skipping to change at page 43, line 25
"property-map": { "property-map": {
"default-network-map.pid:pid1": { "default-network-map.pid:pid1": {
".region": "us-west" ".region": "us-west"
}, },
"default-network-map.pid:pid2": { "default-network-map.pid:pid2": {
".region": "us-east" ".region": "us-east"
} }
} }
} }
10.10. Property Map in Path Vector Example #1 10.10. Filtered Property Map for ANEs Example #5
The following example requests the "maxresbw", "persistent-entities"
and "mec-flavors" properties for abstract network elements between
"pid1" and "pid3" in "default-network-map".
POST /costmap/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;type=application/alto-costmap+json,
application/alto-error+json
Content-Length: [TBD]
Content-Type: application/alto-costmapfilter+json
{ The following example uses the filtered property map resource "ane-
"cost-type": { dc-property-map" to request properties "storage-capacity" and "cpu"
"cost-mode": "array", on several ANEs defined in this property map.
"cost-metric": "ane-path"
},
"pids": {
"srcs": [ "pid1" ],
"dsts": [ "pid3" ]
},
"ane-properties": ["maxresbw", "persistent-entities", "mec-flavors"]
} POST /propmap/lookup/ane-dc HTTP/1.1
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: ###
Content-Type: application/alto-propmapparams+json
{
"entities" : [".ane:dc21", ".ane:dc45.srv9", ".ane:dc6.srv-cluster8"]
"properties" : [ "storage-capacity", "cpu"]
}
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: [TBD] Content-Length: ###
Content-Type: multipart/related; boundary=example-1;
type=application/alto-costmap+json
--example-1
Content-Id: costmap
Content-Type: application/alto-costmap+json
{
"meta": {
"vtag": {
"resource-id": "cost-map-pv.costmap",
"tag": "d827f484cb66ce6df6b5077cb8562b0a"
},
"dependent-vtags": [
{
"resource-id": "my-default-networkmap",
"tag": "75ed013b3cb58f896e839582504f6228"
}
],
"cost-type": {
"cost-mode": "array",
"cost-metric": "ane-path"
}
},
"cost-map": {
"pid1": {
"pid3": [ "ane:L001", "ane:L002", "ane:MEC01", "ane:MEC02" ],
}
}
}
--example-1
Content-Id: propmap
Content-Type: application/alto-propmap+json Content-Type: application/alto-propmap+json
{ {
"meta": { "meta" : {
"dependent-vtags": [
{
"resource-id": "cost-map-pv.costmap",
"tag": "d827f484cb66ce6df6b5077cb8562b0a"
}
]
}, },
"property-map": { "property-map": {
"ane:L001": { "maxresbw": 100000000 }, ".ane:dc21":
"ane:L002": { "maxresbw": 100000000 }, {"storage-capacity" : 40000 Gbytes, "cpu" : 500 Cores},
"ane:MEC01": { "persistent-entities": "mec:192.0.2.1", ".ane:dc45.srv9":
"mec-flavors": [ {"gpu": "2G", "ssd": "128G"}]}, {"storage-capacity" : 100 Gbytes, "cpu" : 20 Cores},
"ane:MEC02": { "persistent-entities": "mec:192.0.2.2", ".ane:dc6.srv-cluster8":
"mec-flavors": [ {"gpu": "1G", "ssd": "128G"}]} {"storage-capacity" : 6000 Gbytes, "cpu" : 100 Cores},
} }
} }
11. Security Considerations 11. Security Considerations
Both Property Map and Filtered Property Map defined in this document Both Property Map and Filtered Property Map defined in this document
fit into the architecture of the ALTO base protocol, and hence the fit into the architecture of the ALTO base protocol, and hence the
Security Considerations (Section 15 of [RFC7285]) of the base Security Considerations (Section 15 of [RFC7285]) of the base
protocol fully apply: authenticity and integrity of ALTO information protocol fully apply: authenticity and integrity of ALTO information
(i.e., authenticity and integrity of Property Maps), potential (i.e., authenticity and integrity of Property Maps), potential
skipping to change at page 40, line 19 skipping to change at page 45, line 10
12. IANA Considerations 12. 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.
12.1. application/alto-* Media Types 12.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.
+----------------+-------------------------+------------------------+ +--------------+--------------------------+------------------------+
| Type | Subtype | Specification | | Type | Subtype | Specification |
+----------------+-------------------------+------------------------+ +--------------+--------------------------+------------------------+
| application | alto- | Section 7.1 | | application | alto-propmap+json | Section 7.1 |
| | propmap+json | | | application | alto-propmapparams+json | Section 8.3 |
| application | alto- | Section 8.3 | +--------------+--------------------------+------------------------+
| | propmapparams+json | |
+----------------+-------------------------+------------------------+
Table 1: Additional ALTO Media Types. Table 1: Additional ALTO Media Types.
Type name: application Type name: application
Subtype name: This document registers multiple subtypes, as listed Subtype name: This document registers multiple subtypes, as listed
in Table 1. in Table 1.
Required parameters: n/a Required parameters: n/a
skipping to change at page 41, line 21 skipping to change at page 46, line 7
Additional information: Additional information:
Magic number(s): n/a Magic number(s): n/a
File extension(s): This document uses the mime type to refer to File extension(s): This document uses the mime type to refer to
protocol messages and thus does not require a file extension. protocol messages and thus does not require a file extension.
Macintosh file type code(s): n/a Macintosh file type code(s): n/a
Person & email address to contact for further information: Person & email address to contact for further information: See
See Authors' Addresses section. Authors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: n/a Restrictions on usage: n/a
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).
12.2. ALTO Entity Domain Type Registry 12.2. ALTO Entity Domain Type Registry
This document requests IANA to create and maintain the "ALTO Entity This document requests IANA to create and maintain the "ALTO Entity
Domain Type Registry", listed in Table 2. Domain Type Registry", listed in Table 2.
+---------------+-------------------------+-------------------------+ +-------------+---------------------------+-------------------------+
| Identifier | Entity | Hierarchy & Inheritance | | Identifier | Entity Identifier | Hierarchy & Inheritance |
| | Identifier Encoding | | | | Encoding | |
+---------------+-------------------------+-------------------------+ +-------------+---------------------------+-------------------------+
| ipv4 | See | See | | ipv4 | See Section 6.1.1 | See Section 6.1.3 |
| | Section 5.1.1 | Section 5.1.3 | | ipv6 | See Section 6.1.2 | See Section 6.1.3 |
| ipv6 | See | See | | pid | See Section 6.2 | None |
| | Section 5.1.2 | Section 5.1.3 | +-------------+---------------------------+-------------------------+
| pid | See | None |
| | Section 5.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.
12.2.1. Consistency Procedure between ALTO Address Type Registry and 12.2.1. Consistency Procedure between ALTO Address Type Registry and
ALTO Entity Domain Type Registry ALTO Entity Domain Type Registry
skipping to change at page 43, line 36 skipping to change at page 48, line 17
New ALTO entity domain types are assigned after IETF Review [RFC5226] New ALTO entity domain types are assigned after IETF Review [RFC5226]
to ensure that proper documentation regarding the new ALTO entity to ensure that proper documentation regarding the new ALTO entity
domain types and their security considerations has been provided. domain types and their security considerations has been provided.
RFCs defining new entity domain types SHOULD indicate how an entity RFCs defining new entity domain types SHOULD indicate how an entity
in a registered type of domain is encoded as an EntityID, and, if in a registered type of domain is encoded as an EntityID, and, if
applicable, the rules defining the entity hierarchy and property applicable, the rules defining the entity hierarchy and property
inheritance. Updates and deletions of ALTO entity domains follow the inheritance. Updates and deletions of ALTO entity domains follow the
same procedure. same procedure.
Registered ALTO entity domain type identifiers MUST conform to the Registered ALTO entity domain type identifiers MUST conform to the
syntactical requirements specified in Section 4.1.2. Identifiers are syntactical requirements specified in Section 5.1.2. Identifiers are
to be recorded and displayed as strings. to be recorded and displayed as strings.
Requests to the IANA to add a new value to the registry MUST include Requests to the IANA to add a new value to the registry MUST include
the following information: the following information:
o Identifier: The name of the desired ALTO entity domain type. o Identifier: The name of the desired ALTO entity domain type.
o Entity Identifier Encoding: The procedure for encoding the o Entity Identifier Encoding: The procedure for encoding the
identifier of an entity of the registered type as an EntityID (see identifier of an entity of the registered type as an EntityID (see
Section 4.1.3). If corresponding entity identifiers of an entity Section 5.1.3). If corresponding entity identifiers of an entity
domain match a known "network" address type, the Entity Identifier domain match a known "network" address type, the Entity Identifier
Encoding of this domain identifier MUST include both Address Encoding of this domain identifier MUST include both Address
Encoding and Prefix Encoding of the same identifier registered in Encoding and Prefix Encoding of the same identifier registered in
the ALTO Address Type Registry [RFC7285]. For the purpose of the ALTO Address Type Registry [RFC7285]. For the purpose of
defining properties, an individual entity identifier and the defining properties, an individual entity identifier and the
corresponding full-length prefix MUST be considered aliases for corresponding full-length prefix MUST be considered aliases for
the same entity. the same entity.
o Hierarchy: If the entities form a hierarchy, the procedure for o Hierarchy: If the entities form a hierarchy, the procedure for
determining that hierarchy. determining that hierarchy.
o Inheritance: If entities can inherit property values from other o Inheritance: If entities can inherit property values from other
entities, the procedure for determining that inheritance. entities, the procedure for determining that inheritance.
o Media type of defining information resource: some entity domain
types allow their entity domain type name to be combined with an
information resource name to define a resource-specific entity
domain. Such an information resource is called "defining
information resource". In this case, the authorized media type of
specific information resources MUST be specified in the document
defining the entity domain type. When this entity domain type
allows combinations with defining resources, this must be
indicated and the conditions fully specified in the document. The
defining information resource for an entity domain type is the one
that:
* has an entry in the IRD,
* defines these entities,
* does not use another information resource that defines these
entities,
* defines and exposes entity identifiers that are all persistent.
* has a unique media type equal to the one specified in the
document defining the entity domain type.
This information is useful when Servers indicate resource specific
entity domains in the property map capabilities. Clients need to
know if the combination of information resource type and entity
domain type is allowed. See also, Section 4.6 and Section 5.1 for
more information.
o Mapping to ALTO Address Type: A boolean value to indicate if the o Mapping to ALTO Address Type: A boolean value to indicate if the
entity domain type can be mapped to the ALTO address type with the entity domain type can be mapped to the ALTO address type with the
same identifier. same identifier.
o Security Considerations: In some usage scenarios, entity o Security Considerations: In some usage scenarios, entity
identifiers carried in ALTO Protocol messages may reveal identifiers carried in ALTO Protocol messages may reveal
information about an ALTO client or an ALTO service provider. information about an ALTO client or an ALTO service provider.
Applications and ALTO service providers using addresses of the Applications and ALTO service providers using addresses of the
registered type should be made aware of how (or if) the addressing registered type should be made aware of how (or if) the addressing
scheme relates to private information and network proximity. scheme relates to private information and network proximity.
This specification requests registration of the identifiers "ipv4", This specification requests registration of the identifiers "ipv4",
"ipv6" and "pid", as shown in Table 2. "ipv6" and "pid", as shown in Table 2.
12.3. ALTO Entity Property Type Registry 12.3. ALTO Entity Property Type Registry
This document requests IANA to create and maintain the "ALTO Entity This document requests IANA to create and maintain the "ALTO Entity
Property Type Registry", listed in Table 3. Property Type Registry", listed in Table 3.
To distinguish with the "ALTO Endpoint Property Type Registry", each This registry extends the "ALTO Endpoint Property Type Registry"
entry in this registry is an ALTO entity property type defined in created by [RFC7285] in that a property is defined on one or more
Section 4.2.1. Thus, registered ALTO entity property type identifier entity domains, rather than just on the IPv4 and IPv6 Internet
MUST conform to the syntactical requirements specified in that address domains. entry in this registry is an ALTO entity property
section. type defined in Section 5.2.1. Thus, registered ALTO entity property
type identifier MUST conform to the syntactical requirements
The initial registered ALTO entity property types are listed in specified in that section.
Table 3.
+---------------------------+---------------------------------------+ +-------------+---------------------------------+
| Identifier | Intended Semantics | | Identifier | Intended Semantics |
+---------------------------+---------------------------------------+ +-------------+---------------------------------+
| pid | See Section 7.1.1 of | | pid | See Section 7.1.1 of [RFC7285] |
| | [RFC7285] | +-------------+---------------------------------+
+---------------------------+---------------------------------------+
Table 3: ALTO Entity Property Types. Table 3: ALTO Entity Property Types.
Requests to the IANA to add a new value to the registry MUST include Requests to the IANA to add a new value to the registry MUST include
the following information: the following information:
o Identifier: The unique id for the desired ALTO entity property o Identifier: The unique id for the desired ALTO entity property
type. The format MUST be as defined in Section 4.2.1 of this type. The format MUST be as defined in Section 5.2.1 of this
document. It includes the information of the applied ALTO entity document. It includes the information of the applied ALTO entity
domain and the property name. domain and the property name.
o Intended Semantics: ALTO entity properties carry with them o Intended Semantics: ALTO entity properties carry with them
semantics to guide their usage by ALTO clients. Hence, a document semantics to guide their usage by ALTO clients. Hence, a document
defining a new type SHOULD provide guidance to both ALTO service defining a new type SHOULD provide guidance to both ALTO service
providers and applications utilizing ALTO clients as to how values providers and applications utilizing ALTO clients as to how values
of the registered ALTO entity property should be interpreted. of the registered ALTO entity property should be interpreted.
This document requests registration of the identifier "pid", as shown o Security Considerations: ALTO entity properties expose information
in Table 3. to ALTO clients. ALTO service providers should be made aware of
the security ramifications related to the exposure of an entity
12.4. ALTO Resource-Specific Entity Domain Registries property.
12.4.1. Network Map
Media-type: application/alto-networkmap+json
+---------------------------------+---------------------------------+
| Entity Domain | Intended |
| Type | Semantics |
+---------------------------------+---------------------------------+
| ipv4 | See |
| | Section 6.2.1 |
| ipv6 | See |
| | Section 6.2.1 |
| pid | See |
| | Section 6.2.1 |
+---------------------------------+---------------------------------+
Table 4: ALTO Network Map Resource-Specific Entity Domain.
12.4.2. Endpoint Property
Media-type: application/alto-endpointprop+json
+---------------------------------+---------------------------------+
| Entity Domain | Intended |
| Type | Semantics |
+---------------------------------+---------------------------------+
| ipv4 | See |
| | Section 6.3.1 |
| ipv6 | See |
| | Section 6.3.1 |
+---------------------------------+---------------------------------+
Table 5: ALTO Endpoint Property Resource-Specific Entity Domain.
12.5. ALTO Resource Entity Property Mapping Registries
12.5.1. Network Map
Media-type: application/alto-networkmap+json
+----------------+-----------------+-------------+------------------+ In security considerations, the request should also discuss the
| Mapping | Entity Domain | Property | Intended | sensitivity of the information, and why such sensitive information is
| Descriptor | Type | Type | Semantics | required for ALTO-based operations. Regarding this discussion, the
+----------------+-----------------+-------------+------------------+ request SHOULD follow the recommendations of Section 14.3. ALTO
| ipv4 -> pid | ipv4 | pid | See | Endpoint Property Type Registry in [RFC7285].
| | | | Section 6.2.2 |
| ipv6 -> pid | ipv6 | pid | See |
| | | | Section 6.2.2 |
+----------------+-----------------+-------------+------------------+
Table 6: ALTO Network Map Entity Property Mapping. This document requests registration of the identifier "pid", listed
in Table 3. Semantics for this property are documented in
Section (TODO: add ref) and security considerations are documented in
Section TODO:ref.
13. Acknowledgments 13. Acknowledgments
The authors would like to thank discussions with Kai Gao, Qiao Xiang, The authors would like to thank discussions with Kai Gao, Qiao Xiang,
Shawn Lin, Xin Wang, Danny Perez, and Vijay Gurbani. The authors Shawn Lin, Xin Wang, Danny Perez, and Vijay Gurbani. The authors
thank Dawn Chen (Tongji University), and Shenshen Chen (Tongji/Yale thank Dawn Chen (Tongji University), and Shenshen Chen (Tongji/Yale
University) for their contributions to earlier drafts. University) for their contributions to earlier drafts.
14. References 14. References
14.1. Normative References 14.1. Normative References
[ISO3166-1]
The International Organization for Standardization, "Codes
for the representation of names of countries and their
subdivisions -- Part 1: Country codes, ISO 3166-1:2013",
2013.
[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 48, line 7 skipping to change at page 52, line 24
<https://www.rfc-editor.org/info/rfc7921>. <https://www.rfc-editor.org/info/rfc7921>.
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
R., and K. Ma, "Content Delivery Network Interconnection R., and K. Ma, "Content Delivery Network Interconnection
(CDNI) Request Routing: Footprint and Capabilities (CDNI) Request Routing: Footprint and Capabilities
Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
<https://www.rfc-editor.org/info/rfc8008>. <https://www.rfc-editor.org/info/rfc8008>.
14.2. Informative References 14.2. Informative References
[draft-ietf-alto-cdni-request-routing-alto]
Roome, J., Yang, Y., Ma, K., Peterson, J., and J. Zhang,
"Content Delivery Network Interconnection (CDNI) Request
Routing: CDNI Footprint and Capabilities Advertisement
using ALTO (work in progress)", 2020.
[I-D.ietf-alto-path-vector] [I-D.ietf-alto-path-vector]
Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang,
"ALTO Extension: Path Vector", draft-ietf-alto-path- "ALTO Extension: Path Vector", draft-ietf-alto-path-
vector-09 (work in progress), November 2019, vector-09 (work in progress), November 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-alto-path- <http://www.ietf.org/internet-drafts/draft-ietf-alto-path-
vector-09.txt>. vector-09.txt>.
Appendix A. Scope of Property Map Appendix A. Scope of Property Map
Using entity domains to organize entities, an ALTO property map Using entity domains to organize entities, an ALTO property map
 End of changes. 127 change blocks. 
741 lines changed or deleted 931 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/