Internet DRAFT - draft-medved-i2rs-topology-requirements
draft-medved-i2rs-topology-requirements
Interface to the Routing System (I2RS) J. Medved
Internet-Draft S. Previdi
Intended status: Standards Track Cisco Systems, Inc.
Expires: August 21, 2013 H. Gredler
T. Nadeau
Juniper Networks, Inc.
S. Amante
Level 3 Communications, Inc.
February 17, 2013
Topology API Requirements
draft-medved-i2rs-topology-requirements-00
Abstract
This document describes requirements for collecting topology data
from network elements and other sources, creating a coherent view of
the network topology from the collected data, and presenting the
topology view to various applications that need to: a) understand the
topology; and, b) leverage topology information in order to improve
application specific mechanisms such as path selection, resources
reservation, etc.
Requirements 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 August 21, 2013.
Copyright Notice
Medved, et al. Expires August 21, 2013 [Page 1]
Internet-Draft Topology API Requirements February 2013
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Operational Model . . . . . . . . . . . . . . . . . . . . . . 3
3. Topology Manager Requirements . . . . . . . . . . . . . . . . 5
3.1. Topology Manager Requirements . . . . . . . . . . . . . . 5
3.1.1. General Requirements . . . . . . . . . . . . . . . . . 5
3.1.2. Data Model Requirements . . . . . . . . . . . . . . . 6
3.1.3. Northbound (Client) API Requirements . . . . . . . . . 10
3.1.4. Southbound (Network & Device) API Requirements . . . . 11
4. Network Element Requirements . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Medved, et al. Expires August 21, 2013 [Page 2]
Internet-Draft Topology API Requirements February 2013
1. Introduction
[I-D.amante-irs-topology-use-cases] demonstrates the need for a
network function that would provide a common, standard-based topology
view to applications. This function is called 'Topology Manager' in
this document. which specifies requirements for the Topology Manager.
Topology Manager requirements fall into one of the following
categories:
General: describes general requirements for the Topology Manager.
Data Model: describes requirements for the network topology data
model & view.
Northbound (Client) API: describes requirements for Topology
Manager's communication with clients.
Southbound (Network & Device) API: describes requirements for
Topology Manager's communication with Network Elements and other
topology data sources.
Network Elements: describes requirements for the Network Element's
data model, capabilities, etc. required to support collection of
network topology data.
The rest of this document is organized as follows. First, the
Topology Manager's Operational Model is described in Section 2.
Topology Manager requirements are presented in Section 3. Finally,
Network Element requirements are presented in Section 4.
2. Operational Model
As defined in [I-D.amante-irs-topology-use-cases], the Topology
Manager performs the following tasks:
Collection of topology data from multiple sources: Network
Elements, routing protocols, inventory collection, statistics
collection, etc, as discussed in
[I-D.amante-irs-topology-use-cases]. Note that some of the data
sources, such as statistics or inventory, will be used not only by
the Topology Manager, but by other applications as well. Note
also that topology data sources may reside in multiple IGP areas
or multiple ASes, and/or in multiple network layers.
Creation of global topology view (i.e.: a common data model) from
the collected data; the topology view can span multiple network
layers as well as multiple Autonomous Systems. The global view
Medved, et al. Expires August 21, 2013 [Page 3]
Internet-Draft Topology API Requirements February 2013
includes all network elements and resources existing in the
infrastructure, whether they are actively used or not. An example
consists of reconstructing the global view of the network
including router or switch ports that are available but not in
use.
Presentation of the network view to clients (applications). The
Topology Manager can create multiple application-specific views
from its common global topology database.
The operational model is shown in Figure 1.
+------------+ +------------+
| Client | | Client |
+------------+ +------------+
^ ^
| Northbound API |
+---------------+----------------+
|
|
+-------------------------+
| Topology Manager |
...<-->| +---------------------+ |<--> Peer Topology
| | Topology Data Model | | Managers
| +---------------------+ |
+-------------------------+
^ ^ Southbound APIs
Other Topology Sources | |
(BGP-LS, Statistics, -----+ | SNMP, NetConf, I2RS,
Inventory) | OF, TL1, ...
+-------------------------+------------------------+
| | |
+----------------+ +----------------+ +----------------+
| Network Element| | Network Element| | Network Element|
| +------------+ |<-LLDP->| +------------+ |<-LMP->| +------------+ |
| | Data Model | | | | Data Model | | | | Data Model | |
| +------------+ | | +------------+ | | +------------+ |
+----------------+ +----------------+ +----------------+
Figure 1: Topology Manager operational model
Topology information from network elements is relayed into the
Topology Manager Function via its Southbound API, as shown in
Figure 1. Sources of topology information may be Network Elements at
different layers of the network, such as appliances, routers, L2
switches, optical transponders, optical switches or monitoring,
provisioning and network analytics tools, such as Statistics
Collection subsystems or an Inventory subsystem.
Medved, et al. Expires August 21, 2013 [Page 4]
Internet-Draft Topology API Requirements February 2013
The Topology Manager Function reconstructs the network/global view
(that can be on a per client or per application base) and distributes
it to its clients through northbound APIs. Examples of possible
northbound APIs are ReST, XMPP or Websockets. The Topology Manager
Function can be instantiated in a standalone server, be a part of a
comprehensive orchestration, data collection, presentation framework
(see [I-D.amante-irs-topology-use-cases]), or embedded in a routing
element. A client can be an application or a function in an upper
layer framework, such as a policy function.
Depending on the data it collects, a Topology Manager may not have
visibility into the entire network. In order to create a global
topology, the Topology Manager may get complementary partial topology
views from other Topology Managers via a Peer Topology Manager API.
3. Topology Manager Requirements
Distribution of all links available in the infrastructure is
certainly possible, however not desirable from a scaling and privacy
point of view. Therefore an implementation may support link to path
aggregation. Rather than advertising all specific links of a domain,
a topology manager may advertise an "aggregate link" between a non-
adjacent pair of nodes. The "aggregate link" represents the
aggregated set of link properties between a pair of non-adjacent
nodes. The actual methods to compute the path properties (of
bandwidth, metric) are outside the scope of this document. The
decision whether to advertise all specific links or aggregated links
is an operator's policy choice. To highlight the varying levels of
exposure, the following deployment examples shall be discussed.
3.1. Topology Manager Requirements
3.1.1. General Requirements
The general requirements are as follows:
TMF-GEN-1: I2RS MUST define a common vocabulary that describes
attributes associated with topological components of a network.
This is more commonly referred to as a "normalized" topology.
TMF-GEN-2: I2RS MUST define a data model that describes the
topological components represented by the Topology Manager
service. This data model will be written using a common
vocabulary, that allows one to assemble the components of a
network topology so that one can, for example, describe a physical
link and all of its associated physical layer attributes such as:
media type, bandwidth, MTU, etc.
Medved, et al. Expires August 21, 2013 [Page 5]
Internet-Draft Topology API Requirements February 2013
TMF-GEN-3: The Topology Manager has a Northbound (Client) API and
multiple Southbound APIs for collecting topology data from
networks. Southbound APIs can be, for example, SNMP, NETCONF,
CLI, I2RS, OpenFlow, or routing protocols (e.g.: IGPs/BGP/BGP-LS).
TMF-GEN-4: The Topology Manager has an East-West (Peer Manager)
API to exchange topology information with peer Topology Managers.
Topologies exchanged with peer Topology Managers can be real or
abstract. Note that the East- West API can be the same as the
Northbound or Southbound APIs.
TMF-GEN-5: The Topology Manager MUST be able to collect and
process topology data from hundreds of thousands of sources
(network elements, etc.). Being able to collect data from large
number of sources is especially important in very large networks.
TMF-GEN-6: The Topology Manager SHOULD be able to provide multiple
application-specific views to different clients.
TMF-GEN-7: The Topology Manager MUST support the flow of topology
data and network (routing or security) policies from the network
as well as Inventory and Statistics Collection warehouses to
clients. The ability for the Topology Manger to support bi-
directional flow of topology data and network policies between
clients and the network is currently out-of-scope.
TMF-GEN-8: The transport protocol on all Topology Manager APIs
MUST support incremental updates between Topology Managers or
between a Topology Manager and a client.
3.1.2. Data Model Requirements
The requirements for the topology data model are as follows:
TMF-DM-1: The topology data model MAY be able to describe topology
and characteristics of different network layers:
* Optical DWDM (for future study)
* Optical OTN (for future study)
* L2 (Aggregated links, L2 topologies)
* IP/MPLS
Medved, et al. Expires August 21, 2013 [Page 6]
Internet-Draft Topology API Requirements February 2013
* VPNs
* Services, such as cloud services, or CDNs
TMF-DM-2: The topology data model MUST support multiple Autonomous
System deployments.
TMF-DM-3: The Topology Manager MUST provide data normalization,
i.e. various types of topology information from different network
elements at different network layers and in different admin
domains is processed into a single, common format for clients'
consumption.
TMF-DM-4: The topology data model MUST be able to convey enough
information so that a client can correlate topologies in different
layers and from multiple Autonomous Systems.
TMF-DM-5: The topology data model MUST support multi-layer
grouping of elements as a means of coalescing different nodes and
links into "network layers". For example, links with IPv4
addresses might represent Layer 3 of the network topology while
links with Ethernet MAC addresses might represent Layer 2.
Furthermore, virtual private networks can be represented using
this grouping mechanism.
TMF-DM-6: Association between components of different layers is
needed as a means of indicating relationships (i.e.: dependency,
stacking, etc...) between components where layers are associated.
For example, a layer 2 port might have several IPv4 or IPv6
interfaces that utilize it. These would be represented as
associations to and from these components.
TMF-DM-7: Both active and inactive topologies MUST be represented
in the topology database. Inactive topology is not exhaustively
seen in IGP routing protocols. It must be retrieved by querying
inventory in network elements, for example new line cards inserted
in a chassis, new chassis, ports in the down state, etc.
TMF-DM-8: The topology data model MUST be hierarchical and MUST
support summarization of sub-topologies. Topology summarization
and creation of abstract topologies can be provided by the
Topology Manager or the Orchestration Function.
TMF-DM-9: The topology data model MUST be able to describe
abstract topologies. Abstract topologies can contain real and
abstract nodes and real and abstract links. An abstract topology
MAY be used by a provider to describe characteristics of a transit
network (bandwidth, delay, protection, etc.)
Medved, et al. Expires August 21, 2013 [Page 7]
Internet-Draft Topology API Requirements February 2013
TMF-DM-10: The topology data model MUST support dynamic data, such
as link and node utilizations (perhaps as optional attributes).
TMF-DM-11: The topology data model MUST allow a user (operator) to
determine the path between two nodes. The path MAY be traceable
at all network layers that participate in the delivery of packets
between two nodes. For example, for IP traffic exchanged between
2 routers, the user should be able to identify all underlying L2
switches that carry the traffic between the routers.
TMF-DM-12: The topology data model MUST support multiple BGP
Autonomous Systems and multiple IGP areas. Support for multiple
administrative domains is for further study.
TMF-DM-13: The topology data model MUST be human-friendly, i.e.
not SNMP MIBs, but something much more analogous to YANG models.
TMF-DM-14: The data model SHOULD support topology abstraction,
allowing clients that consume topology information in a
constrained manner. For example, a client wishing to view only
interfaces and nodes present in a sub-graph of the Layer 3
topology should be able to specify an interest in this subset of
information rather than having to read out and parse through the
entire set of links and nodes.
3.1.2.1. IP/MPLS Layer Data Model Requirements
The requirements for the IP/MPLS topology data model are as follows:
TMF-DM-IP-1: The data model of the IP/MPLS layer MUST support both
link topology and prefixes.
TMF-DM-IP-2: Link topology may be retrieved from an IGP, BGP-LS
([I-D.ietf-idr-ls-distribution]), or by getting node neighbor
information directly from network elements via a management
protocol such as SNMP, NETCONF or CLI.
TMF-DM.IP-3: Links in the IP/MPLS data model includes, among
others, one or more of the following link attributes:
* Local and Remote anchor node IDs (Router ID, AS#, Area ID, MT
Topology ID)
* Metrics
Medved, et al. Expires August 21, 2013 [Page 8]
Internet-Draft Topology API Requirements February 2013
* Admin Group
* Max link bandwidth
* Unreserved / utilized bandwidth
* Link Protection type
* MPLS Protocol mask
* Link prefix
* Link characteristics (BW, delay, error rate)
* Link description
* Link-specific timers, (Hello & Holddown)
TMF-DM.IP-4: Nodes in the IP/MPLS data model MAY include one or
more of the following node attributes:
* Node Type: simple node / aggregate node
* Intra area router
* Inter area router (ISIS L1L2 or OSPF ABR)
* AS boundary router
* MPLS-VPN Edge router (PE)
* Tunnel head-end/tail-end
* Node ID:: Node ID (Router ID, AS#, Area ID, MT Topology ID)
* Flags: Overload, Attached, External, ABR
* Node capabilities as defined in [RFC5073]
* BGP: aggregate IP prefix + mask (with associated tie-down
route information to inject the aggregate route into BGP)
* BGP policy associated with a given iBGP/eBGP neighbor; policy
matching criteria can be, among others, remote-AS, local-AS,
Local-AS tweaks to manipulate AS_PATH recv'd or transmitted,
timers (Hello, HoldTime), AFI/SAFI, route-map/policy-statements
applied/active (including associated prefix-lists, AS_PATH
regexp filters, etc. and resulting manipulation of BGP path
Medved, et al. Expires August 21, 2013 [Page 9]
Internet-Draft Topology API Requirements February 2013
attributes, e.g.: changing LOCAL_PREF, MED, BGP community,
etc.)
* BGP statistics collection: number of IP paths/prefixes
learned per neighbor
3.1.3. Northbound (Client) API Requirements
The requirements for the Topology Manager's northbound (client)
interface are as follows:
TMF-NB-1: The transport protocol between the Topology Manager and
its clients MUST have efficient encoding so that large topologies
can be transferred with reasonable performance.
TMF-NB-2: The transport protocol MUST support flow-control in case
a client cannot digest updates fast enough from its server.
TMF-NB-3: The transport protocol MUST support push of topology
updates from the Topology Manager to clients.
TMF-NB-4: The protocol MUST implement a mechanism through which a
client can efficiently determine the latest information especially
when it receives multiple copies of the same topology from
multiple Topology Managers. An example is the IGP Sequence Number
that is used on IGP routing updates.
TMF-NB-5: The Northbound API MUST support publishing of events to
a dynamic list of clients/applications. This is helpful for the
Northbound API to signal events as they occur in the network,
e.g.: insertion or removal of linecards, etc.
TMF-NB-6: The Northbound API SHOULD support subscription to events
from a dynamic list of clients/applications. This will allow the
Topology System to react dynamically when, for example, new
requests for services are asked to be created.
TMF-NB-7: The Northbound API SHOULD allow clients to subscribe to
a rich assortment of attributes and/or data models so that they
are automatically notified of changes within the network, (as a
result of a node failure, card insertion, etc.), as well as
changes made by other upper-layer applications to the network,
(for example, addition/subtraction of physical links to the
network during network augmentation or optimization, etc.).
Medved, et al. Expires August 21, 2013 [Page 10]
Internet-Draft Topology API Requirements February 2013
TMF-NB-8: The Northbound API MUST provide a means for non-routers
to communicate with the model. Until now, clients that could
gather network topology and inventory information were generally
limited to those that could speak routing protocols.
3.1.4. Southbound (Network & Device) API Requirements
The requirements for the Topology Manager's southbound (network
element) interface are as follows:
TMF-SB-1: The transport protocol between the Topology Manager and
the topology data sources (Network Elements, etc.) SHOULD have
efficient encoding so that large data models can be transferred
with reasonable performance.
TMF-SB-2: The transport protocol MUST support incremental updates
from a Network Element to the Topology Manager.
TMF-SB-3: The transport protocol MUST support push of topology
updates from a Network Element to the Topology Manager.
4. Network Element Requirements
The requirements for the topology data model are as follows:
NE-1: Each network element SHOULD contain an inventory database,
which SHOULD be a definitive source of information with respect to
the physical HW and logical, locally significant identifiers,
e.g.: VLANs, deployed in the system. The Topology Manager
collects inventory data from network elements and creates an
authoritative view of physical hardware deployed in the network.
NE-2: The inventory DB SHOULD be augmented with the physical
properties associated with the ports/interfaces that are directly
connected to the device, (e.g.: BW, media type, etc.).
NE-3: The inventory DB MAY be augmented through the I2RS framework
pushing information into the network element to, for example,
associate information the installer may have knowledge of, but the
network element may not be able to learn on its own, e.g.: it's
physical location (address), rack/bay information, etc.
NE-4: Relevant network elements should automatically and
dynamically acquire information associated with their immediately
adjacent neighbors using protocols such as LLDP, LMP, etc. A
network element should further augment it's physical port
inventory DB with this information so that the system can report
Medved, et al. Expires August 21, 2013 [Page 11]
Internet-Draft Topology API Requirements February 2013
on whom it's directly connected.
5. Acknowledgements
The authors would like to thank Alia Atlas, Chris Metz, and Dave Ward
for their comments and input.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.amante-irs-topology-use-cases]
Amante, S., Medved, J., and T. Nadeau, "Topology API Use
Cases", draft-amante-irs-topology-use-cases-00 (work in
progress), October 2012.
[I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-01
(work in progress), October 2012.
[RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol
Extensions for Discovery of Traffic Engineering Node
Capabilities", RFC 5073, December 2007.
Medved, et al. Expires August 21, 2013 [Page 12]
Internet-Draft Topology API Requirements February 2013
Authors' Addresses
Jan Medved
Cisco Systems, Inc.
170, West Tasman Drive
San Jose, CA 95134
US
Email: jmedved@cisco.com
Stefano Previdi
Cisco Systems, Inc.
Via Del Serafico, 200
Rome 00142
Italy
Email: sprevidi@cisco.com
Hannes Gredler
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: hannes@juniper.net
Thomas Nadeau
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: tnadeau@juniper.net
Shane Amante
Level 3 Communications, Inc.
1025 Eldorado Blvd
Broomfield, CO 80021
US
Email: shane@level3.net
Medved, et al. Expires August 21, 2013 [Page 13]
