idnits 2.17.1 draft-ietf-rserpool-arch-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-04-26) 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: ---------------------------------------------------------------------------- ** 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? == 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 a Security Considerations section. ** 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. 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.) -- The document date (April 2, 2001) is 8425 days in the past. Is this intentional? 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: 'RFC793' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC2608' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'RFC2719' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 572, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 2719 ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 INTERNET DRAFT Siemens AG 4 Q. Xie 5 Motorola 6 R. Stewart 7 M. Shore 8 Cisco 9 L. Ong 10 Point Reyes Networks 11 J. Loughney 12 M. Stillman 13 Nokia 14 Expires October 2, 2001 April 2, 2001 16 Architecture for Reliable Server Pooling 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with all 22 provisions of Section 10 of [RFC2026]. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other groups 26 may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 The goal is to develop an architecture and protocols for the management 42 and operation of server pools supporting highly reliable applications, 43 and for client access mechanisms to a server pool. 45 A proposed architecture is presented and illustrated by examples. 47 1. Introduction 49 1.1. Overview 51 The Internet is always on. Many users expect services to be always 52 available; many business depend upon connectivity 24 hours a day, 7 days 53 a week, 365 days a year. In order to fulfill this, many proprietary 54 solutions and operating system dependent solutions have been developed 55 to provide highly reliable and highly available servers. 57 This document defines a proposed architecture, which can be used to 58 provide highly available services. The way this is achieved is by using 59 servers grouped into pools. Therefore, if a client wants to access a 60 server pool, it will be able to use any of the servers in the server 61 pool taking into account the server pool policy. 63 Highly available services also put the same high reliability 64 requirements upon the transport layer protocol beneath RSerPool - it 65 must provide strong survivability in the face of network component 66 failures. 68 Supporting real time applications is another main focus of RSerPool 69 which leads to requirements on the processing time needed. 71 Scalability is another important requirement. 73 1.2. Terminology 75 This document uses the following terms: 77 Operation scope: 78 The part of the network visible to pool users by a specific 79 instance of the reliable server pooling protocols. 81 Pool (or server pool): 82 A collection of servers providing the same application 83 functionality. 85 Pool handle (or pool name): 86 A logical pointer to a pool. Each server pool will be 87 identifiable in the operation scope of the system by a unique 88 pool handle or "name". 90 Pool element: 91 A server entity having registered to a pool. 93 Pool user: 94 A server pool user. 96 Pool element handle (or endpoint handle): 97 A logical pointer to a particular pool element in a pool, 98 consisting of the name of the pool and a destination transport 99 address of the pool element. 101 Name space: 102 A cohesive structure of pool names and relations that may be 103 queried by an internal or external agent. 105 Name server: 106 Entity which the responsible for managing and maintaining the 107 name space within the RSerPool operation scope. 109 1.3. Abbreviations 111 ASAP: Aggregate Server Access Protocol 113 ENRP: Endpoint Name Resolution Protocol 115 PE: Pool element 117 PU: Pool user 119 SCTP: Stream Control Transmission Protocol 121 TCP: Transmission Control Protocol 123 2. Reliable Server Pooling Architecture 125 In this section, we discuss what a typical reliable server pool 126 architecture may look like. 128 2.1. Common RSerPool Functional Areas 130 The following functional areas or components may likely be present in a 131 typical RSerPool system architecture: 133 - A number of logical "Server Pools" to provide distinct 134 application services. 136 Each of those server pools will likely be composed of some 137 number of "Pool Elements (PEs)" - which are application 138 programs running on distributed host machines, collectively 139 providing the desired application services via, for example, 140 data sharing and/or load sharing. 142 Each server pool will be identifiable in the operation scope 143 of the system by a unique "name". 145 - Some "Pool Users (PUs)" which are the users of the application 146 services provided by the various server pools. 148 - PEs may or may not be PU, depending on whether or not they 149 wish to access other pools in the operation scope of the 150 system. 152 - A "Name Space" which contains all the defined names within the 153 operation scope of the system. 155 - One or more "Name Servers" which carry out various maintenance 156 functions (e.g., registration and de-registration, integrity 157 checking) for the "Name Space". 159 2.2. RSerPool Protocol Overview 161 The RSerPool requested features can be obtained with the help of two 162 protocols: ENRP (Endpoint Name Resolution Protocol) and ASAP (Aggregate 163 Server Access Protocol). 165 ENRP is designed to provide a fully distributed fault-tolerant real-time 166 translation service that maps a name to a set of transport addresses 167 pointing to a specific group of networked communication endpoints 168 registered under that name. ENRP employs a client-server model with 169 which an ENRP server will respond to the name translation service 170 requests from endpoint clients running on the same host or running on 171 different hosts. 173 ASAP in conjunction with ENRP provides a fault tolerant data transfer 174 mechanism over IP networks. ASAP uses a name-based addressing model 175 which isolates a logical communication endpoint from its IP address(es), 176 thus effectively eliminating the binding between the communication 177 endpoint and its physical IP address(es) which normally constitutes a 178 single point of failure. 180 In addition, ASAP defines each logical communication destination as a 181 server pool, providing full transparent support for server-pooling and 182 load sharing. It also allows dynamic system scalability - members of a 183 server pool can be added or removed at any time without interrupting the 184 service. 186 The fault tolerant server pooling is gained by combining two parts, 187 namely ASAP and ENRP. ASAP provides the user interface for name to 188 address translation, load sharing management, and fault management. ENRP 189 defines the fault tolerant name translation service. The protocol stack 190 used is described by the following figure 1. 192 ********* *********** 193 * PE/PU * *ENRP Srvr* 194 ********* *********** 196 +-------+ +----+----+ 197 To other <-->| ASAP |<------>|ASAP|ENRP| <---To Peer ENRP 198 PE/PU +-------+ +----+----+ Name Servers 199 | SCTP | | SCTP | 200 +-------+ +---------+ 201 | IP | | IP | 202 +-------+ +---------+ 203 Figure 1: Typical protocol stack 205 2.3. Typical Interactions between RSerPool Components 207 The following drawing shows the typical RSerPool components and their 208 possible interactions with each other: 210 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 211 ~ operation scope ~ 212 ~ ......................... ......................... ~ 213 ~ . Server Pool 1 . . Server Pool 2 . ~ 214 ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ 215 ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ 216 ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ 217 ~ . ^ ^ . . ^ ^ . | ~ 218 ~ . | (a) | . . | | . | ~ 219 ~ . +----------+ | . . | | . | ~ 220 ~ . +-------+ | | . . | | . | ~ 221 ~ . |PE(1,B)|<---+ | | . . | | . | ~ 222 ~ . +-------+ | | | . . | | . | ~ 223 ~ . ^ | | | . . | | . | ~ 224 ~ .......|........|.|.|.... .......|.........|....... | ~ 225 ~ | | | | | | | ~ 226 ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ 227 ~ | | | | | | | ~ 228 ~ | v v v v v | ~ 229 ~ | +++++++++++++++ (e) +++++++++++++++ | ~ 230 ~ | + ENRP-Server +<---------->+ ENRP-Server + | ~ 231 ~ | +++++++++++++++ +++++++++++++++ | ~ 232 ~ v ^ ^ | ~ 233 ~ ********* | | | ~ 234 ~ * PU(A) *<-------+ (b)| | ~ 235 ~ ********* (b) | | ~ 236 ~ v | ~ 237 ~ ::::::::::::::::: (f) ***************** | ~ 238 ~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ 239 ~ ::::::::::::::::: ***************** ~ 240 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 241 Figure 2: RSerPool components and their possible interactions. 243 In figure 2 we can identify the following possible interactions: 245 (a) Server Pool Elements <-> ENRP Server: (ASAP) 247 Each PE in a pool uses ASAP to register or de-register itself 248 as well as to exchange other auxiliary information with the 249 ENRP Server. The ENRP Server also uses ASAP to monitor the 250 operational status of each PE in a pool. 252 (b) PU <-> ENRP Server: (ASAP) 254 A PU normally uses ASAP to request the ENRP Server for a name- 255 to-address translation service before the PU can send user 256 messages addressed to a server pool by the pool's name. 258 (c) PU <-> PE: (ASAP) 260 ASAP can be used to exchange some auxiliary information of the 261 two parties before they engage in user data transfer. 263 (d) Server Pool <-> Server Pool: (ASAP) 265 A PE in a server pool can become a PU to another pool when the 266 PE tries to initiate communication with the other pool. In 267 such a case, the interactions described in B) and C) above 268 will apply. 270 (e) ENRP Server <-> ENRP Server: (ENRP) 272 ENRP can be used to fulfill various Name Space operation, 273 administration, and maintenance (OAM) functions. 275 (f) Other Clients <-> Proxy/Gateway: standard protocols 277 The proxy/gateway enables clients ("other clients"), which are 278 not RSerPool aware, to access services provided by an RSerPool 279 based server pool. It should be noted that these 280 proxies/gateways may become a single point of failure. 282 3. Examples 284 In this section the basic concepts of ENRP and ASAP will be described. 285 First an RSerPool aware FTP server is considered. The interaction with 286 an RSerPool aware and an non-aware client is given. Finally, a telephony 287 example is considered. 289 3.1. Two File Transfer Examples 291 In this section we present two separate file transfer examples using 292 ENRP and ASAP. We present two separate examples demonstrating an 293 ENRP/ASAP aware client and a client that is using a Proxy or Gateway to 294 perform the file transfer. In this example we will use a FTP [RFC959] 295 model with some modifications. The first example (the RSerPool aware 296 one) will modify FTP concepts so that the file transfer takes place over 297 SCTP. In the second example we will use TCP between the unaware client 298 and the Proxy. The Proxy itself will use the modified FTP with RSerPool 299 as illustrated in the first example. 301 Please note that in the example we do NOT follow FTP [RFC959] precisely 302 but use FTP-like concepts and attempt to adhere to the basic FTP model. 303 These examples use FTP for illustrative purposes, FTP was chosen since 304 many of the basic concept are well known and should be familiar to 305 readers. 307 3.1.1. The RSerPool Aware Client 309 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 310 ~ operation scope ~ 311 ~ ......................... ~ 312 ~ . "File Transfer Pool" . ~ 313 ~ . +-------+ +-------+ . ~ 314 ~ +-> |PE(1,A)| |PE(1,C)| . ~ 315 ~ |. +-------+ +-------+ . ~ 316 ~ |. ^ ^ . ~ 317 ~ |. +----------+ | . ~ 318 ~ |. +-------+ | | . ~ 319 ~ |. |PE(1,B)|<---+ | | . ~ 320 ~ |. +-------+ | | | . ~ 321 ~ |. ^ | | | . ~ 322 ~ |.......|........|.|.|.... ~ 323 ~ | ASAP | ASAP| | |ASAP ~ 324 ~ |(d) |(c) | | | ~ 325 ~ | v v v v ~ 326 ~ | ********* +++++++++++++++ ~ 327 ~ + ->* PU(X) * + ENRP-Server + ~ 328 ~ ********* +++++++++++++++ ~ 329 ~ ^ ASAP ^ ~ 330 ~ | <-(b) | ~ 331 ~ +--------------+ ~ 332 ~ (a)-> ~ 333 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 334 Figure 3: Architecture for RSerPool aware client. 336 To effect a file transfer the following steps would take place. 338 (1) The application in PU(X) would send a login request. The 339 PU(X)'s ASAP layer would send an ASAP request to its ENRP 340 server to request the list of pool elements (using (a)). The 341 pool handle to identify the pool would be "File Transfer 342 Pool". The ASAP layer queues the login request. 344 (2) The ENRP server would return a list of the three PEs PE(1,A), 345 PE(1,B) and PE(1,C) to the ASAP layer in PU(X) (using (b)). 347 (3) The ASAP layer selects one of the PEs, for example PE(1,B). It 348 transmitts the login request, the other FTP control data 349 finally starts the transmission of the requested files (using 350 (c)). For this the multiple stream feature of SCTP could be 351 used. 353 (4) If during the file transfer conversation, PE(1,B) fails, 354 assuming the PE's were sharing state of file transfer, a fail- 355 over to PE(1,A) could be initiated. PE(1,A) would continue the 356 transfer until complete (see (d)). In parallel a request from 357 PE(1,A) would be made to ENRP to request a cache update for 358 the server pool "File Transfer Pool" and a report would also 359 be made that PE(1,B) is non-responsive (this would cause 360 appropriate audits that may remove PE(1,B) from the pool if 361 the ENRP servers had not already detected the failure) (using 362 (a)). 364 3.1.2. The RSerPool Unaware Client 366 In this example we investigate the use of a Proxy server assuming the 367 same set of scenario as illustrated above. 369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 370 ~ operation scope ~ 371 ~ ......................... ~ 372 ~ . "File Transfer Pool" . ~ 373 ~ . +-------+ +-------+ . ~ 374 ~ . |PE(1,A)| |PE(1,C)| . ~ 375 ~ . +-------+ +-------+ . ~ 376 ~ . ^ ^ . ~ 377 ~ . +----------+ | . ~ 378 ~ . +-------+ | | . ~ 379 ~ . |PE(1,B)|<---+ | | . ~ 380 ~ . +-------+ | | | . ~ 381 ~ .......^........|.|.|.... ~ 382 ~ | | | | ~ 383 ~ | ASAP| | |ASAP ~ 384 ~ | | | | ~ 385 ~ | v v v ~ 386 ~ | +++++++++++++++ +++++++++++++++ ~ 387 ~ | + ENRP-Server +<--ENRP-->+ ENRP-Server + ~ 388 ~ | +++++++++++++++ +++++++++++++++ ~ 389 ~ | ASAP ^ ~ 390 ~ | ASAP (c) (b) | ^ ~ 391 ~ +---------------------------------+ | | | ~ 392 ~ | v | (a) ~ 393 ~ v v ~ 394 ~ ::::::::::::::::: (e)-> ***************** ~ 395 ~ : FTP Client :<------------->* Proxy/Gateway * ~ 396 ~ ::::::::::::::::: (f) ***************** ~ 397 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 398 Figure 4: Architecture for RserPool unaware client. 400 In this example the steps will occur: 402 (1) The FTP client and the Proxy/Gateway are using the TCP-based 403 ftp protocol. The client sends the login request to the proxy 404 (using (e)) 406 (2) The proxy behaves like a client and performs the actions 407 described under (1), (2) and (3) of the above description 408 (using (a), (b) and (c)). 410 (3) The ftp communication continues and will be translated by the 411 proxy into the RSerPool aware dialect. This interworking uses 412 (f) and (c). 414 Note that in this example high availability is maintained between the 415 Proxy and the server pool but a single point of failure exists between 416 the FTP client and the Proxy, i.e. the command TCP connection and its 417 one IP address it is using for commands. 419 3.2. Telephony Signaling Example 421 This example shows the use of ASAP/RSerPool to support server pooling 422 for high availability of a telephony application such as a Voice over IP 423 Gateway Controller (GWC) and Gatekeeper services (GK). 425 In this example, we show two different scenarios of deploying these 426 services using RSerPool in order to illustrate the flexibility of the 427 RSerPool architecture. 429 3.2.1. Decomposed GWC and GK Scenario 431 In this scenario, both GWC and GK services are deployed as separate 432 pools with some number of PEs, as shown in the following diagram. Each 433 of the pools will register their unique pool handle (i.e. name) with the 434 ENRP Server. We also assume that there are a Signaling Gateway (SG) and 435 a Media Gateway (MG) present and both are RSerPool aware. 437 ................... 438 . Gateway . 439 . Controller Pool . 440 ................. . +-------+ . 441 . Gatekeeper . . |PE(2,A)| . 442 . Pool . . +-------+ . 443 . +-------+ . . +-------+ . 444 . |PE(1,A)| . . |PE(2,B)| . 445 . +-------+ . . +-------+ . 446 . +-------+ . (d) . +-------+ . 447 . |PE(1,B)|<------------>|PE(2,C)|<-------------+ 448 . +-------+ . . +-------+ . | 449 ................. ........^.......... | 450 | | 451 (c)| (e)| 452 | v 453 +++++++++++++++ ********* ***************** 454 + ENRP-Server + * SG(X) * * Media Gateway * 455 +++++++++++++++ ********* ***************** 456 ^ ^ 457 | | 458 | <-(a) | 459 +-------------------+ 460 (b)-> 462 Figure 5: Deployment of Decomposed GWC and GK. 464 As shown in the figure 5, the following sequence takes place: 466 (1) the Signaling Gateway (SG) receives an incoming signaling 467 message to be forwarded to the GWC. SG(X)'s ASAP layer would 468 send an ASAP request to its "local" ENRP server to request the 469 list of pool elements (PE's) of GWC (using (a)). The key used 470 for this query is the pool handle of the GWC. The ASAP layer 471 queues the data to be sent in local buffers until the ENRP 472 server responds. 474 (2) the ENRP server would return a list of the three PE's A, B and 475 C to the ASAP layer in SG(X) together with information to be 476 used for load-sharing traffic across the gateway controller 477 pool (using (b)). 479 (3) the ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 480 send the signaling message to it (using (c)). The selection is 481 based on the load sharing information of the gateway 482 controller pool. 484 (4) to progress the call, PE(2,C) finds that it needs to talk to 485 the Gatekeeper. Assuming it has already had gatekeeper pool's 486 information in its local cache (e.g., obtained and stored from 487 recent query to ENRP Server), PE(2,C) selects PE(1,B) and 488 sends the call control message to it (using (d)). 490 We assume PE(1,B) responds back to PE(2,C) and authorizes the 491 call to proceed. 493 (5) PE(2,C) issues media control commands to the Media Gateway 494 (using (e)). 496 RSerPool will provide service robustness to the system if some failure 497 would occur in the system. 499 For instance, if PE(1, B) in the Gatekeeper Pool crashed after receiving 500 the call control message from PE(2, C) in step (d) above, what most 501 likely will happen is that, due to the absence of a reply from the 502 Gatekeeper, a timer expiration event will trigger the call state machine 503 within PE(2, C) to resend the control message. The ASAP layer at PE(2, 504 C) will then notice the failure of PE(1, B) through (likely) the 505 endpoint unreachability detection by the transport protocol beneath ASAP 506 and automatically deliver the re-sent call control message to the 507 alternate GK pool member PE(1, A). With appropriate intra-pool call 508 state sharing support, PE(1, A) will be able to correctly handle the 509 call and reply to PE(2, C) and hence progress the call. 511 3.2.2. Collocated GWC and GK Scenario 513 In this scenario, the GWC and GK services are collocated (e.g., they are 514 implemented as a single process). In such a case, one can form a pool 515 that provides both GWC and GK services as shown in figure 6 below. 517 ........................................ 518 . Gateway Controller/Gatekeeper Pool . 519 . +-------+ . 520 . |PE(3,A)| . 521 . +-------+ . 522 . +-------+ . 523 . |PE(3,C)|<---------------------------+ 524 . +-------+ . | 525 . +-------+ ^ . | 526 . |PE(3,B)| | . | 527 . +-------+ | . | 528 ................|....................... | 529 | | 530 +-------------+ | 531 | | 532 (c)| (e)| 533 v v 534 +++++++++++++++ ********* ***************** 535 + ENRP-Server + * SG(X) * * Media Gateway * 536 +++++++++++++++ ********* ***************** 537 ^ ^ 538 | | 539 | <-(a) | 540 +-------------------+ 541 (b)-> 543 Figure 6: Deployment of Collocated GWC and GK. 545 The same sequence as described in 5.2.1 takes place, except that step 546 (4) now becomes internal to the PE(3,C) (again, we assume Server C is 547 selected by SG). 549 4. Acknowledgements 551 The authors would like to thank Bernard Aboba, Matt Holdrege, 552 Christopher Ross, Werner Vogels and many others for their invaluable 553 comments and suggestions. 555 5. References 557 [RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793, 558 September 1981. 560 [RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)", 561 RFC 959, October 1985. 563 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 564 RFC 2026, October 1996. 566 [RFC2608] E. Guttman et al., "Service Location Protocol, Version 2", 567 RFC 2608, June 1999. 569 [RFC2719] L. Ong et al., "Framework Architecture for Signaling 570 Transport", RFC 2719, October 1999. 572 [RFC2960] R. R. Stewart et al., "Stream Control Transmission 573 Protocol", RFC 2960, November 2000. 575 6. Authors' Addresses 577 Michael Tuexen Tel.: +49 89 722 47210 578 Siemens AG e-mail: Michael.Tuexen@icn.siemens.de 579 ICN WN CS SE 51 580 D-81359 Munich 581 Germany 583 Qiaobing Xie Tel.: +1 847 632 3028 584 Motorola, Inc. e-mail: qxie1@email.mot.com 585 1501 W. Shure Drive, #2309 586 Arlington Heights, Il 60004 587 USA 589 Randall Stewart Tel.: +1 815 477 2127 590 Cisco Systems, Inc. e-mail: rrs@cisco.com 591 24 Burning Bush Trail 592 Crystal Lake, Il 60012 593 USA 595 Melinda Shore Tel.: +1 607 272 7512 596 Cisco Systems, Inc. e-mail: mshore@cisco.com 597 809 Hayts Rd 598 Ithaca, NY 14850 599 USA 601 Lyndon Ong Tel.: +1 408 321 8237 602 Point Reyes Networks e-mail: long@pointreyesnet.com 603 1991 Concourse Drive 604 San Jose, CA 605 USA 606 John Loughney Tel.: 607 Nokia Research Center e-mail: john.loughney@nokia.com 608 PO Box 407 609 FIN-00045 Nokia Group 610 Finland 612 Maureen Stillman Tel.: +1 607 273 0724 62 613 Nokia e-mail: maureen.stillman@nokia.com 614 127 W. State Street 615 Ithaca, NY 14850 616 USA 618 This Internet Draft expires October 2, 2001.