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

Versions: 00

                                                                  Mina Azad
Internet Draft                                                  David Allan
Document: draft-azad-mpls-oam-messaging-00.txt              Nortel Networks
Expires: January 2002                                             July 2001



                         MPLS user-plane OAM messaging
                      draft-azad-mpls-oam-messaging-00.txt


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.


Abstract

This Internet draft defines user plane OAM messaging for MPLS availability
verification and performance measurement. The proposal is designed to meet
requirements brought forward in [HARRISON-REQ] and [ALLAN-et-al].

The user plane OAM messaging includes on-demand availability check and
performance measurement based on OAM probes and loopback capability. It employs
the reserved label approach proposed in [HARRISON-MECH] but proposes significant
changes to the PDU encoding to broaden the applicability of the message set
within the MPLS architecture.







Azad et.al                   MPLS user-plane OAM messaging                Page 1



Table of Contents
1.      Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.      Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.      Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
4.      MPLS user-plane OAM messaging framework . . . . . . . . . . . . . . .  4
4.1     Label stack encoding for OAM messaging  . . . . . . . . . . . . . . .  5
4.2     OAM message PDU . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
4.3     OAM message TLVs  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
4.3.1   OAM LSR-ID TLV set  . . . . . . . . . . . . . . . . . . . . . . . . .  6
4.3.2   OAM LSP-ID TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
4.3.3   LSP-ID TLV encoding for LDP format  . . . . . . . . . . . . . . . . .  9
4.3.4   LSP-ID TLV encoding for RSVP_TE Format  . . . . . . . . . . . . . . .  9
4.3.5   LSP-ID TLV encoding for CR-LDP Format . . . . . . . . . . . . . . . . 10
4.3.6   OAM Correlation ID TLV  . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.7   OAM Timestamp TLVs  . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.8   OAM Loopback status TLV . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.9   Performance Statistics TLV  . . . . . . . . . . . . . . . . . . . . . 11
4.4     OAM TLV summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.      Examples of OAM messaging . . . . . . . . . . . . . . . . . . . . . . 12
5.1     Verification Loopback . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2     Performance loopback  . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3     Performance notification  . . . . . . . . . . . . . . . . . . . . . . 12
6.      Security Considerations . . . . . . . . . . . . . . . . . . . . . . . 12
7.      Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.      References  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.      Author's Addresses  . . . . . . . . . . . . . . . . . . . . . . . . . 13


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].




















Azad et.al                   MPLS user-plane OAM messaging                Page 2




1. Motivations

The internet-draft [ALLAN-et-al] discusses requirements, issues, and potential
approaches for user-plane OAM in single and multiple operational domain(s). It
describes benefits and disadvantages of various mechanisms for identifying user
plane OAM messaging, including the reserved OAM label approach proposed in
[HARRISON-MECH].

[HARRISON-MECH] focused primarily on mechanisms and procedures suitable for
permanent, provisioned LSPs. This draft focuses more on user plane OAM messaging
in MPLS networks where a control plane is actively present, with an expectation
that at some point the applications outlined in both will be reconciled.

This document proposes an ingress only based probe-loopback mechanism to
unburden the egress from keeping state for connectivity verification. It also
minimizes state processing on ingress by including probe-loopback correlation
information in probe and loopback messages. Through parameter flexibility that
is introduced here, the same probe-loopback mechanism can be used for
performance measurement.


2. Scope
This document proposes a mechanism for OAM functionality required to determine
availability and performance of LSPs in an operational domain. It supports
- point-to-point and multipoint-to-point topologies
- point-to-multipoint forwarding (based on the "Multipoint forwarding"
assumption below)
- single and hierarchical operational domains but the focus is on single (or
seamlessly multiple) operational domains.
It is not intended that the first draft of this document offer a comprehensive
set of messaging and message content, but merely an initial set of functions to
illustrate the utility of such a protocol framework. The desire is that this I-D
be adopted as a WG document, and the set of functions completed with the input
from vendors and providers.


3. Assumptions
The following assumptions are made in this document:

i) Required flexibility of user-plane OAM message structure
The flexibility of the MPLS architecture requires similar flexibility in the
user plane OAM message structure.

The design philosophy embodied in this proposal is to minimize per LSP state
processing in the MPLS user plane to support OAM. This can only be achieved by
adding information to user plane OAM messages. Having sufficient information in
OAM messages allows user plane OAM capability to be extended to all topological
constructs of the MPLS architecture.


ii) There shall exist a return path

Azad et.al                   MPLS user-plane OAM messaging                Page 3


