idnits 2.17.1 draft-ietf-forces-requirements-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == There are 2 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 10 longer pages, the longest (page 2) being 62 lines 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. 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 (November 2001) is 8169 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) == Missing Reference: 'RFC-2119' is mentioned on line 49, but not defined == Missing Reference: 'RFC2215' is mentioned on line 437, but not defined == Unused Reference: 'RFC2914' is defined on line 544, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DS-PIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'REQ-PART' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Anderson 3 Expiration: May 2002 Intel Labs 4 File: draft-ietf-forces-requirements-01.txt E. Bowen 5 Working Group: ForCES IBM 6 R. Dantu 7 Netrake Inc. 8 A. Doria 9 N/A 10 J. Hadi Salim 11 Znyx Networks 12 H. Khosravi 13 Intel Labs 14 M. Minhazuddin 15 Avaya Inc. 16 M. Wasserman 17 Wind River 18 November 2001 20 Requirements for Separation of IP Control and Forwarding 22 draft-ietf-forces-requirements-01.txt 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026. Internet-Drafts are 28 working documents of the Internet Engineering Task Force (IETF), 29 its areas, and its working groups. Note that other groups may 30 also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as ``work in 36 progress.'' 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 48 this document are to be interpreted as described in [RFC-2119]. 50 1. Abstract 52 This document presents an introduction to issues surrounding a 53 ForCES architecture and defines a set of associated terminology. 54 Subsequently, this document defines a set of architectural, 55 modeling, and protocol requirements for mechanisms to logically 56 separate the control and data forwarding planes of an IP network 57 device. 59 2. Definitions 61 Addressable Entity (AE) - A physical device that is directly 62 addressable given some interconnect technology. For example, on 63 Ethernet, an AE is a device to which we can communicate using an 64 Ethernet MAC address; on IP networks, it is a device to which we can 65 communicate using an IP address; and on a switch fabric, it is a 66 device to which we can communicate using a switch fabric port 67 number. 69 Physical Forwarding Element (PFE) - An AE that includes hardware 70 used to provide per-packet processing and handling. This hardware 71 may consist of (but is not limited to) network processors, ASIC's, 72 or general-purpose processors. For example, line cards in a 73 forwarding backplane are PFEs. 75 PFE Partition - A logical partition of a PFE consisting of some 76 subset of each of the resources (e.g., ports, memory, forwarding 77 table entries) available on the PFE. This concept is analogous to 78 that of the resources assigned to a virtual router [REQ-PART]. 80 Physical Control Element (PCE) - An AE that includes hardware used 81 to provide control functionality. This hardware typically includes 82 a general-purpose processor. 84 PCE Partition - A logical partition of a PCE consisting of some 85 subset of each of the resources available on the PCE. 87 Forwarding Element (FE) - A logical entity that implements the 88 ForCES protocol. FEs use the underlying hardware to provide per- 89 packet processing and handling as directed by a CE via the ForCES 90 protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs. 92 Proxy FE - A name for a type of FE that cannot directly modify its 93 underlying hardware but instead manipulates that hardware using some 94 intermediate form of communication (e.g., a non-ForCES protocol or 95 DMA). A proxy FE will typically be used in the case where a PFE 96 cannot implement (e.g., due to the lack of a general purpose CPU) 97 the ForCES protocol directly. 99 Control Element (CE) - A logical entity that implements the ForCES 100 protocol and uses it to instruct one or more FEs as to how they 101 should process packets. CEs handle functionality such as the 102 execution of control and signaling protocols. CEs may encompass PCE 103 partitions or whole PCEs. 105 Pre-association Phase - The period of time during which a FE Manager 106 (see definition below) and a CE Manager (see definition below) are 107 deciding which FE and CE should be part of the same network element. 109 Post-association Phase - The period of time during which a FE does 110 know which CE is to control it and vice versa, including the time 111 during which the CE and FE are establishing communication with one 112 another (after they have been associated to the same NE). 114 ForCES Protocol - While there may be multiple protocols used within 115 the overall ForCES architecture, the term "ForCES protocol" refers 116 only to the ForCES post-association phase protocol (see below). 118 ForCES Post-Association Phase Protocol - The protocol used for post- 119 association phase communication between CEs and FEs. This protocol 120 does not apply to CE-to-CE communication, FE-to-FE communication, or 121 to communication between FE and CE managers. The ForCES protocol is 122 a master-slave protocol in which FEs are slaves and CEs are masters. 123 This protocol includes both the management of the communication 124 channel (e.g., "connection" establishment, heartbeats) and the 125 control messages themselves. 127 FE Model - A model that describes the logical processing functions 128 of a FE. 130 FE Manager - A logical entity that operates in the pre-association 131 phase and is responsible for determining to which CE(s) a FE should 132 communicate. This determination process is called CE discovery and 133 may involve the FE manager learning the capabilities of available 134 CEs. A FE manager may use anything from a static configuration to a 135 pre-association phase protocol (see below) to determine which CE(s) 136 to use. Being a logical entity, a FE manager might be physically 137 combined with any of the other logical entities mentioned in this 138 section. 140 CE Manager - A logical entity that operates in the pre-association 141 phase and is responsible for determining to which FE(s) a CE should 142 communicate. This determination process is called FE discovery and 143 may involve the CE manager learning the capabilities of available 144 FEs. A CE manager may use anything from a static configuration to a 145 pre-association phase protocol (see below) to determine which FE to 146 use. Being a logical entity, a CE manager might be physically 147 combined with any of the other logical entities mentioned in this 148 section. 150 Pre-association Phase Protocol - A protocol between FE managers and 151 CE managers that helps them determine which CEs or FEs are to be 152 associated to a NE. A pre-association phase protocol may include a 153 CE and/or FE capability discovery mechanism. It is important to 154 note that this capability discovery process is wholly separate from 155 (and does not replace) that used within the ForCES protocol (see 156 Section 7, requirement #1). However, the two capability discovery 157 mechanisms may utilize the same FE model (see Section 6). Pre- 158 association phase protocols are not discussed further in this 159 document. 161 ForCES Network Element (NE) - An entity composed of one or more CEs 162 and one or more FEs. To entities outside a NE, the NE represents a 163 single point of management. Similarly, a NE usually hides its 164 internal organization from external entities. 166 ForCES Protocol Element - A FE or CE. 168 High Touch Capability - This term will be used to apply to the 169 capabilities found in some forwarders to take action on the contents 170 or headers of a packet based on content other than what is found in 171 the IP header. Examples of these capabilities include NAT-PT, 172 firewall, and L7 content recognition. 174 3. Introduction 176 An IP network element is composed of numerous logically separated 177 entities that cooperate to provide a given functionality (such as a 178 routing or IP switching) and yet appear as a normal integrated 179 network element to external entities. Two primary types of network 180 element components exist: control-plane components and forwarding- 181 plane components. In general, forwarding-plane components are ASIC, 182 network-processor, or general-purpose processor-based devices that 183 handle all data path operations. Conversely, control-plane 184 components are typically based on general-purpose processors that 185 provide control functionality such as the processing of routing or 186 signaling protocols. A standard set of mechanisms for connecting 187 these components would provide increased scalability and allow the 188 control and forwarding planes to evolve independently thus promoting 189 faster innovation. 191 For the purpose of illustration, let us consider the architecture of 192 a router to illustrate the concept and value of separate control and 193 forwarding planes. The architecture of a router is composed of two 194 main parts. These components, while inter-related, perform 195 functions that are largely independent of each other. At the bottom 196 is the forwarding path that operates in the data-forwarding plane 197 and is responsible for per-packet processing and forwarding. Above 198 the forwarding plane is the network operating system that is 199 responsible for operations in the control plane. In the case of a 200 router or switch, the network operating system runs routing, 201 signaling and control protocols (e.g., RIP, OSPF and RSVP) and 202 dictates the forwarding behavior by manipulating forwarding tables, 203 per-flow QoS tables and access control lists. Typically, the 204 architecture of these devices combines all of this functionality 205 into a single functional whole with respect to external entities. 207 4. Architecture 209 The chief components of a NE architecture are the CE, the FE, and 210 the interconnect protocol. The CE is mainly responsible for 211 operations such as signaling and control protocol processing and the 212 implementation of management protocols. Based on the information 213 acquired through control processing, the CE(s) dictates the packet- 214 forwarding behavior of its FE(s) via the interconnect protocol. For 215 example, the CE might control a FE by manipulating its forwarding 216 tables, the state of its interfaces, or by adding or removing a NAT 217 binding. 219 The FE operates in the forwarding plane and is responsible chiefly 220 for per-packet processing and handling. By allowing the control and 221 forwarding planes to evolve independently, we expect different types 222 of FEs to be developed - some general purpose and others more 223 specialized. Some functions that FEs could perform include layer 3 224 forwarding, metering, shaping, firewall, NAT, encapsulation (e.g., 225 tunneling), decapsulation, encryption, accounting, etc. Nearly all 226 combinations of these functions may be present in practical FEs. 228 Below is a diagram illustrating an example NE composed of a CE and 229 two FEs. 231 -------------------------------- 232 | NE | 233 | ------------- | 234 | | CE | | 235 | ------------- | 236 | / \ | 237 | / \ | 238 | / \ | 239 | / \ | 240 | ----------- ----------- | 241 | | FE | | FE | | 242 | ----------- ----------- | 243 | | | | | | | | | | 244 | | | | | | | | | | 245 | | | | | | | | | | 246 | | | | | | | | | | 247 -------------------------------- 248 | | | | | | | | 249 | | | | | | | | 251 5. Architectural Requirements 253 The following are the architectural requirements: 255 1) CEs and FEs MUST be able to connect by a variety of interconnect 256 technologies. Examples of interconnect technologies used in current 257 architectures include Ethernet connections, backplanes, and ATM 258 (cell) fabrics. FEs MAY be connected to each other via a different 259 technology than that used for CE/FE communication. 261 2) FEs MUST support a minimal set of capabilities necessary for 262 establishing network connectivity (e.g., interface discovery, port 263 up/down functions). Beyond this minimal set, the ForCES 264 architecture MUST NOT restrict the types or numbers of capabilities 265 that FEs may contain. 267 3) Packets MUST be able to arrive at the NE by one FE and leave the 268 NE via a different FE. 270 4) A NE MUST support the appearance of a single functional device. 271 For example, in a router, the TTL of the packet should be 272 decremented only once as it traverses the NE regardless of how many 273 FEs through which it passes. However, external entities (e.g., FE 274 managers and CE managers) MAY have direct access to individual 275 ForCES protocol elements for providing information to transition 276 them from the pre-association to post-association phase. 278 5) The architecture MUST provide a way to prevent unauthorized 279 ForCES protocol elements from joining a NE. 281 6) A FE MUST be able to asynchronously inform the CE of an 282 increase/decrease in available resources or capabilities on the FE. 283 (Since there is not a strict 1-to-1 mapping between FEs and PFEs, it 284 is possible for the relationship between a FE and its physical 285 resources to change over time. For example, the number of physical 286 ports or the amount of memory allocated to a FE may vary over time. 287 The CE needs to be informed of such changes so that it can control 288 the FE in an accurate way.) 290 7) CEs and FEs MUST determine when a loss of connectivity between 291 them has occurred. 293 8) FEs MUST redirect packets addressed to their interfaces to their 294 CE for further processing. Furthermore, FEs MUST redirect other 295 required packets (e.g., such as those with the router alert option 296 set) to their CE as well. (FEs MAY provide any other 297 classification/redirection capabilities that they desire as 298 described in Section 6.4 requirement #4.) Similarly, CEs MUST be 299 able to create packets and have its FEs deliver them. 301 9) All proposed ForCES architectures MUST explain how that 302 architecture may be applied to support all of a router's functions 303 as defined in [RFC1812]. 305 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by 306 which the FEs in the NE are connected. 308 11) The ForCES NE architecture MUST be capable of supporting (i.e., 309 must scale to) at least hundreds of FEs and tens of thousands of 310 ports. 312 12) FEs MUST be able to join and leave NEs dynamically. 314 13) CEs MUST be able to join and leave NEs dynamically. 316 14) The NE architecture MUST support multiple CEs and FEs. 318 6. FE Model Requirements 320 The variety of FE functionality that the ForCES architecture allows 321 poses a potential problem for CEs. In order for a CE to effectively 322 control a FE, the CE must understand at a logical level how the FE 323 processes packets. We therefore REQUIRE that a FE model be created 324 that can express the logical packet processing capabilities of a FE. 325 This model will be used in the ForCES protocol to describe FE 326 capabilities (see Section 7, requirement #1). 328 6.1. Higher-Level FE Model 330 At its higher level, the FE model MUST express what logical 331 functions can be applied to packets as they pass through a FE. 332 Furthermore, the model MUST be capable of describing the order in 333 which these logical functions are applied in a FE. This ordering is 334 important in many cases. For example, a NAT function may change a 335 packet's source or destination IP address. Any number of other 336 logical functions (e.g., layer 3 forwarding, ingress/egress 337 firewall, shaping, accounting) may make use of the source or 338 destination IP address when making decisions. The CE needs to know 339 whether to configure these logical functions with the pre-NAT or 340 post-NAT IP address. Furthermore, the model MUST be capable of 341 expressing multiple instances of the same logical function in a FE's 342 processing path. Using NAT again as an example, one NAT function is 343 typically performed before the forwarding decision (packets arriving 344 externally have their public addresses replaced with private 345 addresses) and one NAT function is performed after the forwarding 346 decision (for packets exiting the domain, their private addresses 347 are replaced by public ones). 349 6.2. Lower-Level FE Model 351 At its lower level, the FE model MUST be able to express the 352 capabilities of each logical function. As the following examples 353 will illustrate, these lower-level capabilities come in five 354 varieties: classification, action, parameterization, statistic, and 355 events. 357 6.2.1. Classification 359 Classification data is used by a logical function to perform pattern 360 matching. For example, there may be two FEs, both of which provide 361 an ingress firewall function. However, the first FE may filter on 362 any subset of a (source IP, destination IP, IP protocol, source 363 port, destination port)-tuple whereas the second FE may perform only 364 a (destination IP, IP protocol)-tuple classification. In either 365 case, the action applied to matching packets may be the same, e.g. 366 drop. 368 6.2.2. Action 370 Action data is used by a logical function to manipulate the packet 371 because of a classification. For example, there may be two traffic- 372 shaping functions, both of which classify only on destination IP 373 address. However, one of the shaping functions may implement a 374 leaky bucket that requires two parameters whereas the other function 375 may implement a token bucket that requires three parameters. 377 6.2.3. Parameterization 379 Parameterization data can be viewed as parameters to the logical 380 function itself. This data does not affect individual packets but 381 affects how the function as a whole behaves. For example, there may 382 be a congestion function that implements two varieties of RED that 383 require different parameter sets. Parameterization data would be 384 used to select between the two varieties of RED and to provide the 385 necessary configuration to each variety. 387 6.2.4.Statistics 389 Some logical functions may maintain certain statistics (e.g., number 390 of packets processed) about their own operation. The FE model needs 391 to express which statistics a FE�s logical functions maintain so 392 that CEs can later query those statistics to answer queries made by 393 higher level entities. 395 6.2.5.Event 397 Some logical functions may be able to generate asynchronous events 398 that can be sent to the control plane. Two examples of these events 399 include packet redirection events and port state change events 400 (e.g., up/down). The FE model must be able to express the events 401 that a FE�s logical functions may generate so that CEs can register 402 to receive those events when they happen to occur. 404 6.3. Flexibility 406 Finally, the FE model SHOULD provide a flexible infrastructure in 407 which new logical functions and new classification, action, and 408 parameterization data can be easily added. Also, the FE model MUST 409 be capable of describing the types of statistics gathered by each 410 logical function. 412 6.4. Minimal Set of Logical Functions 414 The rest of this section defines a minimal set of logical functions 415 that any FE model MUST support. However, this section shall not be 416 construed as to define a set of functions that all FEs must provide. 417 On the contrary, FEs are not required to support any of the 418 following functions. These requirements only specify that the FE 419 model must be capable of expressing the capabilities that FEs are 420 likely to initially provide. 422 1)Port Functions 423 The FE model MUST be capable of expressing the number of ports on 424 the device, the static attributes of each port (e.g., port type, 425 link speed), and the configurable attributes of each port (e.g., IP 426 address, administrative status). 428 2)Forwarding Functions 429 The FE model MUST be capable of expressing the data that can be used 430 by the forwarding function to make a forwarding decision. 432 3)QoS Functions 433 The FE model MUST allow a FE to express its QoS capabilities in 434 terms of, e.g., metering, policing, shaping, and queuing functions. 435 The FE model MUST be capable of expressing the use of these 436 functions to provide IntServ or DiffServ functionality as described 437 in [RFC2211], [RFC2212], [RFC2215], and [DS-PIB]. 439 4)Generic Filtering Functions 440 The FE model MUST be capable of expressing complex sets of filtering 441 functions. The model MUST be able to express the existence of 442 multiples of these functions at arbitrary points in a FE's packet 443 processing path. The FE model MUST be capable of expressing a wide 444 range of classification abilities from single fields (e.g., 445 destination address) to arbitrary n-tuples. Similarly, the FE model 446 MUST be capable of expressing what actions these filtering functions 447 can perform on packets that the classifier matches. 449 5)Vendor-Specific Functions 450 The FE model SHOULD be extensible so that vendor-specific 451 functionality can be expressed. 453 6)High-Touch Functions 454 The FE model MUST be capable of expressing the encapsulation and 455 tunneling capabilities of a FE. The FE model MUST support functions 456 that mark the IPv4 header TOS octet or the IPv6 Traffic Class octet. 457 The FE model MAY support other high touch functions (e.g., NAT, 458 ALG). 460 7)Security Functions 461 The FE model MUST be capable of expressing the types of encryption 462 that may be applied to packets in the forwarding path. 464 7. ForCES Protocol Requirements 466 This section specifies some of the requirements that a ForCES 467 protocol MUST meet. 469 1)Configuration of Modeled Elements 470 The ForCES protocol MUST allow the CEs to determine the capabilities 471 of each FE. These capabilities SHALL be expressed using the FE 472 model whose requirements are defined in Section 6. Furthermore, the 473 protocol MUST provide a means for the CEs to control all the FE 474 capabilities that are discovered through the FE model. (For 475 example, the protocol must be able to add/remove 476 classification/action entries, set/delete parameters, query 477 statistics, and register for and receive events.) 479 2)Support for Secure Communication 480 Since FE configuration will contain information critical to the 481 functioning of a network (such as IP forwarding tables) and may 482 contain information derived from business relationships (e.g., 483 SLAs), the ForCES protocol MUST support a method of securing 484 communication between FEs and CEs to ensure that information is 485 delivered privately and in an unmodified form. 487 3)Scalability 488 The ForCES protocol MUST be capable of supporting (i.e., must scale 489 to) at least hundreds of FEs and tens of thousands of ports. For 490 example, the ForCES protocol field sizes corresponding to FE or port 491 numbers SHALL be large enough to support the minimum required 492 numbers. This requirement does not relate to the performance of the 493 protocol as the number of FEs or ports in the NE grows. 495 4)Multihop 496 When the CEs and FEs are separated beyond a single hop, the ForCES 497 protocol will make use of an existing RFC2914 compliant L4 protocol 498 with adequate reliability, security and congestion control (e.g. 499 TCP, SCTP) for transport purposes. 501 5)Message Priority 502 The ForCES protocol MUST provide a means to express message 503 priority. 505 6)Reliability 506 The ForCES protocol SHALL assume that it runs on top of an 507 unreliable, datagram service. For IP networks, an encapsulation of 508 the ForCES protocol SHALL be defined that uses a [RFC2914]-compliant 509 transport protocol and provides a datagram service (that could be 510 unreliable). For non-IP networks, additional encapsulations MAY be 511 defined so long as they provide a datagram service to the ForCES 512 protocol. However, since some messages will need to be reliably 513 delivered to FEs, the ForCES protocol MUST provide internal support 514 for reliability mechanisms such as message acknowledgements and/or 515 state change confirmations. 517 8. Security Considerations 519 See architecture requirement #5 and protocol requirement #2. 521 9. References 523 [DS-PIB] M. Fine, et. al., "Differentiated Services Quality of 524 Service Policy Information Base", work in progress, November 2001, 525 . 527 [REQ-PART] T. Anderson, C. Wang, J. Buerkle, "Requirements for the 528 Dynamic Partitioning of Network Elements", work in progress, August 529 2001, . 531 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", 532 RFC1812, June 1995. 534 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load 535 Network Element Service", RFC2211, September 1997. 537 [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of 538 Guaranteed Quality of Service", RFC2212, September 1997. 540 [RFC2212] S. Shenker, J. Wroclawski, "General Characterization 541 Parameters for Integrated Service Network Elements", RFC2215, 542 September 1997. 544 [RFC2914] S. Floyd, "Congestion Control Principles", RFC2914, 545 September 2000. 547 10. Authors' Addresses 549 Todd A. Anderson 550 Intel Labs 551 2111 NE 25th Avenue 552 Hillsboro, OR 97124 USA 553 Phone: +1 503 712 1760 554 Email: todd.a.anderson@intel.com 556 Ed Bowen 557 IBM Zurich Research Laboratory 558 Saumerstrasse 4 559 CH-8803 Rueschlikon Switzerland 560 Phone: +41 1 724 83 68 561 Email: edbowen@us.ibm.com 563 Ram Dantu 564 Netrake Corporation 565 3000 Technology Drive, #100, 566 Plano, Texas, 75074 567 rdantu@netrake.com 568 214 291 1111 570 Avri Doria 571 Phone: +1 401 663 5024 572 Email: avri@acm.org 574 Jamal Hadi Salim 575 Znyx Networks 576 Ottawa, Ontario 577 Canada 578 Email: hadi@znyx.com 580 Hormuzd Khosravi 581 Intel Labs 582 2111 NE 25th Avenue 583 Hillsboro, OR 97124 USA 584 Phone: +1 503 264 0334 585 Email: hormuzd.m.khosravi@intel.com 587 Muneyb Minhazuddin 588 Avaya Inc. 589 123, Epping road, 590 North Ryde, NSW 2113, Australia 591 Phone: +61 2 9352 8620 592 email: muneyb@avaya.com 594 Margaret Wasserman 595 Wind River 596 10 Tara Blvd., Suite 330 597 Nashua, NH 03062 598 Phone: +1 603 897 2067 599 Email: mrw@windriver.com