idnits 2.17.1 draft-dimitri-irs-arch-frame-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 240 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dimitri Papadimitriou 3 Internet Draft Martin Vigoureux 4 Intended status: Informational Alcatel-Lucent 6 Wouter Tavernier 7 Expires: April 14, 2013 Didier Colle 8 UGent 9 October 15 2012 11 IRS Architectural Framework 12 draft-dimitri-irs-arch-frame-00.txt 14 Abstract 16 This document details the possible architectural and design choices 17 in order to determine i) the spatial location of the so-called "IRS 18 interface" and the functional entities it directly and/or indirectly 19 involves, ii) the number of levels of redirection between routing 20 modules and application (and associated identifier space), and iii) 21 the various constraints that can be anticipated when dealing with the 22 coupling of functional planes including the prevention of 23 oscillations between two or more routing system states, coupling 24 effects (leading to amplification chains) and, concurrency (leading 25 to antagonistic action-reaction). 27 Disclaimer: this document doesn't intend to promote any specific 28 architecture; its purpose is to understand (some of) the 29 architectural challenges when designing interaction between routing 30 system and applicative levels/systems. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 This Internet-Draft will expire on April 14 2013. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction.................................................3 72 Conventions used in this document...............................4 73 2. Terminology, Notation and Acronyms...........................5 74 2.1. Terminology and Notation................................5 75 2.2. Acronyms................................................6 76 3. Use Cases....................................................7 77 4. Architectures................................................9 78 4.1. Dual architectures......................................9 79 4.1.1. Boundary on external interface.....................9 80 4.1.2. Boundary on internal interface....................13 81 4.2. Star architecture......................................15 82 4.2.1. Co-located Dispatch Function......................15 83 4.2.2. Non Co-located Dispatch Function..................16 84 4.3. Meshed architecture....................................18 85 5. Comparative Analysis........................................19 86 6. Security Considerations.....................................19 87 7. IANA Considerations.........................................19 88 8. Conclusions.................................................19 89 9. References..................................................20 90 9.1. Normative References...................................20 91 9.2. Informative References.................................20 92 10. Acknowledgments............................................20 94 1. Introduction 96 Nowadays, applicative layers don't only rely on the shared 97 infrastructure for information communication purposes but also for 98 information storage (e.g., content delivery/caching, large date sets) 99 and processing (e.g., grid computing, virtual machines). The 100 expansion of the functional role of the shared infrastructure has in 101 turn induced the rise of intermediate systems/application level hubs 102 under the control / supervision of providers (usually ranging from 103 application providers to mediators). 105 With the current Internet model where the routing system is a closed 106 system, applications have to run their own measurement end-to-end to 107 determine forwarding path characteristics through traffic monitoring 108 but also have no means by which some network path can be enforced (by 109 network path we refer here to the path as computed on-line by routing 110 algorithms or those made available by off-line means). The best 111 example is the triangular inequality violation where the shortest 112 path between two end points (shortcut) may not be the best bandwidth 113 x delay path between these two points. Indeed, as there is no 114 deployed mean (e.g., source routing) by which applicative layers can 115 tell the network which path IP datagrams shall follow, measurements 116 don't allow any subsequent decision tuning on which network path to 117 follow to reach a given destination. The alternative is to drive the 118 routing table entries by applicative-triggers exchanged by means of 119 an API (referred to as IRS since one end of this interface terminates 120 in the "routing system") assuming applications share with the routing 121 system a common understanding of distance and resource usage metrics. 122 In other terms, compared to the decoupling between traffic 123 engineering decisions concerning network path and applicative layers 124 needs, such model would allow cooperation in the routing decision 125 process. 127 In this context, the actual objectives of the present document are 128 the following: 130 i) Enumerate possible architectural and design choices to determine 131 the spatial location of the so-called "IRS interface" and the 132 functional entities it directly and/or indirectly involves. In turn, 133 this enables determining internal vs. external interfaces (those that 134 MAY be standardized and those that MUST be standardized, and those 135 that require specific architectural focus when dealing with security 136 aspects). 138 ii) Determine the number of levels of redirection between routing 139 modules and application (and the associated identifier space). 141 iii) Identify pro's and con's of possible architectures depending on 142 use cases (bottom-up) that in general will combine one or more of 143 these elements: distance/path, topology ((abstract) nodes, (abstract) 144 links), location/mobility (end-point, data, etc.); note that the 145 inclusion of traffic properties leads de facto to the introduction of 146 monitoring points. 148 iv) Anticipate the constraints (from base distributed control and 149 decision theory) when dealing with the coupling of functional planes 150 and some architectural invariants identified (top-down). These 151 includes the prevention of i) oscillations between two or more 152 routing system states, ii) coupling effects (leading to amplification 153 chains) and, iii) concurrency (leading to antagonistic action- 154 reaction). 156 v) Even if the initial architectural scope would be limited to single 157 autonomous system as starting point, propose a generic enough 158 description to enable inter-domain use cases in the future. 160 It is anticipated that the time dimension will limit applicability of 161 such information exchange to the control part of the routing system 162 (i.e. not the forwarding component). Indeed, the closer to the 163 forwarding component the smaller the time scale to ensure proper 164 functionality. The full Shortest Path Tree (SPT) computation takes of 165 the order of 10microsec per IGP destination prefix, optimizations can 166 be obtained using incremental Shortest Path First (iSPF) algorithms. 167 Updating the central node Routing Table (RT) ranges in the same order 168 of magnitude per destination prefix. The consecutive time the routing 169 engine CPU is spending to update the RT entries or their distribution 170 to the Forwarding Table (FT) is determined by the quantum of the 171 swapping process. The quantum time can typically be configured 172 between an order of 10 to 100ms. If we would consider an upper level 173 components and interactions not directly associated to the routing 174 system, it would logically operate in the order of the order 100ms or 175 more generally of the order of seconds and above. The routing system 176 is thus expected to remain the entity in charge of short-term 177 adaptations to network "topological" or "reachability" changes. 179 Conventions used in this document 181 In examples, "C:" and "S:" indicate lines sent by the client and 182 server respectively. 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC-2119 [RFC2119]. 188 In this document, these words will appear with that interpretation 189 only when in ALL CAPS. Lower case uses of these words are not to be 190 interpreted as carrying RFC-2119 significance. 192 In this document, syntax specification uses the augmented Backus-Naur 193 Form (BNF) as described in RFC-2234 [RFC2234]. 195 2. Terminology, Notation and Acronyms 197 2.1. Terminology and Notation 199 - Agent: in general terms equipping a given function (in present 200 context an exchange function) with memory property leads to the 201 notion of object. Providing these objects with the capacity to 202 adapt and to modify their behavior with respect to changing/ 203 variable conditions leads to the notion of adaptive agent. 205 - Application: for the sake of clarity, application refers here to 206 computer software (organized collections of computer data and 207 instructions) performing tasks such as data processing and/or 208 storage, running on top of TCP/IP and accessible directly (or 209 indirectly) to the its end-users on terminals/hosts/servers to 210 accomplish these specific tasks. 212 Note: in practice, it is expected that the IRS will be initially 213 used in the context of "network applications", i.e., programs 214 receiving access to the routing modules and routing table in order 215 to associate specific routing protocol decision/execution and 216 routing table entries to specific needs as explained in Section 3. 218 - APP_i: agent associated to application i (where index i = 1,..,L) 219 that enables information exchanges with the dispatch function d. 221 - Boundary: determines/indicates the logical intersecting edge/area 222 between the routing system and the application system. The 223 existence as well as to the proper operation and management of 224 this edge/area is key in developing and maintaining coherence 225 across the intersecting systems. 227 - Co-located: refers to the placement of entities in close 228 physical/logical proximity so that remotely/distantly they appear 229 as occupying a single position/location. 231 - Dispatch function (D and d): generic term describing the functional 232 block redirecting information. Redirection of information is 233 defined either between dispatch functions or between dispatch 234 function and agents. 236 Additionally the following functionality may be associated to this 237 functional block: syntax and semantic information processing, 238 aggregation/abstraction of information, orchestration, and 239 scheduling. 241 Equipping this function with (at least some of) these 242 additional functionality is also part of the architectural 243 discussion and specification. 245 - External interface: interface that is addressable by objects/ 246 components outside of the objects/components they interconnect/put 247 in relation and which usually belong to different entities; each 248 object/component defining an entry point to the entity to which 249 they individually belong thus resulting in higher security 250 requirements. 252 - Internal interface: interface that is not addressable by objects/ 253 components outside of the objects/components it interconnects/puts 254 in relation or the single entity that comprises them. The objects/ 255 components interacting through an internal interface are co- 256 located. 258 - M_m: traffic monitoring module/point m (where index m = 1,..P). 259 Monitoring modules capture traffic and interface either with the 260 IRS or with other routing modules via the dispatch function. 262 - RTR_j (Router j, where index j = 1,..,M): entity hosting multiple 263 routing modules (RM). 265 - RM_k (Routing module k, where index k = 1,..,N): functional entity 266 such as Interior Gateway Protocols (IGP), Exterior Gateway 267 Protocol (EGP), etc. including the node global Routing Table 268 (database structure and controller) as well as shared routing path 269 computation functions (which for RSVP-TE is referred to as Path 270 Computation Element or PCE). An agent indexed in the same way is 271 associated to each routing module interacting with a dispatch 272 function. 274 2.2. Acronyms 276 EGP Exterior Gateway Protocol 277 FT Forwarding Table 278 IGP Interior Gateway Protocol 279 IRS Interface to the RS 280 RM Routing Module 281 RS Routing System 282 RT Routing Table 283 RTR Router 285 3. Use Cases 287 The general purpose of the IRS is to enable the augmentation or the 288 enhancement of the IGP (and even the EGP) based routing system with 289 i) functionality it is not able to perform when operating on a pure 290 IGP prefix basis with or without additional state information 291 associated to their link (e.g. spatial traffic engineering 292 information), ii) functionality involving time varying information at 293 a higher rate than what IGP (and even EGP) can sustain by design, 294 and/or iii) functionality it has not been initially designed for but 295 that strongly influence the working of the routing system (this 296 category includes anomaly detection, intrusion detection, etc.). 297 Cases belonging to the sets i) and ii) would increase the memory cost 298 and adaptation cost if the IGP would be directly involved in the 299 corresponding routing information exchange process. 301 From this perspective, use cases can be further classified as 302 follows: 304 - Isolation of source (some of which may be included in IGP prefixes 305 and/or prefixes included in the routing table) and/or destination 306 addresses subset of the prefixes stored by the routing table (some of 307 which being derived from the IGP routing information base). 309 - Tuning of the routing entries parameters associated to destination 310 prefix(es) (with as particular case, host-based prefixes) being 311 subset of IGP destination prefixes from which routing table entries 312 are derived. 314 - Sequencing/ordering of the computation and activation of routing 315 table entries (where the sequence if left to the IGP alone would for 316 instance delay convergence). 318 Note that the cases outlined here below are not claimed to be genuine 319 but expectedly illustrative of the possible usage of the "IRS 320 interface". The proposed classes are expected to be generic enough 321 in order to "unify" its design. 323 Isolation refers to cases dealing with distributed intrusion 324 detection and distributed traffic anomaly detection (e.g., dDoS) 325 where the objective is to detect and identify the intrusion/anomaly 326 and possible prevent this intrusion/anomaly to further propagate. The 327 latter typically involves determining through which router the 328 corresponding traffic enters and possibly leaves the routing domain 329 as well as determining the best router from where and to which the 330 incriminated traffic should be deflected. The term distributed means 331 that several routers monitors collect traffic traces/records from the 332 routing domain and the IRS is used as interface to a network 333 application module capable of processing traffic records taken out of 334 various monitors. Techniques enabling detection of never-seen-before 335 patterns are now available (see e.g., [ECODE]) that limit the amount 336 of configuration and maintenance required on each node (as long as the 337 information captured on multiple monitors can be cross-processed). In 338 case of isolation, the propagation of the information by means of the 339 IGP would increase the number of entries to be stored at each router 340 while only some of them require the corresponding information. 342 Tuning refers to use cases dealing with traffic engineering path 343 computation and decision on a finer granularity than the one 344 enforced by the destination prefixes distributed by means of the IGP. 345 Parameter setting includes the possibility to associate a given 346 incoming traffic flow to a specific routing entry (instead of using 347 the "default" entry as determined by the destination address). Such 348 parameters include in particular the bandwidth x delay product that 349 can be computed for some of the (edge-to-edge) segments crossing the 350 routing domain. The IRS can also be used to tune the parameter of the 351 active monitors used to compute the available and residual capacity 352 together with the edge-to-edge delay. On the other hand, passive 353 monitors would not need to be activated on edge routers but placed so 354 as to monitor specific spatial patterns of traffic. Moreover, instead 355 of running at a default rate, the rate of packet / flow capture could 356 be individually adapted depending on the applicative needs and the 357 topological location of the router following that pattern. 359 Sequencing typically involves cases related to distributed decisions 360 that need to be taken more rapidly and/or executions that need to be 361 performed more rapidly than the convergence time IGP would impose 362 (with all associated detrimental effects, e.g., routing loops, loss- 363 of-traffic, etc.). This class includes fast re-routing (activation of 364 a loop-free alternate routing/forwarding entry) but also 365 configuration and maintenance operations involving for instance link 366 metric changes, activation/deactivation of interfaces, etc. 368 As stated above, enabling several of these use cases would increase 369 the memory and adaptation cost if the IGP would be directly involved 370 in the corresponding routing information exchange process. Instead by 371 assuming that i) not all additional entries are needed during the 372 same period of time and ii) the number of active entries << total 373 number of routing entries, one should be able to ensure higher 374 "scaling" (or equivalently lower cost of scale) compared to the 375 default situation IGP imposes (resulting from flooding of routing 376 information). 378 4. Architectures 380 The below section/sub-sections detail the architectures as far as our 381 understanding goes in providing an interaction channel between the 382 routing system (and its individual routers) and the applicative level 383 (and its numerous applications). 385 4.1. Dual architectures 387 These architectures are characterized by three levels (or tiers) of 388 redirection and a logical boundary between the routing system and the 389 application system defined by the interface between their respective 390 dispatch function. 392 4.1.1. Boundary on external interface 394 This architecture is similar to the one exposed in the [RTG_Area] 395 presentation, where each routing entity or router (RTR) owns its 396 individual dispatch function D and each APP agent is associated to a 397 dispatch function d, distinct from the function D. This architecture 398 involves three levels of redirection as depicted in Fig.1a. The 399 logical boundary between the routing system and the application 400 system is determined by the external interface between the dispatch 401 function d and D (see below). 403 From this figure, the following relationships can be derived: 405 - Relationship APP to d: n:m (particular case: 1:1) 407 - Relationship d to D: m:n (particular case: 1:1) 409 - Relationship D to RM (same RTR): 1:n (particular case: 1:1) 411 ------- ------- ------- . . . . . . . . 412 | APP_1 | ... | APP_i | ... | APP_L | ^ 413 ------- ------- ------- | 414 | | | | 415 | | | | 3rd Level 416 | | | | 417 | ----- | v 418 ---- ... -| d |- ... ----- . . . . . . . . 419 ----- ^ 420 / | \ | 421 | | 422 __________________|_____ Boundary | 2nd Level 423 | | 424 | | 426 ----------------- | 427 RTR_1... | RTR_j | | ... RTR_M | 428 | ----- | v 429 | | D | | . . . . . . . . 430 | ----- | ^ 431 | / | \ | | 432 | / | \ | | 1st Level 433 | | | | | | 434 | RM_1 RM_k RM_N | v 435 ----------------- . . . . . . . . 437 Fig.1a: Boundary on external interface d-D (co-located dispatch 438 function D) 440 From Fig.1a, one can identify the following: 442 * Dual dispatch function: 443 . One dispatch function D is associated to each RTR entity. 444 This dispatch function D is co-located with the RTR to which it 445 is associated. 446 . One dispatch function d is associated to a set of one or more APP 447 agents. 448 This dispatch function d is not co-located with the APP agents 449 to which it is associated. 451 * RTR level: 452 . Includes co-located dispatch function D 453 . Agents running on each routing module RM_k communicate with the 454 dispatch function D via an internal interface (the associated 455 routing modules may be known to the local dispatch function D by 456 means of a registration process). 458 * Interfaces: 459 . External interface between APP agents and d 460 . External interface between dispatch functions d and D 461 . Internal interface between D and RM_k agent of RTR_j 463 . In terms of IRS: 464 - The IRS would include the interface defined between the 465 dispatch functions D and d (which is an external interface) 466 - The question which remains is: does the IRS span the 467 interfaces defined between i) RM_k and the dispatch function D 468 and/or ii) APP_i and the dispatch function d. If not then the 469 dispatch function will have to provide the syntax and semantic 470 functionality to process messages receives from various 471 agents. 473 Note that one can extend this architecture and assume that the 474 dispatch function D is not co-located to its associated RTR as 475 depicted in Fig.1b. This architecture also involves three levels of 476 redirection as depicted in Fig.1b. In that case, the following 477 relationships can be derived: 479 - Relationship APP to d: n:m (particular case: 1:1) 481 - Relationship d to D: m:n (particular case: 1:1) 483 - Relationship D to RTR: m:n (particular case: 1:1), meaning that a 484 given dispatch function D can be shared among multiple RTRs. 486 ------- ------- ------- . . . . . . . . 487 | APP_1 | ... | APP_i | ... | APP_L | ^ 488 ------- ------- ------- | 489 | | | | 490 | | | | 3rd Level 491 | | | | 492 | ----- | v 493 ---- ... -| d |- ... ----- . . . . . . . . 494 ----- ^ 495 / | \ | 496 | | 497 __________________|_____ Boundary | 2nd Level 498 | | 499 | | 500 ----- v 501 --------------| D |----------- . . . . . . . . 502 | ----- | ^ 503 | | | | | | 504 | ------|-|-|------ | | 505 RTR_1 |RTR_j | | | | RTR_M | 506 | / | \ | | 1st Level 507 | / | \ | | 508 | | | | | | 509 | RM_1 RM_k RM_N | v 510 ----------------- . . . . . . . . 512 Fig.1b: Boundary on external interface d-D (non co-located dispatch 513 function D) 515 From Fig.1b, one can identify the following: 517 * Dual dispatch function: 519 . One dispatch function D is associated to a set of one or more 520 RTR. 521 This dispatch function D is not co-located with either of the 522 RTR to which it is associated. 523 . One dispatch function d is associated to a set of one or more APP 524 This dispatch function d is not co-located with either of the 525 APP to which it is associated. 526 . The dispatch functions d and D are themselves not co-located, 527 i.e., exchanges are performed by means of an external interface. 529 * RTR level: 530 . No co-located dispatch function D 531 . Agents running on each routing module RM_k communicate with the 532 dispatch function D via an external interface (the associated 533 routing module may be known to the local function D by means of 534 a registration process). 536 * Interfaces: 537 . External interface between APP agents and d 538 . External interface between dispatch functions d and D 539 . External interface between D and RM_k agents of RTR_j 541 . In terms of IRS: 542 - The IRS would include the interface defined between the 543 dispatch function D and d (which is an external interface) 544 - Here too, the question which remains is: does the IRS span the 545 interfaces defined between i) RM_k and the dispatch function D 546 and/or ii) APP_i and the dispatch function d. If not then the 547 dispatch function will have to provide the syntax and semantic 548 functionality to process messages receives from various 549 agents. 551 Remark: this architecture mandates/imposes to standardize all 552 interfaces involved in the exchange process between the routing 553 system and the applicative level. 555 4.1.2. Boundary on internal interface 557 This architecture involves three levels of redirection as depicted in 558 Fig.1c. The main differences with the architecture depicted in 559 Section 4.1.1/Fig.1a are i) non co-located dispatch function D (with 560 its associated RTR) and ii) an internal interface between the 561 dispatch function D and d (instead of an external interface). The 562 main differences with the architecture depicted in Section 563 4.1.1/Fig.1b is the internal interface between dispatch functions D 564 and d (instead of an external interface). The logical boundary 565 between the routing system and the application system is determined 566 by the internal interface between the dispatch function d and D. 568 The following relationships can be derived: 570 - Relationship APP to d: n:m (particular case: 1:1) 572 - Relationship d to D: m:n (particular case: 1:1) 574 - Relationship D to RTR: m:n (particular case: 1:1) 576 ------- ------- ------- . . . . . . . . 577 | APP_1 | ... | APP_i | ... | APP_L | ^ 578 ------- ------- ------- | 579 | | | | 580 | | | | 3rd Level 581 | --------- | | 582 | | ----- | | v 583 ---- ...|-| d |-|... ----- . . . . . . . . 584 | ----- | ^ 585 | | | | 586 _____________|____|____|___ Boundary | 2nd Level 587 | | | | 588 | ----- | v 589 ------------|-| D |-|--------- . . . . . . . . 590 | | ----- | | ^ 591 | --------- | | 592 | | | | | | 593 | ------|-|-|------ | | 594 RTR_1 |RTR_j | | | | RTR_M | 595 | / | \ | | 1st Level 596 | / | \ | | 597 | | | | | | 598 | RM_1 RM_k RM_N | v 599 ----------------- . . . . . . . . 600 Fig.1c: Boundary on internal interface d-D (non co-located dispatch 601 function D) 602 From Fig.1c, one can identify the following: 604 * Dual dispatch function: 605 . One dispatch function D is associated to a set of one or more 606 RTR. 607 . One dispatch function d is associated to a set of one or more 608 APP. 609 . The dispatch functions d and D are themselves co-located, 610 i.e., exchanges are performed by means of an internal interface. 612 * RTR level: 613 . No co-located dispatch function D 614 . Agents running on each routing module RM_k communicate with the 615 dispatch function D via external interface (associated routing 616 module may be known to the local function D by means of a 617 registration process). 619 * Interfaces: 620 . External interface between APP agents and d 621 . Internal interface between dispatch functions d and D 622 . External interface between D and RM_k agents of RTR_j 624 . In terms of IRS: 625 - The IRS would include the interface defined between the 626 dispatch function D and d (which is an internal interface) 627 - Here too, the question which remains is: does the IRS span 628 the interfaces defined between i) RM_k and the dispatch 629 function D and/or ii) APP_i and the dispatch function d. If 630 not then the dispatch function will have to provide the 631 syntax and semantic functionality to process messages 632 receives from various agents. 634 Remark: this architecture doesn't require standardizing the interface 635 between dispatch functions (only procedures performed by the dispatch 636 functions would need specification). 638 4.2. Star architecture 640 These architectures are characterized by i) two levels of 641 redirection, and ii) common dispatch function (dD) between APP and 642 RTR. The boundary in these architectures can be seen as determined by 643 the intersecting/common function dD. When this function is supplied 644 with memory property, it is referred to as a boundary object. 646 4.2.1. Co-located Dispatch Function 648 In this case, the following relationships can be derived: 650 - Relationship APP to dD: n:m (particular case: 1:1) 652 - Relationship dD to RM (same RTR): 1:n (particular case: 1:1) 654 ------- ------- ------- . . . . . . . . 655 | APP_1 | ... | APP_i | ... | APP_N | ^ 656 ------- ------- ------- | 657 | | | | 658 | | | | 2nd Level 659 | ------------------- | | 660 | | RTR_j | | | | 661 | | ----- | | v 662 ---|- .. -| dD |- .. -|--- . . . Boundary 663 | ----- | ^ 664 | | | | | | 665 | / | \ | | 1st Level 666 | / | \ | | 667 | | | | | | 668 | RM_1 RM_k RM_N | v 669 ------------------- . . . . . . . . 671 Fig.2a: Star architecture - Co-located common dispatch function 673 From Fig.2a, one can identify: 675 * Common dispatch function: 676 . A dispatch function dD is associated to each RTR. The same 677 dispatch function dD is associated to a set of one or more APP. 678 One can thus refer the function dD to as a common dispatch 679 function 680 . The dispatch function dD associated to the RTR_j is co-located 681 with the RTR_j 683 * RTR level: 684 . Includes co-located dispatch function dD 685 . Agents running on each routing module RM_k communicate with the 686 dispatch function dD via internal interface (associated routing 687 module may be known to the local function D by means of a 688 registration process). 690 * Interfaces: 691 . External interface between APP agents and dispatch function dD 692 . Internal interface between dispatch function dD and RM_k agents 693 of RTR_j 695 . In terms of IRS: 696 - In this case, the IRS would span the interfaces defined 697 between APP_i and the dispatch function dD. The question 698 - The question which remains is: does the IRS span the 699 interfaces defined between RM_k and the dispatch function D. 700 If not then the dispatch function will have to provide the 701 syntax and semantic functionality to process messages receives 702 from various agents. 704 4.2.2. Non Co-located Dispatch Function 706 In this case, the following relationships can be derived: 708 - Relationship APP to dD: n:m (particular case: 1:1) 710 - Relationship dD to RTR: m:n (particular case: 1:1) 712 ------- ------- ------- . . . . . . . . 713 | APP_1 | ... | APP_i | ... | APP_N | ^ 714 ------- ------- ------- | 715 | | | | 716 | | | | 2nd Level 717 | | | | 718 | ----- | v 719 ---- ... -| dD |- ... ----- . . . Boundary 720 ----- ^ 721 -------|-|-|------- | 722 | RTR_j | | | | | 723 | / | \ | | 1st Level 724 | / | \ | | 725 | | | | | | 726 | RM_1 RM_k RM_N | v 727 ------------------- . . . . . . . . 729 Fig.2b: Star Architecture - Non co-located common dispatch function 730 From Fig.2b, one can identify: 732 * Common dispatch function: 733 . One common dispatch function dD is associated to a set of one or 734 more RTR and to a set of one or more APP. 735 . This dispatch function is neither co-located with the router 736 (RTR) (or its routing modules) nor with the APP agents. In this 737 case, one can refer to a commonly shared dispatch function dD. 739 * RTR level: 740 . No co-located dispatch function dD 741 . Agents running on each routing module RM_k communicate with the 742 dispatch function dD via external interface (associated routing 743 module agents may be known to the local function D by means of a 744 registration process). 746 * Interfaces: 747 . External interface between APP agents and dispatch function dD 748 . External interface between dispatch function dD and RM_k agents 749 of RTR_j 751 . In terms of IRS: 752 - In this case the IRS would span i) the interfaces defined 753 between APP_i and the dispatch function dD and ii) the 754 interfaces defined between RM_k and the dispatch function dD. 756 4.3. Meshed architecture 758 Alternatively, one may consider that each agent executes its own 759 dispatch function and the relationship between APP_i and RM_k agents 760 is n:m. In this architecture, the boundary is thus determined by the 761 set of APP agent to RM agent relationships. 763 This architecture however implies that i) APP and RM agents are 764 knowledgeable of each other, and ii) the individual routers must 765 provide means to ensure consistency and coherence of decisions (by 766 their routing modules) but also to prevent concurrency between 767 decisions (leading to antagonistic action-reaction). For this 768 purpose, a decision control function (hD), performing decision 769 verification, consistency-check, etc. is to be considered that is co- 770 located with individual RTR (see Fig.3). The interface between each 771 routing module RM_k_and the function hD (indicated with asterisks in 772 Fig.3) falls beyond the scope of IRS. 774 ------- ------- ------- 775 | APP_1 | ... | APP_i | ... | APP_N | 776 ------- ------- ------- 777 | | || 778 | | || 779 | | || 780 ----------- | ------------- | 781 | || ------------ 782 | || | 783 -------|-||-|------- 784 | RTR_j | || | | 785 | / || \ | 786 | / || \ | 787 | | || | | 788 | RM_1 RM_k RM_N | 789 | * * * | 790 | * * * | 791 | * ---- * | 792 | ***| hD |*** | 793 | ---- | 794 -------------------- 796 Fig.3: Meshed architecture 798 In a sense, the architectures presented in Section 3.1 and 3.2 799 perform inbound decision control whereas the architecture depicted in 800 Fig.3 performs outbound decision control. Inbound (to RM) means that 801 the function D (in the Fig.1 and Fig.2) processes the incoming 802 information to ensure that the proper decision left subsequently to 803 individual RM but the function D is not part of the decision control 804 process (verification, consistency-check, etc.). This process is 805 performed by the RM themselves. On the other hand, outbound (to RM) 806 means that the function hD (in Fig.3) performs verification, 807 consistency-check, etc. of the (individual) decisions taken by the 808 RMs. 810 5. Comparative Analysis 812 TBD. 814 6. Security Considerations 816 There are multiple levels at which security considerations shall be 817 embedded and from the start as part of the architecture. Indeed, 818 application and routing systems may (and often will) be under the 819 control of different parties/administrative unit and communication 820 between them (using the various external interfaces outlined in this 821 document) may be established across the Internet. 823 - Accessibility and communication: prevent denial of system/service 824 and overloads, enforce authentication of individual communicating 825 entities and prevent unauthorized access/masquerades (authorization). 827 - Information exchange: enforce information integrity and validity 828 (verification process) as well as prevent information/data spoofing; 829 information confidentiality may be critical for certain environments, 830 not necessarily for others (e.g., NREN). 832 - Semantic processing: assuming that routing modules would receive 833 information to derive decisions, individual information can be valid 834 but its interpretation and resulting decisions may lead to executions 835 weakening the routing system. 837 7. IANA Considerations 839 None 841 8. Conclusions 843 TBD 845 9. References 847 9.1. Normative References 849 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 850 Requirement Levels", BCP 14, RFC 2119, March 1997. 852 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 853 Syntax Specifications: ABNF", RFC 2234, Internet Mail 854 Consortium and Demon Internet Ltd., November 1997. 856 9.2. Informative References 858 [RTG_Area] Atlas, A., et al. "Interface to the Internet Routing 859 System (IRS)", Routing Area Meeting, Vancouver (BC), 860 Canada, July 2012. 862 [ECODE] Project website: http://www.ecode-project.eu 864 [OFELIA] Project website: http://www.fp7-ofelia.eu 866 10. Acknowledgments 868 This document was prepared using 2-Word-v2.0.template.dot. 870 Copyright (c) 2012 IETF Trust and the persons identified as authors 871 of the code. All rights reserved. 873 Part of the input that led to this document has been derived from the 874 outcomes of the [ECODE] project (Grant No.223936) that is funded by 875 the Framework Program 7 (FP7) of the European Commission and from the 876 [OFELIA] FP7 project; both projects are part of the Future Internet 877 Research and Experimentation Initiative (FIRE) of the European 878 Commission. 880 Redistribution and use in source and binary forms, with or without 881 modification, are permitted provided that the following conditions 882 are met: 884 o Redistributions of source code must retain the above copyright 885 notice, this list of conditions and the following disclaimer. 887 o Redistributions in binary form must reproduce the above copyright 888 notice, this list of conditions and the following disclaimer in 889 the documentation and/or other materials provided with the 890 distribution. 892 o Neither the name of Internet Society, IETF or IETF Trust, nor the 893 names of specific contributors, may be used to endorse or promote 894 products derived from this software without specific prior written 895 permission. 897 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 898 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 899 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 900 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 901 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 902 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 903 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 904 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 905 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 906 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 907 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 909 Authors' Addresses 911 Dimitri Papadimitriou 912 Alcatel-Lucent Bell N.V. 913 Dep.: Bell Labs Benelux 914 Copernicuslaan 50 915 2018 Antwerpen 916 Belgium 917 Email: dimitri.papadimitriou@alcatel-lucent.com 918 Tel: +32 3 2408491 920 Martin Vigoureux 921 Alcatel-Lucent Bell Labs France 922 Dep.: Bell Labs France 923 Route de Villejust 924 Nozay 91620 925 France 926 Email: martin.vigoureux@alcatel-lucent.com 928 Didier Colle 929 Ghent University 930 Dep.: INTEC 931 Gaston Crommenlaan 8 bus 201 932 9050 Ledeberg - Gent 933 Belgium 934 Email: didier.colle@intec.ugent.be 935 Tel: +32 9 3314900 937 Wouter Tavernier 938 Ghent University 939 Dep.: INTEC 940 Gaston Crommenlaan 8 bus 201 941 9050 Ledeberg - Gent 942 Belgium 943 Email: wouter.tavernier@intec.ugent.be 944 Tel: +32 9 3314900