Internet Draft David Allan Document: draft-allan-mpls-oam-frmwk-00.txt Mina Azad Nortel Networks July 2001 A Framework for MPLS User Plane OAM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright(C) The Internet Society (2001). All Rights Reserved. Allan et.al Expires January 2002 Page 1 A Framework for MPLS User Plane OAM July 2001 Abstract This Internet draft discusses many of the issues associated with user plane OAM for MPLS. Included in this discussion is some of the implications of MPLS architecture on the ability to support fault and performance management OAM applications, potential solutions for distinguishing user plane OAM, and a summary of what the authors believe can be achieved. This framework is predicated on requirements described in [HARRISON- REQ]. Table of Contents 1. Motivations...................................................3 2. Requirements..................................................3 3. Terminology...................................................3 4. Different deployment scenarios................................4 5. MPLS architecture implications for OAM........................5 5.1 Topology variations..........................................5 5.1.1 Implications for fault management:.........................6 5.1.2 Implications for performance management....................6 5.2 Use of TTL...................................................7 5.3 Other design issues..........................................8 6. OAM Applications..............................................8 7. OAM Messaging:................................................9 8. Distinguishing OAM user plane flows..........................10 9. The OAM return path..........................................12 10. Security Considerations.....................................14 11. A summary of what can be achieved...........................14 12. References..................................................15 13. Author's Addresses..........................................15 Allan et. al. Expires January 2002 Page 2 A Framework for MPLS User Plane OAM July 2001 Conventions used in this document 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 [1]. 1. Motivations MPLS OAM and survivability have been tackled in numerous internet drafts. However all existing drafts focus on single provider solutions, or focused on a single aspect of the MPLS architecture such as RSVP,or LDP, or had inconsistent applicability across the MPLS architecture, and/or frequently would required significant modifications to operational procedure in order to provide OAM connectivity. As MPLS matures and relationships between providers become more complex, there is a need to consider multi-operator management functionalities for deployments that span arbitrary networking arrangements and have broader applicability to the MPLS architecture. 2. Requirements MPLS user-plane OAM requirements have been described in [HARRISON-REQ]. This Internet draft refines the requirements on "on demand" connectivity check, extending OAM across the MPLS architecture, and adds additional user-plane OAM requirements and capabilities for managing multi-provider networks and extending OAM across the MPLS architecture. This document also broadens the scope of the requirements discussion in identifying where certain OAM applications simply cannot be implemented without modifications to current practice/architecture. 3. Terminology MPLS introduces a richness in layering which renders traditional definitions inadequate. A provider may have MPLS peer providers, use MPLS transit from serving providers, and offer MPLS transit (overlay or MPLS VPN) to clients. Further, the same provider may use a hierarchy of LSPs and LSP-tunnels within their own network. Hence this Internet Draft defines the concepts of Operations Domain (to cover OAM capabilities operated by a single provider) that may only be a portion of the scope of an LSP. Operations Domain functions are a mix of control-plane, user-plane, and management-plane functions. An LSP "of level m" may span numerous Operational Domains (contiguous user plane) while the control and management planes may be disjoint. The goal is to provide OAM functionality for each LSP "of level m" regardless of "m". Allan et. al. Expires January 2002 Page 3 A Framework for MPLS User Plane OAM July 2001 It is possible to have a hierarchy of operators (e.g. carriers of carriers), where overlay Operational Domains are opaque to the serving Domain. Therefore it is required that each LSP "of level m" implement its own OAM functionality, and the OAM applications are confined to the Operational Domains traversed at level "m". 4. Different deployment scenarios At the present time there are a number of deployment scenarios proposed for MPLS each with a number of subtleties from a user plane OAM perspective. Each can be viewed as a characteristic of an operational domain: The sparse model: This can be in conjunction with a control plane (e.g. MPLS based traffic engineering applied to an IP network) or with simple provisioned LSPs (no control plane). The key feature being that the MPLS operational domain will most likely not implement have any-to-any connectivity within the operational domain. This has operational and scalability implications as OAM connectivity must be explicitly added to the model, or the operator may be obliged to depend on "layer violations" embedded in OAM applications (e.g. [ICMP]) to generate a return path. The ubiquitous model: This model generally combines MPLS, integrated routing and control to produce ubiquitous any-to-any connectivity within an operational domain. This may be combined with a hierarchy of LSPs and LSP tunnels to modify the topology of the underlying serving level/layer. This offers providers the option of utilizing the resources inherent to all planes of the Operational Domain in designing OAM connectivity/functionality. These two models of MPLS connectivity can be stacked or concatenated to support numerous manners of peering and overlay networking arrangements between providers and users. A direct inference being that an operational domain should be able to exist without knowledge of the domains above and below it, and potentially incomplete knowledge of its peers. OAM applications for LSPs of a specific level are confined to an operational domain and its user plane peers. More recently there is a tendency to overlay an L2 or L3 VPN service level on the user plane of an operational domain, with itĘs own identifiers and addressing, while tunneling control information across the control plane of the operational domain using BGP-4 [2547][KOMPELLA] or extended LDP adjacencies [MARTINI]. From a user Allan et. al. Expires January 2002 Page 4 A Framework for MPLS User Plane OAM July 2001 plane OAM perspective, we would consider this to be a separate operational domain, and anticipate that it is only a matter of time before such service levels evolve to span multiple operational domains (for example, an L2 or L3 VPN that spans multiple providers, or the introduction of tandem points at the user plane of the service level). Commercial operating domains can have both vertical (ie stacked layers) and horizontal disjointedness. Any solutions to defect handling must be designed to recognise this reality in order to be scalable and future-proofed. 5. MPLS architecture implications for OAM 5.1 Topology variations There are a number of topology variations in the MPLS architecture that have OAM implications. These are: - Uni-directional and bi-directional LSPs. A uni-directional LSP only provides connectivity in one direction, and if return path connectivity exists, it is an attribute of the operational domain, and not a unique attribute of the LSP. Bi-directional LSPs or specific return path (e.g. [CHANG]) have inherent symmetrical connectivity as an attribute of the LSP. - Multipoint-to-point (MP2P) LSPs where a single LSP uses merge LSR transfer functions to provide connectivity between multiple ingress LSRs and a single egress LSR. There are a number of problems inherent to mp2p topological constructs that cannot be addressed by traditional p2p mechanisms. One issue being that for some OAM applications (e.g. user plane fault propagation) OAM flows may require visibility at merge-points to limit the impact of partial failures or congestion. - Penultimate label popping (PHP), an optimization in the architecture in which the last LSR prior to the egress removes the (supposedly) redundant current MPLS label from the label stack. Therefore the ability to infer LSP specific OAM context is lost prior to reaching the final destination. - E-LSPs [MPLSDIFF] in which a single LSP supports multiple queuing disciplines to support multiple behavior aggregates. This introduces an element of uncertainity, as the LSP may experience failure under some queuing disciplines. Ability to use OAM probing on a "per behavior aggregate" basis is critical to managing E-LSPs. Allan et. al. Expires January 2002 Page 5 A Framework for MPLS User Plane OAM July 2001 - Provisioned LSPs, vs. LSPs associated with a control plane. In many scenarios associated with a control plane, the topology of the LSP varies over time. This can be due to many reasons, implicit routing, dynamic set up of local repair tunnels etc. etc. - The potential existence of multiple LSPs between an ingress and an egress LSR. This can be for many reasons, L-LSPs, equal cost multipath routing etc. etc. These topological variations introduce complexity when attempting to instrument OAM applications such as performance management and fault detection, isolation, and propagation. 5.1.1 Implications for fault management: Mp2p, E-LSPs and PHP have implications for fault management, specifically if an LSR is required to have knowledge of both the ingress LSR and the specific LSP that an OAM message arrived on, or is expected to have knowledge of, and maintain state about the set of ingress LSRs for an LSP. OAM messaging needs to carry sufficient information to distinguish both the ingress LSR and the specific LSP. (This ability is expressed on these terms as LSPs are typically not given globally unique identifiers, more frequently some LSR-ID and LSR administered LSP-ID). Frequently it will not be able to infer the ingress LSR and specific LSP as such information is lost at merge points or due to a PHP. This is true for both OAM messaging, and normal user plane payload. There may be numerous reasons why an ingress-egress pair may have a plurality of LSPs between them, so the ability to distinguish the source and purpose of specific probes beyond mere knowledge of the originating LSR is a hard requirement. 5.1.2 Implications for performance management Many performance management functions can be performed by obtaining and comparing measurements taken at different points in the network. Comparing ingress and egress statistics being the simplest and most scalable example (noting that both measurement points must be trusted, typically confining them to a single operational domain). The key issue is ensuring that "apples-to-apples" comparison of measurements is possible, and that the measurements/comparisons apply to "available" or "in-service" resources. This means that all measurement points need to be able to similarly classify what they are measuring, and that the measurements are synchronized in time and compensate for traffic in flight between the measurement points. Allan et. al. Expires January 2002 Page 6 A Framework for MPLS User Plane OAM July 2001 For example, a relatively simple technique for establishing key performance metrics would be to compare what was sent with what was received. For example the PPP line quality monitoring (LQM) function the ingress periodically sends statistics to the egress for comparison subject to the same queuing discipline as the user plane traffic, such that traffic in flight is properly accounted for. (Note that re- ordering will introduce errors but is not expected to be frequent, examples of re-ordering situations would be routing changes, or E-LSPs encountering congestion). For MPLS, such a simple comparison is not always possible, there is not necessarily the ability to similarly classify what is being measured at the ingress and egress of an LSP. Mp2p LSPs and PHP do not have a 1:1 relationship between the ingress and the egress. For successful PM the 1:1 relationship needs to be restored, either: - The mp2p/PHP LSP is modeled as a collection of "ingress" LSPs for measurement. This means that the egress needs to be able maintain statistics by ingress and appropriately classify traffic measurements. In which case the measurement result of common LSP segments could be misleading. - The mp2p/PHP LSP is modeled as one LSP for measurement. This means that measurements performed at ingress points need to be synchronized and adjusted for common LSP segments such that the results are all presented to the egress simultaneously (again correcting for traffic in flight), a technique dependent on such a high degree of synchronization would be impossible to perfect, hence prone to a degree of error. Neither of the above is achievable at the present time without modifying existing operational procedures, such as overlaying p2p connectivity on top of a merge/PHP based transport level. The existence of E-LSPs adds a wrinkle to the problem of measurement synchronization. An E-LSP may implement multiple diffserv PHBs and incorporate multiple queuing disciplines. An aggregate measurement for the entire LSP sent from ingress to egress would frequently have a small margin of error when compared with an aggregate measurement taken at the egress. Separate measurement comparisons for each supported EXP code point would be required to eliminate the error. 5.2 Use of TTL Experience with the IP world has suggested that TTL was a serendipitous Allan et. al. Expires January 2002 Page 7 A Framework for MPLS User Plane OAM July 2001 feature that can most likely be similarly leveraged by MPLS. However in the MPLS world, TTL suffers from inconsistent implementation depending on the link layer technology spanned by the target LSP. The existence of non-TTL capable links (e.g. MPLS/ATM) has impacts on the utility of using TTL to augment the MPLS OAM toolkit. For example, use of TTL as an aid in fault sectionalization can only isolate a fault to the granularity of a non-TTL capable span of LSH or LSP segments. 5.3 Other design issues It is desirable to make the user plane OAM applications not need to be aware of LSP specifics. We do not want to have to define separate transactions for p2p and mp2p LSPs, and require payload independence. The OAM application originator should not need (as far as is practical) any knowledge of the details of LSP construction. This is less true for performance management. PM may impose certain operational procedures such as the implementation of many OAM applications only being possible for p2p LSPs and will most likely be segregated into only being possible for a select group of levels (e.g. overlaid service labels as per [KOMPELLA] or [MARTINI]). Fault management must be applicable across the spectrum of all label levels and LSR transfer functions. Wherever possible, OAM application state for fault management should be pushed towards the LSP ingress. The reasoning for this is simple, in the current architecture an LSP ingress will always have one LSP egress and will have some useful rudimentary knowledge of why the LSP exists that can be verified. The reverse is not true. An LSP egress may have more than one ingress, typically will not know the full set of ingresses, nor why they exist. Finally, the possibility of re-ordering of OAM messaging must be considered. The design of OAM applications and messaging must be tolerant of out of order delivery. The application originator will require a means to uniquely correlate requests with probe responses (including responses to mis-directed probes). 6. OAM Applications The purpose of having user plane LSP specific transactions is to support useful OAM applications. Examples of such applications include: Fault management - On demand verification: the ability to perform connectivity tests Allan et. al. Expires January 2002 Page 8 A Framework for MPLS User Plane OAM July 2001 that exercise the specific LSP and the provisioning at the ingress and egress. On demand suggests that verification may be performed on an ad-hoc basis. - Fault detection: the ability to perform automated detection of the failure of a specific LSP. Some MPLS deployment scenarios may not have a control plane or may have LSP components not in common with the control plane, so fault detection procedures may need to be augmented with LSP specific methods. - Fault sectionalization: The ability to efficiently determine where a failure has occurred in an LSP. Sectionalization must be able to be performed from an arbitrary LSR along the path of the LSP. - Fault Propagation: specific MPLS deployment scenarios may not have a control plane to propagate LSP failure information. Performance management - the ability to determine whether an LSP meets certain goals with respect to latency, packet loss etc. Of the above applications, verification, detection and sectionalization explicitly need to exercise all components of the forwarding path of the target LSP, otherwise there will be failure scenarios that cannot be detected or properly sectionalized. These applications cannot be supported properly if there are differences in handling between user traffic and OAM probes at intermediate LSRs. 7. OAM Messaging: OAM should be decoupled from user behavior to avoid the use of customers as guinea pigs. We consider it to be self evident that providers will require a toolkit that includes some form of user plane OAM messaging. At the specific LSP level, support of OAM applications require messages that flow between three entities, the LSP ingress, the intervening network and the LSP egress. As an LSP is unidirectional, it should be self evident that OAM applications that require feedback in the reverse direction will have such communication occur either at the specific LSP level, or some user plane LSP level in the operational domain, or one of the other planes (control or management) of the operational domain. The set of possible individual transactions (plus examples of their utility) is as follows: Allan et. al. Expires January 2002 Page 9 A Framework for MPLS User Plane OAM July 2001 LSP specific user plane transactions: - ingress to egress applicability: connectivity verification, fault detection, performance management - ingress to network message will terminate at an intermediate LSR traversed by the LSP. Applicability: sectionalization from source - network to egress message is inserted into the LSP at an intermediate node and terminates at the LSP egress LSR. Applicability: sectionalization from arbitrary point in an LSP. - Network to network Applicability: sectionalization from arbitrary point in an LSP. Feedback transactions - egress to ingress applicability: connectivity verfication, fault detection - egress to network flow originates at the LSP egress and terminates at an intermediate node traversed by the LSP. Applicability: sectionalization from arbitrary point in an LSP. - network to ingress flow will originate at an intermediate LSR traversed by the LSP and terminate at the LSP source. Applicability: sectionalization from ingress. - network to network Applicability: sectionalization from arbitrary point in an LSP. 8. Distinguishing OAM user plane flows MPLS does not currently provide for protocol multiplexing at a specific LSP level. However a requirement still exists to distinguish per-LSP OAM messaging from user payload. The options for addressing the identification of OAM flows are: - Adding an LSP level to the existing LSP using an arbitrary label value that by convention (negotiated at LSP establishment) carries OAM payload. Allan et. al. Expires January 2002 Page 10 A Framework for MPLS User Plane OAM July 2001 - Adding an LSP level to the existing LSP via the use of a stacked reserved label value that explicitly identifies OAM flows. Note that this approach was proposed in [HARRISON-MECH]. - Stealing a bit from the LSP label space. - or making other modifications to the existing MPLS header to permit payload to be distinguished as OAM and not client traffic (e.g. robbing bits from the EXP or TTL fields). Adding an arbitrarily labeled LSP level to multiplex OAM flows will add complexity and additional failure modes that make it an undesirable solution. An arbitrary label identifier may not be distinguishable from normal user-plane traffic in the case of swapped/mismerged LSPs. Adding an LSP level using a reserved label has a number of virtues: - LSP level OAM flows will explicitly exercise the components of the forwarding path. - LSP level OAM flows will not be erroneously forwarded outside the LSP they have been inserted into. The LSP itself may be defective or misrouted (but that is a separate issue) but we have not introduced an additional LSP level for OAM with its own set of possible defects. - LSP level e2e OAM flows are transparent to non-compliant/legacy equipment as no header changes are required. - OAM messaging will still self-identify after a PHP However hop-by-hop OAM flows are not possible (although the approach could be augmented via the use of MPLS TTL or the router alert label to gain SOME of the benefits of hop-by-hop messaging). By losing hop-by- hop, the ability to provide flows with preferential treatment when required is also lost. Modifying the MPLS header or stealing a bit from the label space to permit OAM payload to be uniquely distinguished by all LSRs traversed at the specific LSP level similarly has a number of advantages and disadvantages. We gain hop-by-hop visibility of messaging but at the expense of: - Losing backwards compatibility with legacy equipment. - Losing the ability to ensure we are fully exercising the forwarding path for verification and sectionalization. Similarly PHP, stealing a label bit and E-LSPs becomes problematic as the OAM identifier is lost when the label is popped (in the original MPLS architecture, the label was considered to have no informational value past the next to egress LSR). Adding special handling for OAM packets to specifically avoid PHP would no longer exercise all components of the forwarding path. Allan et. al. Expires January 2002 Page 11 A Framework for MPLS User Plane OAM July 2001 We conclude that the use of a reserved label under the top label would appear to be the approach that had the most utility. 9. The OAM return path The ability to use OAM applications on an "on demand" or "ad-hoc" basis requires the existence of a return path from the intermediate and LSP-egress LSRs to the LSP ingress. This enhances the scalability and reliability of some OAM applications as initiation need only occur at a single LSR, all further coordination of LSRs exercised by the application being performed by user plane messaging inherent to the OAM application. A specific example being use of a loopback where only place state and timing need be maintained is at the loopback originator. This requires a return path to complete the loop between the "target LSP" and the OAM application originator. This will permit reliable transaction flows to be implemented that impose minimal state on the network. For most OAM applications, the return path can be tolerant of being topologically disjoint with the target LSP, reachability of the application originator being the only hard requirement. Similarly, different OAM applications will have different return path requirements, and a hybrid of using all the planes of the operational domain (according to the application) may be significantly simpler and more operationally tractable than significant modifications to current usage to fill in connectivity gaps at the specific label level. This is a key point, LSPs are currently by definition uni-directional (bi-directional to date being a construct of multiple uni-directional LSPs), so for any non-ubiquitous deployment of MPLS connectivity, some modification of operational procedure to provide for OAM messaging will be required. Strict symmetry of connectivity at a specific label level is not guaranteed. In any type of sparse usage scenario (e.g. provisioned LSPs or use exclusively for TE) there will not be an inherent any-to-any connectivity in the user plane, and there may not be a control plane. Additional artificial constructs such as a "reverse notification tree" [CHANG] have been proposed to address this although these introduce additional operational complexity and a requirement for OAM for the OAM connectivity. In an implicit MPLS topology (e.g. LDP DU), any to any connectivity will typically exist, or will be easily available with minor Allan et. al. Expires January 2002 Page 12 A Framework for MPLS User Plane OAM July 2001 alterations to operational procedure (LSRs advertise selves as FECs). This would continue to be true for an integrated model in which TE and an implicit topology were combined. In any type of multi-provider MPLS topology, the scenario is more complex, as for numerous reasons a provider may not wish to provision/advertise external connectivity to their LSRs. Similarly, for security reasons, providers may wish to apply some degree of policy or filtering of OAM traffic at operational domain boundaries. User plane OAM messaging should be designed to leverage as much "free connectivity" as can be obtained in the network, while ensuring the constructs have sufficient extensibility to ensure the corner cases are covered. With the operational domain of a single provider, it is relatively easy to envision that a combination of user plane, and control plane functionality will ensure that a user plane return path is frequently available (although it may be topologically disjoint from the target LSP). This is less so for inter provider scenarios. Here there are a number of potential obstacles such as: - disjoint or different control plane - disjoint addressing plan - requirements for policy enforcement and security - impacts to scalability of ubiquitous visibility of individual LSRs across multiple operational domains. There are a number of approaches to providing inter-domain OAM connectivity, the following is a brief commentary on each: 1) Reverse Notification Tree (a.k.a using bi-directional LSP) In this method, each LSP has a dedicated reverse path - i.e. the reverse path is established and associated with the LSP at the LSP setup time. This requires binding the reverse path to each LSR that is traversed by the LSP. This method is not scaleable, as it requires doubling the number of LSPs in the network. Moreover each reverse path requires its own OAM. 2) Global OAM capability Similar to IP V4 to IP v6 migration methodology, this method proposes use of a global operations domain with control-plane, user-plane, and management-plane that interact with control-plane, user-plane, and management-plane of individual operations domains. This method requires commitment and buy-in from all network operators. Allan et. al. Expires January 2002 Page 13 A Framework for MPLS User Plane OAM July 2001 3) Inter-domain OAM gateway This method proposes use of a gateway like functions at LSRs that are at operations domain boundaries. OAM gateway like functions includes capabilities to correlate OAM information from one operations domain to another and permit inter-carrier sectionalization problems to be resolved. Specification of inter-domain OAM gateway capability would appear to be the most realistic solution. 10. Security Considerations Support for intra-provider user plane OAM messaging does not introduce any new security concerns to the MPLS architecture. Support for inter-provider user plane OAM messaging introduces a number of security concerns as by definition, portions of LSPs will not be in trusted space, the provider has no control over who may inject traffic into the LSP. This creates opportunity for malicious or poorly behaved users to disrupt network operations. Attempts to introduce filtering on target LSP OAM flows may be problematic if flows are not visible to intermediate LSRs. However it may be possible to interdict flows on the return path between providers (as faithfulness to the forwarding path is not a return path requirement) to mitigate aspects of this vulnerability. 11. A summary of what can be achieved. This draft identifies useful MPLS OAM capability that potentially could be provided via user plane OAM messaging. In particular with respect to on-demand verification and fault sectionalization. This draft suggests that it may be possible to provide this capability for any level in the label stack and across the full set of topological constructs available in the MPLS architecture. This "any level"/ "any construct" applicability is a key requirement and differentiates MPLS specific user plane OAM from such previous efforts as [ICMP] and [HARRISON- MECH]. This draft also identifies that many aspects of performance management are problematic without modifications to operational procedure. Any type of comparative measurement between the ingress and egress requires a 1:1 cardinality, or the ability of the egress to uniquely determine the ingress for each measured unit of communication, something that LSP merge and PHP at the measured LSP level undermine. Services requiring performance management functionality will not be able to utilize the full set of constructs in the MPLS architecture at the service level. Allan et. al. Expires January 2002 Page 14 A Framework for MPLS User Plane OAM July 2001 12. References [CHANG] Owens et.al., "A Path Protection/Restoration Mechanism for MPLS Networks", draft-chang-mpls-path-protection-02.txt, IETF work in progress, November 2000. [ICMP] Bonica et. al. "ICMP Extensions for MultiProtocol Label Switching", draft-ietf-mpls-icmp-02.txt, IETF Work in Progress, August 2000. [KOMPELLA] Kompella et.al. "MPLS-based Layer 2 VPNs", draft-kompella-mpls-l2vpn-02.txt, IETF Work in Progress, December 2000 [MARTINI]Martini et.al. "Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-trans-mpls-06.txt, IETF Work in Progress, May 2001 [MPLSDIFF] Le Faucheur et.al. "MPLS Support of Differentiated Services", draft-ietf-mpls-diff-ext-09.txt, IETF Work in Progress, April 2001 [2547] Rosen, E. Rekhter, Y., "BGP/MPLS VPNs", IETF RFC 2547, March 1999 [HARRISON-MECH] Harrison et.al. "OAM Functionality for MPLS Networks", draft-harrison-mpls-oam-00.txt, February 2001 [HARRISON-REQ] Harrison et.al. "Requirements for OAM in MPLS Networks", draft-harrison-mpls-oam-req-00.txt, May 2001 13. Author's Addresses David Allan Nortel Networks Phone: (613) 763-6362 3500 Carling Ave. Email: dallan@nortelnetworks.com Ottawa, Ontario, CANADA Mina Azad Nortel Networks 3500 Carling Ave. phone: 1-613-763-2044 Ottawa, Ontario, CANADA Email: mazad@nortelnetworks.com Allan et. al. Expires January 2002 Page 15