This proposal assumes that for every LSP ingress-egress pair, there is a user-
plane path from the egress to the ingress. The return path will not necessarily
be explicitly bound to the target LSP, but will be indirectly available in that
messaging will carry a useful identifier of the OAM application originating LSR.
This can then be mapped to an FEC and subsequently to an NHLFE entry by OAM
message processing in the message terminating LSR. The definition of a "useful
LSP identifier" depends on the operational characteristics of the label level
under test.

Similarly, the user plane return path may exist as an inherent part of the
natural operation of the network, or operational procedure may have to be
augmented to provide such a path.

This document neither emphasizes on nor precludes use of a high availability LSP
as a return path. It neither assumes that the return path shares facilities with
the monitored LSP or traverses distant facilities.

iii) Multipoint forwarding requires multiple LSPs

At the MPLS layer, multipoint routing is realized by having multiple LSPs
sharing the same ingress. Although to the user protocols (e.g. IGP) this may
seem as one LSP, it is assumed that each of the outgoing paths is effectively a
separate LSP.

iv) Not every LSR has to be fully OAM-capable

It is assumed that operators may likely to desire a limited OAM functionality
(e.g. error/fault notification to management systems) on every LSR but have
small percentage of core network LSRs for full OAM functionality (e.g.
connectivity check and performance measurement).

This document recognizes three classes of OAM capabilities:
a) OAM probe initiation and tracking intended for LSP ingress LSRs
b) OAM probe reception and loopback initiation intended for LSP egress LSRs
c) OAM fault notification intended for all LSRs.

v) MPLS OAM Model

This document considers an operational domain as a network of OAM capable nodes
responsible for monitoring the health and measuring the performance of the user-
plane of the LSPs in a network. In a simple case, LSP ingress and egress LSRs
are the only OAM capable nodes that participate in probe-loopback activities. In
a more complex networks significantly important interim LSRs (such as merge-
points in multipoint-to-point LSPs, geographically significant LSRs in point-to-
point LSPs, the PHP capable LSRs, and operational domain boundary LSRs) are
upgraded to support OAM functionality.

4. MPLS user-plane OAM messaging framework

This document proposes two classes of transactions for MPLS user-plane OAM:

- bi-directional probe-loopback for determining LSP connectivity and performance
measurement
- Uni-directional OAM notifications to convey fault and performance results.
Azad et.al                   MPLS user-plane OAM messaging                Page 4




4.1 Label stack encoding for OAM messaging

User-plane OAM messages are identified by a reserved OAM label [HARRISON-MECH]
which is located at the bottom of the label stack directly beneath the label
level to which the OAM probe applies. The reserved OAM label is immediately
followed by an OAM PDU. The label stack entry immediately above the OAM level is
referred to the user-plane header and determines the forwarding of the OAM
packet along the LSP that is being monitored.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved OAM label                    |EXP  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Reserved OAM label [HARRISON-MACH]
- EXP field: used to replicate the EXP field of the label level under test, it
is copied from the user-plane header
- S bit: 1 (bottom of the stack)
- TTL field: used for fault isolation details of which is for further study.

4.2 OAM message PDU

The OAM PDU employs variable length TLV encoding as defined in section 3.3 of
[LDPSPEC]. Note that at the present time, there is no defined applicability of
the 'F' bit for user plane OAM TLV behavior.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Func Type     |    ver=0      |           PDU Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
\\                   variable length TLV space                 \\
|                                                               |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |Error Detection  (TBD)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Function Type: The following function types are supported.

Function Type       Description
-------------       -----------
0                   Reserved
1                   Availability Probe
2                   Performance Probe
3                   Availability loopback
4                   Performance loopback
5                   Performance notification
6                   Fault notification
Other values        reserved for future use.

Azad et.al                   MPLS user-plane OAM messaging                Page 5



General Usage:
- A probe (availability or performance) originated by an LSP ingress is expected
to be responded by a loopback message. A notification (performance or fault)
message elicits no response from the receiver.
- bi-directional probe-loopback transactions are used for determining
availability as well as performance measurement. The difference between
availability and performance transactions is only in the ingress procedures for
interpreting loopback parameters and extrapolating data based on timestamp
parameters
- Performance notifications are for sending performance measurement results from
an originating LSR to another LSR (using the performance statistics TLV).

Version:
Version of the user plane OAM messaging. Explicitly zero for this version of
this specification.

PDU length:
is the length of the PDU exclusive of the func-type, ver, PDU length  and any
interface specific padding (to meet minimum payload length requirements). It is
used to indicate what portion of the received MPLS payload actually contains
parsable information.

