idnits 2.17.1 draft-salgarelli-issll-mis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 77 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 961, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 964, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-06) exists of draft-ietf-issll-atm-mapping-03 -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- No information found for draft-yavatkar-sbm-ethernet - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '9') -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-02) exists of draft-ietf-rsvp-routing-01 -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 1577 (ref. '12') (Obsoleted by RFC 2225) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force L. Salgarelli, Editor / A. Corghi 2 INTERNET-DRAFT CEFRIEL/Politecnico di Milano 3 draft-salgarelli-issll-mis-00.txt M. Smirnow / H. Sanneck / D. Witaszek 4 10 November 1997 GMD-FOKUS 5 Expires: 15 May 1998 7 Supporting IP Multicast Integrated Services in ATM Networks 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This memo presents an integrated, server-based mechanism for the 30 efficient support of the IP Integrated Services (IIS) model in ATM 31 networks, namely the Multicast Integration Server (MIS) architecture. 32 Instead of viewing IP-ATM multicast address resolution and QoS 33 support separately, the approach in this memo is to consider such 34 issues in an integrated manner. In particular, the MIS architecture 35 defines how a layer-3 setup protocol as RSVP can be mapped to and 36 integrated with a layer-2 multicast address resolution protocol as 37 EARTH - EAsy Multicast Routing THrough ATM clouds. With the use of 38 EARTH, several ATM point-to-multipoint connections with different QoS 39 parameters can be associated to a single IP multicast address. An 40 RSVP server (RSVP-S) within the MIS is used to distribute RSVP 41 messages inside the ATM cloud and to set the corresponding QoS state 42 in the address resolution table of EARTH (setup protocol mapping). 43 In addition, this memo defines a quantized heterogeneity model which 44 supports, together with the MIS, advanced IIS features as QoS 45 heterogeneity and dynamic QoS changes in IP-ATM networks. 47 Editor's note 49 The postscript version of this memo contains figures that are not 50 included in the text version, so it would be best to use the 51 postscript version. Figures will be converted to ASCII in a future 52 version. 54 Contents 56 1 Introduction 3 57 1.1 Motivation .................................................. 3 58 1.2 Scope ....................................................... 3 59 1.3 Architectural Overview ...................................... 4 60 1.4 Operational Overview ........................................ 4 62 2 Multicast Integration Server 6 63 2.1 Relation of layer-2/layer-3 protocols ....................... 6 64 2.2 Functional description: setup protocol mappings ............ 8 65 2.3 Internetworking ............................................. 11 66 2.4 Example ..................................................... 12 68 3 Service model: Quantized Heterogeneity 14 70 4 Specification 15 71 4.1 Interfaces .................................................. 15 72 4.1.1 QSSI and eRSRR........................................ 15 73 4.1.2 User Interface........................................ 15 74 4.1.3 Traffic Control Interface............................. 16 75 4.1.4 Routing Support Interface............................. 16 76 4.2 MARP Table .................................................. 17 77 4.2.1 MARPTable manipulation................................ 18 79 5 Discussion 18 81 6 Security considerations 21 83 A Glossary 21 84 1 Introduction 86 1.1 Motivation 88 The main problem of existing architectures for the support of IP in 89 ATM networks is that they lack a solution for the integration of IIS 90 with ATM and IP Multicast with ATM. Instead of trying to focus on the 91 two problems separately, a generalized, integrated approach for 92 providing mapping of IP multicast flows to ATM pt-to-mpt connections 93 for both best effort and QoS multicast flows as well as RSVP control 94 traffic should be designed. Main advantages of the integrated 95 approach over existing architectures should include, but not be 96 limited to, increased efficiency, reduced layer-3 processing, 97 reduction of the amount of identical data passing the switch several 98 times, reduced VC consumption, reduced reservation establishment 99 delay, and finally layer-2 vs. layer-3 protocol independence. 101 In this memo we consider such an integrated solution, trying to merge 102 RSVP [1] with the EARTH protocol [2]. We call this solution 103 Multicast Integration Server (MIS). In particular, this memo focuses 104 on the definition of how a layer-3 setup protocol like RSVP can be 105 mapped on a layer-2 protocol as EARTH (setup protocol mappings), in 106 order to design an integrated architecture. This memo bases on [3] 107 for what is related to service mapping issues. 109 We are considering EARTH, not MARS [4], not because of differences in 110 address resolution between the two (the multicast ARP support in 111 EARTH mainly follows perfectly specified parts of that in MARS ), but 112 because of architectural advantages of EARTH - support for source 113 specific and quality of service specific groups, support for 114 multicast shortcuts (bypassing IP routers) over the entire ATM cloud 115 which is in this case considered to be a Multicast LIS (MLIS). 116 Benefits of EARTH are becoming even more clear when one starts 117 considering IP multicast together with the resource reservation over 118 ATM. 120 1.2 Scope 122 The architecture presented in this memo is open (i) to any resource 123 reservation protocol based on receiver initiated reservations and 124 soft state approach, and also (ii) to any IP multicast over ATM 125 address resolution protocol based on Multicast ARP (MARP) server, 126 supporting QoS in its MARP cache, transporting QoS objects to hosts 127 within ATM network, and finally providing shortcuts. 129 However, in order to keep this memo readable and short we base the 130 specification on RSVP and EARTH coexistence within the ATM network. 131 Additional publications referenced below cover more details. The 132 paper [5] describes all design alternatives for the proposed 133 architecture, while this memo concentrates on a chosen one. Further 134 details on the solution presented here could be found in [6], while 135 details on EARTH could be found in [2]. 137 We assume ATM as defined by UNI 3.1. 139 1.3 Architectural Overview 141 The Multicast Integration Server is a specialized node in an ATM 142 cloud (MLIS in EARTH terminology). A MIS is composed by an EARTH 143 server (EARTH-S), for IP class-D to ATM NSAP address resolution and 144 layer-2 QoS management, and of an RSVP server (RSVP-S), for layer-3 145 QoS management. The ATM NSAP address of the MIS is a well-known 146 address to each IP node on MLIS. Each participant to an IP Multicast 147 session within MLIS, either sender or receiver, opens a control VC to 148 the MIS. The control VCs are used to exchange EARTH and RSVP protocol 149 messages between IP nodes and the MIS. 150 On one hand, EARTH protocol messages are exchanged between EARTH 151 clients (IP end-systems) and the EARTH-S on the MIS for dynamically 152 resolving IP Class-D addresses to ATM NSAP addresses. 153 On the other hand, RSVP protocol messages are exchanged between RSVP 154 entities(1) (IP end-systems) and the RSVP-S on the MIS, for 155 distributing information about the requested QoS. 156 In particular, PATH messages are sent from sender(s) to the MIS, 157 where the RSVP-S processes, replicates and forwards them to 158 receivers, while all reservations within the MLIS are sent to the 159 RSVP-S, merged and forwarded to the sender(s). This server-based 160 model contrasts to the usual RSVP distributed processing (see 161 also [7] for a server-based approach to enforce reservations on 162 shared/switched Ethernet). More details about the RSVP server 163 approach followed in this memo can be found later in section 2.1. 164 However RSVP as well as EARTH protocol semantics remain unchanged 165 from their original specifications [1, 2]. The MIS is the only point 166 where the layer-3 protocol (RSVP) is mapped on the layer-2 technology 167 (controlled by EARTH). 169 1.4 Operational Overview 171 In IP over ATM networks, we argue that capacity-based admission 172 control is a layer-2 issue. For ATM that means: trying to setup a 173 new VC or adding a leaf to an existing VC. Success or failure are 174 ________________________________ 175 (1)We call "RSVP entities" the standard implementations of RSVP residing 176 on each IP node of MLIS, excluding the MIS, e.g. the RSVP daemons on UNIX 177 workstations. 179 Figure 1: "Layered" view on QoS setup message distribution and setup 180 protocol mappings in the MIS architecture. 182 beyond the control of the layer-3 setup protocol (RSVP). Therefore 183 the MIS implements a mechanism for remote capacity admission control 184 and actual setup of layer-2 data paths triggered by EARTH. 185 Figure 1 gives a generic overview about the layer-3 and layer-2 186 signalling involved for the setup of a QoS VC. In brief, the sender, 187 using layer-3 signalling (RSVP), informs the MIS (1) about its 188 traffic profile, while the MIS (2) forwards this information to 189 receiver(s). Receivers request resource reservation (3). These 190 requests are mapped from layer-3 to layer-2 within the MIS (4), and 191 forwarded to the sender (5) as layer-2 signalling (EARTH). Sender (6) 192 sets-up point-to-multipoint VC(s) according to the requested 193 reservation, and (7) acknowledge layer-2 reservation(s) to the MIS. 194 Within the MIS (8), layer-2 acknowledgment is mapped to layer-3, and 195 finally (9) layer-3 acknowledgment is forwarded to the sender. 196 The shown interface between RSVP-S and EARTH-S at the MIS is the only 197 point where QoS-relevant information passes from layer-3 to layer-2 198 and back, i.e. the MIS is the only location where layer-3 to layer-2 199 setup protocol mapping and QoS translation take place. This design 200 feature is essential for the protocol independence and avoidance of 201 un-coordinated operation in the MIS architecture. It should also be 202 noted that on failure of a QoS VC setup, no reservation merging takes 203 place and the sender needs not to be notified about the rejected QoS 204 setup. Reservation rejection can already take place at the MIS 205 before passing QoS information to layer-2, e.g. because of policy 206 reasons. 207 The detailed functional description of the mechanism briefly 208 introduced in this section will be presented in section 2.2. 210 Figure 2: Distribution of PATH and RESV messages using MIS: a server- 211 based approach to RSVP. 213 2 Multicast Integration Server 215 2.1 Relation of layer-2/layer-3 protocols 217 The architecture presented in this memo is server-based, and 218 integrates the EARTH protocol [2] (layer-2) and the RSVP protocol [1] 219 (layer-3). 221 The core of the architecture is its server, the Multicast Integration 222 Server. The MIS is composed by an EARTH server (EARTH-S) plus an 223 RSVP server (RSVP-S). The EARTH-S implements the whole set of 224 functionalities foreseen by the EARTH specifications [2]. On the 225 other side, the RSVP-S is a slightly modified implementation of a 226 normal RSVP protocol instance. RSVP-S differs from a standard RSVP 227 implementation for the characteristics described in the following. 229 Server-based approach. All RSVP protocol messages related to MLIS 230 have to pass through RSVP-S, which process and eventually modifies 231 them before redistributing them to end-stations or Mrouters, as 232 shown in figure 2. 234 Processing of PATH messages. RSVP-S collects all PATH messages coming 235 from end-stations or Mrouters on MLIS, processes and replicates 236 them, and redistributes them to all participants in a given RSVP 237 session. Before redistribution, RSVP-S can enforce administrative 238 or security policies on PATH messages. 240 Processing of RESV messages. RSVP-S collects all RESV messages coming 241 from end-stations or Mrouters on MLIS, processes and merges them, 242 and forwards them to the proper sender(s) of the session. Before 243 redistribution, RSVP-S can enforce administrative or security 244 policies on RESV messages. 246 Resource reservation policy enforcement. In order to limit the number 247 of ATM VCs needed to support every multicast session, but 248 nevertheless providing a (limited) support for reservation 249 heterogeneity, the RSVP server approach proposed in this memo 250 provides a mechanism for supporting a limited number of QoS levels 251 (i.e. a limited number of point-to-multipoint VCs) per RSVP 252 session. 253 Given a traffic profile (sender's Tspec) generated by a source, 254 the RSVP-S at the MIS can associate a certain number of QoS levels 255 to such profile, basing on policy information, statistics, or 256 other mechanisms. As the standard PATH message arrives at the 257 MIS, the RSVP-S decides which QoS levels are allowed for the 258 related RSVP session, and appends an ADSPEC object containing one 259 Tspec for each allowed QoS level, before re-distributing the 260 message to receivers (refer to figure 2). 261 In addition, RSVP-S can enforce a particular policy on RESV 262 messages before forwarding them towards senders, e.g. RSVP-S can 263 reject reservations to a given set of receivers, or can refuse 264 reservations of a given type. 265 It is out of the scope of this document (i) the definition of the 266 algorithm for the generation of multiple Tspec from a single given 267 Tspec(2), and (ii) the definition of the format of the ADSPEC 268 object which contains multiple Tspecs. However the structure of 269 such an object could be very simple, as a simple sequence of 270 TOKEN_BUCKET objects [8], one for each allowed QoS level. 272 Protocol mapping of RSVP with EARTH is realized through two local 273 interfaces provided by the EARTH-S: the Quality of Service Support 274 Interface (QSSI) and the earth Routing Support for Resource 275 Reservation (eRSRR) interface. QSSI provides a mean for the RSVP-S 276 to communicate to the EARTH-S the desired QoS for a given (set of) 277 receiver(s) and for EARTH-S to inform the RSVP-S about success or 278 failure of layer-2 admission control (see section 2.2). eRSRR is 279 used by RSVP-S in order to get from EARTH-S information (i.e. 280 IP/NSAP addresses) about receivers participating in a multicast 281 ________________________________ 282 (2)The algorithm could be in principle even a statically defined table 283 mapping a set of allowed Tspecs for each "class" of possible Tspec. 285 session, e.g. when RSVP-S has to replicate and re-distribute PATH 286 messages. QSSI and eRSRR will be described in more detail in 287 section 4.1. 289 EARTH and RSVP protocol messages are exchanged between clients and 290 the MIS by way of point-to-point best-effort ATM VCs (control VCs) 291 between each client and the MIS. 293 Clients of the MIS are end-stations and Mrouters on MLIS that want to 294 participate in an IP over ATM multicast session. Each client must 295 have a standard instance of the RSVP protocol running, plus an EARTH 296 client. The EARTH client implements exactly the features foreseen by 297 the EARTH specifications [2]. The RSVP entity on each client 298 implements all the standard functionalities foreseen by RSVP 299 specifications [1], plus a particular implementation of the Traffic 300 Control Interface (TCI: [1, par. 3.11.2]). This TCI is a 301 quasi-dummy TCI, in the sense that actual resource reservation is 302 performed locally on senders at layer-2 by EARTH, as described later 303 in section 2.2. On end-stations (or Mrouters) no particular 304 communication between the local EARTH client and the local instance 305 of RSVP is needed. 307 Note that MIS operations are concerned only with the management of 308 control messages (EARTH and RSVP). The MIS itself is not a MultiCast 309 Server [4], and has nothing to deal with data distribution, that is 310 performed by the standard ATM infrastructure by means of 311 point-to-multipoint VCs. 313 2.2 Functional description: setup protocol mappings 315 Functionally, the MIS architecture implements the RSVP protocol for 316 layer-3 resource reservation, and EARTH as a layer-2 multicast 317 address resolution protocol with QoS supporting features. In 318 IP-over-ATM networks, capacity-based admission control is a layer-2 319 issue, i.e. capacity-based admission control is the operation 320 concerned to the capability of setting-up a new VC or adding a leaf 321 to an existing VC. Using UNI3.1 this operation takes place at the 322 sender(s). However, since is the MIS, not the sender(s), which 323 implements policy admission-control, our architecture adopts a 324 mechanism for remote capacity admission-control, including conversion 325 of QoS information from layer-3 to layer-2 format and actual setup of 326 layer-2 data paths through EARTH. All the relevant information needed 327 by the admission-control procedure pass from the RSVP-S to the 328 EARTH-S and back through the QSSI, as shown in the following of this 329 section. 331 After the preliminary phase (not completely shown in figure), where: 333 Figure 3: "Layered" view on message distribution within the MLIS. 335 o receivers join the multicast session by registering their NSAP 336 addresses to the EARTH server in the MIS (phase 0); 338 o senders retrieve such information, querying the EARTH-S (with the 339 EARTH_request message); 341 o eventual PATH messages from outside MLIS reach the forwarder(s), 343 operations go on as follows: 345 Phase 1, layer-3: PATH message(s) are forwarded to the MIS. 346 The RSVP daemon in the sender, or re-sender (MRouter), sends PATH 347 messages towards the MIS. 349 Phase 2, layer-3: re-distribution of PATH messages. 350 At the MIS, PATH state is established and an ADSPEC with 351 pre-configured ATM QoS levels is appended. RSVP-S obtains from 352 EARTH-S the addresses of registered receivers through the eRSRR 353 interface, then the PATH message is replicated and forwarded to 354 registered receivers through each point-to-point control VC. 356 Phase 3, layer-3: RESV messages sent to the MIS. 357 Receivers send RESV messages upstream(3) to the MIS. The RSVP-S 358 performs policy admission control and RESV state is established, 359 but no RESV message is yet forwarded upstream (pending admission 360 control). 362 Phase 4, layer-3 to layer-2: notification about requested QoS. 363 The translation of layer-3- to layer-2-QoS takes place in the 364 RSVP-S and the EARTH-S is notified about the QoS requested by 365 ________________________________ 366 (3)upstream - from receiver to sender. 368 receivers through the QSSI. 370 Phase 5, layer-2: notification of QoS to sender(s). 371 Upon receipt of the next request (EARTH_request message) by the 372 sender, a message containing address resolution information 373 (EARTH_multi) including the new requested ATM QoS parameters is 374 sent upstream by the EARTH server at the MIS. 376 Phase 6A, layer-2: remote capacity admission control (on sender(s)). 377 The EARTH client at the sender triggers ATM signalling in order to 378 establish a (leaf to a) QoS VC. It sets the received state and 379 gets a call-back about the success/failure in the establishment of 380 the (leaf to) QoS VC from the ATM layer. Note that, supposing 381 successful admission control, at this point, data might begin to 382 flow on the QoS VC. 384 Phase 6B, layer-2 to Layer-3: remote capacity admission control 385 (on MIS). 386 The success/failure report of the establishment of the (leaf to) 387 QoS VC is sent back to the EARTH server (EARTH_qos_notify). On 388 receipt of the EARTH_qos_notify, the EARTH server at MIS informs 389 the RSVP server (through the QSSI) about success or failure of the 390 layer-2 admission procedure. 392 Phase 7, layer-3: RESV message to sender(s). 393 Supposing successful policy and remote capacity admission 394 procedures, the RESV message is forwarded (with next hop object 395 set to the MIS' address) to the upstream sender/MRouter, and 396 pending admission control is resolved. If other reservations for 397 this sender arrive, they have to be admitted as described above, 398 but only one RESV message is forwarded within the usual RSVP timer 399 intervals (i.e. [session, sender, QoS-level]-merging takes place 400 as defined by the usual RSVP merging procedure). The RSVP server 401 regards the reservation as 'installed' on his 'virtual interface' 402 (vif) towards the receiver, which is actually its control VC to 403 this receiver. Through this vif, RSVP messages are sent and 404 received, however the real reservation takes place at layer-2 in 405 the (re-)sender. 407 Phase 8, layer-3: re-distribution of RESV messages outside MLIS. 408 After receipt of the RESV message at the sender, the usual state 409 consistency check is performed. Capacity admission control is 410 always successful (as it has already been performed at layer-2) 411 and the RESV message is forwarded upstream, if needed, outside 412 MLIS(4). 414 Phase 4/6/8, layer-3: handling of reservation errors. 415 On failure of the policy admission (phase 4) or capacity admission 416 (phase 6) control, a RESV_ERROR message is sent downstream to the 417 requesting receiver only. The sender is never notified that a 418 RESV message of this receiver has arrived. Thus, it is not 419 necessary to convey RSVP messages over two hops to finally be 420 notified about a reservation failure, as it would be when capacity 421 admission control is managed by RSVP at the sender. 422 Some RSVP protocol processing failure results in an RESV_ERROR 423 message sent back to the MIS (phase 8), which in turn leads to 424 deleting the EARTH server QoS state for this sender for all 425 receivers and, after the next EARTH refresh, to teardown of the 426 entire QoS-VC. This occurs only if the PATH state of sender and 427 MIS somehow differ, e.g. when a new PATH and a RESV referring to 428 an older PATH state are concurrently transmitted. 430 2.3 Internetworking 432 Internetworking between each MLIS and the rest of the Internet is 433 concerned with two aspects: the layer-3 setup protocol and the 434 layer-2 multicast address resolution protocol. 436 On one hand, the MIS architecture adopts standard RSVP protocol 437 messages. PATH messages incoming in MLIS are treated by RSVP-S as 438 PATH messages generated by a node on MLIS. Also PATH messages 439 outgoing from MLIS are standard RSVP PATH messages. In this case, 440 additional ADSPEC objects defining allowed (policed) QoS levels for a 441 given session that are used within MLIS are converted by Mrouters to 442 single-Tspec PATH messages before forwarding them outside MLIS. The 443 single-Tspec object could be generated using the highest Tspec of the 444 ones contained in the multi-Tspec PATH message. 446 At the same time, reservation incoming from outside MLIS are bounded 447 by Mrouters to the nearest QoS-level available for that session, 448 before forwarding them to the MIS. RESV messages forwarded by 449 Mrouters outside MLIS are standard RSVP reservation messages. The 450 MIS architecture foresees the use of all the other RSVP protocol 451 messages without modifications. 453 On the other hand, internetworking issues related to the multicast 454 address resolution protocol are efficiently addressed by the EARTH 455 ________________________________ 456 (4)This is needed if the sender is actually a MRouter/re-sender, and thus 457 the session has senders outside MLIS. 459 Figure 4: Internetworking: example. 461 protocol, which specifies interworking with non-ATM clouds via DVMRP 462 and via SCSP in case of multiple EARTH servers in large ATM clouds. 464 2.4 Example 466 In order to describe how the MIS architecture works, in this 467 paragraph a complete and accurate description of an extensive 468 case-of-study is presented. Let's consider the example that is shown 469 in figure 4. For a given multicast session there are two senders and 470 four receivers distributed on different networks. One of the two 471 senders is on the external LAN L1 (we assume that both the LAN L1 and 472 the LAN L2 are Ethernets), while the other one is inside the ATM 473 cloud. The receivers are distributed on all the three networks: R1 474 and R2 are on the ATM cloud, while R3 and R4 are on the external 475 LANs. Multicast router M1 is the ingress router for the flow 476 generated by S1 and the egress router for the flow generated by S2. 477 Multicast router M2 acts like egress router for both these data 478 flows. All the receivers join a determined multicast session, namely 479 MS1, using IGMP, on the LANs, and EARTH inside the MLIS. The 480 inter-operation between these two protocol works according to the 481 EARTH specification [2]. Once all the receivers have joint the 482 multicast session and the senders have solved the multicast IP 483 address in the proper set of NSAP addresses two point-to-multipoint 484 best effort connections are opened inside the ATM cloud: the former 485 originating from the sender S2 to the set and the 486 latter from M1 to . Moreover, M1 forwards the data 487 packets from S to the LAN L1 and M2 forwards all the data packets 488 (both from S and from M1(5)) to the LAN L2. No reservations have 489 been still requested, so the QoS functionalities of the EARTH 490 protocol have not yet been employed. 492 The EARTH table (MARPTable) of the MIS contains the information on 493 all the receivers as best-effort receivers for the multicast session 494 MS1. The senders, following the standard RSVP specifications [1], 495 transmit the RSVP PATH messages to the multicast group. The PATH 496 messages originated at S1 are received by R3 and M1. The receiver R3 497 receives directly the PATH message and it requests the desired 498 reservation by sending a RESV message up to the sender. Since M1 is 499 a Mrouter, it has to forward the PATH message to the ATM end-points 500 that have joint the session and it will ask for a reservation 501 according to the requests of the ATM receiver. According to the 502 model described in the paragraph 2.2, the PATH message is sent to the 503 MIS, where the RSVP server takes care of replicating and properly 504 forwarding the messages to the joined receivers. The egress Mrouter 505 M2 in turn forwards the message to the external LAN L2. The PATH 506 messages originated at S2 are delivered following the same rules; in 507 this case, both M1 and M2 acts like egress routers toward the 508 external LANs. 510 Outside the ATM cloud the reservation of resources takes place as 511 defined in [1, 9]. On the contrary, inside the ATM cloud, the MIS 512 approach is applied. As a consequence, the external receivers (i.e. 513 R3 and R4) send their reservation requests to the corresponding 514 previous hops (respectively M1 and M2) and the reservation takes 515 place between the Mrouter (it acts like a re-sender) and the 516 receiver. On the contrary the reservation inside the MLIS follows 517 the rules that have been presented in the paragraph 2.2. All the ATM 518 receivers send the RESV message to the MIS(6), where both the RSVP 519 tables and the EARTH tables are updated and the pending reservation 520 state is set. The senders in the MLIS will be informed about the 521 pending reservations through the EARTH_multi message and then try to 522 set up the corresponding QoS point-to-multipoint VCs directly to 523 receivers. 524 ________________________________ 525 (5)M1 acts like a sender with respect to the ATM cloud; it is actually a 526 re-sender of the data flow originated at S1. 527 (6)Note that the MIS is actually the previous hop for each ATM receiver; 528 but no reservations take place between the MIS and receiver, as the QoS 529 connections are directly opened from the sender to the receiver. 531 Figure 5: Quantized heterogeneity model. 533 3 Service model: Quantized Heterogeneity 535 Although any service model for IIS over ATM can be efficiently 536 supported by the MIS architecture, in this paper the quantized 537 heterogeneity (QH) model is proposed as the advanced service model 538 offered by the MIS. 539 The QH model represents a compromise between the ``full'' and the 540 ``limited heterogeneity'' models specified in [10], by supporting a 541 limited number of QoS levels, included the best-effort class, for 542 each multicast session. Since each ATM point-to-multipoint VC 543 provides a single QoS level, a limited number of ATM 544 point-to-multipoint VCs per session are allowed. As shown in 545 figure 5, each sender of a multicast session can open one best-effort 546 point-to-multipoint connection and a limited number of QoS 547 point-to-multipoint connections with different QoS levels. As a 548 consequence, each receiver can choose the desired QoS level only 549 among the allowed ones. The best-effort point-to-multipoint 550 connection guarantees that each receiver can always join a multicast 551 group even if no resources for a QoS connection are available, as 552 required in [10]. 553 The QH model does not define any guidelines about how to manage 554 information about the allowed QoS levels in a multicast session. 555 Moreover, it does not pose any constraint about the strategy that 556 must be followed in the allocation of a given data stream on the ATM 557 VCs. 559 The QH model can be efficiently integrated in the MIS architecture 560 using the Multicast Integration Server in order to manage (i.e. to 561 define and distribute) information about the allowed QoS levels, 562 using multi-Tspec PATH messages. In this case, senders may generate 563 single-Tspec PATH messages, while information about the 564 pre-configured allowed QoS levels are appended to outgoing PATH 565 messages by RSVP-S at the MIS, enforcing resource reservation policy 566 on the ATM cloud, as described in section 2.1. 568 4 Specification 570 4.1 Interfaces 572 EARTH, being an ATM protocol supporting IP multicast with embedded 573 support for the QoS settings, should work even without any 574 reservation protocol to enable QoS settings. In any case, it would 575 provide an address resolution for best effort flows, supporting 576 minimal QoS functionality in order to allow setup of QoS VCs by 577 manual configuration (UI) or management protocols. 579 4.1.1 QSSI and eRSRR 581 The EARTH-S in the MIS architecture supports resource reservation 582 with two local interfaces: QSSI (Quality of Service Support 583 Interface) and eRSRR (earth Routing Support for Resource 584 Reservations). These interfaces define specific messages in order to 585 pass information to/from the EARTH-S. 587 The QSSI provides the EARTH_QoS_notify message, used to set the 588 requested QoS information in the EARTH-S. For example, RSVP-S sends 589 this message to the EARTH-S when accepting a reservation. With the 590 same message, sent on QSSI in the opposite direction (from EARTH-S to 591 e.g. RSVP-S), the EARTH-S reports a success or a failure of 592 connection establishment at the sender side. 594 The routing support interface (eRSRR) gives the possibility to get 595 locally from the EARTH-S information about receivers participating in 596 a multicast session (needed e.g. for the RSVP-S) with two messages: 597 EARTH_query, to request an address resolution, and EARTH_response 598 returning to the requester addresses of receivers which joined the 599 group. 601 4.1.2 User Interface 603 The operation of the MIS can be customized through the User Interface 604 (UI). The UI allows the customization of both the EARTH-S and the 605 RSVP-S. 607 Through the User Interface the EARTH-S could be customized to 608 support: 610 o Best effort service only (zero QoS), or also non-zero values for 611 QoS. 613 o Additional interfaces, like QSSI or routing support interface for 614 interworking with RSVP or with other means for resource 615 reservation. 617 o Manual configuration of the MARPTable (with the use of the 618 primitives described in 4.2.1). 620 The RSVP server can be customized with the use of UI for the 621 following topics: 623 o Support for hierarchically encoded traffic flows or other. 625 o QoS-levels Generation Algorithm. 627 o Local policies to handle non-conformant (with regard to traffic 628 description) reservation requests. 630 o Mapping of QoS levels to ATM QoS parameters used by UNI 631 signalling. 633 4.1.3 Traffic Control Interface 635 The generic Traffic Control Interface (TCI) is defined in RSVP 636 specifications [1]. In the MIS architecture, TCI is implemented as 637 follows: 639 o TCI at sender or forwarder (Mrouter): only a 'dummy' admission 640 control has to be present as the VC setup has been already 641 successful (of course local policies could be enforced, however an 642 admission rejection at this points has a high message/latency 643 overhead). 645 o TCI at MIS: a link-layer dependent adaptation module (LLDAL) has 646 to be added (as for any other link-layer) which interfaces to the 647 EARTH server's QoS Support Interface (QSSI). 649 4.1.4 Routing Support Interface 651 The Routing Support for Resource Reservation interface (RSRR) defined 652 in [11], is implemented in the MIS architecture by simply mapping 653 control VC endpoints to RSVP virtual interfaces [1]. 655 4.2 MARP Table 657 The Multicast Address Resolution (Protocol) Table (MARPTable), hold 658 by the EARTH-S and EARTH-clients, stores membership information, 659 including multicast address resolution as well as QoS information. 661 MARPTable codes source-specific and QoS-specific information as shown 662 below. 664 MARPTable = null _ MARPTableEntry [, MARPTableEntry [, ... ]] 665 MARPTableEntry = 666 SourceSpecEntryList = SourceSpecEntry [, SourceSpecEntry [...]] 667 SourceSpecEntry = 668 QoSSpecMembers = QoSMembers [, QoSMembers [...]] 669 QoSMembers = 670 MemberList = null _ RecId [, RecId [...]] 671 RecId: = 673 where: 675 null - represents an empty (e.g. zeroed) data structure[s]; 676 a _ b _ ... - mutually excluding alternatives a, b, ...; 677 a [, a [, ...]] - one or any number of instances of entity of type 678 a; 679 - a set of elements a, b, ... 680 Terms used in the description of MARPTable are: 682 MultIPAddr : Multicast IP Address (i.e IP Class D Address). 684 SourceIPAddr : is either IP Address of a source of multicast traffic 685 or must be zero, when multicast group has only registered 686 receivers but no specified source. 688 QoSLevel : a value representing a quality of service level - to be 689 mapped into a quality of service supported by ATM signalling (QoS 690 levels defined in the table QoSMap). The value zero means best 691 effort service. 693 RecNSAPA, RecIPAdd : NSAP and IP Addresses of a receiver registered 694 with EARTH. 696 4.2.1 MARPTable manipulation 698 The messages defined by the EARTH specification, as well as the ones 699 used in QSSI, eRSRR and UI are mapped in a set of primitives which 700 manipulate the MARPTable: p_join, p_leave, p_get_req, p_get_resp, 701 p_set_qos and p_qos_ack. 702 For example the primitives p_get_req(flag, MultIPAddr, SenderIPAddr [, 703 SourceIPAddr]) and p_get_resp(flag, MultIPAddr, SourceIPAddr, 704 QoSSpecMembers) describe request for the entry for a given group 705 (MultIPAddr) and the corresponding answer. The flag indicates 706 whether all the QoS subgroups should be returned or the best effort 707 only. The answer (p_get_resp) depends on the address of the sender 708 (SenderIPAddr) in the request; i.e. only sender relevant (and only 709 for allowed sender) information will be made available. They are 710 mapped into EARTH protocol messages EARTH_request, EARTH_multi as well 711 as defined for eRSRR EARTH_query and EARTH_response. 712 The primitive concerning QoS, p_set_qos(MultIPAddr, SourceIPAddr, 713 prevQoSLevel, newQoSLevel, RecId) allows to set a QoS level of a 714 receiver. The receiver (RecId) is removed from one QoS specific 715 subgroup (prevQoSLevel) and added to another (newQoSLevel) subgroup. 716 The acknowledgment of this primitive is the primitive 717 p_qos_ack(MultIPAddr, SourceIPAddr, prevQoSLevel, newQoSLevel, RecId), 718 with the same parameter list. 719 The EARTH protocol message EARTH_QoS_notify which arrives from the 720 EARTH client (sender) to acknowledge a success or failure of QoS 721 connection setup is mapped into p_set_qos. 722 The messages provided on the QSSI Interface for the QoS support (used 723 by RSVP or by other means for resource reservations), 724 EARTH_RESV(MultIPAddr,SourceIPAddr, prevQoSLevel, newQoSLevel, RecId) 725 and EARTH_RESV_ACK(MultIPAddr,SourceIPAddr, prevQoSLevel, newQoSLevel, 726 RecId), can be mapped into two of above mentioned primitives: 727 p_set_qos for the messages received on QSSI interface, and p_qos_ack 728 for the message sent on the QSSI interface. 730 5 Discussion 732 We argue that the proposed architecture for the Multicast Integration 733 Server should result in increased efficiency, reduced layer-3 734 processing, reduction of the amount of identical data passing the 735 switch several times, reduced VC consumption, and finally reduced 736 reservation establishment delay, when compared to existing 737 architectures. All these achievements are facilitated by major key 738 design issues collected below from the above text and commented from 739 a more generalized perspective. 741 RSVP server. Besides the issues bulleted in section 2.1 it should be 742 noted that the separation of data and control paths over ATM seems 743 to be inevitable for any IP control protocol supporting multicast 744 due to the unidirectional nature of ATM pt-to-mpt connections. In 745 the MIS architecture the RSVP has additional benefits arising from 746 the fact that it reuses control VCs being maintained by EARTH 747 clients. To distinguish between EARTH and RSVP control messages 748 we propose a simple dispatching module in the MIS (refer to [5]). 750 Why EARTH not MARS. The current IETF ION proposed standard RFC 751 2022 [4] does not support QoS and retains the Classical IP over 752 ATM approach to separate the ATM cloud to a number of logically 753 disjoint subnets (clusters) which must consist of members of a 754 single LIS only [4, chapter 8, page 54]. However, the Classical 755 IP over ATM [12, 13 ] is an IP unicast protocol over ATM. Complete 756 mapping of IP multicast service model to the ATM multicast service 757 model requires bypassing of IP routers (shortcuts) in order to 758 take the advantage of connecting of all the ATM endpoints - 759 receivers (whatever LIS they belong) with a single pt-to-mpt VC. 760 The reduction of VC consumption with MIS (due to shortcuts) in 761 comparison with hypothetical MARS (even if supporting the QoS 762 differentiation) could be estimated as O(Q*N), where Q is the 763 number of QoS levels and N is the number of receivers. 764 Another advantage of EARTH (however referring to implementation 765 only) is that it manages the VC establishment via the UNI 3.x 766 signalling in such a way that the multicast data forwarding could 767 be started from the [re-]sender even on non completely established 768 pt-to-mpt VC. This fact brings additional savings to the 769 join/leave/reservation latency, which could be estimated again as 770 O(Q*N). 772 The MIS architecture is open. The MIS architecture is server-based 773 and layered: it defines specific mapping procedures between RSVP 774 and EARTH. The layer-3 RSVP is a consumer protocol with regard to 775 the address resolution and data handling service provided by the 776 layer-2 EARTH protocol. 777 In MIS scenario only QoS assured IP multicast requires limited and 778 strictly specified collaboration between RSVP and EARTH protocols 779 through the two interfaces (QSSI and eRSRR) supported by the 780 EARTH; IP unicast could be supported by RSVP unicast over ATM 781 which is combined with the legacy atmarp. The future development 782 of MARS based IP/ATM networks can use the QSSI defined in this 783 draft for both VC meshes and multicast servers. 784 On the other hand, any other resource reservation protocol can use 785 EARTH's information in order to get receivers' NSAP addresses for 786 an IP multicast session and to use the QSSI in order to set the 787 desired QoS state for any of these receivers. 788 The MIS is open also for the inclusion of any policy admission 789 control, network management or security modules. 791 Remote capacity admission control. Because of the separation of IP 792 data and IP control paths over ATM the question of regulating 793 arises between the place where the reservations are collected and 794 merged (MIS) and the place where the capacity admission control is 795 applied (sender(s)). This problem is solved via the modification 796 of the original EARTH protocol (the EARTH_qos_notify message was 797 added). Therefore this solution is safe with regard to the 798 "standard" operation of RSVP and provides timely updates for the 799 EARTH data base, which data base could be safely used by other 800 consumer protocols. 802 Pre-configured ATM QoS levels. We believe that the practically 803 feasible number of QoS levels in IP/ATM internets could not be 804 large. Moreover, the QoS levels which could be used by IP/RSVP 805 flows must be supported by the ATM signalling, i.e. these 806 available levels must be known in advance and the mapping from a 807 particular RSVP reservation to the ATM QoS should be done with 808 some robustness in mind. 810 The QH model. Due to the connection oriented nature of ATM the 811 renegotiation of the QoS consumes double resources during the 812 transition phase. The quantized heterogeneity model provides 813 significant savings of resources in this case. Supporting only a 814 (configurable) limited amount of QoS levels (i.e. QoS VC) per 815 session, the MIS architecture (i) prevents wasting of network 816 resources unavoidable with the ``full heterogeneity model'' [10], 817 and (ii) provides more flexibility than the single-QoS ``limited 818 heterogeneity'' model, in full accordance with the 819 receiver-initiated philosophy of RSVP. 821 Scalability. Major scalability issues depend on the MIS-centric 822 organization of the MIS architecture. A single server both for 823 multicast address resolution and for QoS management may become a 824 bottleneck if the ATM cloud size grows. On one hand, some 825 solutions to efficiently face the scalability of the EARTH 826 protocol are proposed in [2]. On the other hand, no scalability 827 matters are due to the RSVP protocol, as the distribution of the 828 RSVP signalling messages is organized on the base of the EARTH 829 control connections. 831 Service mappings. The MIS architecture bases on the ongoing work of 832 the ISSLL IETF working-group for what is related to service 833 mappings issues, in particular on what is specified in [3]. 835 Adaptation protocols. By supporting the quantized heterogeneity 836 model, the MIS is capable of augmenting the native capabilities of 837 the ATM link-layer (single QoS per ATM multicast session), thus 838 providing a set of different QoS levels to each IP Multicast 839 session. 841 Statement of non-applicability. Currently, due to the inherent 842 limitations of ATM signalling (no multipoint-to-point capability), 843 only Fixed-Filter style reservations (explicit sender selection, 844 distinct reservations) are supported. However a mapping scheme 845 within the MIS, where a Shared-Explicit or Wildcard-Filter 846 reservation is mapped to several separate layer-2 reservations 847 (i.e. QoS-specific entries in the EARTH server's MARP table) can 848 be realized. 850 Implementation. Two independent implementations of the MIS 851 architecture are being developed at CEFRIEL/Politecnico di Milano 852 and GMD-FOKUS. 854 6 Security considerations 856 Security and policy mechanisms can be enforced for an entire MLIS, at 857 the MIS. However, specific security considerations should be 858 addressed in a separate document dealing with security in IP over ATM 859 networks, especially with the presence of shortcuts. This memo does 860 not imply any new security issues if compared with RSVP over ATM and 861 IP Multicast over ATM, however it amplifies security concerns, 862 through bypassing inter LIS routers and possibly firewalls. 864 This draft recognizes that MIS (EARTH server) could be configured to 865 allow or not to obtain the NSAP address of specific 866 endpoints/LISs/etc. Security management in EARTH case will mean that 867 it's commonly agreed security management between all LISs delegated 868 to a future security entity within the MIS architecture, e.g. entity 869 managing security of shortcuts. 871 A Glossary 873 In this memo the following terms are used with the following 874 meanings: 876 MLIS: a [static] association of all IP multicast gateways (Mrouters) 877 and [dynamic] association of all ATM endpoints/IP hosts willing to 878 participate in any IP multicast session over an ATM cloud. 880 Shortcut: an ATM shortcut is a direct ATM connection between a sender 881 and a (set of) receiver(s) in an MLIS, eventually bypassing 882 inter-unicast-LIS routers. 884 MIS: the acronym ``MIS'' is used in general alone to indicate the 885 server of the architecture proposed in this memo. The 886 architecture itself is indicated as ``MIS architecture''. 888 Mrouter: this term is used to indicate border multicast routers 889 which provide layer-3 multicast connectivity between an ATM cloud 890 and the rest of the internet. 892 Forwarder: a synonym for Mrouter. 894 Re-sender: another synonym for Mrouter. 896 MARP: Multicast Address Resolution Protocol. 898 IIS: Internet Integrated Services architecture [9]. 900 EARTH-S: the server of the EAsy multicast Routing THrough ATM 901 clouds protocol. 903 RSVP-S: the server of the RSVP protocol defined and used in the MIS 904 architecture. 906 QSSI: Quality of Service Support Interface, defined in EARTH 907 specifications [2], and recalled in this memo in section 4.1. 909 eRSRR: extended Routing Support for Resource Reservation Interface, 910 defined in section 4.1. 912 TCI: Traffic Control Interface, defined in [1]. 914 LLDAL: Link-Layer Dependent Adaptation Module, used in section 4.1. 916 References 918 [1] L. Zhang, R. Braden, S. Berson, S. Herzog, and S. Jamin. Resource 919 ReSerVation Protocol (RSVP) - Version 1 Functional Specification. 920 RFC2205, IETF, September 1997. 922 [2] M. Smirnov. Scalable and Efficient Multiprotocol IP Multicast over 923 ATM. In Proceedings of SPIE VV'97 - Broadband Networking 924 Technologies, Dallas - Texas, Nov 1997. SPIE. 926 [3] M. Garret and M. Borden. Interoperation of Controlled-Load and 927 Guaranteed Services with ATM. Work in progress - Internet Draft, 928 IETF, July 1997. draft-ietf-issll-atm-mapping-03.txt. 930 [4] G. Armitage. Support for Multicast over UNI 3.0/3.1 based ATM 931 Networks. RFC2022, IETF, November 1996. 933 [5] A. Corghi, L. Salgarelli, H. Sanneck, M. Smirnov, and D. Witaszek. 934 Design Experiences with IP Multicast Integrated Services over ATM. 935 Unpublished, July 1997. Available at 936 ftp://ftp.fokus.gmd.de/pub/step/papers/mis-alt.ps.gz. 938 [6] L. Salgarelli, A. Corghi, H. Sanneck, and D. Witaszek. Supporting 939 IP Multicast Integrated Services in ATM Networks. In Proceedings 940 of SPIE VV'97 - Broadband Networking Technologies, Dallas - Texas, 941 Nov 1997. SPIE. 943 [7] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, and R. Kennedy. SBM 944 (Subnet Bandwidth Manager): A Proposal for Admission Control over 945 Ethernet. Work in progress - Internet Draft, IETF, February 1997. 946 draft-yavatkar-sbm-ethernet-03.txt. 948 [8] J. Wroclawski. The Use of RSVP with IETF Integrated Services. 949 RFC2210, IETF, September 1997. 951 [9] D. Clark, R. Braden, and S. Shenker. Integrated Services in the 952 Internet Architecture: an Overview. RFC1633, IETF, June 1994. 954 [10] S. Berson and L. Berger. IP Integrated Services with RSVP over 955 ATM. Work in progress - Internet Draft, IETF, March 1997. 956 draft-ietf-issll-atm-support-03.txt, .ps. 958 [11] D. Zappala. RSRR: A routing interface for RSVP. Internet Draft, 959 IETF, November 1996. draft-ietf-rsvp-routing-01.ps. 961 [12] M. Laubach. Classical IP and ARP over ATM. RFC1577, IETF, January 962 1994. 964 [13] M. Laubach and J. Halpern. Classical IP and ARP over ATM. Work in 965 progress - Internet Draft, IETF, October 1997. 966 draft-ietf-ion-ipatm-classic2-03.txt. 968 Authors' Addresses 970 L. Salgarelli and A. Corghi 971 CEFRIEL/Politecnico di Milano 972 via Fucini 2, I-20133 Milano (Italy) 973 Voice: +39-2-23.954.1 974 Fax: +39-2-23.954.254 975 e-mail: -salga, corghi"@cefriel.it 977 M. Smirnow, H. Sanneck and D. Witaszek 978 GMD-FOKUS 979 Kaiserin-Augusta-Allee 31, D-10589 Berlin (Germany) 980 Voice: +49-30-34.637.000 981 Fax: +49-30-34.638.000 982 e-mail: -smirnov, sanneck, witaszek"@fokus.gmd.de