idnits 2.17.1 draft-ietf-mpls-oam-requirements-02.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 8) being 60 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. ** The abstract seems to contain references ([FRAMEWORK], [Y1710]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 194: '... procedures MUST be minimized as amb...' RFC 2119 keyword, line 207: '... The OAM packet MUST follow exactly t...' RFC 2119 keyword, line 241: '...h trace function MUST have the ability...' RFC 2119 keyword, line 286: '... The operator MUST be have the flexi...' RFC 2119 keyword, line 332: '...e. The mechanism SHOULD consider possi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 185 has weird spacing: '...inition of re...' -- 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 (June 2003) is 7613 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'TUNTRACE' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSRMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'TEMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'FTNMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'LBMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRR' ** Downref: Normative reference to an Informational RFC: RFC 3564 (ref. 'DS-TE') -- Possible downref: Non-RFC (?) normative reference: ref. 'Inter-AS TE' ** Obsolete normative reference: RFC 2547 (ref. 'Inter-AS VPN') (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. 'PWE3FRAME' -- Possible downref: Non-RFC (?) normative reference: ref. 'Y1710' -- Possible downref: Non-RFC (?) normative reference: ref. 'GUIDELINES' -- Possible downref: Non-RFC (?) normative reference: ref. 'I610' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAMEWORK' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Thomas D. Nadeau 3 Internet Draft Monique Morrow 4 Expires: November 2003 George Swallow 5 Cisco Systems, Inc. 7 David Allan 8 Nortel Networks 10 Satoru Matsushima 11 Japan Telecom 13 June 2003 15 OAM Requirements for MPLS Networks 16 draft-ietf-mpls-oam-requirements-02.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full 21 conformance with all provisions of Section 10 of RFC 2026 22 [RFC2026]. 24 Internet-Drafts are working documents of the Internet 25 Engineering Task Force (IETF), its areas, and its working 26 groups. Note that other groups may also distribute working 27 documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of 30 six months and may be updated, replaced, or obsoleted by 31 other documents at any time. It is inappropriate to use 32 Internet-Drafts as reference material or to cite them other 33 than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be 39 accessed at http://www.ietf.org/shadow.html. 41 Abstract 43 As transport of diverse traffic types such as voice, frame 44 relay, and ATM over MPLS become more common, the ability to detect, 45 handle and diagnose control and data plane defects becomes 46 critical. 48 Detection and specification of how to handle those defects is not 49 only important because such defects may not only affect the 50 fundamental operation of an MPLS network, but also because they 51 may impact SLA commitments for customers of that network. 53 This Internet draft describes requirements for user and data 54 plane operations and management (OAM) for Multi-Protocol 55 Label Switching (MPLS). These requirements have been gathered 56 from network operators who have extensive experience deploying 57 MPLS networks, similarly some of these requirements have 58 appeared in other documents [Y1710]. This draft specifies OAM 59 requirements for MPLS, as well as for applications of MPLS such 60 as pseudowire voice and VPN services. Those interested in specific 61 issues relating to instrumenting MPLS for OAM purposes are directed 62 to [FRAMEWORK] 64 Table of Contents 66 Introduction.....................................................2 67 Terminology......................................................2 68 Motivations......................................................3 69 Requirements.....................................................4 70 Security Considerations..........................................8 71 Acknowledgments..................................................9 72 References.......................................................9 73 Authors' Addresses..............................................10 74 Intellectual Property Rights Notices............................11 75 Full Copyright Statement........................................11 77 1. Introduction 79 This Internet draft describes requirements for user and data 80 plane operations and management (OAM) for Multi-Protocol 81 Label Switching (MPLS). These requirements have been gathered 82 from network operators who have extensive experience deploying 83 MPLS networks. This draft specifies OAM requirements 84 for MPLS, as well as for applications of MPLS such as 85 pseudowire [PWE3FRAME] voice, and VPN services. 87 No specific mechanisms are proposed to address these 88 requirements at this time. The goal of this draft is to 89 identify a commonly applicable set of requirements for MPLS 90 OAM. Specifically, a set of requirements that apply to 91 the most common set of MPLS networks deployed by service 92 provider organizations today. These requirements can then be used 93 as a base for network management tool development and to guide 94 the evolution of currently specified tools, as well as the 95 specification of OAM functions that are intrinsic to protocols 96 used in MPLS networks. 98 Comments should be made directly to the MPLS mailing list 99 at mpls@uu.net. 101 This memo does not, in its draft form, specify a standard 102 for the Internet community. 104 2. Terminology 106 CE: Customer Edge 108 Defect: Any error condition that prevents an LSP 109 functioning correctly. For example, loss of an 110 IGP path will most likely also result in an LSP 111 not being able to deliver traffic to its 112 destination. Another example is the breakage of 113 a TE tunnel. These may be due to physical 114 circuit failures or failure of switching nodes 115 to operate as expected. 117 Multi-vendor/multi-provider network operation typically 118 requires agreed upon definitions of defects (when it is 119 broken and when it is not) such that both recovery 120 procedures and SLA impacts can be specified. 122 ECMP: Equal Cost Multipath 124 LSP: Label Switch Path 126 LSR: Label Switch Router 128 OAM: Operations and Management 130 PE: Provider Edge 132 PW: Pseudowire 134 SLA: Service Level Agreement 136 VCC: Virtual Channel Connection 138 VPC: Virtual Path Connection 140 3 Motivations 142 MPLS OAM has been tackled in numerous Internet drafts. 143 However all existing drafts focus on single provider 144 solutions or focus on a single aspect of the MPLS architecture 145 or application of MPLS. For example, the use of RSVP or LDP 146 signaling and defects may be covered in some deployments, 147 and a corresponding SNMP MIB module exists to manage this 148 application; however, the handling of defects and specification 149 of which types of defects are interesting to operational 150 networks may not have been created in concert with those for 151 other applications of MPLS such as L3 VPN. This leads to 152 inconsistent and inefficient applicability across the MPLS 153 architecture, and/or requires significant modifications to 154 operational procedure and systems in order to provide consistent 155 and useful OAM functionality. As MPLS matures relationships 156 between providers has become more complex. Furthermore, the 157 deployment of multiple concurrent applications of MPLS is common 158 place. This has led to a need to consider deployments that span 159 arbitrary networking arrangements and boundaries; 160 so that broader and more uniform applicability to the MPLS 161 architecture for OAM is possible. 163 3. Requirements 165 The following sections enumerate the OAM requirements 166 gathered from service providers. Each requirement is 167 further specified in detail to further clarify its 168 applicability. 170 3.1 Detection of Broken Label Switch Paths 172 The ability to detect a broken Label Switch Path (LSP) 173 should not require manual hop-by-hop troubleshooting of 174 each LSR used to switch traffic for that LSP. For example, 175 it is not desirable to manually visit each LSR along the data 176 plane path used to transport an LSP; instead,this function 177 should be automated and performed from the origination of that LSP. 178 Furthermore, the automation of path liveliness is desired in 179 cases where large amounts of LSPs might be tested. For example, 180 automated PE-to-PE LSP testing functionality is desired. 181 The goal is to detect LSP problems before customers do, and 182 this requires detection of problems in a "reasonable" amount of 183 time. 185 One useful definition of reasonable is both predictable and 186 consistent. 188 If the time to detect defects is specified and tools designed 189 accordingly then a harmonized operational framework can be 190 established both within MPLS levels, and with MPLS applications. 191 If the time to detect is known, then automated responses can be 192 specified both w.r.t.with regard to resiliency and SLA 193 reporting. One consequence is that ambiguity in maintenance 194 procedures MUST be minimized as ambiguity in test results impacts 195 detection time. 197 Although ICMP-based ping can be sent through an LSP, 198 the use of this tool to verify the LSP path liveliness has the 199 potential for returning erroneous results (both positive and 200 negative) given the nature of MPLS LSPs. For example, failures can 201 be may occur where inconsistencies exist between the IP and MPLS 202 forwarding tables, inconsistencies in the MPLS control and data 203 plane or problems with the reply path (i.e.: a reverse MPLS 204 path does not exist). Detection tools should have minimal 205 dependencies on network components that do not implement the LSP. 207 The OAM packet MUST follow exactly the customer data path in order 208 to reflect path liveliness used by customer data. Particular 209 cases of interest are forwarding mechanisms such as equal cost 210 multipath (ECMP) scenarios within the operator's network whereby 211 flows are load-shared across parallel (i.e.: equal IGP cost) paths. 212 Where the customer traffic may be spread over multiple paths, it 213 is required to be able to detect failures on any of the path 214 permutations. Where the spreading mechanism is payload specific, 215 payloads need to have forwarding that is common with the traffic 216 under test. Satisfying these requirements introduces complexity 217 into ensuring that ECMP connectivity permutations are exercised, 218 and that defect detection occurs in a reasonable amount of time. 219 [GUIDELINES] discusses some of the issues and offers suggestions 220 for ensuring mutual compatibility of ECMP and maintenance 221 functions (both detection and diagnostic). 223 3.2 Diagnosis of a Broken Label Switch Path 225 The ability to diagnose a broken LSP and to isolate the failed 226 resource in the path is required. This is particularly true for 227 misbranching defects which are particularly difficult to specify 228 recovery actions in an LDP network. 229 Experience suggests that this is best accomplished via a path 230 trace function that can return the entire list of LSRs and links 231 used by a certain LSP (or at least the set of LSRs/links up to the 232 location of the defect) is required. The tracing capability should 233 include the ability to trace recursive paths, such as when nested 234 LSPs are used, or when LSPs enter and exit traffic-engineered 235 tunnels [TUNTRACE]. This path trace function must also be 236 capable of diagnosing LSP mis-merging by permitting comparison 237 of expected vs. actual forwarding behavior at any LSR in the path. 238 The path trace capability should be capable of being 239 executed from both the head end Label Switch Router (LSR) and any 240 mid-point LSR. 241 Additionally, the path trace function MUST have the ability to 242 support equal cost multipath scenarios as described above in 243 section 3.1. 245 3.3 Path characterization 247 The ability of a path trace function to reveal details of LSR 248 forwarding operations relevant to OAM functionality. This would 249 include but not be limited to: 250 - use of pipe or uniform TTL models by an LSR 251 - externally visible aspects of load spreading (such as 252 ECMP), including type of algorithm used 253 examples of how algorithm will spread traffic 254 - data/control plane OAM capabilities of the LSR 255 - stack operations performed by the LSR (pushes and pops) 257 3.4 Service Level Agreement Measurement 259 Mechanisms are required to measure diverse aspects of Service 260 Level Agreements: 261 - availability - in which the service is considered to be 262 available and the other aspects of performance measurement 263 listed below have meaning, or unavailable and other aspects 264 of performance measurement do not. 265 - latency - amount of time required for traffic to transit 266 the network 267 - packet loss 268 - jitter - measurement of latency variation 270 Such measurements can be made independently of the user traffic 271 or via a hybrid of user traffic measurement and OAM probing. 273 At least one mechanism is required to measure the quantity 274 (i.e.: number of packets) of OAM packets. In addition, the 275 ability to measure the qualitative aspects of OAM probing must 276 be available to specifically compute the latency of OAM packets 277 generated and received at each end of a tested LSP. Latency is 278 considered in this context as a measurable parameter for SLA 279 reporting. There is no assumption that bursts of OAM packets are 280 required to characterize the performance of an LSP, but it is 281 suggested that any method considered be capable of measuring the 282 latency of an LSP with minimal impact on network resources. 284 3.5 Frequency of OAM Execution 286 The operator MUST be have the flexibility to configure OAM 287 parameters and the frequency of the execution of any OAM 288 functions provided that there is some synchronization possible 289 of tool usage for availability metrics. The motivation for this 290 is to permit the network to function as a system of harmonious 291 OAM functions consistent across the entire network. 293 To elaborate, there are defect conditions (specifically 294 misbranching or misdirection of traffic) for probe based detection 295 mechanisms combined with automated network response requires 296 harmonization of probe insertion rates and probe handling across 297 the network in order to avoid flapping. 299 One observation would be that commoditization of MPLS, common 300 optimized implementation of monitoring tools and the need for inter- 301 carrier harmonization of defect and SLA handling will drive 302 specification of OAM parameters to commonly agreed on values and 303 such values will have to be harmonized with the surrounding 304 technologies (e.g. SONET/SDH, ATM etc.) in order to be useful. 305 This will become particularly important as networks scale 306 and misconfiguration can result in churn, alarm flapping etc. 308 3.5 Alarm Suppression and layer coordination 310 Devices must provide alarm suppression functionality that 311 prevents the generation of superfluous generation of alarms. 312 When viewed in conjuction with requirement 3.6 below, this 313 typically requires fault notification to the LSP egress, that 314 may have specific time constraints if the client PW independently 315 implements path continuity testing (for example ATM I.610 316 Continuity check (CC)[I610]). 318 This would also be true for LSPs that have client LSPs that are 319 monitored. MPLS arbitrary hierarchy introduces the opportunity to 320 have multiple MPLS levels attempt to respond to defects 321 simultaneously. Mechanisms are required to coordinate network 322 response to defects. 324 3.6 Support for OAM Interworking for Fault Notification 326 An LSR supporting OAM functions for pseudo-wire functions that 327 join one or more networking technologies over MPLS must be 328 able to translate an MPLS defect into the native technology's 329 error condition. For example, errors occurring over the MPLS 330 transport LSP that supports an emulated ATM VC must translate 331 errors into native ATM OAM AIS cells at the edges of the pseudo- 332 wire. The mechanism SHOULD consider possible bounded detection 333 time parameters, e.g., a "hold off" function before reacting as 334 to harmonize with the client OAM. One goal would be alarm 335 suppression in the psuedo-wire's client layer. As observed in 336 section 3.5, this requires that the MPLS layer perform detection 337 in a bounded timeframe in order to initiate alarm suppression 338 prior to the psuedo-wire client layer independently detecting the 339 defect. 341 3.7 Error Detection and Recovery. 343 Mechanisms are needed to detect an error, react to it (ideally 344 in some form of automated response by the network), recover from 345 it and alert the network operator prior to the customer informing 346 the network operator of the error condition. The ideal situation 347 would be where the network is resilient and can restore service 348 prior any significant impact on the customer perception of the 349 service. There are also defects that by virtue of available network 350 resources or topology that cannot be recovered automatically. 352 It is however, sometimes a requirement that the customer be 353 notified of the defect condition at the same time that the network 354 operator is made aware of the defect (as in the example of alarm 355 suppression for PW clients discussed above). In these situations, 356 the customer network may be capable of processing automated 357 responses based on notification of a defect condition. It is 358 preferred that the format of these notifications be made 359 consistent (i.e.: standardized) as to increase the applicability 360 of such messages. Depending on the device's capabilities, the 361 device may be programmed to take automatic corrective actions as 362 a result of detection of defect conditions. These actions may be 363 user or operator-specified, or may simply be inherent to the 364 underlying transport technology (i.e.: MPLS Fast-Reroute, 365 graceful restart or high-availability functionality). 367 3.8 The commoditization of MPLS will require common information 368 modeling of management and control of OAM functionality. This 369 will be reflected in the the integration of standard MPLS-related 370 MIBs (e.g. [LSRMIB][TEMIB][LBMIB][FTNMIB]) for fault, statistics 371 and configuration management. These standard interfaces 372 provide operators with common programmatic interface access to 373 operations and management functions and their status. 375 3.9 Detection of Denial of Service attacks as part of security 376 management. 378 3.10 Per-LSP Accounting Requirements 380 In an MPLS network, SPs can measure traffic from an LSR to the 381 egress 382 of the MPLS network using some MPLS related MIBs, for example. 383 This means that it is reasonable wish to know how much traffic is 384 traveling from where to where (i.e.: a traffic matrix) by analyzing 385 the flow of traffic. 386 Therefore, traffic accounting in an MPLS network can be summarized 387 as 388 the following three items. 390 (1) Collecting information to design network 392 For the purpose of optimized network design, SP offers that the 393 traffic information regarding among POP and/or router. 394 Optimizing network design needs this information. 396 (2) Providing high-level SLA 397 Due to the progress of the recent [MPLS-TE] technology, 398 SPs and their customers may need to verify high-level SLAs. The 399 resource optimization and high-speed restoration by [FRR] is 400 being offered; therefore, continuous improvement of the service 401 is expected. Moreover, bandwidth guaranteed service can be 402 achieved by resource management based on [DS-TE]. 404 To provide services based on these applications, the SP 405 needs to perform traffic accounting to monitor their 406 services. 408 (3) Inter-AS environment 410 SPs which offer inter-as services [Inter-AS TE][Inter-AS VPN] 411 require accounting of the service. 413 These three motivations need to satisfy the following. 415 - In (1) and (2), collection of information on a per-LSP basis 416 is a minimum level of granularity of collecting accounting 417 information at both of ingress and egress of an LSP. 419 - In (3), SP's ASBR carry out interconnection functions as an 420 intermediate LSR. Therefore, identifying a pair of ingress 421 and egress LSRs using each LSP is needed to determine the 422 cost of the service that a customer is using. 424 3.10.1 Requirements 426 Accounting on a per-LSP basis encompasses the following set of 427 functions: 429 (1) At an ingress LSR accounting of traffic through LSPs 430 beginning at each egress in question. 432 (2) At an intermediate LSR, accounting of traffic through 433 LSPs for each pair of ingress to egress. 435 (3) At egress LSR, accounting of traffic through LSPs 436 for each ingress. 438 (4) All LSRs that contain LSPs that are being measuremented 439 need to have a common key to distinguish each LSP. 440 The key must be unique to each LSP, and its mapping to 441 LSP should be provided from whether manual or automatic 442 configuration. 444 3.10.2 Scalability 446 It is not realistic to perform the just described operations by 447 LSRs in a network and on all LSPs which exist in a network. 448 At a minimum, per-LSP based accounting should be performed on the 449 edges of the network -- at the edges of both LSPs and the MPLS 450 domain. 452 4. Security Considerations 454 LSP mis-merging has security implications beyond that of simply 455 being a network defect. LSP mis-merging can happen due to a number 456 of potential sources of failure, some of which (due to MPLS label 457 stacking) are new to MPLS. 459 The performance of diagnostic functions and path characterization 460 involve extracting a significant amount of information about 461 network construction which the network operator may consider 462 private. 463 Mechanisms are required to prevent unauthorized use of either those 464 tools or protocol features. 466 5. Acknowledgments 468 The authors wish to acknowledge and thank the following 469 individuals for their valuable comments to this document: 470 Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr. 471 Ikejiri, NTT Communications and Mr.Kumaki of KDDI. 472 Hari Rakotoranto, Miya Khono, Cisco Systems; Luyuan Fang, AT&T; 473 Danny McPherson, TCB; Dr.Ken Nagami, Ikuo Nakagawa, Intec Netcore. 475 6. References 477 [TUNTRACE] Bonica, R., Kompella, K., Meyer, D., 478 "Tracing Requirements for Generic Tunnels", 479 Internet Draft , November 2001. 482 [LSRMIB] Srinivasan, C., Viswanathan, A. and T. 483 Nadeau, "MPLS Label Switch Router Management 484 Information Base Using SMIv2", Internet 485 Draft , 486 January 2001. 488 [TEMIB] Srinivasan, C., Viswanathan, A. and T. 489 Nadeau, "MPLS Traffic Engineering Management 490 Information Base Using SMIv2", Internet 491 Draft , 492 August 2001. 494 [FTNMIB] Nadeau, T., Srinivasan, C., and A. 495 Viswanathan, "Multiprotocol Label Switching 496 (MPLS) FEC-To-NHLFE (FTN) Management 497 Information Base", Internet Draft , August 2001. 500 [LBMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J. 501 Lang, "Link Bundling Management Information 502 Base Using SMIv2", Internet Draft , September 504 2001. 506 [MPLS-TE] Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP 507 Tunnels", RFC 3209, December 2001 509 [FRR] Pan et.al., "Fast Reroute Extensions to RSVP-TE for LSP 510 Tunnels", Internet draft, 511 , December 2003 513 [DS-TE] Le Faucheur & Lai., "Requirements for Diff-Serv-aware TE", 514 RFC3564, July 2003 516 [Inter-AS TE] Zhang, Vasseur, et. al., "MPLS Inter-AS Traffic 517 Engineering requirements", Internet draft 518 , May 2003 520 [Inter-AS VPN] Rosen, et al., "BGP/MPLS IP VPNs", Internet draft, 521 , September 2003 523 [PWE3FRAME] Pate, P., Xiao, X., White., C., Kompella., 524 K., Malis, A., Johnson, T., and T. Nadeau, 525 "Framework for Pseudo Wire Emulation Edge-to- 526 Edge (PWE3)", Internet Draft , September, 2001. 529 [RFC2026] S. Bradner, "The Internet Standards Process 530 -- Revision 3", RFC 2026, October 1996. 532 [Y1710] ITU-T Recommendation Y.1710, "Requirements for 533 OAM Functionality In MPLS Networks" 535 [GUIDELINES] Allan, D., "Guidelines for MPLS load 536 balancing", Internet draft, 537 , February 538 2003 540 [I610] ITU-T Recommendation I.610, "B-ISDN operations and 541 maintenance principles and functions", February 1999 543 [FRAMEWORK] Allan et.al. "A Framework for MPLS OAM", Internet 544 draft , February 2003 546 7. Authors' Addresses 548 Thomas D. Nadeau 549 Cisco Systems, Inc. 550 300 Beaver Brook Road 551 Boxboro, MA 01719 552 Phone: +1-978-936-1470 553 Email: tnadeau@cisco.com 555 Monique Jeanne Morrow 556 Cisco Systems, Inc. 557 Glatt-Com, 2nd Floor 558 CH-8301 559 Switzerland 560 Voice: (0)1 878-9412 561 Email: mmorrow@cisco.com 563 George Swallow 564 Cisco Systems, Inc. 565 300 Beaver Brook Road 566 Boxboro, MA 01719 567 Voice: +1-978-936-1398 568 Email: swallow@cisco.com 570 David Allan 571 Nortel Networks 572 3500 Carling Ave. 573 Ottawa, Ontario, CANADA 574 Voice: 1-613-763-6362 575 Email: dallan@nortelnetworks.com 577 Satoru Matsushima 578 Japan Telecom 579 4-7-1, Hatchobori, Chuo-ku 580 Tokyo, 104-8508 Japan 581 Phone: +81-3-5540-8214 582 Email: satoru@ft.solteria.net 584 8. Full Copyright Statement 586 Copyright (C) The Internet Society (2001). All Rights 587 Reserved. 589 This document and translations of it may be copied and 590 furnished to others, and derivative works that comment on 591 or otherwise explain it or assist in its implementation may 592 be prepared, copied, published and distributed, in whole or 593 in part, without restriction of any kind, provided that the 594 above copyright notice and this paragraph are included on 595 all such copies and derivative works. However, this 596 document itself may not be modified in any way, such as by 597 removing the copyright notice or references to the Internet 598 Society or other Internet organizations, except as needed 599 for the purpose of developing Internet standards in which 600 case the procedures for copyrights defined in the Internet 601 Standards process must be followed, or as required to 602 translate it into languages other than English. 604 The limited permissions granted above are perpetual and 605 will not be revoked by the Internet Society or its 606 successors or assigns. This document and the information 607 contained herein is provided on an "AS IS" basis and THE 608 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 609 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 610 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 611 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 612 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 613 PURPOSE. 615 9. Intellectual Property Rights Notices 617 The IETF takes no position regarding the validity or scope of any 618 intellectual property or other rights that might be claimed to 619 pertain to the implementation or use of the technology described in 620 this document or the extent to which any license under such rights 621 might or might not be available; neither does it represent that it 622 has made any effort to identify any such rights. Information on the 623 IETF's procedures with respect to rights in standards-track and 624 standards-related documentation can be found in BCP-11. Copies of 625 claims of rights made available for publication and any assurances 626 of licenses to be made available, or the result of an attempt made 627 to obtain a general license or permission for the use of such 628 proprietary rights by implementers or users of this specification 629 can be obtained from the IETF Secretariat. 631 The IETF invites any interested party to bring to its attention any 632 copyrights, patents or patent applications, or other proprietary 633 rights which may cover technology that may be required to practice 634 this standard. Please address the information to the IETF Executive 635 Director.