ALTO WG                                                         W. Roome
Internet Draft                                  Alcatel-Lucent Bell Labs
Intended status: Standards Track                                 Y. Yang
                                                                    Yale
Expires April 2014                                      October 21, 2013

                PID Property Extension for ALTO Protocol
                 draft-roome-alto-pid-properties-00.txt

Abstract

   This document extends the Application-Layer Traffic Optimization
   (ALTO) protocol [I-D.ietf-alto-protocol] by defining PID-based
   properties in much the same way that the original ALTO protocol
   defines endpoint-based properties.

Requirement Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 24, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Roome, Yang                Expires April 2014                   [Page 1]

Internet Draft            ALTO PID Properties           October 21, 2013


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.














































Roome, Yang                Expires April 2014                   [Page 2]

Internet Draft            ALTO PID Properties           October 21, 2013


Table of Contents

    1. Introduction
        1.1. ALTO PIDs
        1.2. ALTO Endpoint Properties
        1.3. PID Properties
        1.4. Inheritance Via Nested PIDs
    2. Services
        2.1. Full PID Property Map Service
        2.2. Filtered PID Property Map Service
        2.3. Extension to ALTO Endpoint Property Service
    3.  Security Considerations
    4.  IANA Considerations
    5.  References
        6.1.  Normative References
        6.2.  Informative References


. Introduction

   1.1. ALTO PIDs

   The ALTO protocol defines a PID (Provider-defined Identifier) as a
   collection of endpoint addresses. Each PID has a name, and the PID's
   address set is defined by one or more endpoint address prefixes
   called CIDRs [RFC4632]. An ALTO server uses PIDs by providing one or
   more Network Maps, each of which is defined by a collection of PIDs.

   PID specifications can overlap. For example, if PID1 is 10.0.0.0/8,
   and PID2 is 10.0.1.0/24, then all endpoints in PID2 are also in PID1.
   However, ALTO requires that an endpoint address be in one, and only
   one, PID. ALTO resolves this ambiguity by saying that if an endpoint
   address matches several CIRDs, the endpoint is in the PID with the
   CIDR with the longest prefix. We refer to this PID as the home PID of
   the endpoint. Thus, for the example, 10.0.1.5 is in PID2, and
   10.0.2.6 in in PID1.

   Although not required by the ALTO protocol, the hierarchical
   structure of the PIDs in a Network Map may reflect the logical
   structure of the network. In particular, although it is not required,
   the endpoints in a PID may be in the same geographical area.

   1.2. ALTO Endpoint Properties

   The ALTO protocol defines endpoint properties as a set of (name,
   value) pairs associated with each selected endpoint address. An ALTO
   server defines those properties, and the ALTO protocol allows a
   client to obtain those properties from a server.



Roome, Yang                Expires April 2014                   [Page 3]

Internet Draft            ALTO PID Properties           October 21, 2013


   1.3. PID Properties

   This document proposes extending the property concept by allowing
   PIDs to have properties. This is useful when the endpoints in a given
   PID share common properties. Examples are "country code", "continent
   code", "ISP", "lat/long bounding box", "endpoint type" (server farm,
   end users, cell data connections, etc).

   1.4. Implicit Inheritance Via Nested PIDs

   In this document, we define PID properties to take advantage of the
   fact that PID definitions can overlap, or nest. That is, an ALTO
   server may define PID1, PID2 and PID3 such that all CIDRs defined in
   PID2 are also covered by the CIDRs in PID1; so are the CIDRs defined
   in PID3. Hence, we say that PID2 and PID3 can be considered "sub-
   PIDs" of PID1.

   To avoid potential issues of "multi-inheritance", for example, when
   PID2 is also a "sub-PID" of PID4, we consider only the case that the
   derived inheritance forms a tree. In other words, for the example
   that PID2 is sub-PID of both PID1 and PID4, then either PID1 is a
   sub-PID of PID4 or vice versa. Hence, we can say uniquely the direct
   parent of a PID. Future ALTO extensions may consider explicit
   definitions of nesting, for example, by specifying that PID1 consists
   of PID2 and PID2, without implicit derivation.

   With nesting, we define that PID2 and PID3 would inherit all
   properties of its ancestors, for example PID1, unless overriden in
   the sub-PIDs. For example, an ALTO server might define continent-
   level PIDs, as well as country-level or region-level sub-PIDs. If the
   ALTO server defines a "continent code" property for the continent-
   level PIDs, the country-level PIDs will automatically inherit that
   property. Such inheritance reduces information redundancy.


   2. Services

   In the interests of simplicity, we will give an overview of the
   proposed services, rather than detailed descriptions.

   2.1. Full PID Property Map Service

   Analogous to ALTO's Full Cost Map Service, a Full PID Map Service
   returns properties defined for all PIDs in a Network Map.

   This is a GET request. The response message is similar to that of
   ALTO's Endpoint Property Service, but with PID names instead of
   endpoint addresses. The IRD entry for the service defines a "prop-



