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