Internet DRAFT - draft-huang-alto-topocomp-framework
draft-huang-alto-topocomp-framework
ALTO WG R. Huang
Internet-Draft Huawei
Intended status: Informational H. Guo
Expires: September 10, 2015 CAICT
Y. Yang
Yale University
March 9, 2015
Network Topology Service (NTS) Framework
draft-huang-alto-topocomp-framework-00
Abstract
This document introduces a network topology service (NTS) framework
to collect network topologies from the physical heterogeneous
network, NTS analyses and stores the topology information, and
provides the path computing and topology information inquiring
ability to applications (including network applications like OSS, and
third-party applications).
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
<Author> Expires September 10, 2015 [Page 1]
INTERNET DRAFT <Document Title> March 9, 2015
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
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. Network Topology Service (NTS) Framework . . . . . . . . . . . 3
4. Topology Managing of NTS Framework . . . . . . . . . . . . . . 6
5. Topology Inquiring of NTS Framework . . . . . . . . . . . . . 6
6. Path Computing of NTS Framework . . . . . . . . . . . . . . . 7
7. Relationship with Other Existing IETF work . . . . . . . . . . 8
7.1. I2RS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Network topology is a prerequisite for performing many critical
network management tasks, including resource managements, path
computation, event correlation, fault monitoring and analysis.
Current networks are continually being refined and upgraded as needs
change and technology evolves. Many technologies have developed
protocol-specific ways to obtain network topologies for their own
usages. For example, a router supporting OSPF maintains an identical
area-topology database to determine the shortest path to any
neighboring router; BGP maintains a consistent view of network
topology to optimize routing and scale the network. However, when
network topologies or route paths are required by applications,
<Author> Expires September 10, 2015 [Page 2]
INTERNET DRAFT <Document Title> March 9, 2015
applications usually wish to be shielded from protocol-specifics
information, even if network state information is collected in
protocol-specific ways. It is obvious that none of these methods
offer a general-purpose tool that can efficiently manage the network
topology for a heterogeneous network with multiple technologies
including BGP/OSPF/ISIS, and even SDN Open Flow, etc.
This document introduces a network topology service (NTS) framework
to collect network topologies from the physical heterogeneous
network, NTS analyses and stores the topology information, and
provides flexible path computing and topology information inquiring
ability to applications (including network applications like OSS, and
third-party applications).
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 RFC 2119 [RFC2119].
This document uses the following terms:
NTS: Network Topology Service
BGP: Border Gateway Protocol
OSPF: Open Shortest Path First
IS-IS: Intermediate System to Intermediate System
SDN: Software Defined Network
OSS: Operational Support Systems
3. Network Topology Service (NTS) Framework
This section describes the NTS framework as shown in Figure 1:
<Author> Expires September 10, 2015 [Page 3]
INTERNET DRAFT <Document Title> March 9, 2015
xxxxxxxxx
x x
x APP x
xxxxxxxxx
---Topology Service Interface---
xxxxxxxxxxxxxxxxx
x x
x Aggregator x
x x
xxxxxxxxxxxxxxxxx
/|\
+----------------+---------------+
| | |
| | |
| | |
\|/ \|/ \|/
xxxxxxxxx xxxxxxxxxx xxxxxxxxx
x x x x x x
x TS x x TS x x TS x
xxxxxxxxx xxxxxxxxxx .... xxxxxxxxx
/|\ /|\ /|\
| | |
| | +----+---+
+----+----+ | | |
| | | | |
| | | | |
xxxxx|xxxxxxxxx|xxxxxxxxxxx|xxxxxxxxxx|xxxxxxxx|xxxxxx
x | | | | | x
x xxx|xxx xx|xxxx xxx|xxx xxx|xxx xxxxxxx x
x x TA x x TA x x TA x x TA x x TA x x
x x R x x R x x R x x R x x R x x
x xxxxxxx....xxxxxxx....xxxxxxx....xxxxxxx..xxxxxxx x
x x
x Physical Network x
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
APP ---- Application
TS ---- Topology Server
TA ---- Topology Agent
Figure 1: Framework of NTS
The entities used in this framework are:
<Author> Expires September 10, 2015 [Page 4]
INTERNET DRAFT <Document Title> March 9, 2015
Topology Agent: A logical entity located in network devices like
switches, routers, etc. It is responsible for reporting the
topology information produced in some protocol-specific ways and
network changes, event, or states to its topology server. One
topology agent can only be controlled by one topology server to
avoid global network topology duplicating.
Topology Server: A server that collects topology information from
physical network for a subset of devices, analyses, abstracts, and
stores the subset topology information in a protocol independent
way. Usually, a large network is too hard for a single topology
server to handle. Thus, multiple topology servers are considered
in this framework. Each of them is only responsible for a part of
the global network. Topology server has the ability to calculate
the special topology or the most optimized path based on specific
algorithms from applications. Different algorithms may lead to
different results.
Aggregator: A server that maintains a sketch topology information
among all topology servers. It does not perceive any detailed
subset topology information as individual topology servers. This
entity is only responsible for generating and maintaining
relationship among different topology servers, and calculating the
final topology or optimized path based on the results calculated
from some or all of the topology servers.
Application: It represents network applications like OSS, and
third-party applications that require to use network topology
service.
The interfaces needed in this framework:
Interface between topology agent and topology server: An interface
that can be used by TA to report different protocol-specific
topology information, e.g., BGP/OSPF/IS-IS,or SDN OpenFlow, to TS.
Besides, TA can use it to notify TS the changes, states, and
events.
Interface between topology server and aggregator: Communication
between topology servers and aggregator. It includes topology
servers reporting their ingress and egress information to the
aggregator, aggregator conveying applications' local topology
algorithms information to topology servers, and topology servers
returning their calculation results based on the local topology
algorithms from applications to the aggregator.
Topology Service Interface: This interface is used by applications
to communicate with the aggregator on path computation requesting
<Author> Expires September 10, 2015 [Page 5]
INTERNET DRAFT <Document Title> March 9, 2015
and topology information obtaining. Applications use the interface
to insert their own algorithms and requirements for the network
topology service system to do some application specific
calculations. Two kinds of algorithms are considered here: One for
a topology server to calculate the special topology or the most
optimized path based on its subset topology information (local
topology algorithm); The other for the aggregator to calculate the
global and the special topology or the most optimized path based
on the results from all topology servers and the sketch topology
information generated by the aggregator (global topology
algorithm).
4. Topology Managing of NTS Framework
In NTS Framework, there are two level topologis: One is the generic
network topology that is managed by TS; Other is managed by
Aggregator.
TA discovers network topology and states/events, then reports the
protocol-specific network topology to TS. TS analyses the network
topology information, and constructs a generic network topology. TS
stores the generic network topology in a protocol independent way. TA
also can generate an abstract topology basing the generic network
topology by partition or aggregation to avoid giving the detail
network information to Application. TS also reports the ingress and
egress information of its managing subnet network to the Aggregator.
Aggregator generates a sketch topology information reflecting the
relationship among all the TSes. In a sketch topology, each subset
network managed by a TS is condensed into a node. Aggregation may be
give the sketch topology to Application to assist the path computing
5. Topology Inquiring of NTS Framework
Any Application can inquiry a special network topology, for example
Network Map or Cost Map in ALTO service, from the NTS framework. The
detailed steps of topology inquiring is listed as following:
* Application inputs local topology algorithm and global topology
algorithm the aggregator to request a special topology.
* Aggregator instructs all (or some relevant) TSes to calculate
their own special topology in their subset topologies based on the
local topology algorithm of the application.
* TS independently calculates the special topology in its subset
<Author> Expires September 10, 2015 [Page 6]
INTERNET DRAFT <Document Title> March 9, 2015
topology, and reports its result to the aggregator.
* Aggregator calculates the final global topology based on the
results of all the TSes, the sketch topology information, and the
global topology algorithm, then Aggregator returns the final
topology to Application.
6. Path Computing of NTS Framework
In SDN network, applications without knowledge of physical network
can be benefit from the NTS framework to obtain the most suitable and
efficient network path based on which they can then do some
programming.
The detailed steps of path computing is listed as following:
* Application inputs local topology algorithm, global topology
algorithm, source information and destination information to the
aggregator to request an optimized path.
* (Optional) Aggregator gives the sketch topology to Application.
* (Optional) With the sketch topology, Application decides whether
or not to filter some irrelevant-like TSes that maybe not appear
in the end to end network path. If so, Application inputs the
filtering algorithm to Aggregator.
* (Optional) Aggregator uses the filtering algorithm to filter
some irrelevant-like TSes.
* Aggregator instructs all (or some relevant) TSes to calculate
their own optimized path in their subset topologies based on the
local topology algorithm of the application.
* TS independently calculates the optimized path in its subset
topology, and reports its result to the aggregator.
* Aggregator calculates the final global optimized path based on
the results of all the TSes, the sketch topology information, and
the global topology algorithm, then Aggregator returns the final
global optimized path to Application.
When the number of TSes increasing, the performance of this framework
maybe reduced as all of the TSes need to do calculation. This can be
solved by applications inputting another algorithm or requirement to
allow the aggregator filtering some irrelevant-like TSes before
<Author> Expires September 10, 2015 [Page 7]
INTERNET DRAFT <Document Title> March 9, 2015
sending any instructions to TSes. Thus, only those TSes which are
responsible for the network topology between the end-to-end network
path are required to do the calculation. However, this function is
optional here since some applications may need to all of the TSes to
take part in the calculation.
7. Relationship with Other Existing IETF work
7.1. I2RS
I2RS is discussing a generic topology data model. However, current
I2RS charter says it is not responsible to develop protocols,
encoding languages, or data models. The topology work in I2RS can be
considered to use in the interface between TA and TS. However, I2RS
will not discuss a detailed topology service. The protocols and data
models produced in I2RS can be considered in this work.
7.2. PCE
PCE is discussing to specify the required protocols so as to compute
of paths for MPLS and GMPLS Point to Point and Point to Multi-point
Traffic Engineered LSPs. PCE does not consider to manage the network
topology from multiple protocols. NTS framework can provides more
flexible path computing algorithm and topology information
inquiring.
8. Security Considerations
TBD.
9. IANA Considerations
This document does not require any IANA creations or modifications.
10. Acknowledgments
TBD.
11. References
11.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
<Author> Expires September 10, 2015 [Page 8]
INTERNET DRAFT <Document Title> March 9, 2015
Authors' Addresses
Rachel Huang
Huawei
101 Software Avenue, Yuhua District
Nanjing 210012
China
EMail: rachel.huang@huawei.com
Huaming Guo
China Academy of Information and Communications Technology
36 A Nanlishi Road, Xicheng District
Beijing 10037
China
EMail: guohuaming@caict.ac
Y. Richard Yang
Yale University
51 Prospect St
New Haven, CT 06511
USA
EMail: yry@cs.yale.edu
<Author> Expires September 10, 2015 [Page 9]