Roome, Yang                Expires April 2014                   [Page 4]

Internet Draft            ALTO PID Properties           October 21, 2013


   types" capability with the names of the properties that this service
   returns, and specifies a "uses" attribute for the Network Map
   defining the PIDs.

   In the interests of limiting the response message size, the Full PID
   Property Map Service would NOT enumerate inherited property values.
   Thus if PID1 defines PROP1, and if PID2 is contained within PID1 and
   does not override the value for PROP1, then the response message
   gives a value for PROP1 in PID1, but not in PID2. In this case the
   client is expected to deduce the inheritance. That is feasible
   because the client has all information needed to do that.

   2.2. Filtered PID Property Map Service

   Analogous to ALTO's Filtered Cost Map Service, a Filtered PID Map
   Service returns a subset of the Full PID Property Map. The client
   specifies the desired property and PID names.

   This is a POST request. The response message is the same as for the
   Full PID Property Map Service. The request message is similar to the
   request message for ALTO's Endpoint Property Service, except with PID
   names instead of endpoint addresses. The IRD entry for the service
   defines a "prop-types" capability with the names of the properties
   this service returns, and specifies a "uses" attribute for the
   Network Map defining the PIDs.

   Unlike the Full Filtered PID Property Service, the Filtered PID
   Property Service would explicitly enumerate inherited property
   values. Thus if PID1 defines PROP1, and if PID2 is contained within
   PID1 and does not override the value for PROP1, then the response
   message includes PID1's value for PROP1 in PID2's properties. This is
   necessary because the Filtered PID Property Map response does not
   give the client enough information to deduce the inherited
   properties. For consistency, the Filtered PID Property Service would
   enumerate inherited properties for a PID even if the client also
   requested properties for all PIDs that containing that PID.

   2.3. Potential Integration with ALTO Endpoint Property Service

   When one considers inheritance and considers that each endpoint
   defines a leaf of the PID inheritance tree, with its direct parent
   being its home PID, then each endpoint will inherit the properties of
   its ancestor PIDs. We propose extending the current Endpoint Property
   Service (EPS) to allow EPS to use PID properties as a default.
   Specifically, if the IRD for an EPS "uses" a Network Map resource,
   then if that EPS does not define a property value for a given
   endpoint, but the PID containing that endpoint does define a value
   for that property, then the EPS will return the PID property. As with



Roome, Yang                Expires April 2014                   [Page 5]

Internet Draft            ALTO PID Properties           October 21, 2013


   the Filtered PID Property Map Service, sub-PIDs would inherit
   property values from higher-level PIDs.

.  Security Considerations

   There are no security considerations relevant to this document.

.  IANA Considerations

   No actions are required from IANA as result of the publication of
   this document.

.  References

   5.1.  Normative References

   [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO
              Protocol", draft-ietf-alto-protocol-20 (work in progress),
              October 2013.

   [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.


   5.2.  Informative References

Authors' Addresses

   Wendy Roome
   Alcatel-Lucent Bell Labs
   600 Mountain Ave, Rm 2B-234
   Murray Hill, NJ 07974
   USA
   Email: w.roome@alcatel-lucent.com

   Y. Richard Yang
   Yale University
   51 Prospect St
   New Haven CT
   USA
   Email: yry@cs.yale.edu









Roome, Yang                Expires April 2014                   [Page 6]