idnits 2.17.1 draft-ward-irs-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 30, 2012) is 4286 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-01 -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Atlas, Ed. 3 Internet-Draft T. Nadeau 4 Intended status: Informational Juniper Networks 5 Expires: January 31, 2013 D. Ward 6 Cisco Systems 7 July 30, 2012 9 Interface to the Routing System Framework 10 draft-ward-irs-framework-00 12 Abstract 14 This document describes a framework for a standard, programmatic 15 interface for full-duplex, streaming state transfer in and out of the 16 Internet's routing system. It lists the information that might be 17 exchanged over the interface, and describes the uses of an interface 18 to the Internet routing system. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 31, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Functional Overview . . . . . . . . . . . . . . . . . . . 3 56 1.2. Example Use-Cases . . . . . . . . . . . . . . . . . . . . 5 57 2. Programmatic Interfaces . . . . . . . . . . . . . . . . . . . 6 58 3. Common Interface Considerations . . . . . . . . . . . . . . . 7 59 3.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.2. Identity, Authorization, Authentication, and Security . . 8 61 3.3. Speed and Frequency of State Installation . . . . . . . . 8 62 3.4. Lifetime of IRS-Installed Routing System State . . . . . . 9 63 3.5. Start-Time of IRS-Installed Routing System State . . . . . 10 64 4. Bidirectional Interfaces to the Routing System . . . . . . . . 10 65 4.1. Static Routing . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1.1. Routing Information Base Interface . . . . . . . . . . 11 67 4.1.2. Label Forwarding Information Base Interface . . . . . 12 68 4.1.3. Multicast Routing Information Base Interface . . . . . 13 69 4.2. Beyond Destination-based Routing . . . . . . . . . . . . . 13 70 4.2.1. Policy-Based Routing Interface . . . . . . . . . . . . 13 71 4.2.2. QoS State . . . . . . . . . . . . . . . . . . . . . . 14 72 4.3. Protocol Interactions . . . . . . . . . . . . . . . . . . 14 73 4.3.1. IGP Interfaces . . . . . . . . . . . . . . . . . . . . 14 74 4.3.2. BGP Interface . . . . . . . . . . . . . . . . . . . . 15 75 4.3.3. PIM and mLDP Interfaces . . . . . . . . . . . . . . . 15 76 4.4. Triggered Sessions and Signaling . . . . . . . . . . . . . 16 77 4.4.1. OAM-related Sessions Interface . . . . . . . . . . . . 16 78 4.4.2. Dynamic Session Creation . . . . . . . . . . . . . . . 16 79 4.4.3. Triggered Signaling . . . . . . . . . . . . . . . . . 16 80 5. Interfaces for Learned Information from the Routing System . . 16 81 5.1. Efforts to Obtain Topological Data . . . . . . . . . . . . 17 82 5.2. Measurements . . . . . . . . . . . . . . . . . . . . . . . 18 83 5.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 6. Manageability Considerations . . . . . . . . . . . . . . . . . 19 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 88 10. Informative References . . . . . . . . . . . . . . . . . . . . 20 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 Routers that form the Internet's routing infrastructure maintain 94 state at various layers of detail and function. For example, each 95 router has a Routing Information Base (RIB), and the routing 96 protocols (OSPF, ISIS, BGP, etc.) each maintain protocol state and 97 information about the state of the network. 99 A router also has information that may be required for applications 100 to understand the network, verify that programmed state is installed 101 in the forwarding plane, measure the behavior of various flows, and 102 understand the existing configuration and state of the router. 103 Furthermore, routers are configured or implemented with procedural or 104 policy-based instructions for how to convert all of this information 105 into the forwarding operations that are installed in the forwarding 106 plane, and this is also state information that describes the 107 behaviour of the router. 109 This document sets out a framework for a common, standard interface 110 to allow access to all of this information. This Interface to the 111 Routing System (IRS) would facilitate control and diagnosis of the 112 routing infrastructure, as well as enabling sophisticated 113 applications to be built on top of today's routed networks. The IRS 114 is a programmatic, streaming interface for transferring state into 115 and out of the Internet's routing system, and recognizes that the 116 routing system and a router's OS provide useful mechanisms that 117 applications could harness to accomplish application-level goals. 119 Fundamental to the IRS is a clear data model that defines the 120 semantics of the information that can be written and read. The IRS 121 provides a framework for registering for and requesting the 122 appropriate information for each particular application. The IRS 123 provides a way for applications to customize network behaviour while 124 leveraging the existing routing system. 126 The IRS, and therefore this document, is specifically focused on an 127 interface for routing and forwarding data. 129 1.1. Functional Overview 131 There are three key aspects to the IRS. First, the interface is a 132 programmatic streaming interface meaning that it is asynchronous and 133 offers fast, interactive access.Second, the IRS gives access to 134 information and state that is not usually configurable or modeled in 135 existing implementations or configuration protocols. Third, the IRS 136 gives applications the ability to learn additional, structured, 137 filterable information and events from the router. 139 IRS is described as a streaming programmatic interface; the key 140 properties that are intended are: 142 Multiple Simultaneous Asynchronous Operations: A single application 143 should be able to send multiple operations to IRS without needing 144 to wait for each to complete before sending the next. 146 Configuration Not Re-Processed: When an IRS operation is processed, 147 it does not require that any of the configuration be processed. 148 I.e. the desired behavior with regard to static configuration is 149 the same as learning a new BGP route - completely orthogonal. 151 Duplex: Communications can be established by either the router or 152 the application. Similarly, events, acknowledgements, failures, 153 operations, etc. can be sent at any time by both the router and 154 the application. This is not a pure pull-model where only the 155 application queries to pull responses. 157 High-Throughput: At a minimum, the IRS should be able to handle 158 hundreds of operations per second. 160 Responsive: It should be possible to complete simple operations 161 within a sub-second time-scale. 163 Multi-Channel: It should be possible for information to be 164 communicated via the interface from different components in the 165 router without requiring going through a single channel. For 166 example, for scaling, some exported data or events may be better 167 sent directly from the forwarding plane, while other interactions 168 may come from the control-plane. Thus a single TCP session per 169 application would not be a good match. 171 Such an interface facilitates the specification of non-permanent 172 state into the routing system as well as the extraction of that 173 information and additional dynamic information from the routing 174 system. A non-routing protocol or application could inject state 175 into a networking node's OS via the state-insertion aspects of the 176 interface, that could then be distributed in a routing or signaling 177 protocol. 179 Where existing mechanisms can provide part of the desired 180 functionality, the coverage and gaps are briefly discussed in this 181 document. 183 The existing mechanisms, such as SNMP and NetConf, that allow state 184 to be written and read do not meet all of the above key properties 185 needed for IRS. The overhead of infrastructure is also quite high 186 and many MIBs do not, in definition or practice, allow writing of 187 state. There is also very limited capability to add new application- 188 specific state to be distributed via the routing system. Conversely, 189 NetConf is challenging for reading state from a router. 191 ForCES is another method for writing state into a router, but its 192 focus is on the forwarding plane. By focusing on the forwarding 193 plane, it requires that the forwarding plane be modeled and 194 programmable and ignores the existence and intelligence of the router 195 OS and routing system. ForCES provides a lower-level interface than 196 IRS is intended to address. 198 1.2. Example Use-Cases 200 A few brief examples of ways an application could use the IRS are 201 presented here. These are intended to give a sense of what could be 202 done rather than to be primary and detailed motivational use-cases. 204 Route Control via Indirection: By enabling an application to 205 install routes in the RIB, it is possible that when, for example, 206 BGP resolves its IGP next-hop via the RIB, that could be to an 207 application-installed route. In general, when a route is 208 redistributed from one protocol to another, this is done via the 209 RIB and such a route could have been installed via the IRS 210 interface. 212 Policy-Based Routing of Unknown Traffic: A static route, installed 213 into the RIB, could direct otherwise unrecognized traffic towards 214 an application, through whatever appropriate tunnel was required, 215 for further handling. Such a static route could be programmed 216 with indirection, so that its outgoing path is whatever is used by 217 another particular route (e.g. to a particular server). 219 Services with Fixed Hours: If an application were to provide 220 services only during fixed time-periods, the application could 221 install both a specific route on the local router in the RIB and 222 advertise the associated prefix as being attached to the local 223 router via the IGP. If the application knew the fixed hours, the 224 state so installed could be time-based and automatically removed 225 at approximately the correct time. 227 Traffic Mirroring: The interface to the multicast RIB could be used 228 to mirror a particular traffic flow to both its original 229 destination and a data collector. 231 Static Multicast Trees: An application could set up static (or 232 partially static) multicast flows via entries in the multicast RIB 233 without requiring an associated multicast protocol. This could be 234 useful in networks with a fixed topology and well-planned 235 distribution tree that provides redundancy. 237 2. Programmatic Interfaces 239 A number of management interfaces exist today that allow for the 240 indirect programming of the routing system. These include 241 proprietary CLI, Netconf, and SNMP. However, none of these 242 mechanisms allows for the direct programming of the routing system. 243 Such streaming interfaces are needed to support dynamic time-based 244 applications. 246 These interfaces should cater to how applications typically interact 247 with other applications and network services rather than forcing them 248 to use older mechanisms that are more complex to understand and 249 implement, as well as operate. 251 The most critical component of the IRS is developing standard data 252 models with their associated semantics. While many routing protocols 253 are standardized, associated data models for IRS are not yet 254 available. Instead, each router uses different information, 255 mechanisms, and CLI which makes a standard interface for use by 256 applications extremely cumbersome to develop and maintain. Well- 257 known data modeling languages, such as YANG [RFC6020], exist and 258 might be used for defining the necessary data models; more 259 investigation into alternatives is required. It is understood that 260 some portion (hopefully a small subset) will remain as proprietary 261 extensions; the data models must support future extensions and 262 proprietary extensions. 264 Since the IRS will need to support remote access between applications 265 running on a host or server and routers in the network, at least one 266 standard mechanism must be identified and defined to provide the 267 transfer syntax, as defined by a protocol, used to communicate 268 between the application and the routing system. Common functionality 269 that IRS needs to support includes acknowledgements, dependencies, 270 request-reserve-commit. 272 Appropriate candidate protocols must be identified that reduce the 273 effort required by applications and, preferably, are familiar to 274 application developers. Ideally, this should not require that 275 applications understand and implement existing routing protocols to 276 interact with IRS. These interfaces should instead be based on 277 light-weight, rapidly deployable approaches; technology approaches 278 must be evaluated but examples could include ReSTful web services, 279 JSON, XMPP, and XML. These interfaces should possess self-describing 280 attributes (e.g. a web services interface) so that applications can 281 quickly query and learn about the active capabilities of a device. 283 It may be desirable to also define the local syntax (e.g. programming 284 language APIs) that applications running local to a router can use. 286 Since evolution is anticipated in IRS over time, it is important that 287 versioning and backwards compatibility are basic supported 288 functionality. Similarly, common consistent error-handling and 289 acknowledgement mechanisms are required that do not severely limit 290 the scalability and responsiveness of these interfaces. 292 3. Common Interface Considerations 294 3.1. Capabilities 296 Capability negotiation is a critical requirement because different 297 implementations and software versions will have different abilities. 298 Similarly, applications may have different capabilities for receiving 299 exported information. 301 The IRS will have multiple interfaces, each with their own set of 302 capabilities. Such capabilities may include the particular data 303 model and what operations can be performed at what scale. 305 The capabilities negotiated may be filtered based upon different 306 information, such as the application's authorization, application's 307 capabilities, and the desired granularity for abstraction which the 308 application understands. Different types of authorization may 309 require the router to advertise different capabilities and 310 restrictions. 312 The capability negotiation may take place at different levels of 313 detail based upon the application and the specific functions in the 314 IRS that the application is negotiating. The router and application 315 must use the IRS to agree upon the proper level of abstraction for 316 the interaction. For example, when an application describes a route 317 between two topological items, these items may vary in detail from a 318 network domain's name at a high level, or down to the port forwarding 319 specifics of a particular device. 321 The data-model and capabilities available for an element may depend 322 upon whether the element is physical or virtual; the virtual/physical 323 distinction does not matter to IRS. Similarly, the location of the 324 element may influence how an application converses with the 325 associated router. 327 3.2. Identity, Authorization, Authentication, and Security 329 Applications that wish to manipulate or interrogate the state of the 330 routing system must be appropriately authorized. This means that at 331 least one means of determining the unique identity of an application 332 and its associated access privileges must be available; this implies 333 that the identity and associated access privileges must be verifiable 334 from the router being programmed. 336 Furthermore, being able to associate a state and the modifications to 337 a state with a specific application would aid in troubleshooting and 338 auditing of the routing system. By associating identity and 339 authorization with installed state, other applications with 340 appropriate authority can clean up state abandoned by failed 341 applications, if necessary. 343 Security of communication between the application and the router is 344 also critical and must be considered in the design of the mechanisms 345 to support these programmatic interfaces. 347 3.3. Speed and Frequency of State Installation 349 A programmatic interface does not by itself imply the frequency of 350 state updates nor the speed at which the state installation is 351 required. These are critical aspects of an interface and govern what 352 an application can use the interface for. The difference between 353 sub-second responsiveness to millions of updates and a day delay per 354 update is, obviously, drastic. The key attributes of the 355 programmatic interface are described in Section 1 and include that 356 the interface must be asynchronous. 358 For each interface in IRS, it will be necessary to specify expected 359 scaling, responsiveness, and performance so that applications can 360 understand the uses to which the IRS can be used. 362 IRS must support asynchronous streaming real-time interactions 363 between the applications and router. IRS must assume that there are 364 many unrelated applications that may be simultaneously using IRS. 365 This implies that applications must be able to subscribe to change 366 events that notify them about changes done to state by other 367 applications or configuration. 369 Furthermore, IRS should construct interfaces that cater to different 370 scaling and frequency of update parameters. For example, slow, but 371 detailed queries of the system, or fast yet higher level (less 372 detailed) queries or modifications. 374 3.4. Lifetime of IRS-Installed Routing System State 376 In routers today, the lifetime of different routing state depends 377 upon how that state was learned and committed. If the state is 378 configuration state, then it is ephemeral when just in the running 379 configuration or persistent when written to the startup 380 configuration. If the state is learned via a routing protocol or 381 SNMP, it is ephemeral, lasting only until the router reboots or the 382 state is withdrawn. 384 Unlike previous injection mechanisms that implied the state lifetime, 385 IRS requires that multiple models be supported for the lifetime of 386 state it installs. This is because the lifetime or persistence of 387 state of the routing system can vary based on the application that 388 programmed it, policies or security authorization of the application. 390 There are four basic models to be supported. 392 Ephemeral: State installed by the application remains on the router 393 in its active memory until such time as it is either removed by a 394 routing or signaling protocol, removed by a configuration 395 initiated by an application, or the router reboots. In the case 396 of the latter, past state is forgotten when the router reboots. 398 Persistent: State installed by the application remains on the 399 router across reboots or restarts of the system. It can be 400 dynamically removed or manipulated by an application, by 401 configuration, or by the routing system itself. This state does 402 not appear in the router's configuration; it is processed after 403 all the configuration upon a reboot. 405 Time-Based: When state is installed by the application, it has an 406 expiration time specified. When that time has passed, the state 407 is removed from the router. It can also be dynamically removed or 408 manipulated by an application, by configuration or the routing 409 system itself. State that hasn't expired will remain on a router 410 through reboots. 412 Time-Based Ephemeral: When state is installed by the application, 413 it has an expiration time specified. When that time has passed, 414 the state is removed from the router. It can also be dynamically 415 removed or manipulated by an application, by configuration, by the 416 routing system itself, or by the router rebooting. Past state is 417 forgotten after the router reboots. 419 3.5. Start-Time of IRS-Installed Routing System State 421 To provide flexibility, pre-programming, and handle dependencies, it 422 is necessary to have multiple models of when a operation is to be 423 handled. There are the following basic models to be supported. 425 Immediate: When the operation is received, it should be acted upon 426 as quickly as reasonable (e.g. queued with other outstanding 427 requests if necessary). 429 Time-Based: An application may provide an operation that is to be 430 initiated at a particular time. When the specified time is 431 reached, the operation should be acted upon as quickly as 432 reasonable. Implementations may, of course, strive to improve the 433 time-accuracy at which the operation is initiated. 435 Triggered: The operation should be initiated when the specified 436 triggering event has happened. A triggering event could be the 437 successful or failed completion of another operation. A 438 triggering event could be a system event, such as an interface up 439 or down, or another event such as a particular route changing its 440 next-hops. 442 Because it is possible to request operations in models other than 443 "Immediate" and some of the start-times will be at an unknown future 444 point (e.g. "Triggered"), it is not feasible to guarantee that the 445 resources required by an operation will always be available without 446 reserving them from the time the operation is received. While that 447 type of resource reservation should be possible, applications must 448 also be able to handle an operation failing or being preempted due to 449 resources or due to a higher priority or better authorized 450 application taking ownership of the associated state or resource. 452 4. Bidirectional Interfaces to the Routing System 454 IRS is a bidirectional programmatic interface that allows both 455 routing and non-routing applications to install, remove, read, and 456 otherwise manipulate the state of the routing system. 458 Just as the Internet routing system is not a single protocol or 459 implementation layer, neither does it make sense for the IRS to be at 460 a single layer or reside within a single protocol. For each protocol 461 or layer, there are different data models, abstractions and interface 462 syntaxes and semantics required. Howeve,r with this in mind, it is 463 ideal that a minimal set of mechanism(s) to define, transfer and 464 manipulate this state will be specified with as few optional 465 characteristics as possible. This will foster better 466 interoperability between different vendor implementations. 468 Since IRS is focused on the routing system, the layers of interest 469 start with the RIB and continue up through the IGPs, BGP, RSVP-TE, 470 LDP, etc. The intent is neither to provide interfaces to the 471 forwarding plane nor to provide interfaces to application layers. 473 It is critical that these interfaces provide the ability to learn 474 state, filtered by request, as well as install state. IRS assumes 475 that there will be multiple applications using IRS and therefore the 476 ability to read state is necessary to fully know the router's state. 477 In general, if an interface allows the setting of state, the ability 478 to read and modify that state is also necessary. 480 4.1. Static Routing 482 The ability to specify static routes exists via CLI and MIBs but 483 these mechanisms do not provide a streaming programmatic interface. 484 IRS solves this problem by proposing interfaces to the RIB, LFIB, and 485 Multicast RIBs. 487 By installing static routes into the RIB layer, IRS is able to 488 utilize the existing router OS and its mechanisms for distributing 489 the selected routes into the FIB and LIB. This avoids the need to 490 model or standardize the forwarding plane. 492 4.1.1. Routing Information Base Interface 494 The RIB is populated with routes and next-hops as supplied by 495 configuration, management, or routing protocols. A route has a 496 preference based upon the specific source from which the route was 497 derived. Static routes, specified via CLI, can be installed with an 498 appropriate preference. The FIB is populated by selecting from the 499 RIB based on policy and tie-breaking criteria. 501 The IRS interface should allow dynamic reading and writing of routes 502 into the RIB. There are several important attributes associated with 503 doing so, as follows: 505 Preference Value: This allows decisions between conflicting routes, 506 whether IRS-installed or otherwise. IRS-installed routes can each 507 be installed with a different preference value. 509 Route Table Context: There can be different route table contexts in 510 the RIB. Examples include multiple protocols (e.g. IPv4, IPv6), 511 multiple topologies, different uses, and multiple networks (e.g. 512 VRF tables for VPNs). Appropriate application-level abstractions 513 are required to describe the desired route table context. 515 Route or Traffic Identification The specific IP prefix or even 516 interface must be specified. 518 Outgoing Path and Encapsulation: It is necessary to specify the 519 outgoing path and associated encapsulation. This may be done 520 directly or indirectly. This is one of the more complex aspects 521 with the following considerations. 523 Primary Next-Hops: To support multi-path forwarding, multiple 524 primary next-hops can be specified and the traffic flows split 525 among them. 527 Indirection: Instead of specifying particular primary next-hops, 528 it is critical to be able to provide the ability for 529 indirection, such as is used between BGP routes and IGP routes. 530 Thus, the outgoing path might be specified via indirection to 531 be the same as another route's. 533 Encapsulation: Associated with each primary next-hop can be 534 details on the type of encapsulation for the packet. Such 535 encapsulation could be MPLS, GRE, etc. as supported by the 536 router. 538 Protection: For fast-reroute protection, each primary next-hop 539 may have one or more alternate next-hops specified. Those are 540 to be used when the primary next-hop fails. 542 DSCP: For QoS, the desired DSCP to be used for the outgoing 543 traffic can be specified. 545 It is useful for an application to be able to read out the RIB state 546 associated with particular traffic and be able to learn both the 547 preferred route and its source as well as other candidates with lower 548 preference. 550 Although there is no standardized model or specification of a RIB, it 551 may be possible to build an interoperable bi-directional interface 552 without one. 554 4.1.2. Label Forwarding Information Base Interface 556 The LFIB has a similar role to the RIB for MPLS labeled packets. 557 Each entry has slightly different information to accommodate MPLS 558 forwarding and semantics. Although static MPLS can be used to 559 configure specific state into the LFIB, there is no bidirectional 560 programmatic interface to program, modify, or read the associated 561 state. 563 Each entry in the LFIB requires a MPLS label context (e.g. platform, 564 per-interface, or other context), incoming label, label operation, 565 and next-hops with associated encapsulation, label operation, and so 566 on. Via the IRS LFIB interface, an application could supply the 567 information for an entry using either a pre-allocated MPLS label or a 568 newly allocated MPLS label that is returned to the application. 570 4.1.3. Multicast Routing Information Base Interface 572 There is no bidirectional programmatic interface to add, modify, 573 remove or read state from the multicast RIB. This IRS interface 574 would add those capabilities. 576 Multicast forwarding state can be set up by a variety of protocols. 577 As with the unicast RIB, an application may wish to install a new 578 route for multicast. The state to add might be the full multicast 579 route information - including the incoming interface, the particular 580 multicast traffic (e.g. (source, group) or MPLS label), and the 581 outgoing interfaces and associated encapsulations to replicate the 582 traffic too. 584 The multicast state added need not match to well-known protocol 585 installed state. For instance, traffic received on an specified set, 586 or all, interfaces that is destined to a particular prefix from all 587 sources or a particular prefix could be subject to the specified 588 replication. 590 4.2. Beyond Destination-based Routing 592 Routing decisions and traffic treatment is not merely expressable via 593 destination-based routing or even (S, G) routing, such as in 594 multicast. Capturing these aspects into appropriate interfaces for 595 the IRS provides the ability for applications to control them as 596 well. 598 4.2.1. Policy-Based Routing Interface 600 A common feature of routers is the ability to specify policy-based 601 routing (PBR) rules for accepting, dropping, or differently 602 forwarding particular traffic. This is a very useful functionality 603 for an application to be able to rapidly add and remove state into. 604 Such state would indicate the particular traffic to be affected and 605 its subsequent behavior (e.g. drop, accept, forward on specified 606 outgoing path and encapsulation, QoS, DSCP marking, policing, etc.). 607 Such state is made more complex by the potential importance of 608 ordering among the PBR rules. 610 While PBR rules can be specified via CLI, this mechanism is not a 611 streaming programmatic interface nor is there generally the ability 612 to specify particular time-based lifetimes for each rule. 614 4.2.2. QoS State 616 While per-hop behaviors are defined as well as standard DSCP 617 meanings, the details of QoS configuration are not standardized and 618 can be highly variable depending upon platform. It is NOT a goal of 619 this work to standardize QoS configurations. Instead, a data object 620 model can define push/pull configurations. More investigation is 621 needed to better describe the details. 623 4.3. Protocol Interactions 625 Providing IRS interfaces to the various routing protocols allows 626 applications to specify policy, local topology changes, and 627 availability to influence the routing protocols in a way that the 628 detailed addition or modification of routes in the RIB does not. 630 The decision to distribute the routing state via a routing or 631 signaling protocol depends upon the protocol-layer at which this 632 state is injected into the routing system. It may also depend upon 633 which routing domain or domains this information is injected as well. 635 In addition it is necessary to have the ability to pull state 636 regarding various protocols from the router, a mechanism to register 637 for asynchronous events, and the means to obtain those asynchronous 638 events. An example of such state might be peer up/down. 640 4.3.1. IGP Interfaces 642 The lack of a streaming programmatic interface to the IGPs limits the 643 ability of applications to influence and modify the desired behavior 644 of the IGP. 646 An application may need to indicate that a router is overloaded (via 647 ISIS or the method described in [RFC3137]) because that router does 648 not yet have sufficient state synchronized or installed into it. 649 When critical state is provided not merely by routers but also from 650 applications via the IRS, a synchronization mechanism can be needed. 652 The ability for an application to modify the local topology can be 653 part of this interface. One possibility is to allow modification of 654 local interface metrics to generally influence selected routes. A 655 more extensive interface might include the ability to create a OSPF 656 or ISIS adjacency across a specified interface (virtual or real) with 657 the appropriate associated encapsulation. 659 The ability to attach a prefix to the local router would provide a 660 straightforward method for an application to program a single router 661 and have the proper routes computed and installed by all other 662 routers in the relevant domains. Additional aspects to the prefix 663 attachment, such as the metric with which to attach the prefix and 664 fast-reroute characteristics, would be part of the interface. 666 Beyond such pure routing information, the need for an application to 667 be able to install state to be flooded via an IGP has already been 668 recognized. [I-D.ietf-isis-genapp] specifies a mechanism for 669 flooding generalized application information via ISIS, but does not 670 describe how an application can generate or consume this information. 671 Similarly, [RFC5250] specifies Opaque LSAs for OSPF to provide for 672 application-specific information to be flooded. An IRS interface and 673 associated data object model would provide such a mechanism. 675 Additional investigation will identify other state that applications 676 may wish to install. 678 From the IGP, applications via IRS can extract significant 679 topological information about the routers, links, and associated 680 attributes. 682 4.3.2. BGP Interface 684 BGP carries significant policy and per-application specific 685 information as well as internet routes. A significant interface into 686 BGP is expected, with different data object models for different 687 applications. For example, the IRS interface to BGP could provide 688 the ability to specify the policy on which paths BGP chooses to 689 advertise. Additionally, the ability to specify information with an 690 application-specified AFI/SAFI could provide substantial flexibility 691 and control. 693 An existing example of application information carried in BGP is BGP 694 Flowspec [RFC5575] which can be used to provide traffic filtering and 695 aid in handling denial-of-service attacks. 697 The ability to extract information from BGP is also quite critical. 698 A useful example of this is the information available from BGP via 699 [I-D.gredler-idr-ls-distribution], which allows link-state topology 700 information to be carried in BGP. 702 4.3.3. PIM and mLDP Interfaces 704 For PIM and mLDP, there are at least two types of state that an 705 application might wish to install. First, an application might add 706 an interface to join a particular multicast group. Second, an 707 application might provide an upstream route for traffic to be 708 received from - rather than having PIM or mLDP need to consult the 709 unicast RIB. 711 Additional investigation will identify other state that applications 712 may wish to install. 714 4.4. Triggered Sessions and Signaling 716 4.4.1. OAM-related Sessions Interface 718 An application may need to trigger new OAM sessions (e.g. BFD, VCCP, 719 etc.) using an appropriate template. For example, there may be 720 applications that need to create a new tunnel, verify its 721 functionality via new triggered OAM sessions, and then bring it into 722 service if that OAM indicates successful functionality. More 723 investigation is needed to better describe the details. 725 4.4.2. Dynamic Session Creation 727 An application may wish to trigger a peering relationship for a 728 protocol. For instance, a targeted LDP session may be required to 729 exchange state installed locally with a remote router. More 730 investigation is needed to better describe the different cases and 731 details. 733 4.4.3. Triggered Signaling 735 To easily create dynamic state throughout the network, an application 736 may need to trigger signaling via protocols such as RSVP-TE. An 737 example of such an application can be a Stateful Path Computation 738 Element (PCE)[I-D.ietf-pce-stateful-pce], which has control of 739 various LSPs that need to be signaled. 741 More investigation is needed to better describe the different cases 742 and details. 744 5. Interfaces for Learned Information from the Routing System 746 Just as applications need to inject state into the routing system to 747 meet various application-specific and policy-based requirements, it 748 is critical that applications be able to also extract necessary state 749 from the routing system. 751 A part of each of these interfaces is the ability to specify the 752 generation of the desired information (e.g., collecting specific per- 753 flow measurements) and the ability to specify appropriate filters to 754 indicate the specifics and abstraction level of the information to be 755 provided 757 The types of information to extract can be generally grouped into the 758 following different categories. 760 Topological: The need to understand the network topology, at a 761 suitable abstraction layer, is critical to applications. 762 Connectivity is not sufficient - the associated costs, bandwidths, 763 latencies, etc. are all important aspects of the network topology 764 that strongly influence the decision-making and behavior of 765 applications. 767 Measurements: Applications require measurements of traffic and 768 network behavior in order to have a more meaningful feedback 769 control loop. Such information may be per-interface, per-flow, 770 per-firewall rule, per-queue, etc. 772 Events: There are a variety of asynchronous events that an 773 application may require or use as triggering conditions for 774 starting other operations. An obvious example is interface state 775 events. 777 Configuration: For some aspects, it may be necessary for 778 applications to be able to learn about the routing configuration 779 on a box. This is partially available via various MIBs and 780 NetConf. What additional information needs to be exported and the 781 appropriate mechanisms needs further examination. 783 The need to extract information from the network is not new; there is 784 on-going work in the IETF in this area. This framework describes 785 those efforts in the context of the above categories and starts the 786 discussion of the aspects still required. 788 5.1. Efforts to Obtain Topological Data 790 Topological data can be defined and presented at different layers 791 (e.g. Layer-2, Layer-3) and with different characteristics exposed 792 or hidden (e.g. physical or virtual, SRLGs, bandwidth, latency, 793 etc.). It can also have different states, such as configured but 794 unavailable, configurable, active, broken, administratively disabled, 795 etc. 797 To solve the problem of only being able to obtain topological data 798 via listening to the IGP in each area, BGP-LS 799 [I-D.gredler-idr-ls-distribution] defines extensions to BGP so that 800 link-state topology information can be carried in BGP and a single 801 BGP listener in the AS can therefore learn and distribute the entire 802 AS's current link-state topology. BGP-LS solves the problem of 803 distributing topological information throughout the network. While 804 IRS may expand the information to be distributed, IRS addresses the 805 API aspect of BGP-LS and not the network-wide distribution. 807 At another level, ALTO [RFC5693] provides topological information at 808 a higher abstraction layer, which can be based upon network policy, 809 and with application-relevant services located in it. The mechanism 810 for ALTO obtaining the topology can vary and policy can apply to what 811 is provided or abstracted. 813 Neither of these fully meet the need to obtain detailed, layered 814 topological state that provides more information than the current 815 functional status. While there are currently no sufficiently 816 complete standards, the need for such functionality can be deduced by 817 the number of proprietary systems that have been developed to obtain 818 and manage topology; even Element Management Systems start with the 819 need for learning and manipulating the topology. Similarly, 820 orchestration layers for applications start with the need to manage 821 topology and the associated database. 823 Detailed topology includes aspects such as physical nodes, physical 824 links, virtual links, port to interface mapping, etc. The details 825 should include the operational and administrative state as well as 826 relevant parameters ranging from link bandwidth to SRLG membership. 827 Layering is critical to provide the topology at the level of 828 abstraction where it can be easily used by the application. 830 A key aspect of this interface is the ability to easily rate-limit, 831 filter and specify the desired information to be extracted. This 832 will help in allowing the interface to scale when queries are done. 834 5.2. Measurements 836 IPFIX [RFC5470] provides a way to measure and export per-traffic flow 837 statistics. Applications that need to collect information about 838 particular flows thus have a clear need to be able to install state 839 to configure IPFIX to measure and export the relevant flows to the 840 appropriate collectors. 842 5.3. Events 844 A programmatic interface for application to subscribe to asynchronous 845 events is necessary. In addition to the interface state events 846 already mentioned, an application may wish to subscribe to certain 847 OAM-triggered events that aren't otherwise exported. 849 A RIB-based event could be reporting when the next-hops associated 850 with a route have changed. Other events could be used to verify that 851 forwarding state has been programmed. For example, an application 852 could request an event whenever a particular route in the RIB has its 853 forwarding plane installation completed. 855 When an application registers for events, the application may request 856 to get only the first such event, all such events, or all events 857 until a certain time. 859 The full set of such events, that are not specifically related to 860 other interfaces, needs to be investigated and defined. 862 6. Manageability Considerations 864 Manageability plays a key aspect in IRS. Some initial examples 865 include: 867 Data Authorization Levels: The data-models used for IRS need the 868 ability to indicate the required authorization level for 869 installing or reading a particular subset of data. This allows 870 control of what interactions each application can have. 872 Identity Authorization Levels: Associated with an application's 873 identity should be an identity authorization level that is in a 874 heirarchy so that higher authorized applications can manage and 875 remove the state and resources used by other applications. The 876 top of such a heirarchy would be the router configuration itself. 878 Resource Limitations: Using IRS, applications can consume 879 resources, whether those be operations in a time-frame, entries in 880 the RIB, stored operations to be triggered, etc. The ability to 881 set resource limits based upon authorization is critical. 883 Configuration Interactions: The interaction of state installed via 884 the IRS and via a router's configuration needs to be clearly 885 defined. 887 7. IANA Considerations 889 This document includes no request to IANA. 891 8. Security Considerations 893 This framework describes interfaces that clearly require serious 894 consideration of security. The ability to identify, authenticate and 895 authorize applications that wish to install state is necessary and 896 briefly described in Section 3.2. Security of communications from 897 the applications is also required. 899 More specifics on the security requirements requires further 900 investigation. 902 9. Acknowledgements 904 The authors would like to thank Ken Gray, Adrian Farrel, Bruno 905 Rijsman, Rex Fernando, Jan Medved, John Scudder, and Hannes Gredler 906 for their suggestions and review. 908 10. Informative References 910 [I-D.gredler-idr-ls-distribution] 911 Gredler, H., Medved, J., Previdi, S., and A. Farrel, 912 "North-Bound Distribution of Link-State and TE Information 913 using BGP", draft-gredler-idr-ls-distribution-02 (work in 914 progress), July 2012. 916 [I-D.ietf-isis-genapp] 917 Ginsberg, L., Previdi, S., and M. Shand, "Advertising 918 Generic Information in IS-IS", draft-ietf-isis-genapp-04 919 (work in progress), November 2010. 921 [I-D.ietf-pce-stateful-pce] 922 Crabbe, E., Medved, J., Varga, R., and I. Minei, "PCEP 923 Extensions for Stateful PCE", 924 draft-ietf-pce-stateful-pce-01 (work in progress), 925 July 2012. 927 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 928 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 929 June 2001. 931 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 932 OSPF Opaque LSA Option", RFC 5250, July 2008. 934 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 935 "Architecture for IP Flow Information Export", RFC 5470, 936 March 2009. 938 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 939 and D. McPherson, "Dissemination of Flow Specification 940 Rules", RFC 5575, August 2009. 942 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 943 Optimization (ALTO) Problem Statement", RFC 5693, 944 October 2009. 946 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 947 Network Configuration Protocol (NETCONF)", RFC 6020, 948 October 2010. 950 Authors' Addresses 952 Alia Atlas (editor) 953 Juniper Networks 954 10 Technology Park Drive 955 Westford, MA 01886 956 USA 958 Email: akatlas@juniper.net 960 Thomas Nadeau 961 Juniper Networks 962 1194 N. Mathilda Ave. 963 Sunnyvale, CA 94089 964 USA 966 Email: tnadeau@juniper.net 968 Dave Ward 969 Cisco Systems 970 Tasman Drive 971 San Jose, CA 95134 972 USA 974 Email: wardd@cisco.com