An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps
Extracted elements (31)
Internet address domain types are RECOMMENDED for properties closely tied to IP addresses or that benefit from CIDR inheritance (e.g., ISP or ASN). The PID domain type is RECOMMENDED for properties arising from the PID's definition itself (e.g., geographic region of a PID), rather than from the IP prefixes it contains.
Property values are extended from JSONString (as RFC 7285 required) to any JSONValue, enabling richer structured property types such as objects, arrays, or numbers. A protocol implementation SHOULD assume values are JSONString or JSON null and fail to parse otherwise, unless an extension explicitly signals other data types.
Resource-specific entity domain names (e.g., 'netmap1.pid') were introduced because the same PID name (e.g., 'mypid10') can be defined in multiple network maps with different address sets. Using just 'pid:mypid10' without a resource scope loses information about the originating information resource, causing ambiguity that this naming scheme resolves.
RFC 7285's Endpoint Property Service has three limitations: properties can only be attached to individual IP addresses (not PIDs or ANEs), endpoint addresses cannot be scoped to a specific information resource (causing PID ambiguity across network maps), and only POST-mode queries are defined with no GET-mode property map. This extension addresses all three.
Property maps and filtered property maps cover the functionality of RFC 7285's Endpoint Property Service. ALTO servers may prefer to provide property maps instead of EPS, but it is recommended that they also retain the EPS to support legacy ALTO clients that do not implement this extension.
The PID domain and the Internet address domains (ipv4, ipv6) are completely independent. An ALTO server MAY choose to assign some or all of a PID's properties to the address prefixes in that PID, but this is not required; a property value on a PID entity does not automatically propagate to the IP addresses it contains.
A filtered property map MUST return an appropriate ALTO error if the request is invalid: E_MISSING_FIELD if 'entities' is absent; E_INVALID_FIELD_VALUE if an entity identifier's domain is not in the resource capabilities or the identifier is not valid for that domain; E_INVALID_FIELD_VALUE if a property name is not in the capabilities. The 'value' field of the error SHOULD indicate the offending value.
Entity domain type identifiers MUST be no more than 64 characters, using only US-ASCII alphanumeric, hyphen-minus, colon, or low line characters. The colon MUST NOT appear more than once and MUST only appear within the 'priv:' prefix. All non-private entity domain types MUST be registered with IANA in the 'ALTO Entity Domain Types' registry.
Entity property type identifiers MUST be no more than 32 characters using only US-ASCII alphanumeric, hyphen-minus, colon, or low line. All entity property types not prefixed with 'priv:' MUST be registered in the 'ALTO Entity Property Types' registry. The 'priv:' prefix alone is not a valid identifier; an additional distinguishing string MUST follow.
For entity domain types 'ipv4', 'ipv6', and 'pid', when resource-specific entity domains are defined, the defining information resource MUST be a network map with media type application/alto-networkmap+json.
If an IPv4 or IPv6 entity would inherit a property value but the server asserts 'no value', the server MUST return a JSON 'null' and the client MUST recognize 'null' as 'no value' (i.e., do not apply inheritance). If the entity would not inherit a value, the server MAY return 'null' or simply omit the property.
If entity domains in a property map depend on other resources, the 'dependent-vtags' field in the response 'meta' MUST be an array including version tags of those resources in the same order as the 'uses' field. For filtered property maps with resource-agnostic entities, all dependent resource vtags from 'uses' MUST be included.
If the 'entities' list in a filtered property map request is empty, the ALTO Server MUST interpret it as containing all entities currently defined in the resource. If the 'properties' list is empty, the Server MUST interpret it as all defined properties. The Server MUST interpret duplicate entries as if they appeared only once.
The ALTO server MAY omit property values that are inherited rather than explicitly defined to achieve compact encoding. As a consequence, the ALTO Client MUST NOT assume inherited property values will be present in the response; if needed, the Client MUST apply the entity domain's inheritance rules to derive them.
The filtered property map response MUST include all inherited property values for requested entities and all entities from which requested entities can inherit. If a property for a requested entity is inherited from an entity not in the request, the response MUST include that property. If a hierarchical identifier covers sub-entities with different property values, the response MUST include all those sub-entities.
When an entity domain type allows associations with defining information resources, the media type of the potential defining information resource MUST be specified both in the document defining the entity domain type and in the IANA 'ALTO Entity Domain Types' registry. A Client MUST ignore entities from a resource-specific entity domain whose defining resource has a noncompliant media type.
A filtered property map is requested via HTTP POST with input media type 'application/alto-propmapparams+json'. Input is ReqFilteredPropertyMap with a required 'entities' field (list of EntityID) and optional 'properties' field (list of EntityPropertyName). An empty 'entities' or 'properties' list signals a request for all applicable entities or properties respectively.
A property map is a new ALTO information resource (media type: application/alto-propmap+json) requested via HTTP GET that returns all properties for all entities in declared entity domains. Its IRD capabilities include a 'mappings' object (type EntityPropertyMapping) associating each entity domain name with the list of applicable entity property names.
An ALTO entity generalizes the concept of an ALTO endpoint. Entities can be individual IP addresses, PIDs, Autonomous Systems, country codes, TCP/UDP flows, routing elements, or Abstract Network Elements (ANEs). An entity is owned by exactly one entity domain name, and if two entities in different domains refer to the same physical object, they are treated as distinct entities.
An entity domain defines a set of entities of the same semantic type. Three categories exist: resource-specific (scoped to an information resource, e.g., 'netmap1.pid'), resource-agnostic (globally unique, e.g., 'ipv4'), and self-defined (scoped to the property map itself, with an entity domain name prefixed by '.').
Internet address (ipv4/ipv6) entity domains support hierarchical property inheritance. If property P is undefined for address I but defined for a CIDR block C containing I, then I inherits P from C. When multiple enclosing blocks define P, the longest-prefix CIDR wins, ensuring unambiguous single-value inheritance. This rule also applies recursively among CIDR blocks.
The 'ipv4' and 'ipv6' entity domain types are resource-agnostic. IPv4 entity identifiers follow RFC 3986 address syntax and RFC 4632 prefix notation; an individual address and its /32 prefix are aliases. IPv6 identifiers follow RFC 5952 and RFC 4291 prefix notation; an address and its /128 prefix are aliases.
The 'pid' entity domain type is always resource-specific; it depends on a network map (defining information resource media type: application/alto-networkmap+json). Entity identifiers are the PID names of the associated network map. There is no hierarchy or inheritance for PID entities; PID properties are independent of properties on the IP prefixes within that PID.
This document defines entity property type 'pid' (identifier: 'pid') extending the RFC 7285 endpoint property type 'pid'. It applies to IPv4 and IPv6 address entities, returns the PID in a given network map that contains the address, and requires application/alto-networkmap+json as its defining information resource media type.
This document creates the 'ALTO Entity Domain Types' IANA registry. Initial entries include 'ipv4', 'ipv6', and 'pid'. Registrations require specifying the identifier, semantics, entity identifier format, hierarchy/inheritance rules, and (where applicable) the defining information resource media type. Types with 'priv:' prefix are reserved for private use without registration.
This document creates the 'ALTO Entity Property Types' IANA registry. New registrations require specifying the identifier, intended semantics, media type of the defining information resource (if resource-specific), and security considerations. The 'pid' property type is the first registered entry. Types with 'priv:' prefix are reserved for private use.
This document registers two ALTO media types: 'application/alto-propmap+json' for property map and filtered property map responses (Section 12.1), and 'application/alto-propmapparams+json' for filtered property map POST input parameters (Section 12.2).
Security considerations for entity property type 'pid' are identical to those for the ALTO endpoint property type 'pid' in RFC 7285. Property maps that expose entity domain contents (PID-to-address mappings, address-to-property mappings) reveal network topology information; ALTO servers should apply access control consistent with RFC 7285's security model to all property map resources.
Entity domain names follow the format: EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType. Resource-specific names use 'resourceID.domainType' (e.g., 'netmap1.pid'), resource-agnostic names are the domain type alone (e.g., 'ipv4'), and self-defined names use '.domainType'. The '.' separator is prohibited within EntityDomainType.
Entity identifiers follow the format: EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID. Examples include 'ipv4:192.0.2.14', 'net1.ipv6:2001:db8::12', 'net1.ipv4:192.0.2.0/26', and 'netmap2.pid:mypid10'. Two textually different representations may refer to the same entity (e.g., IPv6 canonicalization per RFC 5952).
Entity property names follow the format: EntityPropertyName ::= [ [ ResourceID ] '.' ] EntityPropertyType. Resource-specific property names are prefixed with the resource identifier and '.' (e.g., 'netmap1.pid'); when the defining resource is the property map itself, ResourceID SHOULD be omitted. Property values are JSONValue (not just JSONString as RFC 7285 required).