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]