idnits 2.17.1 draft-ietf-mpls-oam-requirements-07.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 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 694. ** 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 'MUST not' in this paragraph: The ability to detect defects in a broken Label Switched Path (LSP) MUST not require manual hop-by-hop troubleshooting of each LSR used to switch traffic for that LSP. For example, it is not desirable to manually visit each LSR along the data plane path used to transport an LSP; instead, this function MUST be automated and able to be performed at some operator specified frequency from the origination point of that LSP. This implies solutions that are interoperable as to allow for such automatic operation. -- 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 (December 2005) is 6697 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) == Outdated reference: A later version (-13) exists of draft-ietf-mpls-lsp-ping-11 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Thomas D. Nadeau 2 Internet Draft Monique Morrow 3 Expires: June 2006 George Swallow 4 Cisco Systems, Inc. 6 David Allan 7 Nortel Networks 9 Satoru Matsushima 10 Japan Telecom 12 December 2005 14 Operations and Management Requirements 15 for Multi-Protocol Label Switched Networks 17 draft-ietf-mpls-oam-requirements-07.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that 22 any applicable patent or other IPR claims of which he or she is 23 aware have been or will be disclosed, and any of which he or she 24 becomes aware will be disclosed, in accordance with Section 6 of 25 BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use 35 Internet-Drafts as reference material or to cite them other than 36 as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Abstract 46 This document specifies Operations and Management requirements 47 for Multi-Protocol Label Switching, as well as for applications 48 draft-ietf-mpls-oam-requirements-07 December 7, 2005 50 of Multi-Protocol Label Switching such as pseudo-wire voice and 51 virtual private network services. These requirements 52 have been gathered from network operators who have extensive 53 experience deploying Multi-Protocol Label Switching networks. 55 Table of Contents 57 Abstract ....................................................1 58 1. Introduction ................................................2 59 2. Document Conventions ........................................2 60 2.1 Terminology .................................................2 61 2.2 Acronyms ....................................................2 62 3. Motivations .................................................2 63 4. Requirements ................................................2 64 5. Security Considerations ....................................26 65 6. IANA considerations ........................................27 66 7. References .................................................27 67 7.1 Normative references .......................................27 68 7.2 Informative references .....................................29 69 8. Author's Addresses .........................................29 70 9. Intellectual Property Notice ...............................30 71 10. Full Copyright Statement ...................................29 73 1. Introduction 75 This document describes requirements for user and data 76 plane operations and management (OAM) for Multi-Protocol 77 Label Switching (MPLS). These requirements have been gathered 78 from network operators who have extensive experience deploying 79 MPLS networks. This draft specifies OAM requirements 80 for MPLS, as well as for applications of MPLS. 82 No specific mechanisms are proposed to address these 83 requirements at this time. The goal of this draft is to 84 identify a commonly applicable set of requirements for MPLS 85 OAM at this time. Specifically, a set of requirements that apply 86 to the most common set of MPLS networks deployed by service 87 provider organizations today at the time this document was 88 written. These requirements can then be used 89 as a base for network management tool development and to guide 90 the evolution of currently specified tools, as well as the 91 specification of OAM functions that are intrinsic to protocols 92 used in MPLS networks. 94 Comments should be made directly to the MPLS mailing list 95 at mpls@lists.ietf.org. 97 draft-ietf-mpls-oam-requirements-07 December 7, 2005 99 2. Document Conventions 101 2.1 Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 Queuing/buffering Latency: delay caused by packet queuing (value is 108 variable since depending on the packet 109 arrival rate in addition to the 110 dependence on the packet length and the 111 link throughput). 113 Probe-based-detection: Active measurement tool which can measure 114 the consistency of an LSP [LSPPING]. 116 Defect: Any error condition that prevents an Label 117 Switched Path functioning correctly. For 118 example, loss of an IGP path will most 119 likely also result in a Label Switched 120 Path not being able to deliver traffic to 121 its destination. Another example is the 122 breakage of a TE tunnel. These may be due 123 to physical circuit failures or failure 124 of switching nodes to operate as expected. 126 Multi-vendor/multi-provider network 127 operation typically requires agreed upon 128 definitions of defects (when it is broken 129 and when it is not) such that both 130 recovery procedures and service level 131 specification impacts can be specified. 133 Head-end Label Switching 134 Router (LSR): The beginning of a label switched path. A 135 head-end LSR is also referred to as an 136 ingress LSR. 138 Tail-end Label Switching 139 Router (LSR): The end of a label switched path. A 140 tail-end LSR is also referred to as an 141 egress LSR. 143 Propagation Latency: The delay added by the propagation of the 144 draft-ietf-mpls-oam-requirements-07 December 7, 2005 146 packet through the link (fixed value that 147 depends on the distance of the link and 148 the propagation speed). 150 Transmission Latency: The delay added by the transmission of 151 the packet over the link i.e. the time 152 it takes put the packet over the media 153 (value that depends on the link 154 throughput and packet length). 156 Processing Latency: The delay added by all the operations 157 related to the switching of labeled 158 packet (value is node implementation 159 specific and may be considered as fixed 160 and constant for a given type of 161 equipment). 163 Node Latency: The delay added by the network element 164 resulting from of the sum of the 165 transmission, processing and queuing/ 166 buffering latency 168 One-hop Delay: The fixed delay experienced by a packet 169 to reach the next hop resulting from the 170 of the propagation latency, the 171 transmission latency and the processing 172 latency. 174 Minimum Path Latency: The sum of the one-hop delays experienced 175 by the packet when traveling from the 176 ingress to the egress LSR. 178 Variable Path Latency: The sum of the delays caused by the 179 queuing latency experienced by the 180 packet at each node over the path. 181 Otherwise known as jitter. 183 2.2 Acronyms 185 ASBR: Autonomous System Border Router 187 CE: Customer Edge 189 PE: Provider Edge 191 SP: Service Provider 192 draft-ietf-mpls-oam-requirements-07 December 7, 2005 194 ECMP: Equal Cost Multi-path 196 LSP: Label Switched Path 198 LSP Ping: Label Switched Path Ping 200 LSR: Label Switching Router 202 OAM: Operations and Management 204 RSVP: Resource reSerVation Protocol 206 LDP: Label Distribution Protocol 208 DoS: Denial of service 210 3. Motivations 212 This document was created in order to provide requirements 213 which could be used to create consistent and useful OAM 214 functionality that meets operational requirements of those 215 service providers who have or are deploying MPLS. 217 4. Requirements 219 The following sections enumerate the OAM requirements 220 gathered from service providers who have deployed MPLS 221 and services based on MPLS networks. Each requirement is 222 specified in detail to clarify its applicability. 223 Although the requirements specified herein are defined by 224 the IETF, they have been made consistent with requirements 225 gathered by other standards bodies such as the ITU [Y1710]. 227 4.1 Detection of Label Switched Path Defects 229 The ability to detect defects in a broken Label Switched Path 230 (LSP) MUST not require manual hop-by-hop troubleshooting of 231 each LSR used to switch traffic for that LSP. For example, 232 it is not desirable to manually visit each LSR along the data 233 plane path used to transport an LSP; instead, this function 234 MUST be automated and able to be performed at some operator 235 specified frequency from the origination point of that LSP. 236 This implies solutions that are interoperable as to allow for 237 such automatic operation. 239 Furthermore, the automation of path liveliness is desired in 240 draft-ietf-mpls-oam-requirements-07 December 7, 2005 242 cases where large numbers of LSPs might be tested. For example, 243 automated ingress LSR to egress LSR testing functionality is 244 desired for some LSPs. The goal is to detect LSP path defects 245 before customers do, and this requires detection and correction 246 of LSP defects in a manner that is both predictable and 247 sufficiently within the constraints of the service level agreement 248 under which the service is being offered. Simply put, the sum of 249 the time it takes an OAM tool to detect a defect and 250 the time needed for an operational support system to react to 251 this defect by possibly correcting it or notifying the customer, 252 must fall within the bounds of the service level agreement in 253 question. 255 Synchronization of detection time bounds by tools used to detect 256 broken LSPs is required. Failure to specify defect detection 257 time bounds may result in an ambiguity in test results. If the 258 time to detect is known, then automated responses can be specified 259 both with respect to and with regard to resiliency and service 260 level specification reporting. Further, if synchronization of 261 detection time bounds is possible, an operational framework can be 262 established that can guide the design and specification of MPLS 263 applications. 265 Although ICMP-based ping [RFC792] can be sent through an LSP as 266 an IP payload, the use of this tool to verify the defect free 267 operation of an LSP has the potential for returning erroneous 268 results (both positive and negative) for a number of reasons. First, 269 since the ICMP traffic is based on legally addressable IP addressing, 270 it is possible for ICMP messages that are originally transmitted 271 inside of an LSP to "fall out of the LSP" at some point along 272 the path. In these cases, since ICMP packets are routable 273 a falsely positive response may be returned. In other cases 274 where the data plane of a specific LSP needs to be tested, it 275 is difficult to guarantee that traffic based on an ICMP ping 276 header is parsed and hashed to the same equal-cost multi-paths 277 as the data traffic. 279 Any detection mechanisms that depend on receiving status via a 280 return path SHOULD provide multiple return options with the 281 expectation that one of them will not be impacted by the original 282 defect. An example of a case where a false negative might occur 283 would be a mechanism that requires a functional MPLS return path. 284 Since MPLS LSPs are unidirectional, it is possible that although 285 the forward LSP which is the LSP under test, might be functioning, 286 the response from the destination LSR might be lost, thus giving 287 the source LSR the false impression that the forward LSP is 288 defective. However, if an alternate return path could be 289 draft-ietf-mpls-oam-requirements-07 December 7, 2005 291 specified -- say IP for example -- then the source could 292 specify this as the return path to the destination, and in 293 this case, would receive a response indicating to it that 294 the return LSP is defective. 296 The OAM packet MUST follow exactly the customer data path in order 297 to reflect path liveliness used by customer data. Particular cases 298 of interest are forwarding mechanisms such as equal cost multi-path 299 (ECMP) scenarios within the operator's network whereby flows are 300 load-shared across parallel (i.e., equal IGP cost) paths. Where 301 the customer traffic may be spread over multiple paths, what is 302 required is to be able to detect failures on any of the path 303 permutations. Where the spreading mechanism is payload specific, 304 payloads need to have forwarding that is common with the traffic 305 under test. Satisfying these requirements introduces complexity 306 into ensuring that ECMP connectivity permutations are exercised, 307 and that defect detection occurs in a reasonable amount of time. 309 4.2 Diagnosis of a Broken Label Switched Path 311 The ability to diagnose a broken LSP and to isolate the failed 312 component (i.e., link or node) in the path is required. For 313 example, note that specifying recovery actions for mis-branching 314 defects in an LDP network is a particularly difficult case. 315 Diagnosis of defects and isolation of the failed component is 316 best accomplished via a path trace function which can return the 317 the entire list of LSRs and links used by a certain LSP (or at 318 least the set of LSRs/links up to the location of the defect) is 319 required. The tracing capability SHOULD include the ability to 320 trace recursive paths, such as when nested LSPs are used. This 321 path trace function MUST also be capable of diagnosing LSP 322 mis-merging by permitting comparison of expected vs. actual 323 forwarding behavior at any LSR in the path. The path trace 324 capability SHOULD be capable of being executed from both the 325 head-end Label Switching Router (LSR) and may permit downstream 326 path components to be traced from an intermediate mid-point LSR. 327 Additionally, the path trace function MUST have the ability to 328 support equal cost multi-path scenarios described above in 329 section 4.1. 331 4.3 Path characterization 333 The path characterization function is the ability to reveal details 334 of LSR forwarding operations. These details can then be compared 335 later during subsequent testing relevant to OAM functionality. 336 This would include but is not limited to: 338 draft-ietf-mpls-oam-requirements-07 December 7, 2005 340 - consistent use of pipe or uniform time to live (TTL) models by 341 an LSR [RFC3443]. 342 - sufficient details that allow the test origin to 343 excursive all path permutations related to load spreading 344 (e.g. ECMP). 345 - stack operations performed by the LSR, such as pushes, pops, 346 and TTL propagation at penultimate hop LSRs. 348 4.4 Service Level Agreement Measurement 350 Mechanisms are required to measure the diverse aspects of Service 351 Level Agreements which include: 352 - defect free forwarding. The service is considered to be 353 available and the other aspects of performance measurement 354 listed below have meaning, or the service is unavailable and 355 other aspects of performance measurement do not. 356 - latency - amount of time required for traffic to transit 357 the network 358 - packet loss 359 - jitter - measurement of latency variation 361 Such measurements can be made independently of the user traffic 362 or via a hybrid of user traffic measurement and OAM probing. 364 At least one mechanism is required to measure the number 365 of OAM packets. In addition, the ability to measure the 366 quantitative aspects of LSPs such as jitter, delay, latency and 367 loss MUST be available in order to determine whether or not the 368 traffic for a specific LSP are traveling within the 369 operator-specified tolerances. 371 Any method considered SHOULD be capable of measuring the latency 372 of an LSP with minimal impact on network resources. See section 373 2.1 for definitions of the various quantitative aspects of LSPs. 375 4.5 Frequency of OAM Execution 377 The operator MUST have the flexibility to configure OAM 378 parameters insofar-as to meet their specific operational 379 requirements. 381 This includes the frequency of the execution of any OAM 382 functions. The capability to synchronize OAM operations is required 383 as to to permit consistent measurement of service level agreements. 384 To elaborate, there are defect conditions such as mis-branching or 385 draft-ietf-mpls-oam-requirements-07 December 7, 2005 387 misdirection of traffic for which probe-based detection mechanisms 388 that incur significant mismatches in their detection frequency may 389 result in flapping. This can be addressed either by synchronizing 390 the rate or having the probes self-identify their probe rate. 391 For example, when the probing mechanisms are bootstrapping, 392 they might negotiate and ultimately agree on a probing rate, 393 therefore providing a consistent probing frequency and avoiding 394 the aforementioned problems. 396 One observation would be that wide-spread deployment of MPLS, common 397 implementation of monitoring tools and the need for 398 inter-carrier synchronization of defect and service level 399 specification handling will drive specification of OAM parameters 400 to commonly agreed on values and such values will have to be 401 harmonized with the surrounding technologies (e.g. SONET/SDH, 402 ATM etc.) in order to be useful. This will become particularly 403 important as networks scale and mis-configuration can result in 404 churn, alarm flapping etc. 406 4.6 Alarm Suppression, Aggregation and Layer Coordination 408 Network elements MUST provide alarm suppression functionality that 409 prevents the generation of superfluous generation of alarms by 410 simply discarding them (or not generating them in the first place), 411 or by aggregating them together, and thereby greatly reducing the 412 number of notifications emitted. When viewed in conjunction with 413 requirement 4.7 below, this typically requires fault notification 414 to the LSP egress that may have specific time constraints if the 415 application using the LSP independently implements path continuity 416 testing (for example ATM I.610 Continuity check (CC)[I610]). 417 These constraints apply to LSPs that are monitored. The nature of 418 MPLS applications allows for the possibility to have multiple MPLS 419 applications attempt to respond to defects simultaneously. For 420 example, layer-3 MPLS VPNs that utilize Traffic Engineered tunnels, 421 where a failure occurs on the LSP carrying the Traffic Engineered 422 tunnel. This failure would affect he VPN traffic that uses the 423 tunnel's LSP. Mechanisms are required to coordinate network response 424 to defects. 426 4.7 Support for OAM Inter-working for Fault Notification 428 An LSR supporting the inter-working of one or more networking 429 technologies over MPLS MUST be able to translate an MPLS defect 430 into the native technology's error condition. For example, errors 431 occurring over a MPLS transport LSP that supports an emulated 432 draft-ietf-mpls-oam-requirements-07 December 7, 2005 434 ATM VC MUST translate errors into native ATM OAM Alarm Indication 435 Signal (AIS) cells at the termination points of the LSP. The 436 mechanism SHOULD consider possible bounded detection time 437 parameters, e.g., a "hold off" function before reacting as to 438 synchronize with the OAM functions. 439 One goal would be alarm suppression by the upper layer using 440 the LSP. As observed in section 4.5, this requires that MPLS 441 perform detection in a bounded timeframe in order to initiate 442 alarm suppression prior to the upper layer independently 443 detecting the defect. 445 4.8 Error Detection and Recovery. 447 Recovery from a fault by a network element can be facilitated by 448 MPLS OAM procedures. These procedures will detect a broader range 449 of defects than that of simple link and node failures. 450 Since MPLS LSPs may span multiple routing areas and service provider 451 domains, fault recovery and error detection should be possible 452 in these configuration as well as in the more simplified 453 single-area/domain configurations. 455 Recovery from faults SHOULD be automatic. It is a requirement that 456 faults SHOULD be detected (and possibly corrected) by the network 457 operator prior to customers of the service in question detecting 458 them. 460 4.9 Standard Management Interfaces 462 The wide-spread deployment of MPLS requires common information 463 modeling of management and control of OAM functionality. 464 Evidence of this is reflected in the standard IETF MPLS-related 465 MIB modules (e.g. [RFC3813][RFC3812][RFC3814]) for fault, 466 statistics and configuration management. These standard interfaces 467 provide operators with common programmatic interface access to 468 operations and management functions and their status. However, 469 gaps in coverage of MIB modules to OAM and other features 470 exists; therefore, MIB modules corresponding to new protocol 471 functions or network tools are required. 473 4.10 Detection of Denial of Service Attacks 475 The ability to detect denial of service (DoS) attacks against the 476 data or control planes MUST be part of any security management 477 related to MPLS OAM tools or techniques. 479 4.11 Per-LSP Accounting Requirements 480 draft-ietf-mpls-oam-requirements-07 December 7, 2005 482 In an MPLS network, service providers (SPs) can measure traffic 483 from an LSR to the egress of the network using some MPLS related 484 MIBs, for example. This means that it is a reasonable to know how 485 much traffic is traveling from where to where (i.e., a traffic 486 matrix) by analyzing the flow of traffic. Therefore, traffic 487 accounting in an MPLS network can be summarized as the following 488 three items. 490 (1) Collecting information to design network 492 Providers and their customers MAY need to verify high-level 493 service level specifications, either to continuously 494 optimize their networks, or to offer guaranteed bandwidth 495 services. Therefore, traffic accounting to monitor MPLS 496 applications is required. 498 (2) Providing a Service Level Specification 500 For the purpose of optimized network design, a service 501 provider may offer the traffic information. Optimizing 502 network design needs this information. 504 (3) Inter-AS environment 506 Service providers that offer inter-AS services require 507 accounting of those services. 509 These three motivations need to satisfy the following. 511 - In (1) and (2), collection of information on a per-LSP 512 basis is a minimum level of granularity of collecting 513 accounting information at both of ingress and egress 514 of an LSP. 516 - In (3), SP's ASBR carry out interconnection functions as an 517 intermediate LSR. Therefore, identifying a pair of ingress 518 and egress LSRs using each LSP is needed to determine the 519 cost of the service that a customer is using. 521 4.11.1 Requirements 523 Accounting on a per-LSP basis encompasses the following set of 524 functions: 526 (1) At an ingress LSR accounting of traffic through LSPs 527 beginning at each egress in question. 529 draft-ietf-mpls-oam-requirements-07 December 7, 2005 531 (2) At an intermediate LSR, accounting of traffic through 532 LSPs for each pair of ingress to egress. 534 (3) At egress LSR, accounting of traffic through LSPs 535 for each ingress. 537 (4) All LSRs that contain LSPs that are being measured 538 need to have a common identifier to distinguish each LSP. 539 The identifier MUST be unique to each LSP, and its mapping to 540 LSP SHOULD be provided from whether manual or automatic 541 configuration. 543 In the case of non-merged LSPs, this can be achieved by 544 simply reading traffic counters for the label stack associated 545 with the LSP at any LSR along its path. However, in order to 546 measure merged LSPs, an LSR MUST have a means to distinguish 547 the source of each flow so as to disambiguate the statistics. 549 4.11.2 Location of Accounting 551 It is not realistic to perform the just described operations by 552 LSRs in a network on all LSPs that exist in a network. 553 At a minimum, per-LSP based accounting SHOULD be performed on the 554 edges of the network -- at the edges of both LSPs and the MPLS 555 domain. 557 5. Security Considerations 559 Provisions to any of the network mechanisms designed to satisfy 560 the requirements described herein are required to prevent their 561 unauthorized use. Likewise, these network mechanisms MUST 562 provide a means by which an operator can prevent denial of 563 service attacks if those network mechanisms are used in such 564 an attack. 566 LSP mis-merging has security implications beyond that of simply 567 being a network defect. LSP mis-merging can happen due to a number 568 of potential sources of failure, some of which (due to MPLS label 569 stacking) are new to MPLS. 571 The performance of diagnostic functions and path characterization 572 involve extracting a significant amount of information about 573 network construction which the network operator MAY consider 574 private. 576 6. IANA Considerations 577 draft-ietf-mpls-oam-requirements-07 December 7, 2005 579 This document creates no new requirements on IANA namespaces 580 [RFC2434]. 582 7. References 584 7.1 Normative References 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 7.2 Informative References 591 [LSPPING] Kompella, K., G. Swallow, " Detecting MPLS Data Plane 592 Failures", Internet Draft draft-ietf-mpls-lsp-ping-11.txt, 593 November 2005. 595 [RFC3812] Srinivasan, C., Viswanathan, A. and T. 596 Nadeau, "Multiprotocol Label Switching 597 (MPLS) Traffic Engineering (TE) 598 Management Information Base (MIB)", 599 RFC3812, June 2004. 601 [RFC3813] Srinivasan, C., Viswanathan, A. and T. 602 Nadeau, "Multiprotocol Label Switching 603 (MPLS) Label Switching Router (LSR) 604 Management Information Base (MIB)", RFC3813, 605 June 2004. 607 [RFC3814] Nadeau, T., Srinivasan, C., and A. 608 Viswanathan, "Multiprotocol Label Switching 609 (MPLS) Forwarding Equivalence Class To Next 610 Hop Label Forwarding Entry (FEC-To-NHLFE) 611 Management Information Base (MIB)", RFC3814, 612 June 2004. 614 [Y1710] ITU-T Recommendation Y.1710, "Requirements for 615 OAM Functionality In MPLS Networks" 617 [I610] ITU-T Recommendation I.610, "B-ISDN operations and 618 maintenance principles and functions", February 1999 620 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 621 an IANA Considerations section in RFCs", BCP 26, RFC 622 2434, October 1998. 624 draft-ietf-mpls-oam-requirements-07 December 7, 2005 626 [RFC792] Postel, J., "Internet Control Message Protocol", RFC792, 627 September 1981. 629 [RFC3443] Agarwal, P, Akyol, B., "Time To Live (TTL) Processing in 630 Multi-Protocol Label Switching (MPLS) Networks.", RFC3443, 631 January 2003. 633 8. Authors' Addresses 635 Thomas D. Nadeau 636 Cisco Systems, Inc. 637 300 Beaver Brook Road 638 Boxboro, MA 01719 639 Phone: +1-978-936-1470 640 Email: tnadeau@cisco.com 642 Monique Jeanne Morrow 643 Cisco Systems, Inc. 644 Glatt-Com, 2nd Floor 645 CH-8301 646 Switzerland 647 Voice: (0)1 878-9412 648 Email: mmorrow@cisco.com 650 George Swallow 651 Cisco Systems, Inc. 652 300 Beaver Brook Road 653 Boxboro, MA 01719 654 Voice: +1-978-936-1398 655 Email: swallow@cisco.com 657 David Allan 658 Nortel Networks 659 3500 Carling Ave. 660 Ottawa, Ontario, CANADA 661 Voice: 1-613-763-6362 662 Email: dallan@nortelnetworks.com 664 Satoru Matsushima 665 Japan Telecom 666 1-9-1, <, Minato-ku 667 Tokyo, 105-7316 Japan 668 Phone: +81-3-6889-1092 669 Email: satoru@ft.solteria.net 670 draft-ietf-mpls-oam-requirements-07 December 7, 2005 672 9. Intellectual Property Statement 674 The IETF takes no position regarding the validity or scope of any 675 Intellectual Property Rights or other rights that might be claimed to 676 pertain to the implementation or use of the technology described in 677 this document or the extent to which any license under such rights 678 might or might not be available; nor does it represent that it has 679 made any independent effort to identify any such rights. Information 680 on the procedures with respect to rights in RFC documents can be 681 found in BCP 78 and BCP 79. 683 Copies of IPR disclosures made to the IETF Secretariat and any 684 assurances of licenses to be made available, or the result of an 685 attempt made to obtain a general license or permission for the use of 686 such proprietary rights by implementers or users of this 687 specification can be obtained from the IETF on-line IPR repository at 688 http://www.ietf.org/ipr. 690 The IETF invites any interested party to bring to its attention any 691 copyrights, patents or patent applications, or other proprietary 692 rights that may cover technology that may be required to implement 693 this standard. Please address the information to the IETF at ietf- 694 ipr@ietf.org. 696 10. Full Copyright Statement 698 Copyright (C) The Internet Society (2005). 700 This document is subject to the rights, licenses and restrictions 701 contained in BCP 78, and except as set forth therein, the authors 702 retain all their rights. 704 This document and the information contained herein are provided on an 705 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 706 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 707 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 708 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 709 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 710 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 712 11. Acknowledgment 713 draft-ietf-mpls-oam-requirements-07 December 7, 2005 715 Funding for the RFC Editor function is currently provided by the 716 Internet Society. 718 The authors wish to acknowledge and thank the following 719 individuals for their valuable comments to this document: 720 Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr. 721 Ikejiri, NTT Communications and Mr.Kumaki of KDDI. 722 Hari Rakotoranto, Miya Kohno, Cisco Systems; Luyuan Fang, AT&T; 723 Danny McPherson, TCB; Dr.Ken Nagami, Ikuo Nakagawa, Intec Netcore, 724 and David Meyer.