Variable length TLV space:
"PDU length" octets containing TLVs. Similar to [LDPSPEC], there is no specific
alignment requirement for the first octet of a TLV.

Error Detection:
CRC 32 or BIP 16 (the need for and details of this field is for further study).


4.3 OAM message TLVs

4.3.1 OAM LSR-ID TLV set

The set of OAM LSR-ID TLVs consists of Originating and Responding LSR-ID TLVs.
LSR-ID TLVs are encoded as follows.


0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| LSR-ID TLV (0x02 or 0x05) |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              =0               |   Address Family              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Address authority                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           LSR-ID                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Azad et.al                   MPLS user-plane OAM messaging                Page 6



Address family:
is a two octet quantity containing a value from ADDRESS FAMILY NUMBERS in RFC
1700 that encodes the address family for the LSR in the LSR-ID field.

Address authority
is the encoded the same as the VPN I.D. in RFC 2685.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      =0       |   OUI(MSB)    |      OUI      |   OUI(LSB)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Index (MSB) |     Index     |     Index     |   Index (LSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Length:
Is the length of the LSR-ID TLV in octets.

LSR-ID:
Is an address encoded to the address family field.

The set of LSR-ID TLVs is:

Originating LSR-ID TLV:
This mandatory TLV identifies the LSR that initiated a probe or a notification
transaction. The Originating LSR-ID must be unique within an operational domain.

Responding LSR-ID TLV:
This TLV identifies the LSR that initiated a loopback transaction in response to
a probe. The TLV is mandatory in loopback messages. Whether it needs to be
optional in probe and notification messages is for further study. The Responding
LSR-ID must be unique within an operational domain.


4.3.2 OAM LSP-ID TLVs

There are two LSP ID TLVs. The set of LSP-ID TLVs is:

Original LSP-ID TLV:
This TLV identifies the LSP that is being probed. It is mandatory in probe and
loopback transactions.


Return path LSP-ID TLV:
This TLV identifies the return path. This is TLV is optional.

The set of LSP-ID TLVs are encoded dependent on how the LSP is identified. LSP
identification depends on the label distribution protocol used in an operational
domain, and LSP topology (point-to-point vs. multipoint-to-point) and the
originating LSR.


Azad et.al                   MPLS user-plane OAM messaging                Page 7



The LSP-ID is frequently expressed with the identification of the that either
created or is the ingress for the LSP. This may be different from the OAM
application originator, hence the potential appearance of multiple LSR-IDs in
OAM messages.

Point-to-Point LSPs are identified by:

-- RSVP:   Same Sender Template (IP tunnel sender IP address,
LSP-ID)

-- Cr-LDP: Same LSP-ID TLV (Ingress LSR Router ID and Local CR-
LSP ID)


Multipoint-to-point LSPs are identified by:
-- RSVP:  Same session object (IP tunnel end point address and
Tunnel ID)

-- Cr-LDP: Same FEC TLV (Host Address and Prefix).[CHANG-et-al]

Given that router identifications are encoded in the OAM LSR-ID TLV's, the OAM
LSP-ID TLVs will only include the local LSP-ID or FEC TLV.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|  LSP-ID TLV (0x01 or 0x04)|             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Format              |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                     Format specific layout                    |
//                                                             //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where format is:

0 = Unknown format
1 = LDP LSP ID
2 = RSVP-TE LSP ID
3 = CR-LDP LSP ID













Azad et.al                   MPLS user-plane OAM messaging                Page 8



4.3.3 LSP-ID TLV encoding for LDP format

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|  LSP-ID TLV (0x01 or 0x04)|             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Format =1           |          Address Family       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Address authority                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           LSR-ID                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Label Space ID          |               =0              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             label                     |         =0            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.3.4 LSP-ID TLV encoding for RSVP_TE Format

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|  LSP-ID TLV (0x01 or 0x04)|             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Format =2           |          Address Family       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Address authority                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           LSR-ID                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            LSP-ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+













Azad et.al                   MPLS user-plane OAM messaging                Page 9

4.3.5 LSP-ID TLV encoding for CR-LDP Format

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|  LSP-ID TLV (0x01 or 0x04)|             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Format =3           |          Address Family       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Address authority                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           LSR-ID                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           LSP-ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.3.6 OAM Correlation ID TLV

A Correlation ID TLV is used for correlating probe and loopback messages in bi-
directional transactions. This TLV must be unique on an LSP ingress. The
encoding of the Correlation ID TLV is as follows.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|Correlation ID TLV (0x09)|         Length = 4              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Correlation ID value                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.3.7 OAM Timestamp TLVs

The set of Timestamp TLVs are encoded identically:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Timestamp TLV (0x03 or 0x06)|      Length = 4             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       timestamp                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Origination Timestamp TLV: This TLV identifies the time when a bi-directional
probe-loopback or a uni-directional notification transaction has been initiated.
This TLV is mandatory in all OAM performance messages.

Response Timestamp TLV:  This TLV identifies the time when a loopback message is
initiated in response to a probe transaction. This TLV is mandatory in
performance loopback transactions and is not applicable to probe and
notification transactions.
Azad et.al                   MPLS user-plane OAM messaging                Page 10




Note: The detailed format and specification of timestamp TLVs are for further
study.


4.3.8 OAM Loopback status TLV

The encoding for the loopback status TLV is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|     LSR-ID TLV (0x07)     |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Loopback Status code                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Loopback Data                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Loopback Status code
        32 bit unsigned integer
        0 = Unknown     1 = normal success
        2 = TTL exhaustion
        3 = Unknown TLV (indicating receipt of an OAM message with invalid PDU
TLV)


Loopback Data:
This TLV provides the data associated with the loopback status code. For
"Unknown TLV" status, it contains the TLV ID of the unknown TLV.


4.3.9 Performance Statistics TLV

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|   LSP statistics (0x08)   |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Packets sent                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Octets sent                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Packets sent and octets sent are unsigned 32 bit counter values.
This optional TLV is used in performance notification transactions. The criteria
for sending performance statistics are for further study





Azad et.al                   MPLS user-plane OAM messaging                Page 11



4.4 OAM TLV summary

Type value      Function
0           Reserved
1           Original LSP-ID
2           Originating LSR-ID
3           Origination Timestamp
4           Return path LSP-ID
5           Return path LSR-ID
6           Response Timestamp
7           Loopback status
8           Performance statistics
9           Correlation ID
10-8192     Reserved for future use
8192-16383      vendor specific.


5. Examples of OAM messaging

The following is a non-exhaustive set of examples of OAM messaging.

5.1 Verification Loopback

Ingress LSR issues availability probe PDU containing originating LSR-ID, LSP-ID,
and correlationID Egress LSR receives probe, modifies Function Type to
availability loopback, adds return path LSR-ID, obtains FEC-NHLFE mapping for
originating LSR-ID and sends availability loopback. Originating LSR receives
availability loopback message, and analyzes data in the loopback message to
correlate probe-loopback messages.

5.2 Performance loopback

Ingress LSR issues performance probe PDU containing originating LSR-ID, LSP-ID,
correlationID and timestamp. Egress LSR receives probe, modifies Function Type
to performance loopback, adds return path LSR-ID and timestamp, and sends
loopback to the originating LSR. By use of successive probe-loopback
transactions, a generic RTT number and indication of jitter can be obtained.

5.3 Performance notification

Ingress LSR issues performance notification PDU containing LSR-ID, LSP-ID, and
performance statistics. Egress LSR receives notification, compares differences
since last set of statistics received to get indication of packet loss, minimum
average bandwidth etc. for the period.

6. Security Considerations

Support for probe-loopback mechanism proposed in this document does not
introduce any new security concerns to the MPLS architecture.





Azad et.al                   MPLS user-plane OAM messaging                Page 12


7. Acknowledgements

Authors would like to acknowledge Neil Harrison, Peter Willis, Shahram Davari,
Ben Mack-Crane and Hiroshi Ohta for bringing forward requirements and proposing
the reserved label approach.

8. References
[ALLAN-et-al] Allan et. al. A Framework for MPLS User Plane OAM draft-allan-
mpls-oam-frmwk-00.txt, July 2001.

[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

[LDPSPEC] Andersson, et. al. "LDP Specification", IETF RFC 3036, January 2001

[RFC2026] Bradner, "The Internet Standards Process -- Revision 3
", IETF RFC 3026, October 1996

[CHANG-et-al] Changcheng et. al. " A Path Protection/Restoration Mechanism for
MPLS Networks", draft-chang-mpls-path-protection-02.txt, May 2001


9. Author's Addresses


Mina Azad
Nortel Networks
3500 Carling Ave.               phone: 1-613-763-2044
Ottawa, Ontario, CANADA Email: mazad@nortelnetworks.com

David Allan
Nortel Networks         Phone: (613) 763-6362
3500 Carling Ave.               Email: dallan@nortelnetworks.com
Ottawa, Ontario, CANADA

















Azad et.al                   MPLS user-plane OAM messaging                Page 13


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