idnits 2.17.1 draft-ietf-forces-tcptml-01.txt: -(269): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1067): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1109): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1131): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1192. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. 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? == There are 31 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 21) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 49 instances of too long lines in the document, the longest one being 21 characters in excess of 72. ** The abstract seems to contain references ([3], [7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1052: '... the CEs and FEs MUST be established b...' RFC 2119 keyword, line 1062: '...points that implement TLS MUST perform...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 128 has weird spacing: '... define both ...' == Line 133 has weird spacing: '...ultiple trans...' == Line 135 has weird spacing: '... will take ...' == Line 434 has weird spacing: '... in chann...' == Line 435 has weird spacing: '... in initA...' == (19 more instances...) ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [2], but that reference does not seem to mention RFC 2119 either. -- 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 (July 2005) is 6860 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) -- Looks like a reference, but probably isn't: '2' on line 47 -- Looks like a reference, but probably isn't: '3' on line 298 -- Looks like a reference, but probably isn't: '7' on line 299 -- Looks like a reference, but probably isn't: '5' on line 99 == Missing Reference: 'RFC3746' is mentioned on line 104, but not defined -- Looks like a reference, but probably isn't: '4' on line 141 == Missing Reference: 'Reqs' is mentioned on line 307, but not defined -- Looks like a reference, but probably isn't: '11' on line 315 -- Looks like a reference, but probably isn't: '8' on line 1059 == Missing Reference: 'ICCCN 2004' is mentioned on line 1145, but not defined == Unused Reference: 'SoftCOM 2004' is defined on line 1142, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SoftCOM 2004' Summary: 13 errors (**), 0 flaws (~~), 14 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Hormuzd Khosravi 3 Internet Draft Shuchi Chawla 4 Document: draft-ietf-forces-tcptml-01.txt Intel Corp. 5 Expires: January 2006 Furquan Ansari 6 Working Group: ForCES Lucent Tech. 7 Jon Maloy 8 Ericsson 10 July 2005 12 TCP/IP based TML (Transport Mapping Layer) for ForCES protocol 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as ``work in 30 progress.'' 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in [2]. 48 Abstract 50 This document defines the TCP/IP based TML (Transport Mapping Layer) 51 for the ForCES protocol. It explains the rationale for choosing the 52 transport protocols and also describes how this TML addresses all 53 the requirements described in the Forces [3] requirements and ForCES 54 protocol [7] document. 56 Table of Contents 58 1. Definitions.....................................................2 59 2. Introduction....................................................3 60 3. Protocol Framework Overview.....................................3 61 3.1.1. The PL layer................................................5 62 3.1.2. The TML layer...............................................5 63 4. TCP/IP TML Overview.............................................5 64 4.1. Rationale for using TCP/IP....................................5 65 4.2. Separate Control and Data channels............................6 66 4.3. Reliability...................................................7 67 4.4. Congestion Control............................................8 68 4.5. Security......................................................8 69 4.6. Addressing....................................................8 70 4.7. Prioritization................................................8 71 4.8. HA Decisions..................................................8 72 4.9. Encapsulations Used...........................................9 73 5. TML Messaging...................................................9 74 6. TML Interface to Upper layer Protocol...........................9 75 6.1. TML Service Interface........................................10 76 6.1.1. TML Initialize.............................................10 77 6.1.2. TML Channel Open...........................................11 78 6.1.3. TML Channel Close..........................................12 79 6.1.4. TML Channel Write..........................................13 80 6.1.5. TML Channel Read...........................................14 81 6.1.6. TML Multicast Group Join...................................15 82 6.1.7. TML Multicast Group Leave..................................16 83 6.2. Protocol Initialization and Shutdown Model...................17 84 6.2.1. Protocol Initialization....................................17 85 6.2.2. Protocol Shutdown..........................................19 86 6.3. Multicast Model..............................................20 87 6.4. Broadcast Model..............................................22 88 7. Security Considerations........................................22 89 7.1. TLS Usage for this TML.......................................23 90 8. IANA Considerations............................................23 91 9. Manageability..................................................23 92 10. References....................................................23 93 10.1. Normative References........................................23 94 10.2. Informative References......................................24 95 11. Acknowledgments...............................................25 96 12. Authors' Addresses............................................25 98 1. Definitions 99 The following definitions are taken from [3], [5] 101 ForCES Protocol - While there may be multiple protocols used within 102 the overall ForCES architecture, the term "ForCES protocol" refers 103 only to the protocol used at the Fp reference point in the ForCES 104 Framework in RFC3746 [RFC3746]. This protocol does not apply to 105 CE-to-CE communication, FE-to-FE communication, or to communication 106 between FE and CE managers. Basically, the ForCES protocol works in 107 a master-slave mode in which FEs are slaves and CEs are masters. 109 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 110 architecture that defines the ForCES protocol messages, the protocol 111 state transfer scheme, as well as the ForCES protocol architecture 112 itself (including requirements of ForCES TML (see below)). 113 Specifications of ForCES PL are defined by this document. 115 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 116 ForCES protocol architecture that specifically addresses the 117 protocol message transportation issues, such as how the protocol 118 messages are mapped to different transport media (like TCP, IP, ATM, 119 Ethernet, etc), and how to achieve and implement reliability, 120 multicast, ordering, etc. This document defines a TCP/IP based 121 ForCES TML. 123 2. Introduction 125 The ForCES (Forwarding and Control Element Separation) working group 126 in the IETF is defining the architecture and protocol for separation 127 of control and forwarding elements in network elements such as 128 routers. [3], [4] define both architectural and protocol 129 requirements for the communication between CE and FE. The ForCES 130 protocol layer [7] describes the protocol specification. It is 131 envisioned that the ForCES protocol would be independent of the 132 interconnect technology between the CE and FE and can run over 133 multiple transport technologies and protocol. Thus a Transport 134 Mapping Layer (TML) has been defined in the protocol framework that 135 will take care of mapping the protocol messages to specific 136 transports. This document defines the TCP/IP based TML for the 137 ForCES protocol layer. It also addresses all the requirements for 138 the TML including security, reliability, etc. 140 3. Protocol Framework Overview 141 The reader is referred to the Framework document [4], and in 142 particular sections 3 and 4, for architectural overview and where 143 and how the ForCES protocol fits in. There may be some content 144 overlap between the ForCES protocol draft [7] and this section in 145 order to provide clarity. 147 The ForCES protocol constitutes two pieces: the PL and TML layer. 148 This is depicted in Figure 1 below. 150 +------------------------------------------------ 151 | CE PL layer | 152 +------------------------------------------------ 153 | CE TML layer | 154 +------------------------------------------------ 155 ^ 156 | 157 ForCES | (i.e. Forces data + control 158 PL | packets ) 159 messages | 160 over | 161 specific | 162 TML | 163 encaps | 164 and | 165 transport | 166 | 167 v 168 +------------------------------------------------ 169 | FE TML layer | 170 +------------------------------------------------ 171 | FE PL layer | 172 +------------------------------------------------ 174 Figure 1: ForCES Interface 176 The PL layer is in fact the ForCES protocol. Its semantics and 177 message layout are defined in [7]. The TML Layer is necessary to 178 connect two ForCES PL layers as shown in Figure 1 above. 180 Both the PL and TML layers are standardized by the IETF. While only 181 one PL layer is defined, different TMLs are expected to be 182 standardized. To interoperate the TML layer at the CE and FE are 183 expected to be of the same definition. 185 On transmit, the PL layer delivers its messages to the TML layer. 186 The TML layer delivers the message to the destination TML layer(s). 187 On reception, the TML delivers the message to its destination PL 188 layer(s). 190 3.1.1.The PL layer 192 The PL is common to all implementations of ForCES and is 193 standardized by the IETF [7]. The PL layer is responsible for 194 associating an FE or CE to an NE. It is also responsible for 195 tearing down such associations. An FE uses the PL layer to throw 196 various subscribed-to events to the CE PL layer as well as respond 197 to various status requests issued from the CE PL. The CE configures 198 both the FE and associated LFBs attributes using the PL layer. In 199 addition the CE may send various requests to the FE to activate or 200 deactivate it, reconfigure it�s HA parameterization, subscribe to 201 specific events etc. 203 3.1.2.The TML layer 205 The TML layer is essentially responsible for transport of the PL 206 layer messages. The TML is where the issues of how to achieve 207 transport level reliability, congestion control, multicast, 208 ordering, etc. are handled. It is expected more than one TML will 209 be standardized. The different TMLs each could implement things 210 differently based on capabilities of underlying media and transport. 211 However, since each TML is standardized, interoperability is 212 guaranteed as long as both endpoints support the same TML. All 213 ForCES Protocol Layer implementations should be portable across all 214 TMLs, because all TMLs have the same top edge semantics. 216 4. TCP/IP TML Overview 218 [TBD: Update this section based on the protocol selected for the 219 data channel.] 220 The TCP/IP TML consists of two TCP connections between the CE and FE 221 over which the protocol messages are exchanged. One of the 222 connections is called the control channel, over which control 223 messages are exchanged, the other is called data channel over which 224 external protocol packets, such as routing packets will be 225 exchanged. The TCP connections will use unique server port numbers 226 for each of the channels. In addition to this, this TML will provide 227 mechanisms to prioritize the messages over the different channels. 229 Some of the rationale for choosing this transport mechanism as well 230 as explanation of how it meets the TML requirements is explained 231 below. 233 4.1.Rationale for using TCP/IP 234 TCP meets all the reliability requirements (no losses, no data 235 corruption, no re-ordering of data) for the ForCES protocol/TML and 236 also provides congestion control mechanism, which is important to 237 meet the scalability requirement. In addition, it helps with 238 interoperability since TCP is a well-understood, widely deployed 239 transport protocol. Using TCP also enables this TML and the protocol 240 to work seamlessly in single hop and multihop scenarios. 242 4.2.Separate Control and Data channels 244 The ForCES NEs are subject to Denial of Service (DoS) attacks 245 [Requirements Section 7 #15]. A malicious system in the network can 246 flood a ForCES NE with bogus control packets such as spurious RIP or 247 OSPF packets in an attempt to disrupt the operation of and the 248 communication between the CEs and FEs. In order to protect against 249 this situation, the TML uses separate control and data channels for 250 communication between the CEs and FEs. Figure 2 below illustrates 251 the different communication channels between the CEs and the FEs. As 252 an example, the communication channels for support of High 253 Availability with redundant CEs are also included. The setup of 254 these channels would be dependent on the High Availability model 255 used in the NE. 257 ACTIVE CE STANDBY CE 258 +-------------------+ +-------------------+ 259 | CE: PL | | CE: PL | 260 +-------------------+ +-------------------+ 261 | CE: TML | | CE: TML | 262 +-------------------+ +-------------------+ 263 | CE: TCP | | CE: TCP | 264 +-------------------+ +-------------------+ 265 | | | | | | | | | | 266 | . | . | . | . | . 267 | | | | | | | | | | 268 | . | . | . | . | . 269 | | | | | | Cc1� Cd1� Cc2� Cd2�Ccn� Cdn� 270 | . | . | . 271 +-Cc1-----+ | | | | +-.-.-.-.-.Cdn.-+ 272 | +-Cd1-.-.+ | . +--------Ccn---+ | 273 | | | | | . 274 | . +Cc2+ . | | 275 | | | +Cd2+ | . 276 | . | | | | 277 +-----------+ +-----------+ +-----------+ 278 | FE: TCP | | FE: TCP | . . . | FE: TCP | 279 +-----------+ +-----------+ +-----------+ 280 | FE: TML | | FE: TML | | FE: TML | 281 +-----------+ +-----------+ +-----------+ 282 | FE: PL | | FE: PL | | FE: PL | 283 +-----------+ +-----------+ +-----------+ 284 FE1 FE2 FEn 285 \-------------V------------/ 286 FE 1+1 Redundancy 288 Legend: 289 ---- Cc# : Unicast Control Channel between Active CE and FE# 290 -.-. Cd# : Unicast Data Channel between Active CE and FE# 292 ---- Cc#�: Unicast Control Channel between Standby CE and FE# 293 -.-. Cd#�: Unicast Data Channel between Standby CE and FE# 295 Figure 2: CE-FE Communication Channels 297 The data channel carries the control protocol packets such as RIP, 298 OSPF messages as outlined in Requirements [3] Section 7 #10, which 299 are carried in ForCES Packet Redirect messages [7], between the CEs 300 and FEs. All the other ForCES messages, which are used for 301 configuration/capability exchanges, event notification, etc, are 302 carried over the control channel. The data channel is set up only 303 after the control channel is set up. By default, the data channel is 304 established on the CE control channel port number +1. 306 The reliability requirements for the data channel messages are 307 different from that of the control messages [Reqs] i.e. they don�t 308 require strict reliability in terms of retransmission, etc. However 309 congestion control is important for the data channel because in case 310 of DoS attacks, if an unreliable transport such as UDP is used for 311 the data traffic, it can more easily overflow the physical 312 connection, overwhelming the control traffic with congestion. Thus 313 we need a transport protocol that provides congestion control but 314 does not necessarily provide full reliability. Datagram Congestion 315 Control Protocol (DCCP) [11], which is currently being defined, is a 316 transport protocol that exactly meets this requirement. However 317 since it is currently not an IETF standard RFC, and the authors are 318 unaware of any existing implementations, this TML uses TCP as 319 transport protocol for the data channel (for IP interconnect). TCP 320 provides the congestion control mechanism required for the data 321 channel and its wide deployment eases interoperability. 323 4.3.Reliability 325 TCP provides the reliability (no losses, no data corruption, no re- 326 ordering of data) required for ForCES protocol control messages. 328 4.4.Congestion Control 330 TCP provides congestion control needed to satisfy this requirement. 332 4.5.Security 334 This TML uses TLS [8] to provide security in insecure environments. 335 Please see section 7 on security considerations for more details. 336 [TBD: Update based on IPSec/TLS decision.] 338 4.6.Addressing 340 This TML uses addressing provided by IP layer. For unicast 341 addressing/delivery, it uses the TCP connection between the CE and 342 FE for control messaging. For multicast/broadcast 343 addressing/delivery of control messages, this TML uses multiple TCP 344 connections between the CE and FEs. 346 Additionally, the TML layer maintains the mapping between the PL 347 layer addresses and the channel descriptors assigned by the TML 348 layer. The PL layer is unaware of these descriptors; the PL layer 349 only uses the PL layer addresses for all communication with the TML 350 layer. 352 [TBD: Add any information on addressing for data channel.] 354 4.7.Prioritization 356 This TML provides prioritization of messages sent over control 357 channel as compared to the data channel. This has also been found to 358 be useful in face of DoS attacks on the protocol. Additionally it 359 supports multiple levels of prioritization for control messages. The 360 scheduling algorithm used at the TML layer gives preferential 361 treatment to higher priority messages. The scheduling algorithm 362 used in the TML layer is implementation dependent. 364 4.8.HA Decisions 366 The TML layer supports heartbeat messages between peer TML layers to 367 indicate liveness of the entity generating it. The frequency of the 368 heartbeat message may be specified at protocol initialization time. 370 [TBD: Remove this? Use liveliness message at TCP layer? What about 371 for the data channel? What if the protocol doesn�t support such a 372 message? If a heartbeat message is required at the TML layer for 373 the data channel, does that imply that TML messaging is required? 374 See updates to Section 4.9 and 5.] 375 TML is responsible for keeping the control and data communication 376 channels up. It however does not have the authority to decide which 377 CE to set up the channels with. That is outside its control. 379 If a FE-CE communication channel goes down or connectivity is lost, 380 the following steps are taken by the TML layer: 381 - FE TML attempts to reestablish the communication channel 382 - If the FE TML is unable to reestablish the channel (after some 383 configured number of retries/timeout), it notifies the FE PL that 384 the channel is down. 385 - CE TML waits for the channel to be reestablished (since only the 386 FE can reestablish it) for some configured timeout prior to 387 notifying the CE PL that the channel is down. 389 TBD: Since the PL layer is unaware of the number of channels etc., 390 what if only one channel goes down, but the other is up? The TML 391 layer notifies the PL layer of which channel (control/data) is down? 393 If an FE goes down and a standby FE exists for it, and it has 394 communication channels set up with the CE, the CE PL may start to 395 use the channels associated with the standby FE. This is not within 396 the scope of TML itself, but falls in the scope of High 397 Availability. 399 TBD: If an FE goes down and a standby FE exists for it, but it does 400 not have communication channels set up with the CE, how should it be 401 notified to set up the channels? This is not within the scope of 402 TML itself, but falls in the scope of High Availability. Do we need 403 this mentioned here? 405 4.9.Encapsulations Used 407 There is no further message encapsulation of control and data 408 messages done at the TML layer. The PL generated control messages 409 are transported as is by the TML layer. The ForCES protocol control 410 messages are encapsulated with a TCP/IP header. [TBD: Encapsulation 411 of data messages is dependent on the protocol that will be used for 412 the data channel (TCP is only for the control channel). If DCCP is 413 used for the data channel, then a DCCP header will be added.] 415 5. TML Messaging 417 There is no TML layer messaging. TML only transports messages from 418 the PL layer. 420 6. TML Interface to Upper layer Protocol 421 ForCES TML interfaces with an upper layer protocol, the PL Layer and 422 a lower layer protocol, TCP (in the case of TCP TML). This section 423 defines the interface to the upper layer protocol. This interface 424 should be used only as a guideline in implementing the API. 425 Additionally, although the current interface is defined mainly as a 426 synchronous interface, the interface may be implemented to be 427 asynchronous if desired. 429 6.1.TML Service Interface 431 6.1.1.TML Initialize 433 status tmlInit( 434 in channelType, 435 in initAttributes) 437 Input Parameters: 438 channelType: control versus data channel 439 initAttributes: initialization parameters 441 Output Parameters: 442 none 444 Returns: 445 status: SUCCESS 446 Errors TBD 448 Synopsis: 449 tmlInit() enables establishment of communication channels on the 450 entity that this API is invoked. Optionally specifies attributes if 451 any, for initialization. This call does not however result in the 452 setup of any channels. 454 ForCES Usage Model: 455 In the case of ForCES which follows a client-server model, this API 456 would be invoked on the CE, which functions as the server. It is 457 invoked once for every class of TML channels on a per channel type 458 basis (control channel versus data channel). For example, say for 459 control messaging, the CE communicates with five FEs using TCP TML 460 and with another two FEs, using UDP TML. tmlInit() will need to be 461 invoked twice, once for the TCP TML attributes and once for the UDP 462 TML attributes for the control channel setup with all of the FEs. 463 The same holds true for the data channel setup in the above case. 465 [TBD: TBD: Should tmlInit() be invoked by the PL Layer at all since 466 we have now said the PL Layer is oblivious of the number of 467 channels, their attributes etc. Currently, we had specified that 468 tmlInit() would specify the attributes for the channels to be setup. 469 It seems like due to the change in the connection setup model this 470 information should be fed to the TML Layer via some other means. 471 The CE functions as the server, so the server should be up and 472 running however prior to the clients (FEs) coming up and trying to 473 connect to the server (CE). The other option is that the mechanism 474 to specify attributes for the channels is distinct from the process 475 that uses those attributes to start up the server. In that case, 476 tmlInit() could be used mainly to start the server.] 478 6.1.2.TML Channel Open 480 status tmlOpen( 481 in elementId, 482 in channelMode, 483 in ctrlChannelAttributes, 484 in dataChannelAttributes, 485 in eventHandlerCallBack) 487 Input Parameters: 488 elementId: Specific CE for which channel needs to be setup 489 channelMode: unicast versus multicast 490 ctrlChannelAttributes: control channel establishment parameters 491 dataChannelAttributes: data channel establishment parameters 492 eventHandlerCallback: Callback function to be invoked on event 493 generation 495 Output Parameters: 496 none 498 Returns: 499 status: SUCCESS 500 Errors TBD 502 Synopsis: 503 tmlOpen() results in one or more communication channels for control 504 and data messaging being established with the specified elementId. 505 It is up to the TML layer implementation whether to setup a single 506 channel for both control and data messaging or distinct channels for 507 each. The channel may be specified as unicast or multicast via 508 channelMode. This call may either trigger the establishment of the 509 channel(s), or if the channel(s) are already established, it only 510 results in a registration for the channel(s). In either case, if 511 successful, status is returned to indicate successful 512 creation/registration of the control and data channels. No 513 descriptors are returned to the PL layer since the TML layer 514 maintains the mapping between the PL provided elementId and the 515 descriptors it allocates. If this call triggers the establishment of 516 the control and data channels, the channels are established using 517 the ctrlChannelAttributes and dataChannelAttributes parameters 518 respectively, specified to the call. Once the channel(s) are setup 519 (or if already setup prior to this call), the caller of this API is 520 also capable of receiving TML events via the specified event 521 handling callback function. If this call is invoked multiple times 522 on a channel that has already been opened and registered, a return 523 status of ALREADY_REGISTERED is returned, with no change to 524 registration. 526 ForCES Usage Model: 527 In the case of ForCES which follows a client-server model, this API 528 would be invoked on the FE by FE PL, which functions as the client. 529 On each FE, it is invoked once for both control and data channels 530 that the FE wishes to setup with the CE. 532 Notes: 533 In the case of TCP TML, since there is no inherent support for 534 multicast, regardless of the channelMode specified, the specified 535 channel would be setup as a unicast channel; however, the unicast 536 channel would be able to support pseudo multicast. Hence, TCP TML 537 has no need to set up distinct channels for unicast and multicast 538 communication; they are both mapped to the same TCP connection. 540 6.1.3. TML Channel Close 542 status tmlClose( 543 in elementId, 544 in mode) 546 Input Parameters: 547 elementId: address of element with which communication channel is 548 to be terminated 549 mode: mode of operation for the close � forced versus controlled 551 Output Parameters: 552 none 554 Returns: 555 status: SUCCESS 556 Errors TBD 558 Synopsis: 559 Tears down/terminates communication channels connecting to the 560 specified elementId. This API closes both control and data channels 561 (regardless of whether they are implemented as a single channel or 562 distinct channels in the TML layer); it is not possible to close 563 just one of them. No further CE PL � FE PL messaging is possible 564 after this. If the mode is specified as controlled, current 565 messages that are pending in the TML layer shall be sent, but no new 566 messages shall be accepted by the TML layer on this channel. In the 567 forced mode, messages pending in the TML layer shall be discarded. 568 Since the channel was terminated, a subsequent tmlOpen() will 569 trigger establishment of the channel. 571 ForCES Usage Model: 572 This API may be invoked by either the CE or the FE. If the FE PL 573 invokes it, it specifies a CE ID for the elementId. If the CE PL 574 invokes it, it specifies an FE ID for the elementId. 576 6.1.4.TML Channel Write 578 status tmlWrite( 579 in elementId, 580 in msgType, 581 in msg, 582 in msgSize, 583 in timeout, 584 out bytesWritten) 586 Input Parameters: 587 elementId: address of element to be written to; may be a unicast, 588 multicast or broadcast address 589 msgType: control versus data message 590 msg: message to be sent 591 msgSize: size of message to be sent 592 timeout: specifies blocking or non-blocking write. Value of -1 593 implies blocking write (wait forever), value of 0 implies non- 594 blocking write 596 Output Parameters: 597 bytesWritten: number of bytes actually transmitted 599 Returns: 600 status: SUCCESS 601 Errors TBD 603 Synopsis: 604 Sends message to the address specified by elementId. If the 605 specified elementId is associated with a multicast group, the 606 message will be sent to all members of the group. Similarly, if the 607 elementId specified is a broadcast address, the message is sent to 608 all elements associated with the broadcast address. The msgType 609 parameter is used to specify whether the message is a control or 610 data type of message. Based on the message type, the TML will send 611 the message over the appropriate channel. The TML layer uses the 612 address specified by elementId and the msgType to map to the 613 appropriate channel to be used for sending the message. The message 614 is queued in the appropriate queue for transmission. Once this call 615 returns, the message buffer may be freed. If TML�s message queues 616 are full, the timeout will be used to determine how long to wait 617 prior to returning; if the specified timeout expires, and no message 618 buffer becomes available, the API returns with an error. 620 ForCES Usage Model: 621 This API may be invoked by either the FE PL or the CE PL. If the FE 622 PL invokes it, it specifies a CE ID for the elementId. If the CE PL 623 invokes it, it specifies an (unicast/multicast/broadcast) FE ID for 624 the elementId. 625 In the case of TCP TML since there is a single channel used for 626 unicast, multicast and broadcast messaging, the same channel is used 627 for sending messages regardless of the address specified. In other 628 cases where there are distinct channels for unicast versus 629 multicast, the channel to be written to will differ based on the 630 address specified. 632 6.1.5.TML Channel Read 634 status tmlRead( 635 in elementId, 636 in msgType, 637 in msgBuf, 638 in timeout, 639 out bytesRead) 641 Input Parameters: 642 elementId: address of element to be read from; may be a unicast, 643 multicast or broadcast address 644 msgType: control versus data message 645 msgBuf: buffer into which message is to be read 646 timeout: specifies blocking or non-blocking read. Value of -1 647 implies blocking read (wait forever), value of 0 implies non- 648 blocking read 650 Output Parameters: 651 bytesRead: number of bytes actually read 653 Returns: 654 status: SUCCESS 655 Errors TBD 657 Synopsis: 658 Reads message from the specified address. The msgType parameter is 659 used to specify whether the message to be read is a control or data 660 type of message. The TML layer uses the address specified by 661 elementId and the msgType to map to the appropriate channel to be 662 used for reading the message. Once the message is copied into 663 msgBuf specified by the call, the TML message buffer may be freed. 664 If TML�s message queues are empty (no message is available), the 665 timeout will be used to determine how long to wait prior to 666 returning; if the specified timeout expires, and no message becomes 667 available, the API returns with an error. 668 If a non-blocking read is executed, the caller of the API is 669 notified via an upcall when a message becomes available. 671 ForCES Usage Model: 672 This API may be invoked by either the CE or the FE. If the FE PL 673 invokes it, it specifies a CE ID for the elementId. If the CE PL 674 invokes it, it specifies an (unicast/multicast/broadcast) FE ID for 675 the elementId. 677 In the case of TCP TML since there is a single channel used for 678 unicast, multicast and broadcast messaging, the same channel is used 679 for reading messages regardless of the address specified. In other 680 cases where there are distinct channels for unicast versus 681 multicast, the channel to be read from will differ based on the 682 address specified. 684 6.1.6.TML Multicast Group Join 686 status tmlMulticastGroupJoin( 687 in groupId, 688 in groupAttributes) 690 Input Parameters: 691 groupId: address of multicast group to join 692 groupAttributes: attributes associated with the multicast group to 693 be joined 695 Output Parameters: 696 none 698 Returns: 699 status: SUCCESS 700 Errors TBD 702 Synopsis: 704 Joins the multicast group specified by groupId as leaf node in the 705 group. Once a member of this group, the entity calling this API will 706 be capable of receiving messages addressed to this multicast group. 707 The TML layer on each end (CE/FE) maintains the mapping between the 708 PL layer multicast address and the descriptors. The TML layer on 709 the element which is the root of the multicast updates the set of 710 elements that are members of the group specified by groupId. 712 ForCES Usage Model: 713 This API would be invoked on both the CE and the FE. Initially, the 714 intent is to only support FE multicast. In such a case. on the FE 715 the API is invoked once the PL layer on the FE receives a request 716 from the PL layer on the CE to join a specified multicast group. On 717 the CE it is invoked after the FE has successfully joined the 718 multicast group. 720 6.1.7.TML Multicast Group Leave 722 status tmlMulticastGroupLeave( 723 in groupId) 725 Input Parameters: 726 groupId: address of multicast group to leave 728 Output Parameters: 729 none 731 Returns: 732 status: SUCCESS 733 Errors TBD 735 Synopsis: 736 Leaves the multicast group specified by groupId it had previously 737 joined. Once an entity is not a member of the multicast group, it is 738 no longer capable of receiving messages addressed to group. The 739 TML layer on each end (CE/FE) updates the mapping between the PL 740 layer multicast address and the descriptors. The TML layer on the 741 element which is the root of the multicast updates the set of 742 elements that are members of the group specified by groupId. 744 ForCES Usage Model: 745 This API would be invoked on both the CE and the FE. Initially, the 746 intent is to only support FE multicast. In such a case, on the FE 747 the API is invoked once the PL layer on the FE receives a request 748 from the PL layer on the CE to leave a specified multicast group. On 749 the CE it is invoked after the FE has successfully left the 750 multicast group. 752 6.2.Protocol Initialization and Shutdown Model 754 In order for the peer PL Layers to communicate, the control and data 755 channels must be setup. This section defines a model for the setup 756 of the channels, using the TML interface defined above. In this 757 model, the peer TML Layers may establish the control and data 758 channels between the FE and the CE without the involvement of the PL 759 Layers, or if desired, the PL Layer may trigger the setup of the 760 channels; this is left as an implementation decision. Both modes 761 may also be supported within an implementation. 763 6.2.1.Protocol Initialization 765 The control channel must be established between the FE TML and the 766 CE TML for establishment of association to proceed. This channel 767 will be used for messages related to the association setup and 768 capability query. The data channel must be established no later 769 than the response from the FE to the CE Topology query message. The 770 following are the significant aspects associated with channel setup: 771 - A single call by the PL layer sets up the communication channels 772 for both control and data messaging to a specific FE. The call 773 specifies Unicast CE Id and attributes for control and data 774 channels. 775 - It is up to the TML layer whether to set up a single channel for 776 both control and data or distinct channels for control and data 777 - TML sets up the appropriate channels and allocates required 778 descriptors for the channels. TML layer maintains a mapping 779 between the Unicast FE/CE Id and the channel descriptors and 780 channel type (control versus data) it creates. 781 - There is no need for channel descriptors to be returned to the PL 782 layer at either the FE or the CE. PL Layer only uses the Unicast 783 FE/CE Id for read/write calls and specifies the type of message 784 (control versus data) to be read/written. 785 - If only one of the channels is setup successfully, the TML layer 786 will have to return appropriate status that specifies which 787 channel is setup successfully and which isn�t. 789 Figure 4 illustrates the initialization model where the PL layer via 790 an interface provided by the TML Layer, triggers the setup of the 791 control and data channels. 793 FE1 PL FE1 TML CE TML CE PL 794 | | | | \ 795 / | | | TBD:tmlInit() | | 796 FE | | | |<--------------| > CE Init/ 797 Init/ < | | | | | Bootup 798 Bootup | | | | | / 799 \ | | | | 800 | tmlOpen(CeId) | | | 801 |-------------->| | | \ 802 | |CtrlChan(Cc) Setup | | | Setup control 803 | |~~~~~~~~~~~~~~~~~~~~~~>| | | channel if not 804 | | FeId . [CcDes] | | setup. TML 805 | | | | > has mapping 806 | |CtrlChan(Cc) Setup Rsp | | | from PL Layer 807 | |<~~~~~~~~~~~~~~~~~~~~~~| | | Id to channel 808 | CeId . [CcDes] | | | descriptor and 809 | | | / channel type. 810 | | | | 811 | |DataChan(Cd) Setup | | | Setup data 812 | |~~~~~~~~~~~~~~~~~~~~~~>| | | channel if not 813 | | FeId . [CcDes, | | setup. TML 814 | | CdDes] | | updates 815 | | | | > mapping from 816 | |DataChan(Cd) Setup Rsp | | | PL Layer 817 | |<~~~~~~~~~~~~~~~~~~~~~~| | | Id to channel 818 | CeId . [CdDes] | | | descriptor and 819 | | | | / channel type. 820 | | | | 821 | <-- status | | | 822 | | | | 823 |tmlEvent(ChUp) | |tmlEvent(ChUp) | 824 |<--.--.--.--.--| |--.--.--.--.-->| 825 | | | | 826 | | Asso Setup Req | | 827 |---------------|-----------------------|-------------->| 828 | | Asso Setup Rsp | | 829 |<--------------|-----------------------|---------------| 830 | | | | 831 | | Capability Query | | 832 |<--------------|-----------------------|---------------| 833 | | Capability Query Rsp | | 834 |---------------|-----------------------|-------------->| 835 | | | | 836 | | Topology Query | | 837 |<--------------|-----------------------|---------------| 838 | | Topology Query Rsp | | 839 |---------------|-----------------------|-------------->| 840 | | | | 841 | |STEADY STATE OPERATION | | 842 |<--------------|-----------------------|-------------->| 843 | | | | 844 Legend: 845 PL --------> PL : Protocol layer messaging 846 PL --------> TML: TML API 847 TML --.--.--> PL : Events/Notifications/Upcalls 848 TML ~~~~~~~~> TML: Internal protocol communication 850 Figure 4: Protocol Initialization (Channel Setup) 852 6.2.2.Protocol Shutdown 854 The control channel teardown must occur only after the association 855 teardown has occurred. The data channel teardown may occur no earlier 856 than the association teardown. 858 The PL Layer may shutdown control and data channels via invocation of 859 the tmlClose() API. When the PL layer shuts down the channels, the 860 channels are torn down; hence ForCES messaging between the CE and FE is 861 no longer possible over those channels. A tmlClose() results in both 862 control and data channels (regardless of whether they are implemented 863 as a single channel or distinct channels in the TML layer) being 864 shutdown; it is not possible to close just one of them. A subsequent 865 tmlOpen() triggers establishment of the channel. The channel(s) may be 866 shutdown by either the FE or the CE. If an FE initiates the shutdown, 867 it specifies the CE Id associated with the channel(s) to be shutdown. 868 If a CE initiates the shutdown, it specifies the FE Id associated with 869 the channel(s) to be shutdown. A channel shutdown by the FE is 870 illustrated in Figure 5 and a channel shutdown by the CE is illustrated 871 in Figure 6. 873 FE PL FE TML CE TML CE PL 874 | | | | 875 | |STEADY STATE OPERATION | | 876 |<--------------|-----------------------|-------------->| 877 | | Config Request | | 878 |<--------------|-----------------------|---------------| 879 | | Config Response | | 880 |---------------|-----------------------|-------------->| 881 | | | | 882 | | Association Teardown | | 883 |<--------------|-----------------------|---------------| 884 | | | | 885 | | | | \ 886 |tmlClose(CeId) | | | | FE initiated: 887 |-------------->| | | > FE specifies CE 888 | <-- status | | | | Id associated 889 | | | | / with channel. 891 Legend: 892 PL --------> PL : Protocol layer messaging 893 PL --------> TML: TML API 894 TML --.--.--> PL : Events/Notifications/Upcalls 895 TML ~~~~~~~~> TML: Internal protocol communication 897 Figure 5: Protocol Shutdown: FE Initiated 899 FE PL FE TML CE TML CE PL 900 | | | | 901 | |STEADY STATE OPERATION | | 902 |<--------------|-----------------------|-------------->| 903 | | Config Request | | 904 |<--------------|-----------------------|---------------| 905 | | Config Response | | 906 |---------------|-----------------------|-------------->| 907 | | | | 908 | | Association Teardown | | 909 |<--------------|-----------------------|---------------| 910 | | | | 911 | | | | \ 912 | | |tmlClose(FeId) | | CE initiated: 913 | | |<--------------| > FE specifies CE 914 | <-- status | | status --> | | Id associated 915 | | | | / with channel. 917 Legend: 918 PL --------> PL : Protocol layer messaging 919 PL --------> TML: TML API 920 TML --.--.--> PL : Events/Notifications/Upcalls 921 TML ~~~~~~~~> TML: Internal protocol communication 923 Figure 6: Protocol Shutdown: CE Initiated 925 6.3.Multicast Model 927 The TML layer provides support for multicast. In the ForCES model, 928 support is required to multicast to the FEs from a CE; in this case, 929 the CE is the source or root of the multicast and the FEs are the 930 leaves. 932 Support for multicast requires that a channel for supporting 933 multicast be opened between an FE and the CE. In the case of TCP 934 TML, the same channel is used for both unicast and multicast 935 messaging since multicast mode is simulated using unicast channels 936 in this case. Once the channel is open, a CE may request FEs to join 937 and leave specified multicast groups. Multicast support is CE- 938 initiated. FEs can join a multicast group only if the CE requests 939 them to join the group. TML maintains mapping between PL layer IDs 940 and channel descriptors for multicast. The following is the 941 significant steps for adding or removing members from a multicast 942 group: 944 - CE PL communicates with FE PL for requesting the FE to join or 945 leave a multicast group. 946 - FE PL informs FE TML regarding the join or leave request. 947 - FE TML updates the multicast group information. It updates the 948 mapping between the FE Multicast Id and the channel descriptor to 949 be used for multicast for that FE. This mapping may be from 950 [Multicast FE Id] . [FE Id] . [Channel descriptor] or directly 951 from [Multicast FE Id] . [Channel descriptor]. This is 952 implementation dependent. 953 - FE PL responds to CE PL informing it of the status of the join or 954 leave request. 955 - If the join or leave request was successful, CE PL informs CETML 956 regarding the update to the multicast group membership. 957 - CE TML updates the multicast group membership. It updates the 958 mapping between the FE Multicast Id and the set of channel 959 descriptors to be used for multicast to the FEs that are members 960 of this group. This mapping may be from [Multicast FE Id] . [Set 961 of FE Ids] . [Set of channel descriptors] or directly from 962 [Multicast FE Id] . [Set of channel descriptors]. This is 963 implementation dependent. 964 - There is no need for any descriptors to be returned to the PL 965 layer at either the FE or the CE. PL Layer only uses the 966 Multicast FE Id for write calls and specifies the type of message 967 (control versus data) to be written. 969 A tmlWrite() on a unicast FE Id results in a unicast message being 970 sent to the FE associated with the channel. A tmlWrite() on a 971 multicast FE Id results in multicast messaging. Figures 7 and 8 972 illustrate multicast scenarios with 2 FEs, FE1 and FE2. In Figure 973 7, the CE requests FE1 to join a multicast group. Although not 974 shown as a separate figure, if FE2 were to join the same group, the 975 join procedure would be the same as in Figure 7; it would result in 976 the multicast group membership being updated at the TML layer on the 977 CE to include FE2 in the group. In Figure 8, the CE requests FE1 to 978 leave the multicast group, thus resulting in only FE2 being a member 979 of the multicast group. 981 Multicast Scenario with FE1 joining group: New group created 983 FE1 PL FE1 TML CE TML CE PL 984 | | | | 985 | | | | \ 986 | MC Grp Join Req (McId) | | 987 |<--------------|-------------------|---------------| | CE:PL Level multicast group 988 [TML | tmlJoin(McId) | | | | join request sent to each 989 updates |-------------->| | | | FE:PL that needs to be part 990 MC grp | McId = {FE1_ChDes} | | > of a multicast group, McId, 991 info] | | | | | where McId specifies a 992 | <-- status | | | | multicast group Id at the 993 | | | | | PL layer. 994 | MC Grp Join Rsp (status) | | 995 |---------------|-------------------|-------------->| / 996 | | | | 997 | | | | \ 998 | | |tmlJoin(McId) | | TML updates multicast 999 | | |<--------------| | group membership. PL is 1000 | | McId = {FE1_ChDes} | > only aware of PL layer 1001 | | | | | multicast group Id, that is, 1002 | | | status --> | | McId] 1003 | | | | / 1005 Figure 7: Multicast Support: FE1 Joins Group 1007 Multicast Scenario with FE1 leaving group: Group membership updated 1008 to exclude FE1 1010 FE1 PL FE1 TML CE TML CE PL 1011 | | | | 1012 | | | | \ 1013 | MC Grp Leave Req (McId, FE1) | | 1014 |<--------------|-------------------|---------------| | CE:PL Level multicast group 1015 [TML | tmlLeave(McId)| | | | leave request sent to FE1:PL 1016 removes |-------------->| | | | that needs to be removed 1017 MC grp | McId = {} | | > from multicast group, McId, 1018 info] | | | | | where McId specifies a 1019 | <-- status | | | | multicast group Id at the 1020 | | | | | PL layer. 1021 | MC Grp Leave Rsp (status) | | 1022 |---------------|-------------------|-------------->| / 1023 | | | | 1024 | | | | \ 1025 | | |tmlLeave(McId) | | TML removes FE1 from 1026 | | |<--------------| | multicast group McId. 1027 | | McId = {FE2_ChDes} | > That leaves only FE2 1028 | | | | | in the group. 1029 | | | status --> | | 1030 | | | | / 1032 Figure 8: Multicast Support: FE1 Leaves Group 1034 6.4.Broadcast Model 1036 The TML layer provides support for broadcast. In the ForCES model, 1037 support is required to broadcast to the FEs from a CE. The 1038 broadcast model is just a special case of multicast, where all FEs 1039 are included. TBD: Is there anything else to be added/discussed 1040 here. Join/Leave messaging also used for broadcast? ForCES draft 1041 also talks of CE broadcast and NE broadcast. 1043 7. Security Considerations 1045 If the CE or FE are in a single box and network operator is running 1046 under a secured environment then it is up to the network 1047 administrator to turn off all the security functions. This is 1048 configured during the pre-association phase of the protocol. 1050 When the CEs, FEs are running over IP networks or in an insecure 1051 environment, this TML uses TLS [8] to provide security. The security 1052 association between the CEs and FEs MUST be established before any 1053 ForCES protocol messages are exchanged between the CEs and FEs. 1055 7.1.TLS Usage for this TML 1056 [TBD: Update based on inclusion of IPSec for security.] 1058 This section is applicable for CE or FE endpoints that use the TML 1059 with TLS [8] to secure communication. 1061 Since CE is master and FEs are slaves, the FEs are TLS clients and 1062 CEs are TLS server. The endpoints that implement TLS MUST perform 1063 mutual authentication during TLS session establishment process. CE 1064 must request certificate from FE and FE needs to pass the requested 1065 information. 1067 We recommend �TLS-RSA-with-AES-128-CBC-SHA� cipher suite, but CE or 1068 FE may negotiate other TLS cipher suites. TLS must be used for all 1069 control channel messages. TLS is optional for the data channel since 1070 data channel packets are not encrypted externally to the NE. 1072 This TML uses TLS to provide security when the NE is in an insecure 1073 environment. This is because IPsec provides less flexibility when 1074 configuring trust anchors since it is transparent to the application 1075 and use of Port identifiers is prohibited within IKE Phase 1. This 1076 provides restriction for IPsec to configure trust anchors for each 1077 application separately and policy configuration is common for all 1078 applications. 1080 8. IANA Considerations 1082 The TCP/IP TML needs to have a one well-defined TCP port number, 1083 which needs to be assigned by IANA. The control port is referred to 1084 as the TCP_TML_CONTROL_PORT. [TBD: Add information for data channel 1085 port if required based on the protocol for the data channel.] 1087 9. Manageability 1089 TBD 1091 10. References 1092 10.1.Normative References 1094 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, 1095 October 1996. 1097 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 1098 Levels", RFC2119 (BCP), IETF, March 1997. 1100 3. Khosravi, et al., �Requirements for Separation of IP Control and 1101 Forwarding�, RFC 3654, November 2003. 1103 4. L. Yang, et al., � ForCES Architectural Framework�, RFC 3746, 1104 April 2004. 1106 5. L. Yang, et al., � ForCES Forwarding Element Functional Model�, 1107 work in progress�, July 2004, 1109 6. A. Audu, et al., � Forwarding and Control Element protocol (FACT)" 1110 draft-gopal-forces-fact-06.txt, February 2004. 1112 7. A. Doria, et al., �ForCES protocol specification�, draft-ietf- 1113 forces-protocol-00.txt, September 2004. 1115 10.2.Informative References 1117 8. Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. 1118 Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 1120 9. Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer 1121 Security over Stream Control Transmission Protocol", RFC 3436, 1122 December 2002. 1124 10. R. Stewart, et al., �Stream Control Transmission Protocol 1125 (SCTP)�, RFC 2960, October 2000. 1127 11. E. Kohler, M. Handley, S. Floyd, J. Padhye, �Datagram 1128 Congestion Control Protocol (DCCP)�, draft-ietf-dccp-spec-04.txt, 1129 June 2003. 1131 12. Floyd, S., �Congestion Control Principles�, RFC 2914, September 1132 2000. 1134 13. A. Doria, F. Hellstrand, K. Sundell, T. Worster, �General 1135 Switch Management Protocol (GSMP) V3�, RFC 3292, June 2002. 1137 14. H. Balakrishnan, et al. �The Congestion Manager�, RFC 3124, 1138 June 2001. 1140 15. H. Khosravi, S. Lakkavali, �Analysis of protocol design issues 1141 for open standards based programmable routers and switches� 1142 [SoftCOM 2004] 1144 16. S. Lakkavali, H. Khosravi, �ForCES protocol design analysis for 1145 protection against DoS attacks� [ICCCN 2004] 1147 11. Acknowledgments 1149 12. Authors' Addresses 1151 Hormuzd Khosravi 1152 Intel 1153 2111 NE 25th Avenue 1154 Hillsboro, OR 97124 1155 Phone: 1-503-264-0334 1156 Email: hormuzd.m.khosravi@intel.com 1158 Furquan Ansari 1159 101 Crawfords Corner Road 1160 Holmdel, NJ 07733 1161 USA 1162 Phone: +1 732-949-5249 1163 Email: furquan@lucent.com 1165 Jon Maloy 1166 Ericsson Research Canada 1167 8400 Boul Decarie 1168 Ville Mont-Royal, Quebec H4P 2N2 1169 Canada 1170 Phone: 1-514-345-7900 1171 Email: jon.maloy@ericsson.com 1173 Shuchi Chawla 1174 Intel 1175 2111 NE 25th Avenue 1176 Hillsboro, OR 97124 1177 Phone: 1-503-712-4539 1178 Email: shuchi.chawla@intel.com 1180 Copyright Statement 1182 Copyright (C) The Internet Society (year). This document is subject 1183 to the rights, licenses and restrictions contained in BCP 78, and 1184 except as set forth therein, the authors retain all their rights. 1186 This document and the information contained herein are provided on 1187 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1188 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1189 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1190 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1191 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1192 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.