[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-mpls-oam-frmwk

        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
     

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/