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