idnits 2.17.1 draft-zamfir-explicit-resource-control-bundle-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 456. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-zamfir-explicit-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-zamfir-explicit-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-zamfir-explicit-', but the file name used is 'draft-zamfir-explicit-resource-control-bundle-05' == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 1 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([RFC3473], [RFC3209]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 134 has weird spacing: '...control and r...' == Line 386 has weird spacing: '...objects may a...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 2005) is 6888 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3477' is mentioned on line 153, but not defined == Missing Reference: 'RFC 3471' is mentioned on line 366, but not defined == Missing Reference: 'RFC 3473' is mentioned on line 366, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-05 -- No information found for draft-farrel-rsvpte-attributes - is the name correct? Summary: 6 errors (**), 1 flaw (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group 3 Internet Draft Anca Zamfir, 4 Zafar Ali 5 Cisco Systems 6 D. Papadimitriou 7 Alcatel 8 Document: draft-zamfir-explicit- 9 resource-control-bundle-05.txt 10 Expires: December 2005 June 2005 12 Component Link Recording and Resource Control for GMPLS Link Bundles 14 draft-zamfir-explicit-resource-control-bundle-05.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 Record Route is a useful administrative tool that has been used 41 extensively by the service providers. However, when TE links are 42 bundled, identification of label resource in RRO is not enough for 43 the administrative purpose. Network service providers would like to 44 know the component link within a TE link that is being used by a 46 Zamfir, A., Ali, Z., Papadimitriou, D. 48 given LSP. In other words, when link bundling is used, resource 49 recording requires mechanisms to specify the component link 50 identifier, along with the TE link identifier and Label. As , it is 51 not possible to record component link in the RRO, this draft defines 52 the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify 53 component link identifiers for resource recording purposes. 55 This draft also defines the ERO counterpart of the RRO extension. The 56 ERO extensions are needed to perform explicit label/ resource control 57 over bundled TE link. Hence, this draft defines the extensions to 58 RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers 59 for explicit resource control and recording over GMPLS link bundles. 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [RFC2119]. 67 Table of Contents 69 1. Terminology....................................................2 70 2. Resource Control and Recording.................................3 71 3. LSP Resource Recording.........................................4 72 3.1 Component Interface Identifier RRO subobject...............4 73 3.2 Processing of Component Interface identifier RRO Subobject.5 74 4. Signaling Component Interface Identifier in ERO................6 75 4.1 Processing of Component Interface Identifier ERO Subobject.7 76 5. Forward Compatibility Note.....................................9 77 6. Security Considerations........................................9 78 7. IANA Considerations...........................................10 79 8. Intellectual Property Considerations..........................10 80 9. References....................................................10 81 9.1 Normative Reference.......................................10 82 9.2 Informative Reference.....................................11 83 10. Author's Addresses...........................................11 84 11. Full Copyright Statement.....................................11 86 1. Terminology 88 TE Link: Unless specified otherwise, it refers to a bundled Traffic 89 Engineering link as defined in [BUNDLE]. Furthermore, the terms TE 90 Link and bundled TE Link are used interchangeably in this draft. 92 Zamfir, A., Ali, Z., Papadimitriou, D 93 Component (interface) link: refers (locally) to a component link as 94 part of a bundled TE link. A component link is numbered/ unnumbered 95 in its own right. For unnumbered component links, the component link 96 ID is assumed to be unique on an advertising node. For numbered 97 component links, the component link ID is assumed to be unique within 98 a domain. 100 Component Interface Identifier: Refers to an ID used to uniquely 101 identify a Component Interface. On a bundled link a combination of 102 is sufficient to unambiguously 103 identify the appropriate resources used by an LSP [BUNDLE]. 105 2. Resource Control and Recording 107 In GMPLS networks that deals with unbundled (being either PSC, L2SC, 108 TDM or LSC) TE Links, one of the types of resources that an LSP 109 originator can control and would like to record are the TE Link 110 interfaces used by the LSP. The resource control and recording is 111 done by the use of an explicit route, i.e., Explicit Route (ERO) 112 Object and record Route, i.e., Record Route Object (RRO) object, 113 respectively. 115 Link Bundling introduced by [BUNDLE], is used to improve routing 116 scalability by reducing the amount of TE related information that 117 needs to be flooded and handled by IGP in a TE network. This is 118 accomplished by aggregating and abstracting the TE Link resource. In 119 some cases the complete resource identification is left as a local 120 decision. However, as described above there are cases when it is 121 desirable for a non-local (e.g., LSP head-end) node to identify 122 completely or partially the LSP resources. In either case, for 123 administrative reasons, it is required to know which component link 124 within a bundled TE link has been used for a given LSP. 126 When link bundling is used to aggregate multiple component links into 127 a TE link, label is not the only resource that needs to be identified 128 and recorded. In other words, the TE Link and the Label specified in 129 the ERO/ RRO objects are not enough to completely identify the 130 resource. For the bundled TE link case, in order to fully specify the 131 resources on a link for a given LSP, the component link needs to be 132 specified along with the label. In the case of bi-directional LSPs 133 both upstream and downstream information may be specified. Therefore, 134 explicit resource control and recording over a bundled TE link also 135 requires ability to specify a component link within the TE link. 137 This draft defines extensions to and describes the use of RSVP-TE 138 [RFC3209], [RFC3471], [RFC3473] to specify the component link 139 identifier for resource recording and explicit resource control over 140 GMPLS link bundles. Specifically, in this document, component 142 Zamfir, A., Ali, Z., Papadimitriou, D 143 interface identifier RRO and ERO subobjects are defined to complement 144 their Label RRO and ERO counterparts. Furthermore, procedures for 145 processing component interface identifier RRO and ERO subobjects and 146 how they can co-exist with the Label RRO and ERO subobjects are 147 specified. 149 3. LSP Resource Recording 151 This refers to the ability to record the resources used by an LSP. 152 The procedure for unbundled numbered TE links is described in 153 [RFC3209] and for unbundled unnumbered TE links in [RFC 3477]. For 154 the purpose of recording LSP resources used over bundled TE Links, 155 the Component Interface Identifier RRO sub-object is introduced. 157 3.1 Component Interface Identifier RRO subobject 159 A new subobject of the Record Route Object (RRO) is used to record 160 component interface identifier of a (bundled) TE Link. This subobject 161 has the following format: 162 Figure 2: Component Interface Identifier RRO subobject 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |L| Type | Length |U| Reserved (must be zero) | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 // IPv4, IPv6 or unnumbered Component Interface Identifier // 170 | . . . | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 0 1 2 3 175 L: 1 bit 177 This bit must be set to 0. 179 Type 181 10 (TBD) Component Interface identifier IPv4 182 11 (TBD) Component Interface identifier IPv6 183 12 (TBD) Component Interface identifier Unnumbered 185 Length 187 Zamfir, A., Ali, Z., Papadimitriou, D 188 The Length contains the total length of the subobject in 189 bytes, including the Type and Length fields. The Length is 190 8 bytes for the Component Interface identifier IPv4 and 191 Component Interface identifier Unnumbered types. For 192 Component Interface identifier IPv6 type of sub-object, the 193 length field is 20 bytes. 195 U: 1 bit 197 This bit indicates the direction of the component 198 interface. It is 0 for the downstream interface. It is 199 set to 1 for the upstream interface and is only used for 200 bi-directional LSPs. 202 3.2 Processing of Component Interface identifier RRO Subobject 204 If a node desires component link recording, the "Component Link 205 Recording desired" flag (value TBD) should be set in the 206 LSP_ATTRIBUTES object, object that is defined in [RSVP-TE-ATTRIBUTE]. 207 Setting of "Component Link Recording desired" flag is independent of 208 the Label Recording flag in SESSION_ATTRIBUTE object as specified in 209 [RFC3209]. Nevertheless, the following combinations are valid: 210 1) If both Label and Comp Link flags are clear, then neither 211 Labels nor Component Links are recorded. 212 2) If Label Recording flag is set and Component Link flag is 213 clear, then only Label Recording is performed as defined in 214 [RFC3209]. 215 3) If Label Recording flag is clear and Component Link flag is 216 set, then Component Link Recording is performed as defined in this 217 proposal. 218 4) If both Label Recording and Component Link flags are set, then 219 Label Recording is performed as defined in [RFC3209] and also 220 Component Link recording is performed as defined in this proposal. 222 In most cases, a node initiates recording for a given LSP by adding 223 the RRO to the Path message. If the node desires Component Link 224 recording and if the outgoing TE link is bundled, then the initial 225 RRO contains the Component Link identifier (numbered or unnumbered) 226 as selected by the sender. As well, the Component Link Recording 227 desired flag is set in the LSP_ATTRIBUTE object. If the node also 228 desires label recording, it sets the Label_Recording flag in the 229 SESSION_ATTRIBUTE object. 231 When a Path message with the "Component Link Recording desired" flag 232 set is received by an intermediate node, if a new Path message is to 233 be sent for a downstream bundled TE link, the node adds a new 234 Component Link subobject to the RRO and appends the resulting RRO to 235 the Path message before transmission. 237 Zamfir, A., Ali, Z., Papadimitriou, D 238 Note also that, unlike Labels, Component Link identifiers are always 239 known on receipt of the Path message. 241 When the destination node of an RSVP session receives a Path message 242 with an RRO and the "Component Link Recording desired" flag set, this 243 indicates that the sender node needs TE route as well as component 244 link recording. The destination node initiates the RRO process by 245 adding an RRO to Resv messages. The processing mirrors that of the 246 Path messages 248 The Component Interface Record subobject is pushed onto the 249 RECORD_ROUTE object prior to pushing on the node's IP address. A node 250 MUST NOT push on a Component Interface Record subobject without also 251 pushing on the IP address or unnumbered Interface Id subobject that 252 identifies the TE Link. 254 When component interfaces are recorded for bi-directional LSPs, 255 component interface RRO subobjects for both downstream and upstream 256 interfaces MUST be included. 258 4. Signaling Component Interface Identifier in ERO 260 A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used 261 to specify component interface identifier of a bundled TE Link. 263 This subobject has the following format: 265 Figure 1: Component Interface Identifier ERO subobject 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |L| Type | Length |U| Reserved (MUST be zero) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 // IPv4, IPv6 or unnumbered Component Interface Identifier // 273 | . . . | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 L: 1 bit 278 This bit must be set to 0. 280 Type 282 10 (TBD) Component Interface identifier IPv4 283 11 (TBD) Component Interface identifier IPv6 285 Zamfir, A., Ali, Z., Papadimitriou, D 286 12 (TBD) Component Interface identifier Unnumbered 288 Length 290 The Length contains the total length of the subobject in 291 bytes, including the Type and Length fields. The Length is 292 8 bytes for the Component Interface identifier types: IPv4 293 and Component Interface identifier Unnumbered. For 294 Component Interface identifier IPv6 type of sub-object, 295 the length field is 20 bytes. 297 U: 1 bit 298 This bit indicates the direction of the component 299 interface. It is 0 for the downstream interface. It is 300 set to 1 for the upstream interface and is only used for 301 bi-directional LSPs. 303 4.1 Processing of Component Interface Identifier ERO Subobject 305 The Component Interface Identifier ERO subobject follows a subobject 306 containing the IP address, or the link identifier [RFC3477], 307 associated with the TE link on which it is to be used. It is used to 308 identify the component of a bundled TE Link. 310 The following SHOULD result in "Bad EXPLICIT_ROUTE object" error 311 being sent upstream by a node processing an ERO that contains the 312 Component Interface ID sub-object: 314 o The first component interface identifier subobject is not 315 preceded by a sub-object containing an IPv4 or IPv6 address, or 316 an interface identifier [RFC3477], associated with a TE link. 317 o The Component Interface Identifier ERO subobject follows a 318 subobject that has the L-bit set. 319 o On unidirectional LSP setup, there is a Component Interface 320 Identifier ERO subobject with the U-bit set. 321 o Two Component Interface Identifier ERO subobjects with the same 322 U-bit values exist. 324 If a node implements the component interface identifier subobject, it 325 must check if it represents a component interface in the bundled TE 326 Link specified in the preceding subobject that contains the IPv4/IPv6 327 address or interface identifier of the TE Link. If the content of the 328 component interface identifier subobject does not match a component 329 interface in the TE link, a "Bad EXPLICIT_ROUTE object" error SHOULD 330 be reported as "Routing Problem" (error code 24). 332 Zamfir, A., Ali, Z., Papadimitriou, D 333 If U-bit of the subobject being examined is cleared (0) and the 334 upstream interface specified in this subobject is acceptable, then 335 the value of the upstream component interface is translated locally 336 in the TLV of the IF_ID RSVP HOP object [RFC 3471]. The local 337 decision normally used to select the upstream component link is 338 bypassed except for local translation into the outgoing interface 339 identifier from the received incoming remote interface identifier. If 340 this interface is not acceptable, a "Bad EXPLICIT_ROUTE object" error 341 SHOULD be reported as "Routing Problem" (error code 24). 343 If the U-bit of the subobject being examined is set (1), then the 344 value represents the component interface to be used for upstream 345 traffic associated with the bidirectional LSP. Again, if this 346 interface is not acceptable or if the request is not one for a 347 bidirectional LSP, then a "Bad EXPLICIT_ROUTE object" error SHOULD be 348 reported as "Routing Problem" (error code 24). Otherwise, the 349 component interface IP address/ identifier is copied into a TLV sub- 350 object as part of the IF_ID RSVP_HOP object. The local decision 351 normally used to select the upstream component link is bypassed 352 except for local translation into the outgoing interface identifier 353 from the received incoming remote interface identifier. 355 The IF_ID RSVP_HOP object constructed as above MUST be included in 356 the corresponding outgoing Path message. 358 Note that, associated with a TE Link sub-object in the ERO, either 359 the (remote) upstream component interface or the (remote) downstream 360 component interface or both may be specified. As specified in 361 [BUNDLE] there is no relationship between the TE Link type (numbered 362 or unnumbered) and the Link type of any one of its components. 364 The component interface identifier ERO subobject is optional. 365 Similarly, presence of the Label ERO sub-objects is not mandatory 366 [RFC 3471], [RFC 3473]. Furthermore, component interface identifier 367 ERO subobject and Label ERO subobject may be included in the ERO 368 independently of each other. One of the following alternatives 369 applies: 370 o When both sub-objects are absent, a node may select any appropriate 371 component link within the TE link and any label on the selected 372 component link. 373 o When the Label subobject is only present for a bundled link, then 374 the selection of the component link within the bundle is a local 375 decision and the node may select any appropriate component link, 376 which can assume the label specified in the Label ERO. 377 o When only the component interface identifier ERO subobject is 378 present, a node MUST select the component interface specified in the 380 Zamfir, A., Ali, Z., Papadimitriou, D 381 ERO and may select any appropriate label value at the specified 382 component link. 383 o When both component interface identifier ERO subobject and Label 384 ERO subobject are present, the node MUST select the locally 385 corresponding component link and the specified label value on that 386 component link. When present, both subobjects may appear in any 387 relative order to each other but they MUST appear after the TE Link 388 sub-object that they refer to. 390 After processing, the component interface identifier subobjects are 391 removed from the ERO. 393 Inferred from above, the interface subobject should never be the 394 first subobject in a newly received message. If the component 395 interface subobject is the first subobject in a received ERO, then it 396 SHOULD be treated as a "Bad strict node" error. 398 Note: Information to construct the Component Interface ERO subobject 399 may come from the same mean used to populate the label ERO subobject. 400 Procedures by which an LSR at the head-end of an LSP obtains the 401 information needed to construct the Component Interface subobject are 402 outside the scope of this document. 404 5. Forward Compatibility Note 406 The extensions specified in this draft do not affect the processing 407 of the RRO, ERO at nodes that do not support them. A node that does 408 not support the Component Interface RRO subobject but that does 409 support Label subobject SHOULD only insert the Label subobject in the 410 RRO as per [RFC3471] and [RFC3473]. 412 A node that receives an ERO that contains a Component Link ID 413 subobject SHOULD send "Bad EXPLICIT_ROUTE object" if it does not 414 implement this subobject. 416 As per [RFC3209], Section 4.4.5, a non-compliant node that receives 417 an RRO that contains Component Interface Identifier sub-objects 418 should ignore and pass them on. This limits the full applicability of 419 if nodes traversed by the LSP are compliant with the proposed 420 extensions. 422 6. Security Considerations 424 This document does not introduce new security issues. The security 425 considerations pertaining to the original RSVP protocol [RFC2205] 426 remain relevant. 428 Zamfir, A., Ali, Z., Papadimitriou, D 429 7. IANA Considerations 431 Type of Component Interface Identifier ERO subobject needs to be 432 assigned. 434 8. Intellectual Property Considerations 436 The IETF takes no position regarding the validity or scope of any 437 Intellectual Property Rights or other rights that might be claimed to 438 pertain to the implementation or use of the technology described in 439 this document or the extent to which any license under such rights 440 might or might not be available; nor does it represent that it has 441 made any independent effort to identify any such rights. Information 442 on the procedures with respect to rights in RFC documents can be 443 found in BCP 78 and BCP 79. 445 Copies of IPR disclosures made to the IETF Secretariat and any 446 assurances of licenses to be made available, or the result of an 447 attempt made to obtain a general license or permission for the use of 448 such proprietary rights by implementers or users of this 449 specification can be obtained from the IETF on-line IPR repository at 450 http://www.ietf.org/ipr. 452 The IETF invites any interested party to bring to its attention any 453 copyrights, patents or patent applications, or other proprietary 454 rights that may cover technology that may be required to implement 455 this standard. Please address the information to the IETF at ietf- 456 ipr@ietf.org. 458 9. References 460 9.1 Normative Reference 462 [RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1, 463 Functional Specification", RFC 2205, Braden, et al, September 464 1997. 465 [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, 466 RFC 3209, December 2001. 467 [BUNDLE] "Link Bundling in MPLS Traffic Engineering", draft-ietf- 468 mpls-bundle-05.txt, K. Kompella, et al, January 2003. 469 [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) 470 Signaling Functional Description, RFC 3471, L. Berger, et al, 471 January 2003. 472 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 473 Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP- 474 TE) Extensions", RFC 3473, L. Berger, et al, January 2003. 476 Zamfir, A., Ali, Z., Papadimitriou, D 478 [RFC3477] "Signaling Unnumbered Links in Resource ReSerVation 479 Protocol - Traffic Engineering (RSVP-TE) ", RFC 3477, K. Kompella, 480 Y. Rekhter, January 2003. 481 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 482 RFC 2119, S. Bradner, March 1997. 484 9.2 Informative Reference 486 [RSVP-TE-ATTRIBUTE] "Encoding of Attributes for Multiprotocol Label 487 Switching (MPLS) Label Switched Path (LSP) Establishment Using 488 RSVP-TE", draft-farrel-rsvpte-attributes-00.txt., A. Farrel. 489 et al, April 2004 491 10. Author's Addresses 493 Anca Zamfir 494 Cisco Systems Inc. 495 2000 Innovation Dr., 496 Kanata, Ontario, K2K 3E8 497 Canada. 498 Phone: (613)-254-3484 499 Email: ancaz@cisco.com 501 Zafar Ali 502 Cisco Systems Inc. 503 2000 Innovation Dr., 504 Kanata, Ontario, K2K 3E8 505 Canada. 506 Phone: (613) 889-6158 507 Email: zali@cisco.com 509 Dimitri Papadimitriou (Alcatel) 510 Fr. Wellesplein 1, 511 B-2018 Antwerpen, Belgium 512 Phone: +32 3 240-8491 513 Email: dimitri.papadimitriou@alcatel.be 515 11. Full Copyright Statement 517 Copyright (C) The Internet Society (2005). This document is subject 518 to the rights, licenses and restrictions contained in BCP 78, and 519 except as set forth therein, the authors retain all their rights. 521 This document and the information contained herein are provided on an 522 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 523 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 525 Zamfir, A., Ali, Z., Papadimitriou, D 526 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 527 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 528 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 529 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 531 Zamfir, A., Ali, Z., Papadimitriou, D