diff options
Diffstat (limited to 'doc/rfc/rfc4377.txt')
| -rw-r--r-- | doc/rfc/rfc4377.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc4377.txt b/doc/rfc/rfc4377.txt new file mode 100644 index 0000000..b1e9156 --- /dev/null +++ b/doc/rfc/rfc4377.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group T. Nadeau +Request for Comments: 4377 M. Morrow +Category: Informational G. Swallow + Cisco Systems, Inc. + D. Allan + Nortel Networks + S. Matsushima + Japan Telecom + February 2006 + + + Operations and Management (OAM) Requirements + for Multi-Protocol Label Switched (MPLS) Networks + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document specifies Operations and Management (OAM) requirements + for Multi-Protocol Label Switching (MPLS), as well as for + applications of MPLS, such as pseudo-wire voice and virtual private + network services. These requirements have been gathered from network + operators who have extensive experience deploying MPLS networks. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Document Conventions ............................................2 + 3. Motivations .....................................................4 + 4. Requirements ....................................................4 + 5. Security Considerations ........................................11 + 6. References .....................................................12 + 7. Acknowledgements ...............................................13 + + + + + + + + + + +Nadeau, et al. Informational [Page 1] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + +1. Introduction + + This document describes requirements for user and data plane + Operations and Management (OAM) for Multi-Protocol Label Switching + (MPLS). These requirements have been gathered from network operators + who have extensive experience deploying MPLS networks. This document + specifies OAM requirements for MPLS, as well as for applications of + MPLS. + + Currently, there are no specific mechanisms proposed to address these + requirements. The goal of this document is to identify a commonly + applicable set of requirements for MPLS OAM at this time. + Specifically, a set of requirements that apply to the most common set + of MPLS networks deployed by service provider organizations at the + time this document was written. These requirements can then be used + as a base for network management tool development and to guide the + evolution of currently specified tools, as well as the specification + of OAM functions that are intrinsic to protocols used in MPLS + networks. + +2. Document Conventions + +2.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + Queuing/buffering Latency: The delay caused by packet queuing (value + is variable since it is dependent on the + packet arrival rate, the packet length, + and the link throughput). + + Probe-based-detection: Active measurement tool that can measure + the consistency of an LSP [RFC4379]. + + Defect: Any error condition that prevents a Label + Switched Path (LSP) from functioning + correctly. For example, loss of an + Interior Gateway Protocol (IGP) path will + most likely result in an LSP not being + able to deliver traffic to its + destination. Another example is the + interruption of the path for a TE tunnel. + These may be due to physical circuit + failures or failure of switching nodes to + operate as expected. + + + + +Nadeau, et al. Informational [Page 2] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + + Multi-vendor/multi-provider network + operation typically requires agreed upon + definitions of defects (when it is broken + and when it is not) such that both + recovery procedures and service level + specification impact can be specified. + + Head-end Label Switching + Router (LSR): The beginning of an LSP. A head-end LSR + is also referred to as an ingress LSR. + + Tail-end Label Switching + Router (LSR): The end of an LSP. A tail-end LSR is also + referred to as an egress LSR. + + Propagation Latency: The delay added by the propagation of the + packet through the link (fixed value that + depends on the distance of the link and + the propagation speed). + + Transmission Latency: The delay added by the transmission of the + packet over the link, i.e., the time it + takes to put the packet over the media + (value that depends on the link throughput + and packet length). + + Processing Latency: The delay added by all the operations + related to the switching of labeled + packets (value is node implementation + specific and may be considered fixed and + constant for a given type of equipment). + + Node Latency: The delay added by the network element + resulting from of the sum of the + transmission, processing, and + queuing/buffering latency. + + One-hop Delay: The fixed delay experienced by a packet to + reach the next hop resulting from the of + the propagation latency, the transmission + latency, and the processing latency. + + Minimum Path Latency: The sum of the one-hop delays experienced + by the packet when traveling from the + ingress to the egress LSR. + + + + + + +Nadeau, et al. Informational [Page 3] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + + Variable Path Latency: The variation in the sum of the delays + experienced by packets transiting the + path, otherwise know as jitter. + +2.2. Acronyms + + ASBR: Autonomous System Border Router + + CE: Customer Edge + + PE: Provider Edge + + SP: Service Provider + + ECMP: Equal-Cost Multi-path + + LSP: Label Switched Path + + LSP Ping: Label Switched Path Ping + + LSR: Label Switching Router + + OAM: Operations and Management + + RSVP: Resource reSerVation Protocol + + LDP: Label Distribution Protocol + + DoS: Denial of Service + +3. Motivations + + This document was created to provide requirements that could be used + to create consistent and useful OAM functionality that meets + operational requirements of those service providers (SPs) who have + deployed or are deploying MPLS. + +4. Requirements + + The following sections enumerate the OAM requirements gathered from + service providers who have deployed MPLS and services based on MPLS + networks. Each requirement is specified in detail to clarify its + applicability. Although the requirements specified herein are + defined by the IETF, they have been made consistent with requirements + gathered by other standards bodies such as the ITU [Y1710]. + + + + + + +Nadeau, et al. Informational [Page 4] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + +4.1. Detection of Label Switched Path Defects + + The ability to detect defects in a broken 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 transited by 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 to allow for such automatic + operation. + + Furthermore, the automation of path liveliness is desired in cases + where large numbers of LSPs might be tested. For example, automated + ingress LSR to egress LSR testing functionality is desired for some + LSPs. The goal is to detect LSP path defects before customers do, + which requires detection and correction of LSP defects in a manner + that is both predictable and within the constraints of the service + level agreement under which the service is being offered. Simply + put, the sum of the time it takes an OAM tool to detect a defect and + the time needed for an operational support system to react to this + defect, by possibly correcting it or notifying the customer, must + fall within the bounds of the service level agreement in question. + + Synchronization of detection time bounds by tools used to detect + broken LSPs is required. Failure to specify defect detection time + bounds may result in an ambiguity in test results. If the time to + detect broken LSPs is known, then automated responses can be + specified with respect and regard to resiliency and service level + specification reporting. Further, if synchronization of detection + time bounds is possible, an operational framework can be established + to guide the design and specification of MPLS applications. + + Although an ICMP-based ping [RFC792] can be sent through an LSP as an + IP payload, the use of this tool to verify the defect-free operation + of an LSP has the potential of returning erroneous results (both + positive and negative) for a number of reasons. For example, in some + cases, because the ICMP traffic is based on legally addressable IP + addressing, it is possible for ICMP messages that are originally + transmitted inside of an LSP to "fall out of the LSP" at some point + along the path. In these cases, since ICMP packets are routable, a + falsely positive response may be returned. In other cases, where the + data plane of a specific LSP needs to be tested, it is difficult to + guarantee that traffic based on an ICMP ping header is parsed and + hashed to the same equal-cost multi-paths (ECMP) as the data traffic. + + Any detection mechanisms that depend on receiving the status via a + return path SHOULD provide multiple return options with the + expectation that one of them will not be impacted by the original + + + +Nadeau, et al. Informational [Page 5] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + + defect. An example of a case where a false negative might occur + would be a mechanism that requires a functional MPLS return path. + Since MPLS LSPs are unidirectional, it is possible that although the + forward LSP, which is the LSP under test, might be functioning, the + response from the destination LSR might be lost, thus giving the + source LSR the false impression that the forward LSP is defective. + However, if an alternate return path could be specified -- say IP for + example -- then the source could specify this as the return path to + the destination, and in this case, would receive a response + indicating that the return LSP is defective. + + The OAM packet MUST follow the customer data path exactly in order to + reflect path liveliness used by customer data. Particular cases of + interest are forwarding mechanisms, such as ECMP scenarios within the + operator's network, whereby flows are load-shared across parallel + paths (i.e., equal IGP cost). Where the customer traffic may be + spread over multiple paths, the ability to detect failures on any of + the path permutations is required. Where the spreading mechanism is + payload specific, payloads need to have forwarding that is common + with the traffic under test. Satisfying these requirements + introduces complexity into ensuring that ECMP connectivity + permutations are exercised and that defect detection occurs in a + reasonable amount of time. + +4.2. Diagnosis of a Broken Label Switched Path + + The ability to diagnose a broken LSP and to isolate the failed + component (i.e., link or node) in the path is required. For example, + note that specifying recovery actions for mis-branching defects in an + LDP network is a particularly difficult case. Diagnosis of defects + and isolation of the failed component is best accomplished via a path + trace function that can return the entire list of LSRs and links used + by a certain LSP (or at least the set of LSRs/links up to the + location of the defect). The tracing capability SHOULD include the + ability to trace recursive paths, such as when nested LSPs are used. + This path trace function MUST also be capable of diagnosing LSP mis- + merging by permitting comparison of expected vs. actual forwarding + behavior at any LSR in the path. The path trace capability SHOULD be + capable of being executed from the head-end Label Switching Router + (LSR) and may permit downstream path components to be traced from an + intermediate mid-point LSR. Additionally, the path trace function + MUST have the ability to support ECMP scenarios described in Section + 4.1. + + + + + + + + +Nadeau, et al. Informational [Page 6] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + +4.3. Path Characterization + + The path characterization function is the ability to reveal details + of LSR forwarding operations. These details can then be compared + during subsequent testing relevant to OAM functionality. This + includes but is not limited to: + + - consistent use of pipe or uniform time to live (TTL) models by + an LSR [RFC3443]. + + - sufficient details that allow the test origin to exercise all + path permutations related to load spreading (e.g., ECMP). + + - stack operations performed by the LSR, such as pushes, pops, + and TTL propagation at penultimate hop LSRs. + +4.4. Service Level Agreement Measurement + + Mechanisms are required to measure the diverse aspects of Service + Level Agreements, which include: + + - latency - amount of time required for traffic to transit the + network + + - packet loss + + - jitter - measurement of latency variation + + - defect free forwarding - the service is considered to be + available, or the service is unavailable and other aspects of + performance measurement do not have meaning. + + Such measurements can be made independently of the user traffic or + via a hybrid of user traffic measurement and OAM probing. + + At least one mechanism is required to measure the number of OAM + packets. In addition, the ability to measure the quantitative + aspects of LSPs, such as jitter, delay, latency, and loss, MUST be + available in order to determine whether the traffic for a specific + LSP is traveling within the operator-specified tolerances. + + Any method considered SHOULD be capable of measuring the latency of + an LSP with minimal impact on network resources. See Section 2.1 for + definitions of the various quantitative aspects of LSPs. + + + + + + + +Nadeau, et al. Informational [Page 7] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + +4.5. Frequency of OAM Execution + + The operator MUST have the flexibility to configure OAM parameters to + meet their specific operational requirements. + + This includes the frequency of the execution of any OAM functions. + The ability to synchronize OAM operations is required to permit a + consistent measurement of service level agreements. To elaborate, + there are defect conditions, such as mis-branching or misdirection of + traffic, for which probe-based detection mechanisms that incur + significant mismatches in their detection frequency may result in + flapping. This can be addressed either by synchronizing the rate or + having the probes self-identify their probe rate. For example, when + the probing mechanisms are bootstrapping, they might negotiate and + ultimately agree on a probing rate, therefore providing a consistent + probing frequency and avoiding the aforementioned problems. + + One observation would be that wide-spread deployment of MPLS, common + implementation of monitoring tools, and the need for inter-carrier + synchronization of defect and service level specification handling + will drive specification of OAM parameters to commonly agreed on + values. Such values will have to be harmonized with the surrounding + technologies (e.g., SONET/SDH, ATM) to be useful. This will become + particularly important as networks scale and mis-configuration can + result in churn, alarm flapping, etc. + +4.6. Alarm Suppression, Aggregation, and Layer Coordination + + Network elements MUST provide alarm suppression functionality that + prevents the generation of a superfluous generation of alarms by + simply discarding them (or not generating them in the first place), + or by aggregating them together, thereby greatly reducing the number + of notifications emitted. When viewed in conjunction with the + requirement in Section 4.7 below, this typically requires fault + notification to the LSP egress that may have specific time + constraints if the application using the LSP independently implements + path continuity testing (for example, ATM I.610 Continuity check + (CC)[I610]). These constraints apply to LSPs that are monitored. + The nature of MPLS applications allows for the possibility of having + multiple MPLS applications attempt to respond to defects + simultaneously, e.g., layer-3 MPLS VPNs that utilize Traffic + Engineered tunnels where a failure occurs on the LSP carrying the + Traffic Engineered tunnel. This failure would affect the VPN traffic + that uses the tunnel's LSP. Mechanisms are required to coordinate + network responses to defects. + + + + + + +Nadeau, et al. Informational [Page 8] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + +4.7. Support for OAM Inter-working for Fault Notification + + An LSR supporting the inter-working of one or more networking + technologies over MPLS MUST be able to translate an MPLS defect into + the native technology's error condition. For example, errors + occurring over an MPLS transport LSP that supports an emulated ATM VC + MUST translate errors into native ATM OAM Alarm Indication Signal + (AIS) cells at the termination points of the LSP. The mechanism + SHOULD consider possible bounded detection time parameters, e.g., a + "hold off" function before reacting to synchronize with the OAM + functions. + + One goal would be alarm suppression by the upper layer using the LSP. + As observed in Section 4.5, this requires that MPLS perform detection + in a bounded timeframe in order to initiate alarm suppression prior + to the upper layer independently detecting the defect. + +4.8. Error Detection and Recovery + + Recovery from a fault by a network element can be facilitated by MPLS + OAM procedures. These procedures will detect a broader range of + defects than that of simple link and node failures. Since MPLS LSPs + may span multiple routing areas and service provider domains, fault + recovery and error detection should be possible in these + configurations as well as in the more simplified single-area/domain + configurations. + + Recovery from faults SHOULD be automatic. It is a requirement that + faults SHOULD be detected (and possibly corrected) by the network + operator prior to customers of the service in question detecting + them. + +4.9. Standard Management Interfaces + + The wide-spread deployment of MPLS requires common information + modeling of management and control of OAM functionality. Evidence of + this is reflected in the standard IETF MPLS-related MIB modules + (e.g., [RFC3813][RFC3812][RFC3814]) for fault, statistics, and + configuration management. These standard interfaces provide + operators with common programmatic interface access to Operations and + Management functions and their statuses. However, gaps in coverage + of MIB modules to OAM and other features exist; therefore, MIB + modules corresponding to new protocol functions or network tools are + required. + + + + + + + +Nadeau, et al. Informational [Page 9] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + +4.10. Detection of Denial of Service Attacks + + The ability to detect denial of service (DoS) attacks against the + data or control planes MUST be part of any security management + related to MPLS OAM tools or techniques. + +4.11. Per-LSP Accounting Requirements + + In an MPLS network, service providers can measure traffic from an LSR + to the egress of the network using some MPLS related MIBs, for + example. This means that it is reasonable to know how much traffic + is traveling from location to location (i.e., a traffic matrix) by + analyzing the flow of traffic. Therefore, traffic accounting in an + MPLS network can be summarized as the following three items: + + (1) Collecting information to design network + + For the purpose of optimized network design, a service + provider may offer the traffic information. Optimizing + network design needs this information. + + (2) Providing a Service Level Specification + + Providers and their customers MAY need to verify high-level + service level specifications, either to continuously optimize + their networks, or to offer guaranteed bandwidth services. + Therefore, traffic accounting to monitor MPLS applications is + required. + + (3) Inter-AS environment + + Service providers that offer inter-AS services require + accounting of those services. + + These three motivations need to satisfy the following: + + - In (1) and (2), collection of information on a per-LSP + basis is a minimum level of granularity for collecting + accounting information at both of ingress and egress of an + LSP. + + - In (3), SP's ASBR carry out interconnection functions as an + intermediate LSR. Therefore, identifying a pair of ingress + and egress LSRs using each LSP is needed to determine the + cost of the service that a customer is using. + + + + + + +Nadeau, et al. Informational [Page 10] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + +4.11.1. Requirements + + Accounting on a per-LSP basis encompasses the following set of + functions: + + (1) At an ingress LSR, accounting of traffic through LSPs that + begin at each egress in question. + + (2) At an intermediate LSR, accounting of traffic through LSPs for + each pair of ingress to egress. + + (3) At egress LSR, accounting of traffic through LSPs for each + ingress. + + (4) All LSRs containing LSPs that are being measured need to have + a common identifier to distinguish each LSP. The identifier + MUST be unique to each LSP, and its mapping to LSP SHOULD be + provided whether from manual or automatic configuration. + + In the case of non-merged LSPs, this can be achieved by simply + reading traffic counters for the label stack associated with the + LSP at any LSR along its path. However, in order to measure + merged LSPs, an LSR MUST have a means to distinguish the source of + each flow so as to disambiguate the statistics. + +4.11.2. Location of Accounting + + It is not realistic for LSRs to perform the described operations on + all LSPs that exist in a network. At a minimum, per-LSP based + accounting SHOULD be performed on the edges of the network -- at the + edges of both LSPs and the MPLS domain. + +5. Security Considerations + + Provisions to any of the network mechanisms designed to satisfy the + requirements described herein are required to prevent their + unauthorized use. Likewise, these network mechanisms MUST provide a + means by which an operator can prevent denial of service attacks if + those network mechanisms are used in such an attack. + + LSP mis-merging has security implications beyond that of simply being + a network defect. LSP mis-merging can happen due to a number of + potential sources of failure, some of which (due to MPLS label + stacking) are new to MPLS. + + The performance of diagnostic functions and path characterization + involve extracting a significant amount of information about network + construction that the network operator MAY consider private. + + + +Nadeau, et al. Informational [Page 11] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +6.2. Informative References + + [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol + Label Switched (MPLS) Data Plane Failures", RFC 4379, + February 2006. + + [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Traffic Engineering + (TE) Management Information Base (MIB)", RFC 3812, June + 2004. + + [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB)", RFC 3813, + June 2004. + + [RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, + "Multiprotocol Label Switching (MPLS) Forwarding + Equivalence Class To Next Hop Label Forwarding Entry + (FEC-To-NHLFE) Management Information Base (MIB)", RFC + 3814, June 2004. + + [Y1710] ITU-T Recommendation Y.1710, "Requirements for OAM + Functionality In MPLS Networks" + + [I610] ITU-T Recommendation I.610, "B-ISDN operations and + maintenance principles and functions", February 1999 + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC + 792, September 1981. + + + + + + + + + + +Nadeau, et al. Informational [Page 12] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + + [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in + Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, + January 2003. + +7. Acknowledgements + + The authors wish to acknowledge and thank the following individuals + for their valuable comments to this document: Adrian Smith, British + Telecom; Chou Lan Pok, SBC; Mr. Ikejiri, NTT Communications; and Mr. + Kumaki, KDDI. Hari Rakotoranto, Miya Kohno, Cisco Systems; Luyuan + Fang, AT&T; Danny McPherson, TCB; Dr. Ken Nagami, Ikuo Nakagawa, + Intec Netcore, and David Meyer. + +Authors' Addresses + + Comments should be made directly to the MPLS mailing list + at mpls@lists.ietf.org. + + Thomas D. Nadeau + Cisco Systems, Inc. + 300 Beaver Brook Road + Boxboro, MA 01719 + + Phone: +1-978-936-1470 + EMail: tnadeau@cisco.com + + + Monique Jeanne Morrow + Cisco Systems, Inc. + Glatt-Com, 2nd Floor + CH-8301 + Switzerland + + Phone: (0)1 878-9412 + EMail: mmorrow@cisco.com + + + George Swallow + Cisco Systems, Inc. + 300 Beaver Brook Road + Boxboro, MA 01719 + + Phone: +1-978-936-1398 + EMail: swallow@cisco.com + + + + + + + +Nadeau, et al. Informational [Page 13] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + + David Allan + Nortel Networks + 3500 Carling Ave. + Ottawa, Ontario, CANADA + + Phone: 1-613-763-6362 + EMail: dallan@nortel.com + + + Satoru Matsushima + Japan Telecom + 1-9-1, Higashi-Shinbashi, Minato-ku + Tokyo, 105-7316 Japan + + Phone: +81-3-6889-1092 + EMail: satoru@ft.solteria.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nadeau, et al. Informational [Page 14] + +RFC 4377 OAM Requirements for MPLS Networks February 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Nadeau, et al. Informational [Page 15] + |