Internet DRAFT - draft-scharf-alto-yang
draft-scharf-alto-yang
ALTO WG M. Scharf
Internet-Draft Alcatel-Lucent Bell Labs
Intended status: Standards Track July 4, 2014
Expires: January 5, 2015
ALTO Extension for YANG Modules
draft-scharf-alto-yang-00
Abstract
The Application-Layer Traffic Optimization (ALTO) protocol is
designed to expose network topology information to applications. The
ALTO protocol includes a well-defined set of base services. This
document specifies an optional ALTO extension that enables ALTO
clients to discover and query additional data being defined by YANG
modules. This document describes the corresponding extensions of the
ALTO Information Resource Directory and other required mechanisms.
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 January 5, 2015.
Copyright Notice
Copyright (c) 2014 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
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
Scharf Expires January 5, 2015 [Page 1]
Internet-Draft ALTO Extension for YANG July 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ALTO Network Topology Exposure vs. Network Configuration . . 3
4. Benefits of Using YANG Data Models . . . . . . . . . . . . . 4
5. Extending ALTO to Support YANG Modules . . . . . . . . . . . 5
5.1. ALTO Information Resource Directory . . . . . . . . . . . 5
5.2. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 6
5.3. YANG Data Model Assumptions . . . . . . . . . . . . . . . 6
5.4. Media Type . . . . . . . . . . . . . . . . . . . . . . . 7
5.5. Accessing the URI . . . . . . . . . . . . . . . . . . . . 7
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The Application-Layer Traffic Optimization (ALTO) protocol
[I-D.ietf-alto-protocol] is designed to expose network topology
information to applications. The ALTO Information Resource Directory
(IRD) of an ALTO server describes the services supported by an ALTO
server and corresponding attributes. As defined in
[I-D.ietf-alto-protocol], each information resource has several
associated attributes, including an assigned identifier, a response
format, capabilities, accepted input parameters, and other resources
that it may depend on. Prior to obtaining ALTO guidance, ALTO client
may retrieve the Information Resource Directory from the ALTO server
to determine the attributes of individual information resources that
this ALTO Server provides.
The ALTO protocol is designed to be extensible, and several protocols
extensions have been suggested, including for instance
[I-D.roome-alto-pid-properties] or [I-D.randriamasy-alto-multi-cost].
In addition to such extensions of the ALTO protocol, an ALTO server
may be willing to offer additional network information and guidance
beyond the base functionality of the ALTO protocol. In this case,
one option is to specify the offered guidance using YANG [RFC6020] as
data modeling language.
Scharf Expires January 5, 2015 [Page 2]
Internet-Draft ALTO Extension for YANG July 2014
This document specifies an optional ALTO extension that enables ALTO
clients to discover and query additional data offered by an ALTO
server, being defined by YANG modules. This document describes the
corresponding extensions of the ALTO Information Resource Directory
and other required mechanisms.
2. Terminology
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 [RFC2119].
3. ALTO Network Topology Exposure vs. Network Configuration
ALTO is designed as a protocol between clients integrated in
applications and servers that provide network information and
guidance (e.g., basic network location structure and preferences of
network paths). The objective is to modify network resource
consumption patterns at application level while maintaining or
improving application performance. The basic information of ALTO is
based on an abstract representation of the network as it matters to
applications at endpoints.
Given the focus on topology exposure to guidance, there are several
differences between ALTO and other protocols used for network
management, such as SNMP [RFC3411] or NETCONF [RFC6241]:
o Specialization: ALTO is an optimized protocol focused on exposing
network topology data. This is different to general-purpose
protocols.
o Read-only: ALTO is a query/response protocol to retrieve data.
Neither ALTO network/cost map queries nor queries to the ALTO
endpoint property or cost services are designed to affect state in
the ALTO server or in the ALTO client. Network management
protocols are typically designed to manipulate the configuration
of network devices.
o Trust model: The ALTO protocol has been designed for use cases
where the ALTO server and client can be located in different
organizations or trust domains. Network configuration will
require a much stronger security model.
o Non-NMS applications: ALTO is designed for applications that
perform resource selections among endpoints, e.g., in an
application overlay. Such applications are typically not part of
an Element Management System (EMS) or Network Management System
(NMS).
Scharf Expires January 5, 2015 [Page 3]
Internet-Draft ALTO Extension for YANG July 2014
o A priori knowledge: ALTO does not assume that an ALTO client has
any a priori knowledge about the ALTO server and its supported
features. An ALTO server can be discovered automatically. In
network management, there is often a need for explicit
configuration, e.g., of security credentials.
o Terminology: In ALTO, the application is running a client, while
the network offers a service by means of a server. SNMP would use
the terms manager and agent for these entities, and NETCONF may
use the terms server and client in the opposite way. This
reflects the different usage patterns.
These aspects are also detailed in [I-D.ietf-alto-deployments].
The same differences also apply to control plane protocols designed
to configure state on network elements, such as components of a Path
Computation Element (PCE) architecture or an Interface to the Routing
System (I2RS).
4. Benefits of Using YANG Data Models
Despite different use cases, ALTO clients could use a limited set of
functions originally designed for network management, including
protocol functions for read-only retrieval of data. For instance, an
ALTO server may use network monitoring data or Operations,
Administration, and Maintenance (OAM) measurement results as data
sources [I-D.ietf-alto-deployments], and that data could originate
from Network Management Systems (NMS). If permitted by privacy
policies, an ALTO server could be willing to optionally expose such
input data used by the ALTO service to ALTO clients.
In that case, a straightforward solution is to transform that input
data into a format supported by ALTO, e.g., network and cost maps
with additional cost metrics. Yet, if the ALTO server already
queries data specified in YANG [RFC6020], it could optionally also
expose that data to ALTO clients, provided that the aforementioned
restrictions are taken into account.
Support of YANG modules would be a simple way for an ALTO server to
offer optional, additional services, e.g., to access monitoring data.
A data model described in YANG could enable an ALTO client to easily
determine the type of additional data exposed by ALTO, since a YANG
module specifies the corresponding syntax.
As a specific example, an ALTO server may have access to interface
statistics for endpoints in the network, using the YANG module "ietf-
interfaces" [RFC7223], and it may use these statistics to e.g. to
calculate network and cost maps. If an ALTO client would
Scharf Expires January 5, 2015 [Page 4]
Internet-Draft ALTO Extension for YANG July 2014
specifically be interested in counter metrics such as "out-errors",
the ALTO server could obviously expose this by ALTO, e.g., as several
cost maps or as an endpoint/PID property
[I-D.roome-alto-pid-properties]. An alternative approach would be
that the ALTO server natively exposes that data in a YANG-based
format. This requires a solution to support YANG modules in ALTO.
5. Extending ALTO to Support YANG Modules
This section specifies how an ALTO server can announce the support of
additional, optional services defined by YANG modules.
5.1. ALTO Information Resource Directory
According [I-D.ietf-alto-protocol], objects in the ALTO Information
Resource Directory (IRD) have the following format:
object {
JSONString uri;
JSONString media-type;
[JSONString accepts;]
[Capabilities capabilities;]
[ResourceID uses<0..*>;]
} IRDResourceEntry;
The extension in this document use this format and defines the
following setting of these objects:
o uri: A URI at which the data is provided. This can both be an URI
at the ALTO server, or it can delegate to another server
(Section 9.2.4 of [I-D.ietf-alto-protocol]). This extension uses
the URI to refer to data described in YANG modules.
o media-type: The media type that is to be used by GET (or POST)
requests to the corresponding URI. This is further detailed
below.
o accepts: This optional parameter can also be set if required, as
described in [I-D.ietf-alto-protocol].
o capabilities: Capabilities are optional. A server MAY announce
the use of YANG as data modeling language for certain resources as
a capability ("yang" : true), if this is not already implied by
the media-type. Further capabilities might be used to describe
the YANG modules, but this is TBD.
o uses: The setting of this parameter is for further study.
According to [I-D.ietf-alto-protocol], this setting can be used to
Scharf Expires January 5, 2015 [Page 5]
Internet-Draft ALTO Extension for YANG July 2014
define other resources on which this resource directly depends.
As a result, it could for instance be used to refer to ALTO cost
maps that are related to the data described in this resource
refering to YANG modules.
An example of a corresponding ALTO Information Resource Directory
entry would be:
...
"my-own-map-data" : {
"uri" :
"http://alto.example.com/restconf/data/my-own-map-data",
"media-type" : "application/yang.data+json",
"capabilities" : {
"yang" : true
}
},
...
5.2. JSON Encoding
The ALTO protocol uses a REST-ful design and encodes its requests and
responses using JSON [RFC4627]. Therefore, all data returned using
this specification MUST be encoded in JSON.
[I-D.ietf-netmod-yang-json] defines rules for representing data
defined using YANG as JSON text.
5.3. YANG Data Model Assumptions
YANG can model configuration data as well as state data. The latter
is marked by the "config false" statement [RFC6020]. State data on a
system is no configuration data and cannot be changed, such as read-
only status information and collected statistics. When a node in a
YANG module is tagged with "config false", its sub-hierarchy is
flagged as state data as well.
Since ALTO only offers read-only access to information, this document
implicitly assumes that the URI announced by an ALTO server only
exposes read-only data. This document only describes how an ALTO
client can discover the URI for additional data and learn now to
retrieve data by a REST protocol from there; the actual communication
and interpretation of data is outside the scope of this document.
Read-only access can trivially be enforced if an ALTO server using
the mechanism in this document only use YANG modules that contain
state data only, i.e., all containers, lists, and leafs etc. are be
covered by "config false" statements. Alternatively, there could be
Scharf Expires January 5, 2015 [Page 6]
Internet-Draft ALTO Extension for YANG July 2014
ways to ensure read-only access, e.g., by appropriate selection of
the URI.
Any write access by a client using the information in the ALTO IRD is
outside the scope of this memo.
This document does not cover notifications. The handling of
"notifications" in a YANG module is therefore outside the scope of
the document.
The handling of "rpc" statements in a YANG module is for further
study.
5.4. Media Type
This document does not register additional media types. An ALTO
client SHOULD use the media type(s) defined in the ALTO IRD to access
the URI, as detailed in the next section.
An example media type could be "application/yang.data+json" as
defined in [I-D.ietf-netconf-restconf].
5.5. Accessing the URI
The way to retrieve data from the URI returned by the ALTO IRD
depends on the media type. An ALTO client can determine from the
media type whether it supports the method and whether optional data
from an ALTO server can be retrieved. This document describes an
optional ALTO extension and does not mandate that an ALTO client
supports any specific protocol.
One approach to retrieve additional data described by a YANG model
would be RESTCONF [I-D.ietf-netconf-restconf]. In this case, the
ALTO IRD is basically used as a discovery mechanism for corresponding
RESTCONF URIs. For RESTCONF, the syntax of the URI, as well as the
protocol for data retrieval is defined in
[I-D.ietf-netconf-restconf]. For instance, a valid URI would be
"http://alto.example.com/restconf/data/my-own-map-data", and a
corresponding media type could be "application/yang.api". If the URI
points to the RESTCONF root, the client could also use other APIs as
defined in [I-D.ietf-netconf-restconf], e.g., to retrieve the YANG
module definition file. The latter would enable an ALTO client to
dynamically learn the YANG module definitions.
In a simpler variant, an ALTO server would just return the complete
tree of state data encoded in JSON [I-D.ietf-netmod-yang-json]. This
could be sufficient for extensions equivalent to the current ALTO
network and cost map services without filtering, which always return
Scharf Expires January 5, 2015 [Page 7]
Internet-Draft ALTO Extension for YANG July 2014
all available data without fine-grained query access. Details of
this mode are for further study.
6. Example
In the following, we illustrate the mechanism described in this
document with a simple example.
The initial query of an ALTO client to an ALTO server's IRD could be:
GET /directory HTTP/1.1
Host: alto.example.com
Accept: application/alto-directory+json,
application/alto-error+json
The server would then return the supported ALTO services, including
the one specified in this document:
HTTP/1.1 200 OK
Content-Length: TBD
Content-Type: application/alto-directory+json
{
"meta" : {
...
},
"resources" : {
...
"my-own-map-data" : {
"uri" :
"http://alto.example.com/restconf/data/my-own-map-data",
"media-type" : "application/yang.data+json",
"capabilities" : {
"yang" : true
}
},
...
}
}
Since the media type refers to [I-D.ietf-netconf-restconf], a follow-
up query of the ALTO client supporting this protocol could be:
GET /restconf/data/my-own-map-data HTTP/1.1
Host: alto.example.com
Accept: application/yang.data+json
Scharf Expires January 5, 2015 [Page 8]
Internet-Draft ALTO Extension for YANG July 2014
The response of the server is outside the scope of this document and
depends on the YANG data model accessed by that URI. For instance,
assume the following trivial model of an extension just giving a
convenient list of the PIDs currently used by the ALTO server:
module my-own-map-data {
...
container my-own-map-data {
config false;
list pid-list {
key pid;
leaf pid {
type string;
}
}
}
...
}
Then, the server response could be:
HTTP/1.1 200 OK
Content-Length: TBD
Content-Type: application/yang.data+json
{
"my-own-map-data" : {
"pid-list" : [
{
"pid" : "PID1",
},
{
"pid" : "PID2",
},
...
{
"pid" : "PID9",
}
]
}
}
This is a trivial example, but the same principle is applicable to
any YANG module. Obviously, an ALTO client has to support processing
of the corresponding YANG module (or modules) to make use of this
extension.
Scharf Expires January 5, 2015 [Page 9]
Internet-Draft ALTO Extension for YANG July 2014
7. IANA Considerations
TBD
8. Security Considerations
This document descibes read-only access to data optionally announced
by an ALTO server. The security considerations of the ALTO protocol
as detailed in [I-D.ietf-alto-protocol] and
[I-D.ietf-alto-deployments] apply to the ALTO extension in this
document. Specifically, the operator of an ALTO server has to ensure
that there is no unauthorized access to sensitive data. This
extension should not be used if there are privacy concerns.
9. Conclusion
TBD
10. References
10.1. Normative References
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
ietf-alto-protocol-27 (work in progress), March 2014.
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
"RESTCONF Protocol", draft-ietf-netconf-restconf-01 (work
in progress), July 2014.
[I-D.ietf-netmod-yang-json]
Lhotka, L., "JSON Encoding of Data Modeled with YANG",
draft-ietf-netmod-yang-json-00 (work in progress), April
2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
Scharf Expires January 5, 2015 [Page 10]
Internet-Draft ALTO Extension for YANG July 2014
10.2. Informative References
[I-D.ietf-alto-deployments]
Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf,
"ALTO Deployment Considerations", draft-ietf-alto-
deployments-10 (work in progress), July 2014.
[I-D.randriamasy-alto-multi-cost]
Randriamasy, S., Roome, B., and N. Schwan, "Multi-Cost
ALTO", draft-randriamasy-alto-multi-cost-07 (work in
progress), October 2012.
[I-D.roome-alto-pid-properties]
Roome, W. and Y. Yang, "PID Property Extension for ALTO
Protocol", draft-roome-alto-pid-properties-02 (work in
progress), July 2014.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, May 2014.
Author's Address
Michael Scharf
Alcatel-Lucent Bell Labs
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: michael.scharf@alcatel-lucent.com
Scharf Expires January 5, 2015 [Page 11]
