idnits 2.17.1 draft-ietf-mpls-p2mp-oam-reqs-01.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 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 583. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 'SHOULD not' in this paragraph: The ability to detect defects in a P2MP LSP SHOULD not require manual, hop-by-hop troubleshooting of each LSR used to switch traffic for that LSP, and SHOULD rely on proactive OAM procedures (such as continuous path connectivity and SLA measurement mechanisms). Any solutions SHOULD either extend or work in close conjunction with existing solutions developed for point-to-point MPLS, such as those specified in [RFC4379] where this requirement is not contradicted by the other requirements in this section. This will leverage existing software and hardware deployments. -- 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 (February 2006) is 6646 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) ** Downref: Normative reference to an Informational RFC: RFC 4377 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Seisho Yasukawa 2 Internet Draft NTT Corp 3 Expires: August 2006 4 Adrian Farrel 5 Old Dog Consulting 7 Daniel King 8 Aria Networks Ltd. 10 Thomas D. Nadeau 11 Cisco Systems, Inc. 13 February 2006 15 OAM Requirements for Point-to-Multipoint MPLS Networks 17 draft-ietf-mpls-p2mp-oam-reqs-01.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 Multi-Protocol Label Switching (MPLS) has been extended to encompass 44 point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with 45 point-to-point MPLS LSPs the requirement to detect, handle and 46 diagnose control and data plane defects is critical. 48 For operators deploying services based on P2MP MPLS LSPs the 49 detection and specification of how to handle those defects is 50 important because such defects may not only affect the fundamentals 51 of an MPLS network, but also because they may impact service level 52 specification commitments for customers of their network. 54 This document describes requirements for data plane operations and 55 management for P2MP MPLS LSPs. These requirements apply to all forms 56 of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and 57 multicast LSPs. 59 Table of Contents 61 1. Introduction .................................................. 2 62 2. Terminology ................................................... 3 63 2.1 Conventions ................................................ 3 64 2.2 Terminology ................................................ 3 65 2.3 Acronyms ................................................... 3 66 3. Motivations ................................................... 3 67 4. General Requirements .......................................... 4 68 4.1 Detection of Label Switch Path Defects ..................... 4 69 4.2 Diagnosis of a Broken Label Switch Path .................... 5 70 4.3 Path characterization ...................................... 6 71 4.4 Service Level Agreement Measurement ........................ 6 72 4.5 Frequency of OAM Execution ................................. 7 73 4.6 Alarm Suppression, Aggregation and Layer Coordination ...... 7 74 4.7 Support for OAM Interworking for Fault Notification ........ 7 75 4.8 Error Detection and Recovery ............................... 8 76 4.9 Standard Management Interfaces ............................. 8 77 4.10 Detection of Denial of Service Attacks .................... 9 78 4.11 Per-LSP Accounting Requirements ........................... 9 79 5. Security Considerations ....................................... 9 80 6. IANA Considerations .......................................... 10 81 7. References ................................................... 10 82 7.1 Normative References ...................................... 10 83 7.2 Informative References .................................... 10 84 8. Acknowledgements ............................................. 11 85 9. Authors' Addresses ........................................... 11 86 10. Intellectual Property Statement ............................. 12 87 11. Full Copyright Statement .................................... 12 89 1. Introduction 91 This document describes requirements for data plane operations and 92 management (OAM) for point-to-multipoint (P2MP) Multi-Protocol Label 93 Switching (MPLS). This draft specifies OAM requirements for P2MP 94 MPLS, as well as for applications of P2MP MPLS. 96 These requirements apply to all forms of P2MP MPLS LSPs, and include 97 P2MP Traffic Engineered (TE) LSPs [P2MP-SIG-REQ] and [P2MP-RSVP], as 98 well as multicast LDP LSPs [MCAST-LDP]. 100 Note that the requirements for OAM for P2MP MPLS build heavily on the 101 requirements for OAM for point-to-point MPLS. These latter 102 requirements are described in [RFC4377] and are not repeated in this 103 document. 105 For a generic framework for OAM in MPLS networks, refer to [RFC4378]. 107 2. Terminology 109 2.1 Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2.2 Terminology 117 Definitions of key terms for MPLS OAM are found in [RFC4377] and the 118 reader is assumed to be familiar with those definitions which are not 119 repeated here. 121 [P2MP-SIG-REQ] includes some important definitions and terms for use 122 within the context of P2MP MPLS. The reader should be familiar with 123 at least the terminology section of that document. 125 2.3 Acronyms 127 The following acronyms are used in this document. 129 CE: Customer Edge 130 DoS: Denial of service 131 ECMP: Equal Cost Multipath 132 LDP: Label Distribution Protocol 133 LSP: Label Switch Path 134 LSR: Label Switch Router 135 OAM: Operations and Management 136 OA&M: Operations, Administration and Maintenance. 137 RSVP: Resource reSerVation Protocol 138 P2MP: Point-to-Multipoint 139 SP: Service Provider 140 TE: Traffic Engineering 142 3. Motivations 144 OAM for MPLS networks has been established as a fundamental 145 requirement both through operational experience and through its 146 documentation in numerous Internet drafts. Many such documents (for 147 example, [RFC4379], [RFC3812], [RFC3813], [RFC3814], and [RFC3815]) 148 developed specific solutions to individual issues or problems. 149 Coordination of the full OAM requirements for MPLS was achieved by 150 [RFC4377] in recognition of the fact that the previous piecemeal 151 approach could lead to inconsistent and inefficient applicability of 152 OAM techniques across the MPLS architecture, and might require 153 significant modifications to operational procedures and systems in 154 order to provide consistent and useful OAM functionality. 156 This document builds on these realizations and extends the statements 157 of MPLS OAM requirements to cover the new area of P2MP MPLS. That is, 158 this document captures the requirements for P2MP MPLS OAM in advance 159 of the development of specific solutions. 161 Nevertheless, at the time of writing, some effort had already been 162 expended to extend existing MPLS OAM solutions to cover P2MP MPLS 163 (for example, [P2MP-LSP-PING]). While this approach of extending 164 existing solutions may be reasonable, in order to ensure a consistent 165 OAM framework it is necessary to articulate the full set of 166 requirements in a single document. This will facilitate a uniform set 167 of MPLS OAM solutions spanning multiple MPLS deployments and 168 concurrent applications. 170 4. General Requirements 172 The general requirements described in this section are similar to 173 those described for point-to-point MPLS in [RFC4377]. The subsections 174 below do not repeat material from [RFC4377], but simply give 175 references to that document. 177 However, where the requirements for P2MP MPLS OAM differ from or are 178 more extensive than those expressed in [RFC4377], additional text is 179 supplied. 181 In general, it should be noted that P2MP LSPs introduce a scalability 182 issue with respect to OAM that is not present in point-to-point MPLS. 183 That is, an individual P2MP LSP will have more than one egress and 184 the path to those egresses will very probably not be linear (for 185 example, it may have a tree structure). Since the number of egresses 186 for a single P2MP LSP is unknown and not bounded by any small number, 187 it follows that all mechanisms defined for OAM support MUST scale 188 well with the number of egresses and the complexity of the path of 189 the LSP. Mechanisms that are able to deal with individual egresses 190 will scale no worse than similar mechanisms for point-to-point LSPs, 191 but it is desirable to develop mechanisms that are able to leverage 192 the fact that multiple egresses are associated with a single LSP, and 193 so achieve better scaling. 195 4.1 Detection of Label Switch Path Defects 197 The ability to detect defects in a P2MP LSP SHOULD not require 198 manual, hop-by-hop troubleshooting of each LSR used to switch traffic 199 for that LSP, and SHOULD rely on proactive OAM procedures (such as 200 continuous path connectivity and SLA measurement mechanisms). Any 201 solutions SHOULD either extend or work in close conjunction with 202 existing solutions developed for point-to-point MPLS, such as those 203 specified in [RFC4379] where this requirement is not contradicted by 204 the other requirements in this section. This will leverage existing 205 software and hardware deployments. 207 Note that P2MP LSPs may introduce additional scaling concerns for LSP 208 probing by tools such as [RFC4379]. As the number of leaves of a P2MP 209 LSP increases it potentially becomes more expensive to inspect the 210 LSP to detect defects. Any tool developed for this purpose MUST be 211 cognitive of this issue and MUST include techniques to reduce the 212 scaling impact of an increase in the number of leaves. Nevertheless, 213 it should also be noted that the introduction of additional leaves 214 may mean that the use of techniques such as [RFC4379] are less 215 appropriate for defect detection with P2MP LSPs, while the technique 216 may still remain useful for defect diagnosis as described in the next 217 section. 219 Due to the above scaling concerns, LSRs or other network resources 220 MUST NOT be overwhelmed by the operation of normal proactive OAM 221 procedures, and measures taken to protect LSRs and network resources 222 against being overwhelmed MUST NOT degrade the operational value or 223 responsiveness of proactive OAM procedures. 225 By "overwhelmed" we mean that it MUST NOT be possible for an LSR to 226 be so busy handling proactive OAM that it is unable to continue to 227 process control or data plane traffic at its advertised rate. 228 Similarly, a network resource (such as a data link) MUST NOT be 229 carrying so much proactive OAM traffic that it is unable to carry the 230 advertised data rate. At the same time, it is important to configure 231 proactive OAM, if it is in use, to not raise alarms caused by the 232 failure to receive an OAM message if the component responsible for 233 processing the messages is unable to process because other components 234 are consuming too many system resources - such alarms might turn out 235 to be false. 237 In practice, of course, the requirements in the previous paragraph 238 may be overcome by careful specification of the anticipated data 239 throughput of LSRs or data links, but it should be recalled that 240 proactive OAM procedures may be scaled linearly with the number of 241 LSPs, and the number of LSPs is not necessarily a function of the 242 available bandwidth in an LSR or on a data link. 244 4.2 Diagnosis of a Broken Label Switch Path 246 The ability to diagnose a broken P2MP LSP and to isolate the failed 247 component (i.e., link or node) in the path is REQUIRED. These 248 functions include a path connectivity test that can test all branches 249 and leaves of a P2MP LSP for reachability, as well as a path tracing 250 function. Note that this requirement is distinct from the requirement 251 to detect errors or failures described in the previous section. In 252 practice Detection and Diagnosis/Isolation MAY be performed by 253 separate or the same mechanisms according to the way in which the 254 other requirements are met. 256 It MUST be possible for the operator (or an automated process) to 257 stipulate a timeout after which the failure to see a response shall 258 be flagged as an error. 260 Any mechanism developed to perform these functions is subject to the 261 scalability concerns expressed in section 4. 263 4.3 Path Characterization 265 The path characterization function [RFC4377] is the ability to reveal 266 details of LSR forwarding operations for P2MP LSPs. These details can 267 then be compared later during subsequent testing relevant to OAM 268 functionality. Therefore, LSRs supporting P2MP LSPs MUST provide 269 mechanisms that allow operators to interrogate and characterize P2MP 270 paths. 272 Since P2MP paths are more complex than the paths of point-to-point 273 LSPs, the scaling concerns expressed in section 4 apply. 275 Note that path characterization SHOULD lead to the operator being 276 able to determine the full tree for a P2MP LSP. That is, it is not 277 sufficient to know the list of LSRs in the tree, but it is important 278 to know their relative order and where the LSP branches. 280 Since, in some cases, the control plane state and data paths may 281 branch at different points from the control plane and data plane 282 topologies (for example, figure 1), it is not sufficient to present 283 the order of LSRs, but it is important that the branching points on 284 that tree are clearly identified. 286 E 287 / 288 A---B---C===D 289 \ 290 F 292 Figure 1. An example P2MP tree where the data path and control plane 293 state branch at C, but the topology branches at D. 295 A diagnostic tool that meets the path characterization requirements 296 SHOULD collect information that is easy to process to determine the 297 P2MP tree for a P2MP LSP, rather than provide information that must 298 be post-processed with some complexity. 300 4.4 Service Level Agreement Measurement 302 Mechanisms are required to measure the diverse aspects of Service 303 Level Agreements for services that utilize P2MP LSPs. The aspects 304 are listed in [RFC4377]. 306 Service Level Agreements are often measured in terms of the quality 307 and rate of data delivery. In the context of P2MP MPLS, data is 308 delivered to multiple egress nodes. The mechanisms MUST, therefore, 309 be capable of measuring the aspects of Service Level Agreements as 310 they apply to each of the egress points to a P2MP LSP. At the same 311 time, in order to diagnose issues with meeting Service Level 312 Agreements, mechanisms SHOULD be provided to measure the aspects of 313 the agreements at key points within the network such as at branch 314 nodes on the P2MP tree. 316 4.5 Frequency of OAM Execution 318 As stipulated in [RFC4377], the operator MUST have the flexibility 319 to configure OAM parameters to meet their specific operational 320 requirements. This requirement is potentially more important in P2MP 321 deployments where the effects of the execution of OAM functions can 322 be potentially much greater than in a non-P2MP configuration. For 323 example, a mechanism that causes each egress of a P2MP LSP to respond 324 could result in a large burst of responses for a single OAM request. 326 Therefore, solutions produced SHOULD NOT impose any fixed limitations 327 on the frequency of the execution of any OAM functions. 329 4.6 Alarm Suppression, Aggregation and Layer Coordination 331 As described in [RFC4377], network elements MUST provide alarm 332 suppression and aggregation mechanisms to prevent the generation of 333 superfluous alarms within or across network layers. The same time 334 constraint issues identified in [RFC4377] also apply to P2MP LSPs. 336 A P2MP LSP also brings the possibility of a single fault causing a 337 larger number of alarms than for a point-to-point LSP. This can 338 happen because there are a larger number of downstream LSRs (for 339 example, a larger number of egresses). The resultant multiplier in 340 the number of alarms could cause swamping of the alarm management 341 systems to which the alarms are reported, and serves as a multiplier 342 to the number of potentially duplicate alarms raised by the network. 344 Alarm aggregation or limitation techniques MUST be applied within any 345 solution, or be available within an implementation, so that this 346 scaling issue can be reduced. Note that this requirement introduces a 347 second dimension to the concept of alarm aggregation. Where 348 previously it applied to the correlation and suppression of alarms 349 generated by different network layers, it now also applies to similar 350 techniques applied to alarms generated by multiple downstream LSRs. 352 4.7 Support for OAM Interworking for Fault Notification 354 [RFC4377] specifies that an LSR supporting the interworking of 355 one or more networking technologies over MPLS MUST be able to 356 translate an MPLS defect into the native technology's error 357 condition. This also applies to any LSR supporting P2MP LSPs. 358 However, careful attention to the requirements for alarm suppression 359 stipulated therein and in section 4.6 SHOULD be observed. 361 Note that the time constraints for fault notification and alarm 362 propagation impact upon the solutions that might be applied to the 363 scalability problem inherent in certain OAM techniques applied to 364 P2MP LSPs. For example, a solution to the issue of a large number 365 of egresses all responding to some form of probe request at the 366 same time, might be to make the probes less frequent - but this 367 might impact on the ability to detect and/or report faults. 369 Where fault notification to the egress is required, there is the 370 possibility that a single fault will give rise to multiple 371 notifications, one to each egress node of the P2MP that is downstream 372 of the fault. Any mechanisms MUST manage this scaling issue while 373 still continuing to deliver fault notifications in a timely manner. 375 Where fault notification to the ingress is required, the mechanisms 376 MUST ensure that the notification identifies the egress nodes of the 377 P2MP LSP that are impacted (that is, those downstream of the fault) 378 and does not falsely imply that all egress nodes are impacted. 380 4.8 Error Detection and Recovery 382 Recovery from a fault by a network element can be facilitated by 383 MPLS OAM procedures. As described in [RFC4377], these procedures 384 will detect a broad range of defects, and SHOULD be operable where 385 MPLS P2MP LSPs span multiple routing areas, or multiple Service 386 Provider domains. 388 The same requirements as those expressed in [RFC4377] with respect 389 to automatic repair and operator intervention ahead of customer 390 detection of faults apply to P2MP LSPs. 392 It should be observed that faults in P2MP LSPs MAY be recovered 393 through techniques described in [P2MP-RSVP]. 395 4.9 Standard Management Interfaces 397 The wide-spread deployment of MPLS requires common information 398 modeling of management and control of OAM functionality. This is 399 reflected in the integration of standard MPLS-related MIBs 400 [RFC3813], [RFC3812], [RFC3814], [RFC3815] for fault, statistics 401 and configuration management. These standard interfaces provide 402 operators with common programmatic interface access to 403 operations and management functions and their status. 405 The standard MPLS-related MIB modules [RFC3812], [RFC3813], 406 [RFC3814], and [RFC3815] SHOULD be extended wherever possible, to 407 support P2MP LSPs, the associated OAM functions on these LSPs, and 408 the applications that utilize P2MP LSPs. Extending them will 409 facilitate the reuse of existing management software both in LSRs 410 and in management systems. In cases where the existing MIB modules 411 cannot be extended, then new MIB modules MUST be created. 413 4.10 Detection of Denial of Service Attacks 415 The ability to detect denial of service (DoS) attacks against the 416 data or control planes which signal P2MP LSPs MUST be part of 417 any security management related to MPLS OAM tools or techniques. 419 4.11 Per-LSP Accounting Requirements 421 In an MPLS network where P2MP LSPs are in use, Service Providers can 422 measure traffic from an LSR to the egress of the network using some 423 MPLS-related MIB modules (see section 4.9), for example. Other 424 interfaces MAY exist as well and enable the creation of traffic 425 matrices so that it is possible to know how much traffic is 426 traveling from where to where within the network. 428 Analysis of traffic flows to produce a traffic matrix is more 429 complicated where P2MP LSPs are deployed because there is no simple 430 pairing relationship between an ingress and a single egress. 431 Fundamental to understanding traffic flows within a network that 432 supports P2MP LSPs will be the knowledge of where the traffic is 433 branched for each LSP within the network. That is, where within the 434 network the branch nodes for the LSPs are located and what their 435 relationship is to links and other LSRs. Traffic flow and 436 accounting tools MUST take this fact into account. 438 5. Security Considerations 440 This document introduces no new security issues compared with 441 [RFC4377]. It is worth highlighting, however, that any tool designed 442 to satisfy the requirements described in this document MUST include 443 provisions to prevent its unauthorized use. Likewise, these tools 444 MUST provide a means by which an operator can prevent denial of 445 service attacks if those tools are used in such an attack. 446 LSP mis-merging is described in [RFC4377] where it is pointed out 447 that it has security implications beyond simply being a network 448 defect. It needs to be stressed that it is in the nature of P2MP 449 traffic flows that any erroneous delivery (such as caused by LSP 450 mis-merging) is likely to have more far reaching consequences since 451 the traffic will be mis-delivered to multiple receivers. 453 As with the OAM functions described in [RFC4377], the 454 performance of diagnostic functions and path characterization may 455 involve the extraction of a significant amount of information about 456 network construction. The network operator MAY consider this 457 information private and wish to take steps to secure it, but further, 458 the volume of this information may be considered as a threat to the 459 integrity of the network if it is extracted in bulk. This issue may 460 be greater in P2MP MPLS because of the potential for a large number 461 of receivers on a single LSP and the consequent extensive path of the 462 LSP. 464 6. IANA Considerations 466 This document creates no new requirements on IANA namespaces. 468 7. References 470 7.1 Normative References 472 [RFC4377] T. Nadeau, M. Morrow, G. Swallow, D. Allan, and 473 S. Matsushima, "Operations and Management (OAM) 474 Requirements for Multi-Protocol Label Switched 475 (MPLS) Networks", RFC 4377, February 2006. 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, March 1997. 480 7.2 Informative References 482 [RFC4378] Alan, D., Nadeau T., "A Framework for 483 Multi-Protocol Label Switching (MPLS) Operations 484 and Management (OAM)", RFC4378, February 2006. 486 [RFC4379] Kompella, K., and Swallow, G., (Editors), "Detecting 487 MPLS Data Plane Failures", RFC 4379, February 2006. 489 [MCAST-LDP] IJ., Wijnands, I. Minei, et al., "Label Distribution 490 Protocol Extensions for Point-to-Multipoint and 491 Multipoint-to-Multipoint Label Switched Paths", 492 draft-minei-wijnands-mpls-ldp-p2mp, work in 493 progress. 495 [P2MP-LSP-PING] Yasukawa, S., Farrel, A., Ali, Z., and Fenner, B., 496 "Detecting Data Plane Failures in 497 Point-to-Multipoint MPLS Traffic Engineering - 498 Extensions to LSP Ping", 499 draft-yasukawa-mpls-p2mp-lsp-ping, work in progress. 501 [P2MP-RSVP] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 502 "Extensions to RSVP-TE for Point to Multipoint TE 503 LSPs", draft-ietf-mpls-rsvp-te-p2mp, work in 504 progress. 506 [P2MP-SIG-REQ] Yasukawa, S. (Editor), "Signaling Requirements for 507 Point to Multipoint Traffic Engineered MPLS LSPs", 508 draft-ietf-mpls-p2mp-sig-requirement, work in 509 progress. 511 [RFC3812] Srinivasan, C., Viswanathan, A. and T. 512 Nadeau, "MPLS Traffic Engineering Management 513 Information Base Using SMIv2", RFC3812, June 2004. 515 [RFC3813] Srinivasan, C., Viswanathan, A. and T. 516 Nadeau, "MPLS Label Switch Router Management 517 Information Base Using SMIv2", RFC3813, June 2004. 519 [RFC3814] Nadeau, T., Srinivasan, C., and A. 520 Viswanathan, "Multiprotocol Label Switching 521 (MPLS) FEC-To-NHLFE (FTN) Management 522 Information Base", RFC3814, June 2004. 524 [RFC3815] Cucchiara, J., Sjostrand, H., and Luciani, J., 525 "Definitions of Managed Objects for the 526 Multiprotocol Label Switching (MPLS), Label 527 Distribution Protocol (LDP)", RFC 3815, June 2004. 529 8. Acknowledgment 531 The authors wish to acknowledge and thank the following 532 individuals for their valuable comments to this document: 533 Rahul Aggarwal, Neil Harrison, Ben Niven-Jenkins and Dimitri 534 Papadimitriou. 536 9. Authors' Addresses 538 Adrian Farrel 539 Old Dog Consulting 540 Phone: +44 (0) 1978 860944 541 Email: adrian@olddog.co.uk 543 Daniel King 544 Aria Networks Ltd. 545 Phone: +44 (0)1249 665923 546 Email: daniel.king@aria-networks.com 548 Thomas D. Nadeau 549 Cisco Systems, Inc. 550 1414 Massachusetts Ave. 551 Boxborough, MA 01719 552 Email: tnadeau@cisco.com 553 Seisho Yasukawa 554 NTT Corporation 555 9-11, Midori-Cho 3-Chome 556 Musashino-Shi, Tokyo 180-8585, 557 Japan 558 Phone: +81 422 59 4769 559 Email: yasukawa.seisho@lab.ntt.co.jp 561 10. Intellectual Property Statement 563 The IETF takes no position regarding the validity or scope of any 564 Intellectual Property Rights or other rights that might be claimed to 565 pertain to the implementation or use of the technology described in 566 this document or the extent to which any license under such rights 567 might or might not be available; nor does it represent that it has 568 made any independent effort to identify any such rights. Information 569 on the procedures with respect to rights in RFC documents can be 570 found in BCP 78 and BCP 79. 572 Copies of IPR disclosures made to the IETF Secretariat and any 573 assurances of licenses to be made available, or the result of an 574 attempt made to obtain a general license or permission for the use of 575 such proprietary rights by implementers or users of this 576 specification can be obtained from the IETF on-line IPR repository at 577 http://www.ietf.org/ipr. 579 The IETF invites any interested party to bring to its attention any 580 copyrights, patents or patent applications, or other proprietary 581 rights that may cover technology that may be required to implement 582 this standard. Please address the information to the IETF at 583 ietf-ipr@ietf.org. 585 11. Full Copyright Statement 587 Copyright (C) The Internet Society (2006). This document is subject 588 to the rights, licenses and restrictions contained in BCP 78, and 589 except as set forth therein, the authors retain all their rights. 591 This document and the information contained herein are provided on an 592 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 593 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 594 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 595 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 596 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.