idnits 2.17.1 draft-yizhou-trill-multi-destination-ping-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: RBridge receiving the incoming frame with hop count equal to 1 MUST send back error notification of 'Hop Count is Zero'. RBridges MUST not generate any echo reply in this case. If hop count in incoming echo request is more than 1, control plane will not do anything. RBridge forwards the frame as normal multi-destination TRILL frame in data plane. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When an echo reply is going to be sent to the originator RBridge, 'Hop Count is Zero' error notification MUST not be sent in response to the same echo request. -- The document date (May 4, 2012) is 4372 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: 'RF6325' is mentioned on line 102, but not defined == Missing Reference: 'RFC2119' is mentioned on line 107, but not defined == Unused Reference: 'RFC6325' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC6165' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'RFC6326' is defined on line 516, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-trill-rbridge-channel-02 == Outdated reference: A later version (-02) exists of draft-ietf-trill-rbridge-oam-01 ** Obsolete normative reference: RFC 2030 (ref. 'NTP') (Obsoleted by RFC 4330) -- Obsolete informational reference (is this intentional?): RFC 6326 (Obsoleted by RFC 7176) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Y. Li 2 Internet Draft W. Hao 3 Intended status: Standards Track Huawei Technologies 4 Expires: December 2012 D. Bond 5 IBM 6 V. Manral 7 Hewlett Packard Co. 8 May 4, 2012 10 OAM tool for RBridges: Multi-destination Ping 11 draft-yizhou-trill-multi-destination-ping-02.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on November 4, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 Unicast and multi-destination data frame may follow the different 51 path in TRILL network. We need the ping and traceroute like 52 applications for the connectivity testing and fault isolation on the 53 multi-destination path in addition to the unicast path. This document 54 specifies the format and handling of the new TRILL OAM protocol 55 messages and TLVs which can be used for the multi-destination OAM. 57 Table of Contents 59 1. Introduction ................................................ 3 60 2. Conventions used in this document............................ 3 61 3. Motivations ................................................. 3 62 4. RBridge Channel Message Format............................... 4 63 5. OAM Protocol Frame Format for Echo in the Long Format........ 4 64 6. TLV Encodings ............................................... 6 65 6.1. Target RBridge ......................................... 6 66 6.2. Jitter ................................................. 7 67 7. Processing Echo Messages for Multi-destination Path...........8 68 7.1. Sending an echo request................................. 8 69 7.2. Receiving an echo request............................... 9 70 7.2.1. If H Flag Is Not Set............................... 9 71 7.2.2. If H Flag Is Set.................................. 10 72 7.3. Sending an echo reply.................................. 11 73 7.4. Receiving an echo reply................................ 12 74 8. Security Considerations..................................... 12 75 9. IANA Considerations ........................................ 12 76 10. References ................................................ 12 77 10.1. Normative References.................................. 12 78 10.2. Informative References................................ 13 79 11. Acknowledgments ........................................... 13 81 1. Introduction 83 When RBridges are deployed in a real network, a number of 84 applications are necessary for error detection/reporting and 85 diagnostic purpose. TRILL RBridge channel [RBridgeChannel] was 86 designed for carrying the OAM relevant messages. [RBridgeOAM] has 87 defined the ping and traceroute applications for unicast path and 88 also the error reporting mechanisms. 90 Multi-destination data path in TRILL network has different 91 characteristics from the unicast path. One or more distribution trees 92 are formed for multi-destination traffic. RBridges advertise their 93 interests in receiving the traffic of the specific VLANs. The 94 distribution tree may or may not be pruned based on VLAN ID. 95 Troubleshooting on the multi-destination path is a desirable feature 96 of TRILL OAM. This document specifies the messages and mechanisms 97 used by multi-destination OAM. 99 2. Conventions used in this document 101 The same terminology and acronyms are used in this document as in 102 [RF6325]. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC-2119 [RFC2119]. 108 3. Motivations 110 In an RBridge campus, unicast and multi-destination traffic may 111 follow different paths between the same ingress and egress RBridges. 112 [RBridgeOAM] specifies some OAM along unicast path. For diagnostic 113 purposes it is also desirable to check the connectivity between two 114 or more RBridges along a particular distribution tree. 116 There are various things we want to test for multi-destination path. 118 - Along a distribution tree, who are the leaf nodes of an inner VLAN? 119 The leaf nodes here refer to the RBridges announcing the given inner 120 VLAN as their interested VLAN in INT-VLAN sub-TLV. It is useful when 121 we want to check if the configuration/provisioning are consistent 122 with the design. 124 - Along a distribution tree, check the connectivity from the ingress 125 RBridge to one or more leaf nodes of an inner vlan. It can be used as 126 the first step in diagnosis when we suspect multi-destination data 127 path to certain RBridge fails. Transit nodes do not decapsulate the 128 multi-destination data frame; therefore we do not think it is much of 129 interest to check the connectivity to any non-leaf RBridges. 131 - Along a distribution tree, trace the multi-destination data path 132 hop-by-hop to a target RBridge. It is useful when we want to find out 133 where exactly is the failed hop. 135 This document specifies new messages and TLVs used by multi- 136 destination OAM applications like multi-destination ping and 137 traceroute. Processing of these messages is also discussed in the 138 draft. 140 4. RBridge Channel Message Format 142 The RBridge Channel Header fields is as follows, 144 o CHV (Channel Header Version): zero. 145 o Channel Protocol: 0x006 (Echo in the Long Format) (TBD) 146 o Flags: The SL and NA bits SHOULD be zero, the MH bit SHOULD be one 147 o ERR: zero. 149 5. OAM Protocol Frame Format for Echo in the Long Format 151 The frame format is shown as follows. In the rest of this document, 152 echo request and echo reply are brief ways to refer to the Echo 153 Request in Long Format and Echo Reply in Long Format messages. 155 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 156 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 157 | RBridge Channel | 158 | Header | 159 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 160 | Sender's Instance | 161 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 162 | SPID | Sequence | 163 | | Number | 164 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 165 | Reply mode | Flags | 166 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 167 | | 168 | TimeStamp Sent (48) | 169 | | 170 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 171 | | 172 | TimeStamp Received (48) | 173 | | 174 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 175 . . 176 . TLVs . 177 . . 178 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 179 Figure 1 Echo Request with Long Format 181 o Sender's Instance: An instance ID used by sender to associate 182 the echo operation with different application instances, e.g. 183 different Telnet sessions. Echo reply should return the value 184 unchanged. 186 o SPID: 187 1 - Echo Request in the Long Format 188 2 - Echo Reply in the Long Format 190 o Sequence Number: An arbitrary 28-bit unsigned integer used to 191 aid in matching reply messages to echo requests. It MAY be zero. 192 o Reply Mode: Default is 2. It can take one of the following 193 values. 194 1 - Do not reply. It can be used for one-way connectivity 195 check. The receiving RBridge may perform monitoring and statistics 196 collection on delay and/or jitter using one-way echo operation. 198 2 - Reply with Echo Reply in the Long Format and send back 199 unicast in TRILL OAM channel. This value would be used by echo 200 request in most cases. 201 o Flags: A bit vector with the following format. Currently only 202 the H (Respond Only When Hop Count is Zero) flag is defined. In 203 practice, we set H flag to be 0 for ping type applications and 1 for 204 traceroute type applications of multi-destination OAM. With H flag 205 set, it will help to prevent the duplicate echo replies from the same 206 RBridge triggered by echo request with different hop count value in 207 the same traceroute operation. H flag is only significant in echo 208 request and MUST NOT be set in echo reply. The detailed processing 209 based on the value of H flag is explained in section 7.2. 210 | 0| 1| 2| 3| 4| 5| 6| 7| 211 +--+--+--+--+--+--+--+--+ 212 | MBZ | H| 213 +--+--+--+--+--+--+--+--+ 215 o TimeStamp Sent: time-of-day (3 octets for seconds and 3 octets 216 for microseconds) in NTP format that the echo request was sent 217 according to the sender's clock. 218 o TimeStamp Received: time-of-day (3 octets for seconds and 3 219 octets for microseconds) in NTP format that the corresponding echo 220 request was received according to the receiver's clock. This value is 221 significant only in echo reply and MUST be set to all zeros in echo 222 request and ignored on receipt of an echo request. 223 o TLVs: A set of type, length, value encoded fields as specified 224 in next section. 226 6. TLV Encodings 228 6.1. Target RBridge 230 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 231 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 232 | Type = 0x05 | Length = 2 + 2*n | 233 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 234 | Number of Target RBridges | 235 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 236 . Target RBridge Nickname 1 . 237 . ... . 238 . Target RBridge Nickname n . 239 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 241 o Number of Target RBridges: The number of nicknames specified in 242 the following fields, the maximum number is 127. 244 o Target RBridge Nickname: The nickname of a Target RBridge. 246 This TLV MAY appear in an echo request. It SHOULD be copied back in 247 the corresponding echo reply messages. 249 Target RBridge TLV is used by multi-destination OAM. For ping along 250 the multi-destination path, the Target RBridge TLV with multiple 251 nicknames MAY be included in echo request. It implies RBridges with 252 any of the nicknames in the TLV should reply. While for traceroute 253 like application, only a single nickname can be included in this TLV. 254 If there was more than one nickname in the TLV, only the first 255 nickname MUST be used as target nickname for tracing purpose. 257 When Target RBridge TLV is not included in an echo request, it 258 implies the unspecified target. If an echo request with unspecified 259 target was sent by ping like applications, then all leaf nodes in 260 distribution tree pruned by the given inner VLAN SHOULD send back 261 echo reply. If echo request with unspecified target was sent by 262 traceroute like application, RBridges receiving the incoming frame 263 with hop count value 1 would process the echo request and send back 264 'Hop Count is Zero' error notification. 266 6.2. Jitter 268 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 269 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 270 | Type = 0x07 | Length = 0x02 | 271 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 272 | Jitter time | 273 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 275 o Jitter time: Set to the upper bound of the jitter period in 276 milliseconds. A responding node SHOULD wait a random amount of time 277 between zero milliseconds and the value specified. 279 This TLV MAY appear in an Echo Request in the Long format. It SHOULD 280 NOT be present in echo reply messages. 282 7. Processing Echo Messages for Multi-destination Path 284 7.1. Sending an echo request 286 The inner frame header and TRILL header fields are as follows: 288 o Inner.MacSA: MAC address of RBridge originating the echo request 289 o Inner.MacDA: Defaults to All-Egress-RBridges. It can be set to L2 290 multicast address derived from IP multicast group. 291 o Inner.VLAN ID: Defaults to 1. It can be any enabled VLAN ID on the 292 ingress RBridge. 293 o Ingress RBridge Nickname: the nickname of RBridge originating the 294 echo request 295 o Egress RBridge Nickname: the nickname of a distribution tree root 296 o M bit: 1 297 o Hop Count: defaults to maximum value 0x3F. 299 - For ping like applications, it can be any value which is believed 300 to be no less than the number of hops from ingress RBridge to the 301 most distant target RBridge in the tree. 303 - For traceroute like applications, hop count value starts from 1 304 and is increased by one for each sending of echo request. 306 H(Respond Only When Hop Count is Zero) flag in echo request is set to 307 1 for traceroute like applications and 0 for ping like applications. 309 The originating RBridge chooses the values of Sender's Instance and 310 Sequence Number for the echo request. Sequence number should be 311 increased by 1 for each new subsequent echo request of the same 312 Sender's Instance. The Timestamp Sent is set to the time-of-day in 313 NTP format [NTP] according to the sender's clock. The Timestamp 314 Received is set to zero. 316 The originating RBridge MAY use Target RBridge TLV to specify the 317 target. For ping like applications, multiple nicknames MAY be present 318 in one such TLV if sender wants to ping multiple targets at one time. 319 For traceroute like applications, the TLV should at most contain one 320 nickname as the tracing target. If there is more than one nickname, 321 only the first one takes effect. 323 Echo request without Target RBridge TLV means the originating RBridge 324 potentially wants to target every RBridge in the distribution tree. 325 We also call it echo request with the unspecified target. For ping 326 like applications, echo request with the unspecified target implies 327 the sender wants to know who are the leaf nodes of the inner VLAN in 328 the distribution tree. For traceroute like applications, it implies 329 the sender wants to know the whole distribution tree structure hop- 330 by-hop. 332 The Originating RBridge MAY include the Jitter TLV (see section 6.2) 333 in the echo request in order to randomize the delay of the replying 334 echo message from multiple RBridges. 336 7.2. Receiving an echo request 338 RBridge receiving an echo request with M bit set with EtherType of 339 RBridge channel [RBridgeChannel] SHOULD replicate it to the control 340 plane for processing and also forward it as normal multi-destination 341 data frame. When a RBridge receives an incoming frame with hop count 342 is 1 in TRILL header, it will not forward the frame further. If reply 343 mode is 1, no echo reply is generated. For the sub sections below, we 344 assume the reply mode is set to 2. 346 7.2.1. If H (Respond Only When Hop Count is Zero) Flag Is Not Set 348 - If Target RBridge TLV is not present in the echo request: 350 All leaf nodes of the distribution tree in the inner VLAN MUST 351 process the incoming echo request and send back echo reply. 353 - If Target RBridge TLV is present in the echo request: 355 An RBridge owning any one of the specified target nicknames in the 356 incoming echo request MUST send back echo reply when it is a leaf 357 node of the distribution tree in the inner VLAN. 359 If echo reply has already been generated for the incoming echo 360 request, RBridge will not generate 'Hop Count is Zero' error 361 notification even when the hop count value in the incoming echo 362 request is one. 364 Echo request with 'H' flag unset is for ping like application. It 365 should be noted that if an RBridge receives an echo request with its 366 own nickname listed as one of the targets, it does not send back the 367 echo reply if the RBridge did not advertise its interest of inner 368 VLAN. That is to say, the connectivity check using ping in multi- 369 destination path is constrained by inner VLAN. Normally VLAN 1 is the 370 default VLAN and enabled on every RBridge. Therefore it is 371 recommended to put inner VLAN to be 1 when we want to check the 372 connectivity without the constraint of a particular customer VLAN. We 373 may use the echo replies from that to plot the whole distribution 374 tree. 376 7.2.2. If H (Respond Only When Hop Count is Zero) Flag Is Set 378 When hop count of the incoming echo request is not one, RBridge would 379 never generate any echo reply or 'hop count iz zero' error 380 notification. 382 If the hop count is one in the incoming echo request: 384 - If Target RBridge TLV is not present in the echo request: 386 RBridge receiving the incoming frame with hop count equal to 1 387 MUST send back error notification of 'Hop Count is Zero'. RBridges 388 MUST not generate any echo reply in this case. If hop count in 389 incoming echo request is more than 1, control plane will not do 390 anything. RBridge forwards the frame as normal multi-destination 391 TRILL frame in data plane. 393 - If Target RBridge TLV is present in the echo request: 395 RBridges owning the only target nickname listed in TLV MUST send 396 back echo reply if it is a leaf node of the inner VLAN in the 397 distribution tree. If it is not a leaf node of the inner vlan, no 398 echo reply will be generated by the owner RBridge; however, 'Hop 399 Count is Zero' error notification will be sent back instead. 401 If an RBridge not owning the only target nickname listed in TLV 402 receives the incoming frame with hop count equal to 1, it SHOULD 403 check its LSDB. If it sits in-between of the ingress RBridge and 404 the target RBridge along the specified distribution tree, RBridge 405 MUST send back the error notification of 'Hop Count is Zero'; 406 otherwise the RBridge should not generate such error notification. 407 The purpose of suppressing the error notification here is to make 408 sure the ingress only receives the error notification along the 409 real data path and to reduce the processing burden at ingress. 411 If RBridge not owning the first target nickname listed in TLV 412 receives the incoming frame with hop count greater than 1, the 413 frame is forwarded as usual. 415 Echo request with 'H' flag set is for traceroute like applications. 416 For traceroute with unspecified target, the ingress RBridge will be 417 able to construct the whole distribution tree (when tree is not 418 pruned) or the distribution tree of inner vlan (when tree is pruned 419 by inner VLAN) according to the returned error notifications. For 420 traceroute with a specified target in an inner VLAN, the ingress 421 RBridge will receive the error notifications from the RBridges along 422 the path to the target in the tree. If the target announced its 423 interest of the inner VLAN, it will finally send back echo reply to 424 the ingress. If the target did not announce its interest of the inner 425 VLAN, either the target will not receive the echo request (e.g. it is 426 located in the tree path being pruned) or the target will send back 427 error notification of 'Hop Count is Zero' instead of echo reply. 429 7.3. Sending an echo reply 431 The inner frame header and TRILL header fields are as follows, 433 o Inner.MacSA: The MAC address of the RBridge generating the echo 434 reply 435 o Inner.MacDA: All-Egress-RBridges 436 o Inner.VLAN ID: same as Inner.VLAN ID in the received echo request 437 to which the echo reply responds 438 o Ingress RB Nickname: the nickname of the RBridge generating the 439 echo reply. 440 o Egress RBridge Nickname: the ingress RBridge nickname in the 441 corresponding received echo request 442 o M bit: 0 443 o Hop Count: defaults to the maximum value 0x3F. It can be any value 444 that is believed to be larger than the number of hops from ingress to 445 egress RBridge. 447 The values of Sender's Instance, Sequence Number and Timestamp sent 448 in an echo reply MUST be same as those in its corresponding echo 449 request. H flag MUST be zero in echo reply. The value of Timestamp 450 Received is set to the time-of-day in NTP format [NTP] according to 451 the receiver's clock. 453 If Target RBridge TLV was present in the echo request, the 454 corresponding echo reply SHOULD copy it. 456 Next Hop Nickname and Incoming Port ID TLV [RBridgeOAM] MAY be 457 included in echo reply. 459 When an echo reply is going to be sent to the originator RBridge, 460 'Hop Count is Zero' error notification MUST not be sent in response 461 to the same echo request. 463 7.4. Receiving an echo reply 465 An RBridge SHOULD use the Sender's Instance and Sequence Number to 466 match up the received echo reply with the echo request it sent. If 467 there is no match found, the RBridge should discard the echo reply. 469 If Jitter TLV was present in the echo request, the round trip time 470 should not be calculated based on the difference between the arriving 471 time of echo reply and the value of "TimeStamp sent" in the replying 472 frame. However the single trip time is always correct to be 473 calculated on Timestamp Received minus Timestamp Sent when the clocks 474 of sender and receiver are synchronized. 476 When an RBridge receives either an echo reply or 'hop count is zero' 477 error notification from the target RBridge for traceroute like 478 application, it SHOULD stop sending echo request with increased hop 479 count value. 481 8. Security Considerations 483 The security vulnerabilities raised in [RBridgeOAM] also apply to 484 the multi-destination RBridge ping in this document. The same 485 mechanisms can be used to prevent or alleviate the security issues. 487 9. IANA Considerations 489 New error notification sub-code needs to be allocated by IANA as 490 specified in Section 7. 492 10. References 494 10.1. Normative References 496 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 497 Ghanwani, "Routing Bridges (RBridges): Base Protocol 498 Specification", RFC 6325, July 2011. 500 [RBridgeChannel] Eastlake, D., Manral, V., Yizhou, L., Aldrin, S., 501 and D. Ward, "RBridges: TRILL RBridge Channel Support", draft- 502 ietf-trill-rbridge-channel-02 (work in progress), July 2011. 504 [RBridgeOAM] D. Bond, and V. Manral, "RBridges: Operations, 505 Administration, and Maintenance (OAM) Support", draft-ietf- 506 trill-rbridge-oam-01 (work in progress), October 2011. 508 [NTP] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 509 IPv4, IPv6 and OSI", RFC 2030, October 1996. 511 10.2. Informative References 513 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 514 Systems", RFC 6165, April 2011. 516 [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 517 Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011. 519 11. Acknowledgments 521 This document was prepared using 2-Word-v2.0.template.dot. 523 Authors' Addresses 525 Yizhou Li 526 Huawei Technologies 527 101 Software Avenue, 528 Nanjing 210012 529 China 531 Phone: +86-25-56624558 532 Email: liyizhou@huawei.com 534 Weiguo Hao 535 Huawei Technologies 536 101 Software Avenue, 537 Nanjing 210012 538 China 540 Phone: +86-25-56623144 541 Email: haoweiguo@huawei.com 542 David Michael Bond 543 International Business Machines 544 2051 Mission College Blvd. 545 Santa Clara, CA 95054 546 US 548 Phone: +1-603-339-7575 549 EMail: mokon@mokon.net 550 URI: http://mokon.net 552 Vishwas Manral 553 Hewlett Packard Co. 554 19111 Pruneridge Ave, 555 Cupertino, CA 95014 USA 557 Phone: +1-408-447-1497 558 EMail: vishwas.manral@hp.com