idnits 2.17.1 draft-gandhi-ippm-stamp-srpm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 29, 2021) is 1064 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) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: October 31, 2021 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 R. Foote 12 Nokia 13 April 29, 2021 15 Simple TWAMP (STAMP) Extensions for Segment Routing Networks 16 draft-gandhi-ippm-stamp-srpm-03 18 Abstract 20 Segment Routing (SR) leverages the source routing paradigm. SR is 21 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 22 (SRv6) data planes. This document specifies RFC 8762 (Simple Two-Way 23 Active Measurement Protocol (STAMP)) extensions for SR networks, for 24 both SR-MPLS and SRv6 data planes by augmenting the optional 25 extensions defined in RFC 8972. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 31, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 63 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 65 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 3 66 3. Destination Node Address TLV . . . . . . . . . . . . . . . . 4 67 4. Return Path TLV . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Return Path Sub-TLVs . . . . . . . . . . . . . . . . . . 6 69 4.1.1. Return Path Control Code Sub-TLV . . . . . . . . . . 6 70 4.1.2. Return Address Sub-TLV . . . . . . . . . . . . . . . 7 71 4.1.3. Return Segment List Sub-TLVs . . . . . . . . . . . . 8 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 7.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Segment Routing (SR) leverages the source routing paradigm and 83 greatly simplifies network operations for Software Defined Networks 84 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 85 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR Policies as defined 86 in [I-D.ietf-spring-segment-routing-policy] are used to steer traffic 87 through a specific, user-defined paths using a stack of Segments. 88 Built-in SR Performance Measurement (PM) is one of the essential 89 requirements to provide Service Level Agreements (SLAs). 91 The Simple Two-way Active Measurement Protocol (STAMP) provides 92 capabilities for the measurement of various performance metrics in IP 93 networks [RFC8762] without the use of a control channel to pre-signal 94 session parameters. [RFC8972] defines optional extensions for STAMP. 96 The STAMP test packets are transmitted along an IP path between a 97 Session-Sender and a Session-Reflector to measure performance delay 98 and packet loss along that IP path. It may be desired in SR networks 99 that the same path (same set of links and nodes) between the Session- 100 Sender and Session-Reflector is used for the STAMP test packets in 101 both directions. This is achieved by using the STAMP [RFC8762] 102 extensions for SR-MPLS and SRv6 networks specified in this document 103 by augmenting the optional extensions defined in [RFC8972]. 105 2. Conventions Used in This Document 107 2.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119] [RFC8174] 112 when, and only when, they appear in all capitals, as shown here. 114 2.2. Abbreviations 116 MPLS: Multiprotocol Label Switching. 118 PM: Performance Measurement. 120 SID: Segment ID. 122 SL: Segment List. 124 SR: Segment Routing. 126 SR-MPLS: Segment Routing with MPLS data plane. 128 SRv6: Segment Routing with IPv6 data plane. 130 SSID: STAMP Session Identifier. 132 STAMP: Simple Two-way Active Measurement Protocol. 134 2.3. Reference Topology 136 In the reference topology shown below, the STAMP Session-Sender R1 137 initiates a STAMP test packet and the STAMP Session-Reflector R3 138 transmits a reply test packet. The reply test packet may be 139 transmitted to the STAMP Session-Sender R1 on the same path (same set 140 of links and nodes) or a different path in the reverse direction from 141 the path taken towards the Session-Reflector. 143 The nodes R1 and R3 may be connected via a link or an SR path 144 [RFC8402]. The link may be a physical interface, virtual link, or 145 Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The 146 SR path may be an SR Policy [I-D.ietf-spring-segment-routing-policy] 147 on node R1 (called head-end) with destination to node R3 (called 148 tail-end). 150 T1 T2 151 / \ 152 +-------+ Test Packet +-------+ 153 | | - - - - - - - - - ->| | 154 | R1 |=====================| R3 | 155 | |<- - - - - - - - - - | | 156 +-------+ Reply Test Packet +-------+ 157 \ / 158 T4 T3 160 STAMP Session-Sender STAMP Session-Reflector 162 Reference Topology 164 3. Destination Node Address TLV 166 The STAMP Session-Sender may need to transmit test packets to the 167 STAMP Session-Reflector with a different destination address not 168 matching an address on the Session-Reflector e.g. when the STAMP test 169 packet is encapsulated by a tunneling protocol or an MPLS Segment 170 List with IPv4 address from 127/8 range. In an error condition, the 171 STAMP test packet may not reach the intended STAMP Session-Reflector, 172 an un-intended node may transmit reply test packets resulting in 173 reporting of invalid measurement metrics. 175 [RFC8972] defines STAMP test packets that can include one or more 176 optional TLVs. In this document, Destination Node Address TLV (Type 177 TBA1) is defined for STAMP test packet [RFC8972] and has the 178 following format shown in Figure 1: 180 0 1 2 3 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |STAMP TLV Flags| Type=TBA1 | Length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Reserved | Address Family | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 . Address . 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 1: Destination Node Address TLV Format 192 The Address Family field indicates the type of the address, and it 193 SHALL be set to one of the assigned values in the "IANA Address 194 Family Numbers" registry. 196 The STAMP TLV Flags are set using the procedures described in 197 [RFC8972]. 199 The Destination Node Address TLV is optional. The Destination Node 200 Address TLV indicates the address of the intended Session-Reflector 201 node of the test packet. The STAMP Session-Reflector that supports 202 this TLV, MUST NOT transmit reply test packet if it is not the 203 intended destination node of the received Session-Sender test packet. 205 4. Return Path TLV 207 For end-to-end SR paths, the STAMP Session-Reflector may need to 208 transmit the reply test packet on a specific return path. The STAMP 209 Session-Sender can request this in the test packet to the STAMP 210 Session-Reflector using a Return Path TLV. With this TLV carried in 211 the STAMP Session-Sender test packet, signaling and maintaining 212 dynamic SR network state for the STAMP sessions on the Session- 213 Reflector are avoided. 215 For links, the STAMP Session-Reflector may need to transmit the reply 216 test packet on the same incoming link in the reverse direction. The 217 STAMP Session-Sender can request this in the test packet to the STAMP 218 Session-Reflector using a Return Path TLV. 220 [RFC8972] defines STAMP test packets that can include one or more 221 optional TLVs. In this document, the TLV Type (value TBA2) is 222 defined for the Return Path TLV that carries the return path for the 223 STAMP Session-Sender test packet. The format of the Return Path TLV 224 is shown in Figure 2: 226 0 1 2 3 227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |STAMP TLV Flags| Type=TBA2 | Length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Return Path Sub-TLVs | 232 . . 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2: Return Path TLV 237 The STAMP TLV Flags are set using the procedures described in 238 [RFC8972]. 240 The Return Path TLV is optional. The STAMP Session-Sender MUST only 241 insert one Return Path TLV in the STAMP test packet. The STAMP 242 Session-Reflector that supports this TLV, MUST only process the first 243 Return Path TLV in the test packet and ignore other Return Path TLVs 244 if present, and it MUST NOT add Return Path TLV in the reply test 245 packet. 247 4.1. Return Path Sub-TLVs 249 The Return Path TLV contains one or more Sub-TLVs to carry the 250 information for the requested return path. A Return Path Sub-TLV can 251 carry Return Path Control Code, Return Path IP Address or Return Path 252 Segment List. 254 The STAMP Sub-TLV Flags are set using the procedures described in 255 [RFC8972]. 257 When Return Path Sub-TLV is present in the Session-Sender test 258 packet, the STAMP Session-Reflector that supports this TLV, MUST 259 transmit reply test packet using the return path information 260 specified in the Return Path Sub-TLV. 262 A Return Path TLV MUST NOT contain both Control Code Sub-TLV as well 263 as Return Address or Return Segment List Sub-TLV. 265 4.1.1. Return Path Control Code Sub-TLV 267 The format of the Return Path Control Code Sub-TLV is shown in 268 Figure 3. The Type of the Return Path Control Code Sub-TLV is 269 defined as following: 271 o Type (value 1): Return Path Control Code. The STAMP Session- 272 Sender can request the STAMP Session-Reflector to transmit the 273 reply test packet based on the flags defined in the Control Code 274 field. 276 0 1 2 3 277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |STAMP TLV Flags| Type | Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Control Code | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 3: Control Code Sub-TLV in Return Path TLV 286 Control Code Flags (32-bit): Defined as follows. 288 0x0: No Reply Requested. 290 0x1: Reply Requested on the Same Link. 292 When Control Code flag is set to 0x0 in the STAMP Session-Sender test 293 packet, the Session-Reflector does not transmit reply test packet to 294 the Session-Sender and terminates the STAMP test packet. Optionally, 295 the Session-Reflector may locally stream performance metrics via 296 telemetry using the information from the received test packet. All 297 other Return Path Sub-TLVs are ignored in this case. 299 When Control Code flag is set to 0x1 in the STAMP Session-Sender test 300 packet, the Session-Reflector transmits the reply test packet over 301 the same incoming link where the test packet is received in the 302 reverse direction towards the Session-Sender. 304 4.1.2. Return Address Sub-TLV 306 The STAMP reply test packet may be transmitted to a different node 307 than the Session-Sender (e.g. to a controller for telemetry use- 308 cases). For this, the Session-Sender can specify in the test packet 309 the receiving destination node address for the Session-Reflector 310 reply test packet. 312 The format of the Return Address Sub-TLV is shown in Figure 4. The 313 Address Family field indicates the type of the address, and it SHALL 314 be set to one of the assigned values in the "IANA Address Family 315 Numbers" registry. The Type of the Return Address Sub-TLV is defined 316 as following: 318 o Type (value 2): Return Address. Destination node address of the 319 STAMP Session-Reflector reply test packet different than the 320 Source Address in the Session-Sender test packet. 322 0 1 2 3 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 |STAMP TLV Flags| Type | Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Reserved | Address Family | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 . Address . 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 4: Return Address Sub-TLV in Return Path TLV 334 4.1.3. Return Segment List Sub-TLVs 336 The format of the Segment List Sub-TLVs in the Return Path TLV is 337 shown in Figure 5. The segment entries MUST be in network order. 338 The Segment List Sub-TLV can be one of the following Types: 340 o Type (value 3): SR-MPLS Label Stack of the Return Path 342 o Type (value 4): SRv6 Segment List of the Return Path 344 0 1 2 3 345 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |STAMP TLV Flags| Type | Length | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Segment(1) | 350 . . 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 . . 353 . . 354 . . 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Segment(n) (bottom of stack) | 357 . . 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Figure 5: Segment List Sub-TLV in Return Path TLV 362 An SR-MPLS Label Stack Sub-TLV may carry only Binding SID 363 [I-D.ietf-pce-binding-label-sid] of the Return SR-MPLS Policy. 365 An SRv6 Segment List Sub-TLV may carry only Binding SID 366 [I-D.ietf-pce-binding-label-sid] of the Return SRv6 Policy. 368 The STAMP Session-Sender MUST only insert one Segment List Return 369 Path Sub-TLV in the test packet. The STAMP Session-Reflector MUST 370 only process the first Segment List Return Path Sub-TLV in the test 371 packet and ignore other Segment List Return Path Sub-TLVs if present. 373 5. Security Considerations 375 The performance measurement is intended for deployment in well- 376 managed private and service provider networks. As such, it assumes 377 that a node involved in a measurement operation has previously 378 verified the integrity of the path and the identity of the STAMP 379 Session-Reflector. 381 If desired, attacks can be mitigated by performing basic validation 382 and sanity checks, at the STAMP Session-Sender, of the timestamp 383 fields in received reply test packets. The minimal state associated 384 with these protocols also limits the extent of measurement disruption 385 that can be caused by a corrupt or invalid test packet to a single 386 test cycle. 388 The security considerations specified in [RFC8762] and [RFC8972] also 389 apply to the extensions defined in this document. 391 6. IANA Considerations 393 IANA will create a "STAMP TLV Type" registry for [RFC8972]. IANA is 394 requested to allocate a value for the following Destination Address 395 TLV Type from the IETF Review TLV range of this registry. This TLV 396 is to be carried in the STAMP test packets. 398 o Type TBA1: Destination Node Address TLV 400 IANA is also requested to allocate a value for the following Return 401 Path TLV Type from the IETF Review TLV range of the same registry. 402 This TLV is to be carried in the STAMP test packets. 404 o Type TBA2: Return Path TLV 406 IANA is requested to create a sub-registry for "Return Path Sub-TLV 407 Type". All code points in the range 1 through 175 in this registry 408 shall be allocated according to the "IETF Review" procedure as 409 specified in [RFC8126]. Code points in the range 176 through 239 in 410 this registry shall be allocated according to the "First Come First 411 Served" procedure as specified in [RFC8126]. Remaining code points 412 are allocated according to Table 1: 414 +-----------+--------------+---------------+ 415 | Value | Description | Reference | 416 +-----------+--------------+---------------+ 417 | 0 | Reserved | This document | 418 | 1 - 175 | Unassigned | This document | 419 | 176 - 239 | Unassigned | This document | 420 | 240 - 251 | Experimental | This document | 421 | 252 - 254 | Private Use | This document | 422 | 255 | Reserved | This document | 423 +-----------+--------------+---------------+ 425 Table 1: Return Path Sub-TLV Type Registry 427 IANA is requested to allocate the values for the following Sub-TLV 428 Types from this registry. 430 o Type (value 1): Return Path Control Code 432 o Type (value 2): Return Address 434 o Type (value 3): SR-MPLS Label Stack of the Return Path 436 o Type (value 4): SRv6 Segment List of the Return Path 438 7. References 440 7.1. Normative References 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, 444 DOI 10.17487/RFC2119, March 1997, 445 . 447 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 448 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 449 May 2017, . 451 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 452 Two-Way Active Measurement Protocol", RFC 8762, 453 DOI 10.17487/RFC8762, March 2020, 454 . 456 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 457 and E. Ruffini, "Simple Two-Way Active Measurement 458 Protocol Optional Extensions", RFC 8972, 459 DOI 10.17487/RFC8972, January 2021, 460 . 462 7.2. Informative References 464 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 465 Decraene, B., Litkowski, S., and R. Shakir, "Segment 466 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 467 July 2018, . 469 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 470 Writing an IANA Considerations Section in RFCs", BCP 26, 471 RFC 8126, DOI 10.17487/RFC8126, June 2017, 472 . 474 [I-D.ietf-spring-segment-routing-policy] 475 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 476 P. Mattes, "Segment Routing Policy Architecture", draft- 477 ietf-spring-segment-routing-policy-09 (work in progress), 478 November 2020. 480 [I-D.ietf-pce-binding-label-sid] 481 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 482 and C. Li, "Carrying Binding Label/Segment Identifier in 483 PCE-based Networks.", draft-ietf-pce-binding-label-sid-08 484 (work in progress), April 2021. 486 [IEEE802.1AX] 487 IEEE Std. 802.1AX, "IEEE Standard for Local and 488 metropolitan area networks - Link Aggregation", November 489 2008. 491 Acknowledgments 493 The authors would like to thank Thierry Couture for the discussions 494 on the use-cases for Performance Measurement in Segment Routing. The 495 authors would also like to thank Greg Mirsky, Mike Koldychev, Gyan 496 Mishra, Tianran Zhou, and Cheng Li for providing comments and 497 suggestions. 499 Authors' Addresses 501 Rakesh Gandhi (editor) 502 Cisco Systems, Inc. 503 Canada 505 Email: rgandhi@cisco.com 507 Clarence Filsfils 508 Cisco Systems, Inc. 510 Email: cfilsfil@cisco.com 512 Daniel Voyer 513 Bell Canada 515 Email: daniel.voyer@bell.ca 516 Mach(Guoyi) Chen 517 Huawei 519 Email: mach.chen@huawei.com 521 Bart Janssens 522 Colt 524 Email: Bart.Janssens@colt.net 526 Richard Foote 527 Nokia 529 Email: footer.foote@nokia.com