Network Working Group Dimitri Papadimitriou Internet Draft Martin Vigoureux Intended status: Informational Alcatel-Lucent Wouter Tavernier Expires: April 14, 2013 Didier Colle UGent October 15 2012 IRS Architectural Framework draft-dimitri-irs-arch-frame-00.txt Abstract This document details the possible architectural and design choices in order to determine i) the spatial location of the so-called "IRS interface" and the functional entities it directly and/or indirectly involves, ii) the number of levels of redirection between routing modules and application (and associated identifier space), and iii) the various constraints that can be anticipated when dealing with the coupling of functional planes including the prevention of oscillations between two or more routing system states, coupling effects (leading to amplification chains) and, concurrency (leading to antagonistic action-reaction). Disclaimer: this document doesn't intend to promote any specific architecture; its purpose is to understand (some of) the architectural challenges when designing interaction between routing system and applicative levels/systems. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt D.Papadimitriou Expires Apr.14, 2013 [Page 1] Internet-Draft IRS Architectural Framework Oct.15 2012 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 14 2013. Copyright Notice Copyright (c) 2012 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 Conventions used in this document...............................4 2. Terminology, Notation and Acronyms...........................5 2.1. Terminology and Notation................................5 2.2. Acronyms................................................6 3. Use Cases....................................................7 4. Architectures................................................9 4.1. Dual architectures......................................9 4.1.1. Boundary on external interface.....................9 4.1.2. Boundary on internal interface....................13 4.2. Star architecture......................................15 4.2.1. Co-located Dispatch Function......................15 4.2.2. Non Co-located Dispatch Function..................16 4.3. Meshed architecture....................................18 5. Comparative Analysis........................................19 6. Security Considerations.....................................19 7. IANA Considerations.........................................19 8. Conclusions.................................................19 9. References..................................................20 9.1. Normative References...................................20 9.2. Informative References.................................20 10. Acknowledgments............................................20 D.Papadimitriou Expires Apr.14, 2013 [Page 2] Internet-Draft IRS Architectural Framework Oct.15 2012 1. Introduction Nowadays, applicative layers don't only rely on the shared infrastructure for information communication purposes but also for information storage (e.g., content delivery/caching, large date sets) and processing (e.g., grid computing, virtual machines). The expansion of the functional role of the shared infrastructure has in turn induced the rise of intermediate systems/application level hubs under the control / supervision of providers (usually ranging from application providers to mediators). With the current Internet model where the routing system is a closed system, applications have to run their own measurement end-to-end to determine forwarding path characteristics through traffic monitoring but also have no means by which some network path can be enforced (by network path we refer here to the path as computed on-line by routing algorithms or those made available by off-line means). The best example is the triangular inequality violation where the shortest path between two end points (shortcut) may not be the best bandwidth x delay path between these two points. Indeed, as there is no deployed mean (e.g., source routing) by which applicative layers can tell the network which path IP datagrams shall follow, measurements don't allow any subsequent decision tuning on which network path to follow to reach a given destination. The alternative is to drive the routing table entries by applicative-triggers exchanged by means of an API (referred to as IRS since one end of this interface terminates in the "routing system") assuming applications share with the routing system a common understanding of distance and resource usage metrics. In other terms, compared to the decoupling between traffic engineering decisions concerning network path and applicative layers needs, such model would allow cooperation in the routing decision process. In this context, the actual objectives of the present document are the following: i) Enumerate possible architectural and design choices to determine the spatial location of the so-called "IRS interface" and the functional entities it directly and/or indirectly involves. In turn, this enables determining internal vs. external interfaces (those that MAY be standardized and those that MUST be standardized, and those that require specific architectural focus when dealing with security aspects). ii) Determine the number of levels of redirection between routing modules and application (and the associated identifier space). D.Papadimitriou Expires Apr.14, 2013 [Page 3] Internet-Draft IRS Architectural Framework Oct.15 2012 iii) Identify pro's and con's of possible architectures depending on use cases (bottom-up) that in general will combine one or more of these elements: distance/path, topology ((abstract) nodes, (abstract) links), location/mobility (end-point, data, etc.); note that the inclusion of traffic properties leads de facto to the introduction of monitoring points. iv) Anticipate the constraints (from base distributed control and decision theory) when dealing with the coupling of functional planes and some architectural invariants identified (top-down). These includes the prevention of i) oscillations between two or more routing system states, ii) coupling effects (leading to amplification chains) and, iii) concurrency (leading to antagonistic action- reaction). v) Even if the initial architectural scope would be limited to single autonomous system as starting point, propose a generic enough description to enable inter-domain use cases in the future. It is anticipated that the time dimension will limit applicability of such information exchange to the control part of the routing system (i.e. not the forwarding component). Indeed, the closer to the forwarding component the smaller the time scale to ensure proper functionality. The full Shortest Path Tree (SPT) computation takes of the order of 10microsec per IGP destination prefix, optimizations can be obtained using incremental Shortest Path First (iSPF) algorithms. Updating the central node Routing Table (RT) ranges in the same order of magnitude per destination prefix. The consecutive time the routing engine CPU is spending to update the RT entries or their distribution to the Forwarding Table (FT) is determined by the quantum of the swapping process. The quantum time can typically be configured between an order of 10 to 100ms. If we would consider an upper level components and interactions not directly associated to the routing system, it would logically operate in the order of the order 100ms or more generally of the order of seconds and above. The routing system is thus expected to remain the entity in charge of short-term adaptations to network "topological" or "reachability" changes. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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]. D.Papadimitriou Expires Apr.14, 2013 [Page 4] Internet-Draft IRS Architectural Framework Oct.15 2012 In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [RFC2234]. 2. Terminology, Notation and Acronyms 2.1. Terminology and Notation - Agent: in general terms equipping a given function (in present context an exchange function) with memory property leads to the notion of object. Providing these objects with the capacity to adapt and to modify their behavior with respect to changing/ variable conditions leads to the notion of adaptive agent. - Application: for the sake of clarity, application refers here to computer software (organized collections of computer data and instructions) performing tasks such as data processing and/or storage, running on top of TCP/IP and accessible directly (or indirectly) to the its end-users on terminals/hosts/servers to accomplish these specific tasks. Note: in practice, it is expected that the IRS will be initially used in the context of "network applications", i.e., programs receiving access to the routing modules and routing table in order to associate specific routing protocol decision/execution and routing table entries to specific needs as explained in Section 3. - APP_i: agent associated to application i (where index i = 1,..,L) that enables information exchanges with the dispatch function d. - Boundary: determines/indicates the logical intersecting edge/area between the routing system and the application system. The existence as well as to the proper operation and management of this edge/area is key in developing and maintaining coherence across the intersecting systems. - Co-located: refers to the placement of entities in close physical/logical proximity so that remotely/distantly they appear as occupying a single position/location. - Dispatch function (D and d): generic term describing the functional block redirecting information. Redirection of information is defined either between dispatch functions or between dispatch function and agents. D.Papadimitriou Expires Apr.14, 2013 [Page 5] Internet-Draft IRS Architectural Framework Oct.15 2012 Additionally the following functionality may be associated to this functional block: syntax and semantic information processing, aggregation/abstraction of information, orchestration, and scheduling. Equipping this function with (at least some of) these additional functionality is also part of the architectural discussion and specification. - External interface: interface that is addressable by objects/ components outside of the objects/components they interconnect/put in relation and which usually belong to different entities; each object/component defining an entry point to the entity to which they individually belong thus resulting in higher security requirements. - Internal interface: interface that is not addressable by objects/ components outside of the objects/components it interconnects/puts in relation or the single entity that comprises them. The objects/ components interacting through an internal interface are co- located. - M_m: traffic monitoring module/point m (where index m = 1,..P). Monitoring modules capture traffic and interface either with the IRS or with other routing modules via the dispatch function. - RTR_j (Router j, where index j = 1,..,M): entity hosting multiple routing modules (RM). - RM_k (Routing module k, where index k = 1,..,N): functional entity such as Interior Gateway Protocols (IGP), Exterior Gateway Protocol (EGP), etc. including the node global Routing Table (database structure and controller) as well as shared routing path computation functions (which for RSVP-TE is referred to as Path Computation Element or PCE). An agent indexed in the same way is associated to each routing module interacting with a dispatch function. 2.2. Acronyms EGP Exterior Gateway Protocol FT Forwarding Table IGP Interior Gateway Protocol IRS Interface to the RS RM Routing Module RS Routing System RT Routing Table D.Papadimitriou Expires Apr.14, 2013 [Page 6] Internet-Draft IRS Architectural Framework Oct.15 2012 RTR Router 3. Use Cases The general purpose of the IRS is to enable the augmentation or the enhancement of the IGP (and even the EGP) based routing system with i) functionality it is not able to perform when operating on a pure IGP prefix basis with or without additional state information associated to their link (e.g. spatial traffic engineering information), ii) functionality involving time varying information at a higher rate than what IGP (and even EGP) can sustain by design, and/or iii) functionality it has not been initially designed for but that strongly influence the working of the routing system (this category includes anomaly detection, intrusion detection, etc.). Cases belonging to the sets i) and ii) would increase the memory cost and adaptation cost if the IGP would be directly involved in the corresponding routing information exchange process. From this perspective, use cases can be further classified as follows: - Isolation of source (some of which may be included in IGP prefixes and/or prefixes included in the routing table) and/or destination addresses subset of the prefixes stored by the routing table (some of which being derived from the IGP routing information base). - Tuning of the routing entries parameters associated to destination prefix(es) (with as particular case, host-based prefixes) being subset of IGP destination prefixes from which routing table entries are derived. - Sequencing/ordering of the computation and activation of routing table entries (where the sequence if left to the IGP alone would for instance delay convergence). Note that the cases outlined here below are not claimed to be genuine but expectedly illustrative of the possible usage of the "IRS interface". The proposed classes are expected to be generic enough in order to "unify" its design. Isolation refers to cases dealing with distributed intrusion detection and distributed traffic anomaly detection (e.g., dDoS) where the objective is to detect and identify the intrusion/anomaly and possible prevent this intrusion/anomaly to further propagate. The latter typically involves determining through which router the corresponding traffic enters and possibly leaves the routing domain as well as determining the best router from where and to which the D.Papadimitriou Expires Apr.14, 2013 [Page 7] Internet-Draft IRS Architectural Framework Oct.15 2012 incriminated traffic should be deflected. The term distributed means that several routers monitors collect traffic traces/records from the routing domain and the IRS is used as interface to a network application module capable of processing traffic records taken out of various monitors. Techniques enabling detection of never-seen-before patterns are now available (see e.g., [ECODE]) that limit the amount of configuration and maintenance required on each node (as long as the information captured on multiple monitors can be cross-processed). In case of isolation, the propagation of the information by means of the IGP would increase the number of entries to be stored at each router while only some of them require the corresponding information. Tuning refers to use cases dealing with traffic engineering path computation and decision on a finer granularity than the one enforced by the destination prefixes distributed by means of the IGP. Parameter setting includes the possibility to associate a given incoming traffic flow to a specific routing entry (instead of using the "default" entry as determined by the destination address). Such parameters include in particular the bandwidth x delay product that can be computed for some of the (edge-to-edge) segments crossing the routing domain. The IRS can also be used to tune the parameter of the active monitors used to compute the available and residual capacity together with the edge-to-edge delay. On the other hand, passive monitors would not need to be activated on edge routers but placed so as to monitor specific spatial patterns of traffic. Moreover, instead of running at a default rate, the rate of packet / flow capture could be individually adapted depending on the applicative needs and the topological location of the router following that pattern. Sequencing typically involves cases related to distributed decisions that need to be taken more rapidly and/or executions that need to be performed more rapidly than the convergence time IGP would impose (with all associated detrimental effects, e.g., routing loops, loss- of-traffic, etc.). This class includes fast re-routing (activation of a loop-free alternate routing/forwarding entry) but also configuration and maintenance operations involving for instance link metric changes, activation/deactivation of interfaces, etc. As stated above, enabling several of these use cases would increase the memory and adaptation cost if the IGP would be directly involved in the corresponding routing information exchange process. Instead by assuming that i) not all additional entries are needed during the same period of time and ii) the number of active entries << total number of routing entries, one should be able to ensure higher "scaling" (or equivalently lower cost of scale) compared to the default situation IGP imposes (resulting from flooding of routing information). D.Papadimitriou Expires Apr.14, 2013 [Page 8] Internet-Draft IRS Architectural Framework Oct.15 2012 4. Architectures The below section/sub-sections detail the architectures as far as our understanding goes in providing an interaction channel between the routing system (and its individual routers) and the applicative level (and its numerous applications). 4.1. Dual architectures These architectures are characterized by three levels (or tiers) of redirection and a logical boundary between the routing system and the application system defined by the interface between their respective dispatch function. 4.1.1. Boundary on external interface This architecture is similar to the one exposed in the [RTG_Area] presentation, where each routing entity or router (RTR) owns its individual dispatch function D and each APP agent is associated to a dispatch function d, distinct from the function D. This architecture involves three levels of redirection as depicted in Fig.1a. The logical boundary between the routing system and the application system is determined by the external interface between the dispatch function d and D (see below). From this figure, the following relationships can be derived: - Relationship APP to d: n:m (particular case: 1:1) - Relationship d to D: m:n (particular case: 1:1) - Relationship D to RM (same RTR): 1:n (particular case: 1:1) ------- ------- ------- . . . . . . . . | APP_1 | ... | APP_i | ... | APP_L | ^ ------- ------- ------- | | | | | | | | | 3rd Level | | | | | ----- | v ---- ... -| d |- ... ----- . . . . . . . . ----- ^ / | \ | | | __________________|_____ Boundary | 2nd Level | | | | D.Papadimitriou Expires Apr.14, 2013 [Page 9] Internet-Draft IRS Architectural Framework Oct.15 2012 ----------------- | RTR_1... | RTR_j | | ... RTR_M | | ----- | v | | D | | . . . . . . . . | ----- | ^ | / | \ | | | / | \ | | 1st Level | | | | | | | RM_1 RM_k RM_N | v ----------------- . . . . . . . . Fig.1a: Boundary on external interface d-D (co-located dispatch function D) From Fig.1a, one can identify the following: * Dual dispatch function: . One dispatch function D is associated to each RTR entity. This dispatch function D is co-located with the RTR to which it is associated. . One dispatch function d is associated to a set of one or more APP agents. This dispatch function d is not co-located with the APP agents to which it is associated. * RTR level: . Includes co-located dispatch function D . Agents running on each routing module RM_k communicate with the dispatch function D via an internal interface (the associated routing modules may be known to the local dispatch function D by means of a registration process). * Interfaces: . External interface between APP agents and d . External interface between dispatch functions d and D . Internal interface between D and RM_k agent of RTR_j . In terms of IRS: - The IRS would include the interface defined between the dispatch functions D and d (which is an external interface) - The question which remains is: does the IRS span the interfaces defined between i) RM_k and the dispatch function D and/or ii) APP_i and the dispatch function d. If not then the dispatch function will have to provide the syntax and semantic functionality to process messages receives from various agents. D.Papadimitriou Expires Apr.14, 2013 [Page 10] Internet-Draft IRS Architectural Framework Oct.15 2012 Note that one can extend this architecture and assume that the dispatch function D is not co-located to its associated RTR as depicted in Fig.1b. This architecture also involves three levels of redirection as depicted in Fig.1b. In that case, the following relationships can be derived: - Relationship APP to d: n:m (particular case: 1:1) - Relationship d to D: m:n (particular case: 1:1) - Relationship D to RTR: m:n (particular case: 1:1), meaning that a given dispatch function D can be shared among multiple RTRs. ------- ------- ------- . . . . . . . . | APP_1 | ... | APP_i | ... | APP_L | ^ ------- ------- ------- | | | | | | | | | 3rd Level | | | | | ----- | v ---- ... -| d |- ... ----- . . . . . . . . ----- ^ / | \ | | | __________________|_____ Boundary | 2nd Level | | | | ----- v --------------| D |----------- . . . . . . . . | ----- | ^ | | | | | | | ------|-|-|------ | | RTR_1 |RTR_j | | | | RTR_M | | / | \ | | 1st Level | / | \ | | | | | | | | | RM_1 RM_k RM_N | v ----------------- . . . . . . . . Fig.1b: Boundary on external interface d-D (non co-located dispatch function D) From Fig.1b, one can identify the following: * Dual dispatch function: D.Papadimitriou Expires Apr.14, 2013 [Page 11] Internet-Draft IRS Architectural Framework Oct.15 2012 . One dispatch function D is associated to a set of one or more RTR. This dispatch function D is not co-located with either of the RTR to which it is associated. . One dispatch function d is associated to a set of one or more APP This dispatch function d is not co-located with either of the APP to which it is associated. . The dispatch functions d and D are themselves not co-located, i.e., exchanges are performed by means of an external interface. * RTR level: . No co-located dispatch function D . Agents running on each routing module RM_k communicate with the dispatch function D via an external interface (the associated routing module may be known to the local function D by means of a registration process). * Interfaces: . External interface between APP agents and d . External interface between dispatch functions d and D . External interface between D and RM_k agents of RTR_j . In terms of IRS: - The IRS would include the interface defined between the dispatch function D and d (which is an external interface) - Here too, the question which remains is: does the IRS span the interfaces defined between i) RM_k and the dispatch function D and/or ii) APP_i and the dispatch function d. If not then the dispatch function will have to provide the syntax and semantic functionality to process messages receives from various agents. Remark: this architecture mandates/imposes to standardize all interfaces involved in the exchange process between the routing system and the applicative level. D.Papadimitriou Expires Apr.14, 2013 [Page 12] Internet-Draft IRS Architectural Framework Oct.15 2012 4.1.2. Boundary on internal interface This architecture involves three levels of redirection as depicted in Fig.1c. The main differences with the architecture depicted in Section 4.1.1/Fig.1a are i) non co-located dispatch function D (with its associated RTR) and ii) an internal interface between the dispatch function D and d (instead of an external interface). The main differences with the architecture depicted in Section 4.1.1/Fig.1b is the internal interface between dispatch functions D and d (instead of an external interface). The logical boundary between the routing system and the application system is determined by the internal interface between the dispatch function d and D. The following relationships can be derived: - Relationship APP to d: n:m (particular case: 1:1) - Relationship d to D: m:n (particular case: 1:1) - Relationship D to RTR: m:n (particular case: 1:1) ------- ------- ------- . . . . . . . . | APP_1 | ... | APP_i | ... | APP_L | ^ ------- ------- ------- | | | | | | | | | 3rd Level | --------- | | | | ----- | | v ---- ...|-| d |-|... ----- . . . . . . . . | ----- | ^ | | | | _____________|____|____|___ Boundary | 2nd Level | | | | | ----- | v ------------|-| D |-|--------- . . . . . . . . | | ----- | | ^ | --------- | | | | | | | | | ------|-|-|------ | | RTR_1 |RTR_j | | | | RTR_M | | / | \ | | 1st Level | / | \ | | | | | | | | | RM_1 RM_k RM_N | v ----------------- . . . . . . . . Fig.1c: Boundary on internal interface d-D (non co-located dispatch function D) D.Papadimitriou Expires Apr.14, 2013 [Page 13] Internet-Draft IRS Architectural Framework Oct.15 2012 From Fig.1c, one can identify the following: * Dual dispatch function: . One dispatch function D is associated to a set of one or more RTR. . One dispatch function d is associated to a set of one or more APP. . The dispatch functions d and D are themselves co-located, i.e., exchanges are performed by means of an internal interface. * RTR level: . No co-located dispatch function D . Agents running on each routing module RM_k communicate with the dispatch function D via external interface (associated routing module may be known to the local function D by means of a registration process). * Interfaces: . External interface between APP agents and d . Internal interface between dispatch functions d and D . External interface between D and RM_k agents of RTR_j . In terms of IRS: - The IRS would include the interface defined between the dispatch function D and d (which is an internal interface) - Here too, the question which remains is: does the IRS span the interfaces defined between i) RM_k and the dispatch function D and/or ii) APP_i and the dispatch function d. If not then the dispatch function will have to provide the syntax and semantic functionality to process messages receives from various agents. Remark: this architecture doesn't require standardizing the interface between dispatch functions (only procedures performed by the dispatch functions would need specification). D.Papadimitriou Expires Apr.14, 2013 [Page 14] Internet-Draft IRS Architectural Framework Oct.15 2012 4.2. Star architecture These architectures are characterized by i) two levels of redirection, and ii) common dispatch function (dD) between APP and RTR. The boundary in these architectures can be seen as determined by the intersecting/common function dD. When this function is supplied with memory property, it is referred to as a boundary object. 4.2.1. Co-located Dispatch Function In this case, the following relationships can be derived: - Relationship APP to dD: n:m (particular case: 1:1) - Relationship dD to RM (same RTR): 1:n (particular case: 1:1) ------- ------- ------- . . . . . . . . | APP_1 | ... | APP_i | ... | APP_N | ^ ------- ------- ------- | | | | | | | | | 2nd Level | ------------------- | | | | RTR_j | | | | | | ----- | | v ---|- .. -| dD |- .. -|--- . . . Boundary | ----- | ^ | | | | | | | / | \ | | 1st Level | / | \ | | | | | | | | | RM_1 RM_k RM_N | v ------------------- . . . . . . . . Fig.2a: Star architecture - Co-located common dispatch function From Fig.2a, one can identify: * Common dispatch function: . A dispatch function dD is associated to each RTR. The same dispatch function dD is associated to a set of one or more APP. One can thus refer the function dD to as a common dispatch function . The dispatch function dD associated to the RTR_j is co-located with the RTR_j * RTR level: . Includes co-located dispatch function dD D.Papadimitriou Expires Apr.14, 2013 [Page 15] Internet-Draft IRS Architectural Framework Oct.15 2012 . Agents running on each routing module RM_k communicate with the dispatch function dD via internal interface (associated routing module may be known to the local function D by means of a registration process). * Interfaces: . External interface between APP agents and dispatch function dD . Internal interface between dispatch function dD and RM_k agents of RTR_j . In terms of IRS: - In this case, the IRS would span the interfaces defined between APP_i and the dispatch function dD. The question - The question which remains is: does the IRS span the interfaces defined between RM_k and the dispatch function D. If not then the dispatch function will have to provide the syntax and semantic functionality to process messages receives from various agents. 4.2.2. Non Co-located Dispatch Function In this case, the following relationships can be derived: - Relationship APP to dD: n:m (particular case: 1:1) - Relationship dD to RTR: m:n (particular case: 1:1) ------- ------- ------- . . . . . . . . | APP_1 | ... | APP_i | ... | APP_N | ^ ------- ------- ------- | | | | | | | | | 2nd Level | | | | | ----- | v ---- ... -| dD |- ... ----- . . . Boundary ----- ^ -------|-|-|------- | | RTR_j | | | | | | / | \ | | 1st Level | / | \ | | | | | | | | | RM_1 RM_k RM_N | v ------------------- . . . . . . . . Fig.2b: Star Architecture - Non co-located common dispatch function D.Papadimitriou Expires Apr.14, 2013 [Page 16] Internet-Draft IRS Architectural Framework Oct.15 2012 From Fig.2b, one can identify: * Common dispatch function: . One common dispatch function dD is associated to a set of one or more RTR and to a set of one or more APP. . This dispatch function is neither co-located with the router (RTR) (or its routing modules) nor with the APP agents. In this case, one can refer to a commonly shared dispatch function dD. * RTR level: . No co-located dispatch function dD . Agents running on each routing module RM_k communicate with the dispatch function dD via external interface (associated routing module agents may be known to the local function D by means of a registration process). * Interfaces: . External interface between APP agents and dispatch function dD . External interface between dispatch function dD and RM_k agents of RTR_j . In terms of IRS: - In this case the IRS would span i) the interfaces defined between APP_i and the dispatch function dD and ii) the interfaces defined between RM_k and the dispatch function dD. D.Papadimitriou Expires Apr.14, 2013 [Page 17] Internet-Draft IRS Architectural Framework Oct.15 2012 4.3. Meshed architecture Alternatively, one may consider that each agent executes its own dispatch function and the relationship between APP_i and RM_k agents is n:m. In this architecture, the boundary is thus determined by the set of APP agent to RM agent relationships. This architecture however implies that i) APP and RM agents are knowledgeable of each other, and ii) the individual routers must provide means to ensure consistency and coherence of decisions (by their routing modules) but also to prevent concurrency between decisions (leading to antagonistic action-reaction). For this purpose, a decision control function (hD), performing decision verification, consistency-check, etc. is to be considered that is co- located with individual RTR (see Fig.3). The interface between each routing module RM_k_and the function hD (indicated with asterisks in Fig.3) falls beyond the scope of IRS. ------- ------- ------- | APP_1 | ... | APP_i | ... | APP_N | ------- ------- ------- | | || | | || | | || ----------- | ------------- | | || ------------ | || | -------|-||-|------- | RTR_j | || | | | / || \ | | / || \ | | | || | | | RM_1 RM_k RM_N | | * * * | | * * * | | * ---- * | | ***| hD |*** | | ---- | -------------------- Fig.3: Meshed architecture In a sense, the architectures presented in Section 3.1 and 3.2 perform inbound decision control whereas the architecture depicted in Fig.3 performs outbound decision control. Inbound (to RM) means that the function D (in the Fig.1 and Fig.2) processes the incoming information to ensure that the proper decision left subsequently to D.Papadimitriou Expires Apr.14, 2013 [Page 18] Internet-Draft IRS Architectural Framework Oct.15 2012 individual RM but the function D is not part of the decision control process (verification, consistency-check, etc.). This process is performed by the RM themselves. On the other hand, outbound (to RM) means that the function hD (in Fig.3) performs verification, consistency-check, etc. of the (individual) decisions taken by the RMs. 5. Comparative Analysis TBD. 6. Security Considerations There are multiple levels at which security considerations shall be embedded and from the start as part of the architecture. Indeed, application and routing systems may (and often will) be under the control of different parties/administrative unit and communication between them (using the various external interfaces outlined in this document) may be established across the Internet. - Accessibility and communication: prevent denial of system/service and overloads, enforce authentication of individual communicating entities and prevent unauthorized access/masquerades (authorization). - Information exchange: enforce information integrity and validity (verification process) as well as prevent information/data spoofing; information confidentiality may be critical for certain environments, not necessarily for others (e.g., NREN). - Semantic processing: assuming that routing modules would receive information to derive decisions, individual information can be valid but its interpretation and resulting decisions may lead to executions weakening the routing system. 7. IANA Considerations None 8. Conclusions TBD D.Papadimitriou Expires Apr.14, 2013 [Page 19] Internet-Draft IRS Architectural Framework Oct.15 2012 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 9.2. Informative References [RTG_Area] Atlas, A., et al. "Interface to the Internet Routing System (IRS)", Routing Area Meeting, Vancouver (BC), Canada, July 2012. [ECODE] Project website: http://www.ecode-project.eu [OFELIA] Project website: http://www.fp7-ofelia.eu 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved. Part of the input that led to this document has been derived from the outcomes of the [ECODE] project (Grant No.223936) that is funded by the Framework Program 7 (FP7) of the European Commission and from the [OFELIA] FP7 project; both projects are part of the Future Internet Research and Experimentation Initiative (FIRE) of the European Commission. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. D.Papadimitriou Expires Apr.14, 2013 [Page 20] Internet-Draft IRS Architectural Framework Oct.15 2012 o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. D.Papadimitriou Expires Apr.14, 2013 [Page 21] Internet-Draft IRS Architectural Framework Oct.15 2012 Authors' Addresses Dimitri Papadimitriou Alcatel-Lucent Bell N.V. Dep.: Bell Labs Benelux Copernicuslaan 50 2018 Antwerpen Belgium Email: dimitri.papadimitriou@alcatel-lucent.com Tel: +32 3 2408491 Martin Vigoureux Alcatel-Lucent Bell Labs France Dep.: Bell Labs France Route de Villejust Nozay 91620 France Email: martin.vigoureux@alcatel-lucent.com Didier Colle Ghent University Dep.: INTEC Gaston Crommenlaan 8 bus 201 9050 Ledeberg - Gent Belgium Email: didier.colle@intec.ugent.be Tel: +32 9 3314900 Wouter Tavernier Ghent University Dep.: INTEC Gaston Crommenlaan 8 bus 201 9050 Ledeberg - Gent Belgium Email: wouter.tavernier@intec.ugent.be Tel: +32 9 3314900 D.Papadimitriou Expires Apr.14, 2013 [Page 22]