idnits 2.17.1 draft-jobert-tictoc-ptp-link-local-00.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 547, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 557, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'Fab1999' is defined on line 578, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TICTOC Working Group S. Jobert 2 Internet Draft France Telecom Orange 3 Intended status: Informational March 5, 2012 4 Expires: September 2012 6 Transporting PTP messages over MPLS networks 7 using a link local addressing 8 draft-jobert-tictoc-ptp-link-local-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before November 17 10, 2008. The person(s) controlling the copyright in some of this 18 material may not have granted the IETF Trust the right to allow 19 modifications of such material outside the IETF Standards Process. 20 Without obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be modified 22 outside the IETF Standards Process, and derivative works of it may 23 not be created outside the IETF Standards Process, except to format 24 it for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on September 5, 2012. 45 MPLS networks using a link local addressing 47 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. 59 Abstract 61 This document introduces a method for transporting PTP messages over 62 an MPLS network supported by an Ethernet physical layer. The MPLS 63 layer itself is not used to carry the PTP messages with this method; 64 instead, a link local Ethernet channel is used. Several advantages 65 related to this method are highlighted in this document. The method 66 targets in particular telecom applications requiring accurate 67 phase/time synchronization, with "link-by-link" PTP architectures, 68 where all the network nodes support a PTP function, such as Boundary 69 Clock or Transparent Clock. 71 Table of Contents 73 1. Introduction ................................................ 3 74 2. Conventions used in this document............................ 4 75 3. Analysis of the PTP frequency telecom profile with MPLS networks 76 ............................................................... 4 77 4. Transporting PTP messages over MPLS networks with a "link-by- 78 link" PTP architecture ......................................... 5 79 4.1. Need for identifying the PTP messages in MPLS networks... 6 80 4.2. Use of a link local addressing over MPLS networks supported 81 by an Ethernet physical layer................................ 7 82 4.3. Use of link local addressing with Transparent Clocks..... 8 83 5. Security Considerations..................................... 12 84 6. IANA Considerations ........................................ 12 85 7. References ................................................. 13 86 7.1. Normative References................................... 13 87 7.2. Informative References................................. 13 88 8. Acknowledgments ............................................ 13 89 MPLS networks using a link local addressing 91 1. Introduction 93 The Precision Time Protocol version 2 (PTPv2), defined by the 94 [IEEE1588-2008] standard, is used to support telecom applications 95 that may include MPLS networks. Telecoms applications may require 96 frequency synchronization only or accurate phase/time 97 synchronization. 99 This has led to the definition of two PTP telecom profiles at the 100 ITU-T: the Recommendation [G.8265.1] (finalized) defines a PTP 101 telecom profile for frequency synchronization in an "end-to-end" 102 mode (the intermediate network nodes do not support PTP functions) 103 and the future Recommendation G.8275.1 (under development) will 104 define a PTP telecom profile for phase/time synchronization in a 105 "link-by-link" mode (all the intermediate network nodes support PTP 106 functions). 108 For frequency applications using the ITU-T frequency profile, there 109 is no particular need to identify the PTP messages in case they are 110 carried in an MPLS layer. The use of a high priority class of 111 service is in general sufficient to minimize the Packet Delay 112 Variation (PDV) introduced by the network nodes. The identification 113 of the PTP messages in a network node which does not support PTP 114 functions is not expected in general to provide a better performance 115 than the positioning of the PTP messages in a dedicated high 116 priority queue. 118 For phase/time applications with stringent requirements (e.g. sub- 119 micro-second accuracy), it is in general recognized that PTP support 120 from the network nodes is required to avoid the generation of Packet 121 Delay Variation. Therefore, being able to identify the PTP messages 122 is considered important. This is the one of the objectives of the 123 definition of a PTP mapping. Some mappings are already defined in 124 the [IEEE1588-2008] standard, and may be applicable to an MPLS 125 network. 127 This document introduces a method for transporting PTP messages over 128 an MPLS network supported by an Ethernet physical layer. The MPLS 129 layer itself is not used to carry the PTP messages with this method; 130 instead, a link local Ethernet channel is used. 132 Several advantages related to this method are highlighted in this 133 document. The method targets in particular telecom applications 134 requiring accurate phase/time synchronization, with "link-by-link" 135 PTP architectures, where all the network nodes support a PTP 136 function, such as Boundary Clock (BC) or Transparent Clock (TC). 138 MPLS networks using a link local addressing 140 2. Conventions used in this document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC-2119 [RFC2119]. 146 In this document, these words will appear with that interpretation 147 only when in ALL CAPS. Lower case uses of these words are not to be 148 interpreted as carrying RFC-2119 significance. 150 PTP: Precision Time Protocol 152 PDV: Packet Delay Variation 154 BC: Boundary Clock 156 TC: Transparent Clock 158 3. Analysis of the PTP frequency telecom profile with MPLS networks 160 For applications requiring frequency synchronization only, when the 161 use of physical layer synchronization methods such as Synchronous 162 Ethernet is not possible, the ITU-T PTP frequency telecom profile 163 defined in the Recommendation G.8265.1 is in general relevant, 164 especially in order to address mobile networks needs. 166 This PTP telecom profile is based on an "end-to-end" PTP 167 architecture: the intermediate network nodes do not support PTP 168 functions such as Boundary Clock (BC) or Transparent Clock (TC). As 169 such, they generate Packet Delay Variation (PDV). The PTP 170 communication is only performed between a PTP master function and a 171 PTP slave function. 173 This PTP dialog may involve different layers, due to different 174 encapsulations. In particular, it is common that PTP messages are 175 carried within an MPLS layer when using this PTP profile. 177 In order to minimize the PDV generated by the intermediate network 178 nodes, PTP messages MUST be marked as high priority traffic, and 179 MUST be positioned in high priority queues. This marking does not 180 involve new PTP functions in the network nodes; it corresponds 181 simply to the usual DiffServ functions supported in these devices. 183 MPLS networks using a link local addressing 185 In particular, the intermediate network nodes do not identify the 186 PTP messages among the rest of the traffic; only the marking of the 187 packets is considered to position them in the relevant queues. 189 The identification of the PTP messages by an intermediate network 190 node which does not support PTP functions with this PTP frequency 191 telecom profile is not expected in general to provide real 192 performance improvements compared to the prioritization of the PTP 193 traffic and the positioning of the PTP messages in a dedicated high 194 priority queue. 196 Indeed, more specialized treatment of the PTP messages would make 197 the network node very close to a node supporting PTP functions such 198 as Boundary Clocks or Transparent Clocks. This would be quite 199 contradictory to the architecture assumptions of this PTP frequency 200 telecom profile. 202 In conclusion, when the ITU-T PTP frequency telecom profile defined 203 in the Recommendation G.8265.1 is used, the identification of the 204 PTP messages among the rest of the MPLS traffic does neither appear 205 necessary, nor providing real performance benefits. 207 4. Transporting PTP messages over MPLS networks with a "link-by-link" 208 PTP architecture 210 For applications requiring accurate phase/time synchronization, the 211 use of the future ITU-T PTP phase/time telecom profile under 212 definition in the Recommendation G.8275.1 is foreseen to be relevant 213 to address the needs of mobile networks. 215 This PTP telecom profile is based on a "link-by-link" PTP 216 architecture: the intermediate network nodes MUST support PTP 217 functions such as Boundary Clock or Transparent Clock. This 218 architecture is considered as necessary to avoid the generation of 219 Packet Delay Variation, due to the stringent accuracy requirements 220 that are targeted. The PTP communication is therefore performed 221 between different PTP entities: PTP master function, PTP slave 222 function, PTP Boundary Clocks, PTP Transparent Clocks. 224 Hence, being able to identify the PTP messages is considered 225 important, in order to allow the intermediate network nodes to apply 226 the special treatment on the PTP packets corresponding to the PTP 227 function that they implement (BC or TC). 229 MPLS networks using a link local addressing 231 This is one of the objectives of the definition of a PTP mapping. 232 Some mappings are already defined in the [IEEE1588-2008] standard, 233 and may be applicable to an MPLS network. The transport of PTP 234 messages over MPLS networks SHOULD NOT involve the MPLS layer itself 235 in this type of "link-by-link" PTP architecture. 237 4.1. Need for identifying the PTP messages in MPLS networks 239 The "link-by-link" PTP architecture described above may be 240 applicable over MPLS networks. As such, it is relevant to discuss 241 the mapping options for transporting the PTP messages over MPLS 242 networks when considering this type of PTP architecture. 244 Two PTP operations may be necessary in the MPLS nodes in order to 245 handle the PTP packets in the general case: 247 o PTP packets detection: how to detect that a packet contains PTP 248 payload? (this question is applicable to both Boundary Clock or 249 Transparent Clock types of PTP support) 251 o PTP payload position in the packet: how to determine where the 252 PTP payload is in the message once the relevant packets have been 253 detected? (this question is applicable only to Transparent Clock 254 PTP support, because Boundary Clocks terminate and process the 255 PTP payload) 257 Regarding the first point listed above (PTP packets detection), the 258 three following mappings could be considered in the general case: 260 o in case of an Ethernet mapping, the PTP packets can be detected 261 thanks to a specific Ethertype. Some PTP mappings already defined 262 in [IEEE1588-2008] already cover this point (see Annex F). 264 o in case of an IP/UDP mapping, the PTP packets can be detected 265 thanks to specific UDP port numbers. Some PTP mapping already 266 defined in [IEEE1588-2008] already cover this point (see Annexes 267 D and E). This mapping corresponds to the mapping specified for 268 the PTP frequency telecom profile defined in [G.8265.1]. 270 MPLS networks using a link local addressing 272 o in case of MPLS mapping, if relevant, the draft [4] 273 ("Transporting PTP messages (1588) over MPLS Networks") currently 274 discussed in the IETF TICTOC Working Group aims at specifying new 275 MPLS mappings enabling to detect the PTP packets among the 276 traffic. Note that these new PTP mappings are not defined in 277 [IEEE1588-2008]. 279 This document advocates that the third type of mapping (MPLS 280 mappings) is not necessary for carrying PTP messages over MPLS 281 networks supported by an Ethernet physical layer when using a "link- 282 by-link" PTP architecture as depicted above in this document. 283 Instead, it is considered that the use of a link local addressing is 284 more relevant when the MPLS network is supported by an Ethernet 285 physical layer. This point will be discussed further in the next 286 sections of this document. 288 Regarding the second point (PTP payload position in the packet), it 289 should be stressed the network nodes may not know exactly where the 290 PTP payload is in the packet in some cases (e.g. when tunnels are 291 used), because of other potential encapsulations beyond the layer 292 handled by the node. This situation may happen in the case of MPLS 293 network nodes. In particular, as mentioned above, it raises problems 294 for modifying the PTP payload in case of a Transparent Clock PTP 295 support. 297 This document explains that the use of a link local addressing 298 simplifies this point, since the PTP payload is in this case at a 299 fixed location in the message. It is moreover in line the with the 300 principles of a "link-by-link" PTP architecture, where the PTP 301 messages are sent to the next network node, and are not assumed to 302 be forwarded through a tunnel. This point will be discussed further 303 in the next sections of this document. 305 4.2. Use of a link local addressing over MPLS networks supported by an 306 Ethernet physical layer 308 This section introduces a solution to carry PTP messages over an 309 MPLS network supported by an Ethernet physical layer, using a link 310 local Ethernet addressing. This solution fits very well with the 311 "link-by-link" PTP architecture depicted before. 313 With this solution, Ethernet interfaces supporting MPLS traffic MUST 314 use the Ethernet multicast address: '01-80-C2-00-00-0E' based on the 315 Annex F of IEEE1588-2008 for all the PTP messages that are sent. 317 MPLS networks using a link local addressing 319 This type of addressing aims at making sure that the PTP messages 320 will be sent to the next network node in the chain (which may be or 321 not an MPLS node). 323 This solution has several advantages: 325 o It prevents unwanted forwarding of PTP messages over network 326 nodes which do not provide PTP support: indeed, such a network 327 node is assumed in general to drop the PTP messages, and not to 328 forward them. It is useful in order to avoid the generation of 329 PDV. This property is considered in line with the "link-by-link" 330 PTP architecture principles depicted earlier. 332 o It facilitates the configuration for the operator, since no 333 particular addressing needs to be configured in the network 334 nodes. 336 o It allows having a consistent PTP mapping all along the chain: 337 all the PTP messages are transported the same way, using the same 338 mapping, whatever the actual layers used to transport the user 339 plane. In particular, an MPLS node may establish a PTP dialog 340 with an IP node or a node working at the layer 2 with this type 341 of solution. 343 o It facilitates the PTP payload identification, since the PTP 344 payload is necessarily at a fixed location. 346 Note: in case of MPLS nodes connected together via a different 347 physical layer than Ethernet, another link local channel linked to 348 the physical layer might be used. This is beyond the scope of this 349 document. 351 4.3. Use of link local addressing with Transparent Clocks 353 The case of Transparent Clock type of PTP support deserves a 354 specific analysis when considering the use of a link local 355 addressing. Indeed, some designs of Transparent Clock may not 356 terminate the PTP messages; it creates issues in order to forward 357 the PTP messages when link local addressing is used. 359 This section highlights however that some simple mechanisms might be 360 implemented in Transparent Clocks to ensure their compatibility with 361 the use of a link local addressing as proposed in the previous 362 MPLS networks using a link local addressing 364 section. It also shows that a link local addressing may avoid the 365 layer violation issues with TCs. 367 Three main steps are observed in a standard Transparent Clock which 368 does not terminate the PTP messages in order to treat and forward 369 them: 371 1- Detection of the PTP packet among the rest of the traffic on an 372 active PTP port, and precise timestamping of the arrival instant of 373 the packet in the network node. 375 2- The PTP packet is treated/forwarded in the network node as a 376 standard packet, e.g. analysis of the network header of the packet 377 corresponding to the layer treated by the network node, in order to 378 determine using the forwarding engine towards which output port the 379 packet must be forwarded (for instance: IP lookup operation in a 380 routing table). In summary: the output port is determined based on 381 information contained in the PTP packet itself, using standard 382 forwarding functions in the network node. 384 3- Transmission of the PTP packet at the output of the network node 385 on the port determined before, and precise timestamping of the 386 emission instant of the packet in the network. Modification of the 387 "correction field" of the packet to include the residence time 388 calculation. 390 The layer violation is due here to the fact that the PTP packet has 391 been modified (correction field update) by an intermediate node 392 which was assumed only to forward it. Moreover, there might be some 393 difficulties to determine where the PTP payload is located, as 394 mentioned earlier. 396 The use of a link local addressing might not be suitable with this 397 model of TC. Indeed, it can be observed that the step 2 requires in 398 the general case that the necessary information (e.g. final 399 destination address) would be contained in the network header of the 400 PTP messages to determine the output port where each PTP message 401 must be forwarded. This is not the case with link local addressing, 402 because each message is sent to the next node over a single link. 404 However, there are easy ways to overcome this issue. One possible 405 straightforward solution could be to include locally in the network 406 node the necessary information for the forwarding of the PTP 407 messages. This might correspond to a "PTP local forwarding 408 MPLS networks using a link local addressing 410 function", which could be part of the network node configuration 411 (manual configuration would be possible, but automatic procedures 412 would also work). 414 As for the case of a standard TC, three main steps are observed in 415 order to treat and forward a PTP message in a Transparent Clock 416 implementing a PTP local forwarding function: 418 o The step 1 is similar in both cases (standard TC and TC with PTP 419 local forwarding function). 421 o The step 2 would differ in this example (TC with PTP local 422 forwarding function): the standard forwarding function of the 423 network node (forwarding engine) MUST NOT be used in this case to 424 forward the PTP packets; instead, the PTP local forwarding 425 function MUST be used. This allows handling PTP packets without 426 forwarding information in the network header of the packet. 428 o The step 3 is quite similar in both cases (standard TC and TC 429 with PTP local forwarding function). 431 It must be stressed that the use of link local addressing leads to 432 terminate the PTP packets that are received by the network node, 433 since the recipient of the PTP messages is the network node itself. 434 The PTP packets sent at the output of the TC with PTP local 435 forwarding function are therefore new PTP packets, similarly to a 436 BC. This is the reason why it can be considered as a way to avoid 437 the layer violation issue. 439 In practice, the operations are similar between standard TC and TC 440 with PTP local forwarding function for generating a new PTP packet 441 based on the PTP packet received (e.g. update of the correction 442 field, etc...). 444 Moreover, it must also be stressed that the use of link local 445 addressing leads to a fixed location of the PTP payload in the 446 packet. This is expected to greatly simplify the operations. 448 The PTP local forwarding function includes locally in the network 449 node all the necessary information for forwarding the PTP packets. 450 For instance, it may associate one or several output ports to an 451 input port. An example of what could be a PTP local forwarding 452 function is provided in the figure 1 below. 454 MPLS networks using a link local addressing 456 +------------------------------------------------------------------+ 457 | | 458 | +------------------------------------------------------+ | 459 | | Network node | | 460 | \---/ +---+ | 461 | | x | ----------------------------------------| 4 | | 462 | /---\ / +---+ | 463 | | / | | 464 | +-----+ / | | 465 | |+---+|/ +---+ | 466 | || 2 ||--------------------------------------------| 5 | | 467 | |+---+| +---+ | 468 | +-----+ | | 469 | | +-----+ | 470 | +---+ |+---+| | 471 | | 3 |--------------------------------------------|| 6 || | 472 | +---+ |+---+| | 473 | | +-----+ | 474 | | | | 475 | +------------------------------------------------------+ | 476 | | 477 | +-----+ | 478 | |+---+| | 479 | || || Enabled PTP upstream port | 480 | |+---+| | 481 | +-----+ | 482 | | 483 | +---+ | 484 | | | Enabled PTP downstream port | 485 | +---+ | 486 | | 487 | \---/ | 488 | | x | Disabled PTP port | 489 | /---\ | 490 | | 491 +------------------------------------------------------------------+ 493 Figure 1 - Example of a possible configuration of the PTP local 494 forwarding function 496 In the figure 1 above, three configurations are possible for a PTP 497 port in a TC with PTP local forwarding function: 499 MPLS networks using a link local addressing 501 o Disabled PTP port: any potential PTP packet received on this port 502 MUST be discarded. 504 o Enabled PTP upstream port: corresponds to a port where upstream 505 PTP packets are received (e.g. the PTP packets generated by a PTP 506 master port). When a PTP packet is received on an enabled PTP 507 upstream port, a new PTP packet MUST be transmitted by one or 508 several enabled PTP downstream ports of the network node 509 associated to the enabled PTP upstream port. This/these new PTP 510 packet(s) is/are formed using the information of the original PTP 511 packet that was received, and by modifying the fields normally 512 modified by a TC (the correction field in particular). 514 o Enabled PTP downstream port: corresponds to a port where 515 downstream PTP packets are received (e.g. the PTP packets 516 generated by a PTP slave port). When a PTP packet is received on 517 an enabled PTP downstream port, a new PTP packet MUST be 518 transmitted by the enabled PTP upstream port of the network node 519 associated to the enabled PTP downstream port. This new PTP 520 packet is formed using the information of the original PTP packet 521 that was received, and by modifying the fields normally modified 522 by a TC (the correction field in particular). 524 Note that the case of a two-port device is an example where implicit 525 PTP local forwarding function exists: every port PTP packet received 526 on one port must be forwarded by the other port. 528 The advantages of this type of mechanism are that it allows mixing 529 BCs and TCs in a chain in a consistent way, using link local 530 addressing. It also allows avoiding layer violation issues, since 531 the PTP messages are terminated and processed by each network node, 532 including the TC with PTP local forwarding function. 534 5. Security Considerations 536 538 6. IANA Considerations 540 541 MPLS networks using a link local addressing 543 7. References 545 7.1. Normative References 547 [1] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 551 Syntax Specifications: ABNF", RFC 2234, Internet Mail 552 Consortium and Demon Internet Ltd., November 1997. 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 558 Syntax Specifications: ABNF", RFC 2234, Internet Mail 559 Consortium and Demon Internet Ltd., November 1997. 561 [IEEE1588-2008] IEEE 1588-2008, "IEEE Standard for a Precision 562 Clock Synchronization Protocol for Networked Measurement 563 and Control Systems", July 2008. 565 [G.8265.1] ITU-T Recommendation G.8265.1 "Precision time protocol 566 telecom profile for frequency synchronization", October 567 2010. 569 7.2. Informative References 571 [3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 572 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 573 1583. 575 [4] Davari, Oren, Bhatia, Roberts, Montini "Transporting PTP 576 messages (1588) over MPLS Networks", October 2011 578 [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in 579 TCP and Its Effect on Busy Servers", Proc. Infocom 1999 580 pp. 1573-1583. 582 8. Acknowledgments 584 This document was prepared using 2-Word-v2.0.template.dot. 586 MPLS networks using a link local addressing 588 Authors' Addresses 590 Sebastien Jobert 591 France Telecom Orange 592 2 avenue Pierre Marzin 593 22300 LANNION, FRANCE 595 Email: sebastien.jobert@orange.com