idnits 2.17.1 draft-ozugur-ccamp-gmpls-label-flag-00.txt: -(463): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(464): 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): ---------------------------------------------------------------------------- ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 11 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 59 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: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (May 2002) is 8010 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: '1-6' is mentioned on line 180, but not defined == Missing Reference: '3-8' is mentioned on line 180, but not defined == Missing Reference: '5-8' is mentioned on line 184, but not defined == Missing Reference: '3-4' is mentioned on line 186, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-08 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-07 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-06 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-02 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group T. Ozugur 3 Category: Internet Draft D. Papadimitriou 4 Document: draft-ozugur-ccamp-gmpls-label-flag-00.txt Alcatel 6 May 2002 8 Label Set Priority and Flagging Operations 10 draft-ozugur-ccamp-gmpls-label-flag-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document presents the GMPLS Signaling mechanisms referred to as 35 generalized label flagging method, and RSVP-TE/CR-LDP specific 36 signaling extensions formats needed to ease forward-link label 37 unavailability when the downstream label selection is restricted by 38 the upstream node using the Label Set. It also relaxes backward-link 39 label collision when the downstream label collides with competing 40 label selection. This method introduces the Flagged Label Set 41 object/TLV in order to prioritize the reservation of the labels 42 included in the Label Set enabling to decrease the forward- and 43 backward-link blocking probability. 45 1. Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in RFC-2119. 51 T.Ozugur et al. Expires November 2002 1 52 2. Introduction 54 In Generalized MPLS context (see [GMPLS-ARCH] and [GMPLS-SIG]), a 55 Generalized Label may represent a specific fiber, wavelength, or 56 timeslot. If wavelength converters are available at a given optical 57 LSR, a label, which represents the wavelength sub-interface (for a 58 given incoming interface) may correspond to another wavelength at a 59 given outgoing interface. Otherwise, incoming-outgoing pair uses the 60 same wavelength assigned through their corresponding label value for 61 this connection. 63 In this context, a connection setup request may fail due to one of 64 two blocking events, namely forward-link and backward-link blocking. 65 Forward-link blocking occurs when the resources are not available on 66 the forward (i.e. outgoing) link while the signalling request 67 travels in the downstream direction. Backward-link blocking happens 68 when for more than one connection request the same wavelength (i.e. 69 the same label) over the same interface is selected i.e. when the 70 signalling response flows towards the ingress node. Forward-link 71 blocking is the reasoning of insufficient label resources and non- 72 load balancing routing algorithms. Backward-link blocking happens 73 due to label conflict during (label) reservation. 75 Therefore, assigned labels may collide and result in failure during 76 the connection establishment. The Label Set (see [GMPLS-SIG]) is 77 used to restrict label range values that may be used for a 78 particular LSP setup between two peers. The receiver of a Label Set 79 must restrict its label choice (i.e. the selection) to one of the 80 label within the set. Thus, the labels included in the Label Set 81 restrict the labels that can be selected by the egress node. 82 However, the selection method can be improved in order to provide an 83 efficient solution to the label-collision problem and in turn 84 decrease the wavelength blocking probability. This even if feedback 85 is allowed using the Acceptable Label Set commodity (see [GMPLS- 86 SIG]). 88 This document presents the GMPLS Signalling mechanisms (referred to 89 as generalized label flagging method) and RSVP-TE/CR-LDP specific 90 signaling extensions formats needed to ease forward-link label 91 unavailability when the downstream label selection is restricted by 92 the upstream node using the Label Set (see [GMPLS-SIG]). It also 93 relaxes backward-link label collision when the downstream label 94 collides with competing label selection. This method introduces the 95 Flagged Label Set object/TLV in order to prioritize the reservation 96 of the labels included in the Label Set and enabling to decrease the 97 forward- and backward-link blocking probability. 99 In order to prioritize the label reservation, each set of labels is 100 inserted by each node along the path into the Flagged Label Set 101 object/TLV with a certain priority. Each node keeps track of each 102 label by using a local timestamp indicating when the label has been 103 reserved but not selected yet with respect to any other previous 104 label set. A pool, which is referred to as Flagged Pool (besides the 106 T.Ozugur et al. Expires November 2002 2 107 Used Pool and Available Pool), points to these labels. Therefore, 108 this pool provides a gray area for the labels, which are subject to 109 collision, and thus being in an intermediate state between the 110 labels belonging to the Used Pool (reserved and selected) and the 111 ones belonging to the Available Pool (neither reserved or selected). 113 The Flagged Pool uses a local timestamp information for label 114 selection purposes. Moreover, the corresponding Flagged Label Set 115 object/TLV restricts the choice of the downstream node by using 116 several priority levels. This enables relaxing the usage of the 117 label set. In turn, by means of a specific threshold mechanism the 118 number of label collisions during the label selection phase can be 119 minimized. 121 Consider for instance the following network topology and lambda LSP 122 requests from source to destination: LSP1 (1 -> 6), LSP2 (2 -> 4) 123 and LSP3 (3 -> 5) 125 2 4 126 | | 127 | | 128 | | 129 1 ----- A ----- B ----- C ----- D ----- 6 130 | | 131 | | 132 | | 133 3 5 135 In this context, the following situations would have occurred when 136 Node 1 then Node 2 sends sequentially (or at least Node 1 Path 137 message is sent before the Resv message of the first connection 138 request reaches Node A) a connection request to setup LSP1 and LSP2, 139 respectively. The Node A Label Set policy may be as follows: 141 1. LSP1 Label Set is disjoint from LSP2 Label Set: no blocking 143 2. LSP1 Label Set overlap with LSP2 Label Set: in order to avoid 144 blocking, the resulting LSP2 Label Set should include the label 145 corresponding to the Label Set values of LSP2 minus the 146 overlapping values. In order to give precedence the following is 147 considered using the proposed approach: set non-intersecting 148 values to a higher priority (and include them in a default Label 149 Set object/TLV) and the intersecting ones to a lower priority 150 (and include them in a Flagged Label Set object/TLV). At 151 subsequent nodes, selection will be first performed on highest 152 priority labels. 154 3. LSP1 and LSP2 Label Set are embedded: 156 3a. LSP1 Label Set larger than LSP2 Label Set: 158 No action capable to avoid blocking since dependent on 159 subsequent decisions by the corresponding egress nodes. 161 T.Ozugur et al. Expires November 2002 3 162 3b. LSP1 Label Set smaller than Node 2 Label Set: 164 Node A to reduce Node 2 Label Set to their difference in 165 order to avoid any blocking probability. In order to give 166 precedence the following is considered using the proposed 167 approach: set non-intersecting values to a higher priority 168 and the intersecting ones to a lower priority. Corresponding 169 labels are respectively included in a default (non-flagged) 170 Label Set object/TLV or in a Flagged Label Set object/TLV. At 171 subsequent nodes, selection will be first performed on 172 highest priority labels. 174 The proposed (backward compatible) approach enable to enhance the 175 processing that would normally occur with common Label Set policy by 176 enabling to cover cases 2 and 3b in a more effective way. 178 For instance, as currently defined in [GMPLS-SIG], Node 1 (Node 2) 179 for LSP1 (for LSP2) would use a Label Set object/TLV including the 180 label range [1-6] ([3-8]) restricted by Node A to [1-6] ([5-8], 181 respectively). Consider now that Node 6 support only label 6 and 182 Node 4 only label 4. In such a case, LSP2 connection would be 183 rejected. Using the Flagged Label Set approach, Node A would use a 184 higher priority non-Flagged Label Set including the label range [5- 185 8] and a lower priority Flagged Label Set including the label range 186 [3-4]. Obviously, if both requests arrives simultaneously at Node A, 187 LSP1 (LSP2) would use the following label set {[1-2], [3-6]} ({[7- 188 8], [3-6]}, respectively). 190 4. Generalized Label Flagging Method 192 This section modifies the Label Set object/TLV to be carried in the 193 Path/Label Request message while requesting a label. 195 To deal with the label blocking issues (i.e. unavailability and 196 collision) described in the Section 2, a modified form of Label Set 197 object/TLV is required, which is referred to as Flagged Label Set 198 object/TLV. This object/TLV is identical to the Label Set object/TLV 199 as defined in [GMPLS-SIG] except that it introduced a new Flag field 200 in its Reserved field. 202 4.1. Flagged Label Set Object/TLV 204 The Label Set is used to limit the label choices of a downstream 205 node to a set of acceptable labels. This limitation applies on a per 206 hop basis. The Label Set can for instance be specified on an end-to- 207 end basis in the optical domain, where there is a sequence of 208 interfaces which cannot support wavelength conversion (CI-incapable) 209 and require the same wavelength be used end-to-end over a sequence 210 of hops, or even an entire path. 212 A Label Set is composed of one or more Label Set objects/TLVs 213 [GMPLS-SIG] including (or excluding) one or more elements referred 215 T.Ozugur et al. Expires November 2002 4 216 to as a sub-channel identifiers which have the same format as a 217 Generalized Label. 219 Here, the Label Set is composed of one or more Flagged Label Set 220 objects/TLVs. The format Flagged Label Set object/TLV is the same as 221 the canonical Label Set object/TLV except that it includes a Flag 222 field. In RSVP-TE, the Flagged Label Set object uses Class-Number 223 TBA (of form 0bbbbbbb) and the C-Type of 1. In CR-LDP, the 224 corresponding Type field in the Flagged Label Set TLV is TBA. 226 The format of the Flagged Label Set object is: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Length | Class-Num(TBA)| C-Type (1) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Action | Flag | Reserved | Label Type | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Subchannel 1 | 236 | ... | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 : : : 239 : : : 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Subchannel N | 242 | ... | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Action: 8 bits (see [GMPLS-SIG]) 247 Flag: 4 bits: 249 The Flag field is subdivided as follows: 251 Priority (P): 2 bits 253 Indicates the priority of the Flagged Label Set object 254 0x00 Highest priority (for backward compatibility) 255 0x01 Second highest priority 256 0x10 Third highest priority 257 0x11 Lowest priority 259 Operation (O): 2 bits 261 Indicates the flagging operation (see Section 5) 263 0x00 Non-Flagging Operation (backward compatibility) 264 0x01 Aggressive Flagging Operation 265 0x10 Full Flagging Operation 266 0x11 Reserved 268 Reserved: 6 bits 270 T.Ozugur et al. Expires November 2002 5 271 This field is reserved. It MUST be set to zero on 272 Transmission and MUST be ignored on receipt. 274 Label Type: 14 bits 276 Indicates the type and format of the labels carried in the 277 object. Values match the C-Type of the appropriate Label 278 object. Only the low order 8 bits are used in this field 279 (see [GMPLS-SIG].) 281 See [GMPLS-SIG] for a description of the other fields. 283 The format of the Flagged Label Set TLV is: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |U|F| Type (TBA by IANA) | Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Action | Flag | Reserved | Label Type | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Subchannel 1 | 293 | ... | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 : : : 296 : : : 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Subchannel N | 299 | ... | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 4.2. Flagged Label Set Object/TLV Processing 304 A Path message may carry more than one Flagged Label set object/TLV, 305 where each object represents a different priority according for 306 instance to their elapsed selection period (also referred to as 307 selection time) or the corresponding LSP Setup priority. Flagged 308 Label Set objects/TLVs are the same as Label Set except for the Flag 309 field which includes the Priority and Operation fields. The Priority 310 of the Flag field indicates the selection priority of the 311 corresponding labels. Flagging operations are described in Section 312 5. Note that the Flagged Label Set objects/TLVs do not carry any 313 timestamp or clock information. Time-related information is only 314 stored locally within the Flagged Pool (FP) structure. 316 The priority indicated in the Flagged Label Set object/TLV is 317 inferred from a certain time interval referring at which the same 318 labels have been previously selected within another label set. When 319 processing a Path/Label Request message, the LSR first investigates 320 the label sub-objects listed in the highest priority Label Set 321 object(s)/TLV(s) before the ones included in lower priority Flagged 322 Label Set objects/TLV. The highest priority Label Set object/TLV 324 T.Ozugur et al. Expires November 2002 6 325 corresponds exactly to the Label Set object/TLV currently defined in 326 [GMPLS-SIG]). Consequently the proposed method is fully backward 327 compatible. 329 Moreover, each LSR keeps an entry for each label using local 330 timestamps indicating when the label has been selected. This 331 information is stored in the Flagged Pool (FP) at each LSR. When 332 processing a Path/Label Request message, the LSR investigates 333 whether the labels listed in the Flagged Label Set object(s)/TLV(s) 334 are in the FP. If any label is in the FP, the LSR calculates the 335 difference of selection time (i.e. clock�timestamp) for this label. 336 The timestamp refers to the time when this label has been previously 337 selected. 339 If the value of local time of the label indicates a lesser priority 340 than the priority of the label's current Flagged Label Set object/ 341 TLV, the LSR MUST insert the label into a Flagged Label Set object/ 342 TLV with a lesser priority. If this object doesn�t exist, the LSR 343 inserts a new Flagged Label Set object/TLV into the Path/Label 344 Request message before forwarding to downstream. 346 The key points of the Flagged Label Set object/TLV are as follows: 347 - FPs store the local timestamp of the label when it is 348 suggested; however, by taking difference of (local clock- 349 timestamp), it reaches global information to prioritize the 350 Flagged Label Set objects. 351 - LSRs use local clock timing without any synchronization. 352 However, by taking (local clock-timestamp) difference and 353 locating labels within the Flagged Label Set objects/TLVs 354 according to this difference, makes the Flagged Label Set 355 objects globally prioritized without using synchronization. 357 4.3. Backward Compatibility 359 If the Flagged Label Set object/TLV and its processing is not 360 supported, the corresponding object/TLV is ignored and not further 361 processed. 363 Moreover, when the Flagged Label Set object/TLV is supported its 364 highest priority (see Section 4.1) corresponds exactly to the Label 365 Set object/TLV as defined in [GMPLS-SIG]. 367 5. Flagging Operation and Procedure 369 The flagging operation using Flagged Label Set objects/TLVs at each 370 LSR can be grouped into two modes in addition to the Non Flagging 371 default operation: 1) Aggressive Flagging Operation, 2) Full 372 Flagging Operation. The Operation (O) field in the Flagged Label Set 373 object indicates which flagging operation is in use. 375 In the Aggressive Flagging Operation method, the label is extracted 376 from the Flagged Label Set object(s) and Label Set object(s), and 377 the label is not advertised in any of these objects while forwarding 379 T.Ozugur et al. Expires November 2002 7 380 the Path message in the downstream direction. In Full Flagging 381 Operation method, any label whose in the Flagged Pool, is inserted 382 into a corresponding Flagged Label Set object before forwarding the 383 Path message downstream. 385 The Flagged Label Set object/TLV with the priority field set to 0x11 386 has the lowest priority and represents the labels, which have been 387 recently selected for another LSP. The Flagged Label Set object/TLV 388 with the priority field set to 0x10 has the third highest priority. 389 In other words, labels within this object with the priority field 390 set to 0x10 have been selected some time ago such that the 391 probability of previous requesting LSP selected a different label is 392 lower. The Flagged Label Set object/TLV with the priority field set 393 to 0x01 has the second highest priority includes labels that have 394 been selected for a long time ago such that the probability of 395 previous requesting LSP selected a different label is quite low. 396 Last, the Flagged Label Set object/TLV with the priority set to 0x00 397 has the highest priority and include labels that are not selected 398 for any other LSPs (or any previous selection has elapsed) such that 399 the blocking probability due to their selection is the lowest. 401 At each LSR, the flagging operation is itemized as follows: 403 1. A path message with Generalized Label Request object/TLV 404 arrives to the LSR. 405 2. Investigate each label within the Flagged Label Set objects/TLV. 406 3. If the label is an element of the Available pool, then keep the 407 Label within the Flagged Label Set with its current Flag field 408 settings. 409 4. If the label is not an element of the Available Pool, then check 410 whether the label is an element of Flagged Pool (FP). 411 5. If the label is an element of the FP, the label is inserted into 412 the corresponding Flagged Label Set object/TLV and processed with 413 respect to its operation mode (aggressive 0x01 or full flagging 414 0x10) 415 6. If the label is not an element of the AP or FP, then it is an 416 element of Used Pool (UP), then remove the label from Flagged 417 Label Set object/TLV. 418 7. If all labels within the Flagged Label Set objects/TLVs are 419 investigated, terminate the procedure. Otherwise, go to item 1. 421 The downstream LSR SHOULD NOT insert a label into a higher priority 422 Flagged Label Set object than its current Flagged Label Set object. 424 Moreover, when the egress node receives the Path message, it 425 randomly selects a label among the labels within the Flagged Label 426 Set object starting with the highest priority one. For example, if 427 there is no labels in the Flagged Label Set with the priority field 428 set to 0x00, then the egress node randomly selects a label among the 429 labels within the next (highest) priority Flagged Label Set, which 430 is with the priority field set to 0x01, and so on. 432 T.Ozugur et al. Expires November 2002 8 433 6. Acknowledgments 435 Valuable comments and input were received from numerous people, 436 including Dominique Verchere, Jim Jones, Francesco Masetti, Kevin 437 Hardee and Jason Jue. 439 7. Security Considerations 441 This draft introduces no new security considerations to the 442 Generalized MPLS RSVP-TE [GMPLS-RSVP]] and CR-LDP [GMPLS-LDP] 443 Signalling extensions. 445 8. Intellectual Property Considerations 447 Alcatel is seeking patent protection on technology described in this 448 Internet-Draft. If technology in this Internet-Draft is adopted as a 449 standard, Alcatel agrees to license, on reasonable and non- 450 discriminatory terms, any patent rights it obtains covering such 451 technology to the extent necessary to comply with the standard. 453 9. References 455 [GMPLS-SIG] L.Berger et al., �Generalized MPLS - Signaling 456 Functional Description�, draft-ietf-mpls-generalized- 457 signaling-08.txt, work in progress, April 2002 459 [GMPLS-RSVP] L.Berger et al., �Generalized MPLS Signaling - RSVP-TE 460 Extensions�, draft-ietf-mpls-generalized-rsvp-te- 461 07.txt, work in progress, April 2002. 463 [GMPLS-LDP] L.Berger et al., �Generalized MPLS Signaling � CR-LDP 464 Extensions�, draft-ietf-mpls-generalized-cr-ldp-06.txt, 465 work in progress, April 2002. 467 [GMPLS-ARCH] E.Mannie et al., �Generalized Multi-Protocol Label 468 Switching (GMPLS) Architecture�, work in progress, 469 draft-ietf-ccamp-gmpls-architecture-02.txt, Feb�02. 471 10. Author's Addresses 473 Timucin Ozugur (Alcatel) 474 1000 Coit Road M/S CT02 475 Plano, TX 75075 USA 476 E-mail: tim.ozugur@alcatel.com 477 Phone: (972) 477-2737 479 Dimitri Papadimitriou (Alcatel) 480 Francis Wellesplein 1 481 B-2018 Antwerp, Belgium 482 Email: dimitri.papadimitriou@alcatel.be 483 Phone: (+32) 3 2408491 485 T.Ozugur et al. Expires November 2002 9