Frame Relay Operations, Administration, and Maintenance ... · FRF.19.1, Frame Relay Operations, Administration, and Maintenance Implementation Agreement Note: The user’s attention

Frame Relay Operations, Administration, and Maintenance

Implementation Agreement

FRF.19.1

Final Ballot Text

MFA Forum Technical Committee April 2007

Frame Relay Operations, Administration, and Maintenance Implementation Agreement FRF.19.1

This page is intentionally left blank.

FRF.19.1, Frame Relay Operations, Administration, and Maintenance Implementation Agreement

Note: The user’s attention is called to the possibility that implementation of the frame relay implementation agreement contained herein may require the use of inventions covered by patent rights held by third parties. By publication of this frame relay implementation agreement, the MFA Forum makes no representation that the implementation of the specification will not infringe on any third party rights. The MFA Forum takes no position with respect to any claim that has been or may be asserted by any third party, the validity of any patent rights related to any such claims, or the extent to which a license to use any such rights may not be available.

Editor:

Timothy Mangan Sync Research 26 Angela Street Canton, MA 02021 USA Phone: +1 781 492-0403 Email:[email protected]

Ed Sierecki AT&T, Inc. 2600 Camino Ramon, Rm 2W550I San Ramon, CA 94583 Phone: +1 925 824-1033 Email: [email protected]

For more information contact:

The MFA Forum Suite 117 48377 Fremont Blvd. Fremont, CA 94538 USA Phone: +1 (510) 492-4055 FAX: +1 (510) 492-4001 E-Mail: [email protected] WWW: http://www.mfaforum.org/

Copyright © MFA Forum 2007. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the MFA Forum, except as needed for the purpose of developing Frame Relay standards (in which case the procedures for copyrights defined by the MFA Forum must be followed), or as required to translate it into languages other than English.

This document and the information contained herein is provided on an "AS IS" basis and THE MFA FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

April 2007

mailto:[email protected]

mailto:[email protected]


This page is intentionally left blank.

April 2007


Table of Contents

1 INTRODUCTION.................................................................................................................. 1 1.1 PURPOSE.........................................................................................................................................................1

1.1.1 Overview................................................................................................................................................1 1.2 DEFINITIONS...................................................................................................................................................1 1.3 ACRONYM LIST ..............................................................................................................................................2 1.4 TERMINOLOGY ...............................................................................................................................................3 1.5 RELEVANT STANDARDS .................................................................................................................................3

2 REFERENCE MODEL ......................................................................................................... 4

3 OA&M PROTOCOL FORMATS........................................................................................ 7 3.1 ENCAPSULATION FORMATS ............................................................................................................................7

3.1.1 Multiprotocol Encapsulation .................................................................................................................7 3.1.2 Non-UI Encapsulation ...........................................................................................................................8

3.2 OA&M MESSAGE FORMAT............................................................................................................................9 3.2.1 Message Type Field ...............................................................................................................................9 3.2.2 Domain Identification ..........................................................................................................................10

3.2.2.1 DOMAIN IDENTIFIER FORMAT FOR “USER DEFINED “ PLAN.......................................................................................................10 3.2.2.2 DOMAIN IDENTIFIER FORMAT FOR "OUI" PLAN..........................................................................................................................10 3.2.2.3 DOMAIN IDENTIFIER FOR "IPV4 NETWORK" PLAN.......................................................................................................................10 3.2.2.4 DOMAIN IDENTIFIER FORMAT FOR “X.121” PLAN.......................................................................................................................10 3.2.2.5 DOMAIN IDENTIFIER FORMAT FOR “E.164” PLAN ......................................................................................................................11 3.2.2.6 DOMAIN IDENTIFIER FORMAT FOR “PRIVATE” PLAN ..................................................................................................................11

3.2.3 Source Location Identifier Field..........................................................................................................11 3.2.4 Destination Location Identifier Field ..................................................................................................11 3.2.5 OA&M Information Field Format .......................................................................................................12

3.2.5.1 I.F. TYPE FIELD VALUES .............................................................................................................................................................12 3.2.5.2 INFORMATION FIELD LENGTH .....................................................................................................................................................12

3.3 OA&M INFORMATION FIELDS .....................................................................................................................13 3.3.1 Per Type Formats of Information Fields .............................................................................................13

3.3.1.1 CAPABILITIES INFORMATION FIELD.............................................................................................................................................13 3.3.1.2 FRAME TRANSFER DELAY INFORMATION FIELD...........................................................................................................................15 3.3.1.3 FRAME TRANSFER DELAY RESULTS INFORMATION FIELD ............................................................................................................16 3.3.1.4 FRAME DELIVERY RATIO SYNC INFORMATION FIELD...................................................................................................................17 3.3.1.5 FRAME DELIVERY RATIO RESULTS INFORMATION FIELD .............................................................................................................18 3.3.1.6 DATA DELIVERY RATIO SYNC INFORMATION FIELD .....................................................................................................................19 3.3.1.7 DATA DELIVERY RATIO RESULTS INFORMATION FIELD................................................................................................................20 3.3.1.8 NON-LATCHING LOOPBACK INFORMATION FIELD .......................................................................................................................21 3.3.1.9 LATCHING LOOPBACK INFORMATION FIELD................................................................................................................................22 3.3.1.10 DIAGNOSTIC INDICATION INFORMATION FIELD ...........................................................................................................................23 3.3.1.11 FULL SOURCE ADDRESS INFORMATION FIELD.............................................................................................................................24 3.3.1.12 OPAQUE INFORMATION FIELD.....................................................................................................................................................25 3.3.1.13 PAD INFORMATION FIELD ...........................................................................................................................................................26

4 OA&M PROCEDURES ...................................................................................................... 27 4.1 MESSAGE ENCODING/DECODING RULES ......................................................................................................27

4.1.1 Order of transmission ..........................................................................................................................27 4.1.2 Order of Information Fields ................................................................................................................27 4.1.3 Usage of Information Fields ................................................................................................................27 4.1.4 Counters and Counter Wrap................................................................................................................28

4.2 GENERAL MESSAGE PROCESSING.................................................................................................................28 4.2.1 Transmission of Messages ...................................................................................................................28 4.2.2 Reception and Forwarding of Messages..............................................................................................29

4.2.2.1 ARRIVING OA&M MESSAGE FROM A FOREIGN DOMAIN .............................................................................................................29

April 2007 Page i


4.2.2.2 ARRIVING OA&M MESSAGES FROM SAME DOMAIN ....................................................................................................................29 4.2.3 Timers ..................................................................................................................................................29

4.3 HELLO MESSAGE PROCESSING (DEVICE DISCOVERY) ..................................................................................30 4.3.1 Sending the Hello Message..................................................................................................................31

4.3.1.1 CONNECTION INITIALIZATION ......................................................................................................................................................31 4.3.1.2 PERIODIC TRANSMISSION INTERVAL ............................................................................................................................................32

4.3.2 Processing the Received Hello Message..............................................................................................32 4.3.2.1 DISCOVERY OF A NEW PEER ........................................................................................................................................................32 4.3.2.2 PREVIOUSLY RECORDED PEER ....................................................................................................................................................32

4.3.3 TIMER_HELLO_RX Expiration ..........................................................................................................32 4.4 SERVICE LEVEL VERIFICATION MESSAGE PROCESSING................................................................................33

4.4.1 Sending the Service Verification Message ...........................................................................................33 4.4.1.1 PERIODIC TRANSMISSION INTERVAL FOR MEASUREMENT INITIATIONS.........................................................................................33

4.4.2 Processing the Received Service Verification Message.......................................................................33 4.4.3 Procedures for Delay Measurement ....................................................................................................33

4.4.3.1 DELAY INITIATION .......................................................................................................................................................................34 4.4.3.2 DELAY TURNAROUND ..................................................................................................................................................................34 4.4.3.3 DELAY MEASUREMENT ................................................................................................................................................................34 4.4.3.4 DELIVERY OF DELAY RESULTS .....................................................................................................................................................34 4.4.3.5 ERROR HANDLING .......................................................................................................................................................................34

4.4.4 Procedures for Frame Delivery Ratio Measurement...........................................................................34 4.4.4.1 FRAME DELIVERY RATIO INITIATION............................................................................................................................................34 4.4.4.2 FRAME DELIVERY RATIO MEASUREMENT.....................................................................................................................................35 4.4.4.3 DELIVERY OF FRAME DELIVERY RATIO RESULTS .........................................................................................................................36 4.4.4.4 FDR ERROR HANDLING ..............................................................................................................................................................36

4.4.5 Procedures for Data Delivery Ratio Measurement .............................................................................36 4.4.5.1 DATA DELIVERY RATIO INITIATION ..............................................................................................................................................36 4.4.5.2 DATA DELIVERY RATIO MEASUREMENT .......................................................................................................................................36 4.4.5.3 DELIVERY OF DATA DELIVERY RATIO RESULTS............................................................................................................................37 4.4.5.4 DDR ERROR HANDLING ..............................................................................................................................................................37

4.5 NON-LATCHING LOOPBACK MESSAGE PROCESSING ....................................................................................38 4.5.1 Initiating the Non-latching Loopback Request ....................................................................................38 4.5.2 Processing the Received Non-Latching Loopback Message................................................................38

4.6 LATCHING LOOPBACK MESSAGE PROCESSING .............................................................................................39 4.6.1 Initiating the Latching Loopback Request ...........................................................................................39 4.6.2 Processing the Received Latching Loopback Request .........................................................................39 4.6.3 Clearing a Latched Loopback..............................................................................................................39

4.7 DIAGNOSTIC INDICATIONS MESSAGE PROCESSING.......................................................................................40 4.7.1 Initiating the Diagnostics Indication Message ....................................................................................40 4.7.2 Processing the Received Diagnostic Indications Message ..................................................................40

A APPENDIX – GENERAL RECEIVE PROCEDURES ...................................................... 41

B APPENDIX – MESSAGE FLOWS ....................................................................................... 42 B.1 DISCOVERY ..................................................................................................................................................42 B.2 FTD MEASUREMENT....................................................................................................................................43 B.3 FDR/DDR MEASUREMENT ..........................................................................................................................44 B.4 NON-LATCHING LOOPBACK .........................................................................................................................45 B.5 LATCHING LOOPBACK ..................................................................................................................................46

C APPENDIX – EXAMPLE OF DELIVERY RATIO CALCULATION ............................ 47 C.1 INGRESS PROCESSING...................................................................................................................................48 C.2 EGRESS PROCESSING ....................................................................................................................................48

Page ii April 2007


List of Tables Table 1 - OA&M Message Type Values .......................................................................................................................9 Table 2 - Domain Identification Plan ..........................................................................................................................10 Table 3 - Information Field Type Values ....................................................................................................................12 Table 4 - Capability Information Field Type Values...................................................................................................13 Table 5 - Non-Latching Loopback Code Values .........................................................................................................21 Table 6 - Latched Loopback Code Values...................................................................................................................22 Table 7 - Event Types for Diagnostic Indication.........................................................................................................23 Table 8 – Address Type Values...................................................................................................................................24 Table 9 - Information Fields by Message Type ...........................................................................................................28 Table 10 - OA&M Timers ...........................................................................................................................................30

List of Figures Figure 1 – Network Reference Model ...........................................................................................................................4 Figure 2 - Relationship with FRF.13 .............................................................................................................................5 Figure 3 – Administrative Domain Reference Model....................................................................................................5 Figure 4 - Multiprotocol Encapsulation Format ............................................................................................................7 Figure 5 - Non-UI Encapsulation Format ......................................................................................................................8 Figure 6 - OA&M Message Format...............................................................................................................................9 Figure 7 - OA&M Information Field Format ..............................................................................................................12 Figure 8 - Capabilities Information Field Format........................................................................................................13 Figure 9 - Multi-octet Capability Format ....................................................................................................................14 Figure 10 - Frame Transfer Delay Information Field Format......................................................................................15 Figure 11 - Frame Transfer Delay Results Information Field Format .........................................................................16 Figure 12 - Frame Delivery Ratio Sync Information Field Format .............................................................................17 Figure 13 - Frame Delivery Ratio Results Information Field Format..........................................................................18 Figure 14 - Data Delivery Ratio Sync Information Field Format................................................................................19 Figure 15 - Data Delivery Ratio Results Information Field Format ............................................................................20 Figure 16 - Non-Latching Loopback Information Field Format..................................................................................21 Figure 17 - Latching Loopback Information Field Format..........................................................................................22 Figure 18 - Diagnostic Indication Information Field Format ......................................................................................23 Figure 19 - Full Source Address Information Field.....................................................................................................24 Figure 20 - Opaque Information Field Format ............................................................................................................25 Figure 21 - Pad Information Field Format...................................................................................................................26 Figure 22 - Example of Hello Messages on a VC with multiple Administrative Domains .........................................31 Figure 23 – VC Latched Loopback..............................................................................................................................39

April 2007 Page iii


Revision History

Version Change Date FRF.OA&M Document Approved March, 2001 FRF.19.1 Changes added to recognize OAM message type values used by

“Performance Monitoring Across Multiservice Networks” Technical Specification.

July, 2006

Page iv April 2007

1 Introduction

1.1 Purpose This document is an Operations, Administration, and Maintenance (OA&M) Protocol and Procedures Implementation Agreement for a Frame Relay Service. The agreements herein were reached in the Frame Relay Forum, and are based on, and enhance, the relevant frame relay standards referenced in section 1.4. This Implementation Agreement (IA) documents agreements reached among vendors and suppliers of frame relay products and services.

This IA provides a means to Test, Diagnose, and Measure the quality of, Frame Relay Services. This OA&M protocol and procedures document is designed to either supplement, or replace, I.620 [5]. Interoperability with I.610 [4] is beyond the scope of this IA.

Interoperability with other OA&M protocols is beyond the scope of this IA. Specifically, interoperation with ATM equipment in the case of Service Interworking is left for further study.

1.1.1 Overview This document is divided into the following sections:

• Section 2. A reference model for measurement. • Section 3. A protocol (message formats) for managing Virtual Circuits, in whole or in sections. • Section 4. Procedures for using this protocol, especially in application to FRF.13 [14]. • Several Annexes. Informative text to aid interoperability.

The protocol and procedures may be used for Public and Private Frame Relay Networks by Service Providers and/or End-users. It is applicable to PVCs, as well as to the data transfer phase of SVCs.

1.2 Definitions The following terms, when used in this document and highlighted in bold, are used as defined in this section:

• Must, Shall, or Mandatory - the item is an absolute requirement of this implementation agreement. • Should - the item is highly desirable. • May or Optional - the item is not compulsory, and may be followed or ignored according to the needs

of the implementation. • Not Applicable - the item is outside the scope of this implementation agreement.

October, 2006 Page 1


1.3 Acronym List AESA ATM End System Address

ATM Asynchronous Transfer Mode

BECN Backward Explicit Congestion Notification

CIR Committed Information Rate

DCE Data Circuit-terminating Equipment

DDR Data Delivery Ratio

DE Discard Eligibility

DLCI Data Link Connection Identifier

DTE Data Terminal Equipment

FDR Frame Delivery Ratio

FECN Forward Explicit Congestion Notification

FR Frame Relay

FROMP Frame Relay OA&M Maintenance Point

FTD Frame Transfer Delay

IA Implementation Agreement

IEEE Institute of Electrical and Electronics Engineers

I.F. Information Field

IPv4 Internet Protocol Version 4

ITU International Telecommunication Union

MTU Maximum Transmission Unit

NLPID Network Layer Protocol Identification

NNI Network to Network Interface

OA&M Operations, Administration, and Maintenance

OUI Organizationally Unique Identifier

PHY Physical Interface

PVC Permanent Virtual Circuit

SLA Service Level Agreement

SVC Switched Virtual Circuit

UNI User to Network Interface

VC Virtual Circuit

xDR Frame or Data Delivery Ratio (as appropriate)

Page 2 April 2007


1.4 Terminology The following terms, when used in this IA, are used as defined in FRF.13:

• Frame Transfer Delay • Frame Delivery Ratio • Data Delivery Ratio • Frames_offered • Frames_received • Data_offered • Data_received • Availability

1.5 Relevant Standards The following is a list of standards on which these implementation agreements are based:

[1] E.164 ITU-T. Recommendation E.164/I.331 (1997), The international public telecommunication numbering plan.

[2] I.370 ITU-T. Recommendation I.370 (1991), Congestion management for the ISDN frame relaying bearer service.

[3] I.555 ITU-T. Recommendation I.555 (1997), Frame Relaying Bearer Service interworking.

[4] I.610 ITU-T. Recommendation I.610 (1999) B-ISDN operation and maintenance principles and functions.

[5] I.620 ITU-T. Recommendation I.620 (1996) Frame relay operation and maintenance principles and functions.

[6] X.36 ITU-T. Recommendation X.36 (2000), Interface between Data Terminal Equipment (DTE) and Data circuit-terminating Equipment for public data networks providing frame relay data transmission service by dedicated circuit.

[7] X.76 ITU-T. Recommendation X.76 (2000), Network-to-network interface between public data networks providing the frame relay data transmission service.

[8] X.121 ITU-T. Recommendation X.121 (1996), International numbering plan for public data networks.

[9] Q.922 ITU-T. Recommendation Q.922 (1992), ISDN Data Link Layer Specification for Frame Mode Bearer Services.

[10] Q.933 ITU-T. Recommendation Q.933 (1995), ISDN Digital Signaling Specification no. 1 (DSS 1) signalling specifications for Frame Mode Switched and Permanent Virtual Connection Control and Status Monitoring.

[11] FRF.3.2 Frame Relay Forum. Multiprotocol Encapsulation Implementation Agreement, April 2000.

[12] FRF 8.1 Frame Relay Forum. Frame Relay / ATM PVC Service Interworking Implementation Agreement, February 2000.

[13] FRF.11 Frame Relay Forum. Voice Over Frame Relay Implementation Agreement, May, 1997.

[14] FRF.13 Frame Relay Forum. Service Level Definitions Implementation Agreement, November 1998.

April 2007 Page 3


2 Reference Model Figure 1 illustrates a reference Frame Relay Network that is interworking with an ATM network. A number of example monitoring points are indicated. In this reference network, the following examples of circuit connections may be indicated: • A VC that spans a single FR Access Network Section. • A VC that spans two FR Access Network Sections connected by an NNI. • A VC that spans two FR Access Network Sections connected by a FR Transit Network. • A VC that spans two FR Access Network Sections connected by an ATM Transit Network Section using

Network Interworking. • A FR Circuit that spans a single FR Access Network Section but is terminated as an ATM Circuit using Service

Interworking.

NNI

FrameRelayDTE

UNI

ATMDTEATM Network

FrameRelayDTE

UNIFrameRelayDTE

UNI

UNI

Frame RelayAccess Network Section

NNI

NNI

Ser

vice

IWF

Net

wor

k IW

F

Frame

ATMIWF

Net

wor

k IW

FMP

MP

MP

MP

MP

MP

LegendExample Monitor Point for optional Frame Relay OA&Mmaintenance device (FROMP).

MP

Frame RelayTransit Network Section

Frame

ATMIWF

MP

MP

Frame

ATM

IWFM

P

AMP

Frame RelayAccess Network Section

Example Monitor Point for optional ATM OA&M device.AMP

MP

Note: Monitoring points may be external probes or embedded in DTE or DCE equipment.Note: AMP shown for reference to ATM OA&M function. Coexistence with this functionis not precluded by this IA. Interoperability with this function is beyond the scope of thisIA and is shown for reference only.

Figure 1 – Network Reference Model

Page 4 April 2007


FRF.13 provides a reference model for an individual Virtual Circuit. Figure 2 below overlays Frame Relay OA&M Maintenance Points (FROMPS) for verification of various types of Service Level Agreements.

Frame RelayNetwork

FrameRelay

DTE

FrameRelayDTE

UNI

MP

MP

LegendMonitor Point for optional FrameRelay OA&M device.

UNI

MP

MP

MP

Edge-to-Edge-Queue

Edge-to-Edge

End-to-End

F.R.Switch

F.R.

Switch

F.R.Switch

F.R.Switch

MP

F.R.Switch

F.R.Switch

MP

Figure 2 - Relationship with FRF.13

A VC may consist of several sections and components administered by multiple organizations. The portions of a VC that are administered by the same organization(s) create an Administrative Domain. Figure 3 presents the Administrative Domain Reference Model.

Access Network Transit Network Access Network

DTE DTE

Domain A

Domain B

Domain C Domain D

A1 A2B1 B6B2

C1/B3

C2/B4 B5

D1 D2

Domain Identifiers/Location Identifiers

MP

MP

MP

MP

MP

MP

MP

MP

MP

MP

Figure 3 – Administrative Domain Reference Model

April 2007 Page 5


Four different and overlapping types of administrative domains are illustrated in this model. An Administrative Domain may consist of any arbitrary collection of locations on the Virtual Circuit.

Domain A – Set of interfaces and devices administered by the end-user (locations A1 and A2).

Domain B – Set of interfaces and devices administered by a global service provider working with local partners in each region (locations B1, B2, B3, B4, B5, and B6).

Domain C – Set of interfaces and devices administered by a local partner of the global service provider (locations C1 and C2). A network partner has granted the global service provider permission to interrogate OA&M devices operated by the local partner. This permission is reflected in multiple domain memberships (C1/B2 and C2/B3).

Domain D – Set of interfaces and devices controlled by a local partner of the global service provider (locations D1 and D2). The partner has refused to grant the global service provider permission to interrogate OA&M devices operated by the local partner.

Administrative Domains provide well-defined zones for OA&M messaging. At the outermost points of an administrative domain on a given VC (see Figure 3 points B1 and B6 for domain B), an Administrative Boundary exists to delineate the domain. All OA&M messages include a Domain Identification, which is used to identify the intended administrative domain.

A FROMP at a domain boundary of a VC’s administrative domain prevents messages intended for the domain from being forwarded beyond the domain boundary. As an example, location D2 does not send an OA&M message with a domain identification for domain D towards B6.

Further, these boundary devices detect and discard counterfeit messages originating outside the administrative domain. Thus, if a rogue application at location B5 creates a message claiming to have domain identification D and sends the message to D1, D1 will discard the message to prevent an illegal OA&M request from entering the domain.

Messages for other domains must be passed through the domain boundary in either direction without interpretation or discard. As an example, location A1 transmits a message towards location A2. Location B1, a boundary device for Domain B, checks the administrative domain identification and verifies that the message does not claim to originate from within Domain B. The message is then forwarded onward to locations C1 and D1 where the same boundary checks are made. The message is then forwarded onward to location A2, the target of the message.

Messages received from within a domain are trusted. As an example, location B1 in Domain B trusts messages from direction C1 with the domain identification for domain B because they share a common administrative domain.

Page 6 April 2007


3 OA&M Protocol Formats Frame Relay OA&M messages are carried in standard Frame Relay frames. Two encapsulation formats for the data portion of these Frame Relay frames are defined to allow for interoperability with other traffic. The messages consist of a header portion, and one or more information fields. The remainder of this section describes the format of Frame Relay OA&M Protocol messages, and consists of three portions:

• An encapsulation format (section 3.1) • An OA&M message (section 3.2) containing one or more • OA&M Information Fields (section 3.3)

Note: See section 4.1 for rules on encoding and decoding these formats. Figures throughout this IA illustrate 2-octet DLCI encoding. Both 2- and 4-octet addresses are supported in all cases.

3.1 Encapsulation Formats The Frame Relay OA&M Protocol supports two encapsulation formats. These formats allow for implementation in a variety of network elements and for compatibility with U-plane traffic formats.

Implementations must support the Multiprotocol Encapsulation format to be compliant with this IA. Implementations may optionally support the Non-UI encapsulations.

3.1.1 Multiprotocol Encapsulation The Multiprotocol encapsulation format is compatible with Frame Relay equipment and applications. The format uses a NLPID (0xB2) to distinguish OA&M traffic from U-plane traffic conforming to FRF.3.2 [11], FRF.11 [13], and FRF 8.1 traffic. Figure 4 depicts the multiprotocol encapsulation format when a Q.922 Annex A [9] 2-octet header is used.

Bits

8 7 6 5 4 3 2 1 Octet x x x x x x 0 0

DLCI (msb) C/R EA 1

x x x x x x x 1

DLCI (lsb) FECN BECN DE EA 2

0 0 0 0 0 0 1 1 Control

3

(Note 1) 1 0 1 1 0 0 1 0

NLPID 4

FR_OAM Message 5

Note 1: Control is at octet 5 when 4-octet addressing of Q.922 Annex A is used.

Figure 4 - Multiprotocol Encapsulation Format

April 2007 Page 7


3.1.2 Non-UI Encapsulation The non-UI encapsulation format is designed for use with Frame Relay traffic that is not distinguishable from the OA&M multiprotocol encapsulation format. The prime example of this is I.555 [3] section 5 (X.25 encapsulated) traffic. Figure 5 depicts the non-UI encapsulation format when a Q.922 Annex A 2-octet header is used.

Bits

8 7 6 5 4 3 2 1 Octet x x x x x x 0 0

DLCI (msb) C/R EA 1

x x x x x x x 1

DLCI (lsb) FECN BECN DE EA 2

0 0 0 0 0 0 1 0 Control

3

(Note 1) 1 0 1 1 0 0 1 0

NLPID 4

FR_OAM Message 5

Note 1: Control is at octet 5 when 4-octet addressing of Q.922 Annex A is used.

Figure 5 - Non-UI Encapsulation Format

Page 8 April 2007


3.2 OA&M Message Format Figure 6 depicts the format of OA&M messages.

Bits 8 7 6 5 4 3 2 1 Octet

Message Type (Ref: 3.2.1)

N+1 (Note 1)

Domain Identification (Ref: 3.2.2)

N+2

Source Location Identifier (Ref 3.2.3)

N+7

Destination Location Identifier (Ref 3.2.4)

N+11

Information Field 1 (Ref 3.2.5) N+15

Information Field x N+m

(Note 2) Note 1: Offset N is 4, 6, or 10, depending upon encapsulation and address size used. Note 2: Information fields are populated as needed.

Figure 6 - OA&M Message Format

3.2.1 Message Type Field The purpose of the Message Type field is to identify the message being sent. Values for this field are shown in Table 1 below. The MFA Forum Technical Specification, “Performance Management Across Multiservice Networks” (PMIW) uses this same message format, but with a separate set of message types. Table 1 shows the message type values reserved for PMIW, in addition to those specified for FRF.19. Equipment that supports both FRF.19 and PMIW should use the message type field in any OAM frame to determine if that frame originated from an FRF.19 FROMP or a PMIW OMP, and process each frame accordingly. Equipment supporting only FRF.19 should allow OAM frames with PMIW message types to pass through without attempting any FRF.19-related processing.

Message Type Value

Usage

0x1 FRF.19 Hello (see section 4.3 for usage) 0x2 FRF.19 Service Verification (see section 4.4 for usage) 0x3 FRF.19 Non-Latching Loopback (see section 4.5) 0x4 FRF.19 Latching Loopback (see section 4.6) 0x5 FRF.19 Diagnostic Indication (see section 4.7) 0x81 PMIW Hello 0x82 PMIW Service Verification

Table 1 - OA&M Message Type Values

April 2007 Page 9


3.2.2 Domain Identification The purpose of the Domain Identification field is to uniquely identify the Administrative Domain to which this message belongs. This field consists of two parts, a 1-octet descriptor for the type of plan, shown in Table 2 below, followed by a 4-octet domain identifier.

Domain Identification Plan Value

Usage

0x00 Reserved for future use 0x01 User Defined Identifier 0x02 OUI Identifier 0x03 IPv4 Network Identifier 0x31 X.121 [8] Identifier 0x33 E.164 [1] Identifier 0xFF Private Domain Identifier

Notes: • User Defined Identifiers are for use by End-User administered equipment. • OUI, IPv4, X.121, and E.164 Identifiers are for use by Service Providers. • Private Domain Identifiers are for use via multi-lateral agreement.

Table 2 - Domain Identification Plan

The Domain Identification field (the combined values of the type of plan and domain identifier) must be unique for each administration along the path of a VC. The format of the 4-octet domain identifier is dependent upon the value of the Domain Identification plan.

3.2.2.1 Domain Identifier Format for “User Defined “ Plan The "User Defined" Plan is intended for use by Customer Administered equipment. When the Domain Identification Plan indicates usage of the User Defined Identifier, the format of the remaining 4 octets is not subject to standardization. A value of zero may be used as the default value to indicate the last OA&M capable device on the VC.

3.2.2.2 Domain Identifier Format for "OUI" Plan The "OUI" Plan is one of several plans intended for use by Service Providers. When the Domain Identification Plan indicates usage of the OUI Identifier, the format of the remaining 4 octets is created by using a zero byte followed by a 3-octet OUI. OUI Identifiers are assigned and administered by the IEEE.

3.2.2.3 Domain Identifier for "IPv4 Network" Plan The "IPv4" Plan is also intended for use by Service Providers. When the Domain Identification Plan indicates usage of the IPv4 Identifier, the format of the remaining 4 octets is the network portion of a public IPv4 address block owned by the service provider. Public IPv4 addresses are administered by the IETF.

3.2.2.4 Domain Identifier format for “X.121” Plan The "X.121" Plan is also intended for use by Service Providers. When the Domain Identification Plan indicates usage of the X.121 Identifier, the value of the remaining 4 octets are created as follows: • Take X.121 DNIC, as defined in X.76 [7]. • Pad on the left with zeros, as necessary, to 8 octets. • BCD encode the result into 4 octets.

Page 10 April 2007


3.2.2.5 Domain Identifier Format for “E.164” Plan The "E.164" Plan is also intended for use by Service Providers. When the Domain Identification Plan indicates usage of the E.164 Identifier, the value of the remaining 4 octets are created as follows: • Take E.164 Network Identification Field of the Transit Network ID, as defined in X.76. • Pad on the left with zeros, if necessary, to 8 octets. • BCD encode the result into 4 octets.

3.2.2.6 Domain Identifier Format for “Private” Plan When the Domain Identification Plan indicates usage of the Private Domain Identifier, the format of the remaining 4 octets is not subject to standardization.

3.2.3 Source Location Identifier Field The purpose of the Source Location Identifier Field is to uniquely identify the source of an OA&M message with the indicated Administrative Domain. The values used in the Source Location Identifier field must be unique for each administration along the path of a VC. The value of all ones is reserved and may not be used as a Source Location Identifier. The format of this 4-octet field is not subject to standardization.

3.2.4 Destination Location Identifier Field The purpose of the Destination Location Identifier Field is to uniquely identify the destination of an OA&M message with the indicated Administrative Domain, or to indicate a Broadcast Destination. The values used in the Destination Location Identifier field must be unique for each administration along the path of a VC. The value of all ones is used to indicate the global (all destinations) broadcast for the identified administration. The format of this 4-octet field is not subject to standardization.

April 2007 Page 11


3.2.5 OA&M Information Field Format OA&M information fields are self identifying type-length-data entities. Figure 7 depicts the general format of an information field. Each type of information field will be defined in subsequent sections.

Bits 8 7 6 5 4 3 2 1 Octet

I.F. Type (Note 1)

1

Length (Note 2)

2

Data 3

Note 1: Information Field Type values are defined in section 3.2.5.1. Note 2: Length includes Type, Length, and Data sub-fields.

Figure 7 - OA&M Information Field Format

3.2.5.1 I.F. Type Field Values The values for the I.F. Type field of the OA&M Information Field are defined in Table 3 below:

Information Field Type Value

Usage Reference Section

0x01 Capabilities Section 3.3.1.1 0x02 Frame Transfer Delay Section 3.3.1.2 0x03 Frame Transfer Delay Results Section 3.3.1.3 0x04 Frame Delivery Ratio Sync Section 3.3.1.4 0x05 Frame Delivery Ratio Results Section 3.3.1.5 0x06 Data Delivery Ratio Sync Section 3.3.1.6 0x07 Data Delivery Ratio Results Section 3.3.1.7 0x08 Non-Latching Loopback Section 3.3.1.8 0x09 Latching Loopback Section 3.3.1.9 0x0A Diagnostic Indication Section 3.3.1.10 0xB Full Source Address Section 3.3.1.11 0xFE Opaque Section 3.3.1.12 0xFF Pad Section 3.3.1.13

Table 3 - Information Field Type Values

3.2.5.2 Information Field Length The Length field of an Information Field includes the Type, Length, and Data Fields. The value of this field must be in the range of 2 through 255 inclusive.

Page 12 April 2007


3.3 OA&M Information Fields An OA&M message includes one or more information fields.

3.3.1 Per Type Formats of Information Fields The formats and values of the Data field of the OA&M Information Field are dependent upon the Information Field Type.

3.3.1.1 Capabilities Information Field The capabilities information field is used to advertise a willingness to participate in OA&M functions to other OA&M devices within the administrative domain. The format of this field is shown in Figure 8 below:

Bits

8 7 6 5 4 3 2 1 Octet 0 0 0 0 0 0 0 1

Type 1

x x x x x x x x

Length 2

Capability #1 (Note 1, Note 2)

3

Capability #N 3+N

Note 1: Capability field values are multi-octet with the high-order bit used to indicate extension of this capability (high order bit=1 indicates another octet follows for this capability), and are defined in Table 4.

Note 2: The Capabilities I.F. must include the Hello Message capability. All other capabilities are optional.

Figure 8 - Capabilities Information Field Format

Capability Field Value

Length Usage

0x01 (see Figure 9) 5-octet Hello Message (Note 1) 0x02 1-octet Supports Frame Transfer Delay 0x03(see Figure 9) 5-octet Supports Frame Delivery Ratio 0x04 (see Figure 9) 5-octet Supports Data Delivery Ratio 0x05 1-octet Supports Latching Loopback 0x06 1-octet Supports Non-latching Loopback

Table 4 - Capability Information Field Type Values

The single octet capabilities are formatted using an 8-bit value of the capability from Table 4.

April 2007 Page 13


The Hello, Frame Delivery Ratio, and Data Delivery Ratio capabilities use a multi octet format, which provides a maximum-time capability value. The format for these is shown in Figure 9.

Bits

8 7 6 5 4 3 2 1 Octet 1 X X X X X X X

EA Capability Type 1

1 X X X X X X X

EA Capability Value (high order bits) 2

1 X X X X X X X

EA Capability Value (mid-h order bits) 3

1 X X X X X X X

EA Capability Value (mid-l order bits) 4

0 X X X X X X X

EA Capability Value (low order bits) 5

Figure 9 - Multi-octet Capability Format

3.3.1.1.1 Hello Message Capability The Hello Capability uses a 5-octet extended format supporting a 28-bit value. This value indicates the time (in milliseconds) that the transmitting FROMP advertises as the recommended expiration value of the TIMER_HELLO_RX timer.

3.3.1.1.2 Supports FDR Capability The Supports FDR Capability uses a 5-octet extended format capability supporting a 28-bit value. This value, in milliseconds, represents the maximum amount of time that may expire before any of the transmitting FROMP FDR counters (either its Tx and Rx counters) can cycle.

3.3.1.1.3 Supports DDR Capability The Supports DDR Capability uses a 5-octet extended format capability supporting a 28-bit value. This value, in milliseconds, represents the maximum amount of time that may expire before any of the transmitting FROMP DDR counters (either its Tx and Rx counters) can cycle.

Page 14 April 2007


3.3.1.2 Frame Transfer Delay Information Field The frame transfer delay information field is used to measure Frame Transfer Delay (FTD). The format for this information field is shown in Figure 10 below:

Bits 8 7 6 5 4 3 2 1 Octet 0 0 0 0 0 0 1 0

Type 1

0 0 0 0 x 1 1 0

Length 2

Initiator TX Time-stamp (Note 1)

3

Receiver RX Time-stamp (Note 2)

7

Receiver TX Time-stamp (Note 2)

11

Note 1: Time-stamp fields shall be 4 octets in length and represent milliseconds. The value is assumed to be of local significance only.

Note 2: These fields are only present in response to an FTD message. The length of the information field (1110 or 0110) is used to determine if this is the request or response.

Figure 10 - Frame Transfer Delay Information Field Format

April 2007 Page 15


3.3.1.3 Frame Transfer Delay Results Information Field The frame transfer delay results information field is used to return the result of a FTD round-trip measurement. The format for this information field is shown in Figure 11 below:

Bits 8 7 6 5 4 3 2 1 Octet 0 0 0 0 0 0 1 1

Type 1

0 0 0 0 0 1 1 0

Length 2

Calculated Result (Note 1)

3

Note 1: Calculated result is a 4-octet value in milliseconds representing the ONE-WAY FTD determined by a dividing in half the results of the round-trip test measurement initiated by the transmitter of this message.

Figure 11 - Frame Transfer Delay Results Information Field Format

Page 16 April 2007


3.3.1.4 Frame Delivery Ratio Sync Information Field The frame delivery ratio sync information field is used to determine the Frame Delivery Ratio (FDR). The format for this information field is shown in Figure 12 below:

Bits 8 7 6 5 4 3 2 1 Octet 0 0 0 0 0 1 0 0

Type 1

0 0 0 0 1 1 1 0

Length 2

FramesOfferredCommitted 3

FramesOfferredExcess

(See note 1) 7

VC Time

(See note 2) 11

Note 1: Does not include frames in CIR or in excess of CIR+ Excess Burst. Note 2: 4-octet value indicating an approximate time offset (in ms) relative to the counters. This value

must increase in successive polls. Set to zero by initiator to indicate a restart condition. See section 4.4.4

Figure 12 - Frame Delivery Ratio Sync Information Field Format

April 2007 Page 17


3.3.1.5 Frame Delivery Ratio Results Information Field The frame delivery ratio results information field is used to return the result of a FDR measurement. The format for this information field is shown in Figure 13 below:

Bits 8 7 6 5 4 3 2 1 Octet 0 0 0 0 0 1 0 1

Type 1

0 0 0 1 0 0 1 0

Length 2

∆FramesDeliveredCommitted (Note 1)

3

∆FramesDeliveredExcess (Note 1, Note 2)

7

∆FramesLostCommitted (Note 1)

11

∆FramesLostExcess (Note 1, Note 2)

15

Note 1: These fields are 4 octets each. They are be used to deliver the results of a Frame Delivery measurement in the reverse direction.

Note 2: Does not include frames within CIR or in excess of CIR+ Excess Burst.

Figure 13 - Frame Delivery Ratio Results Information Field Format

Page 18 April 2007


3.3.1.6 Data Delivery Ratio Sync Information Field The data delivery ratio sync information field is used to determine the Data Delivery Ratio (DDR). The format for this information field is shown in Figure 14 below:

Bits 8 7 6 5 4 3 2 1 Octet 0 0 0 0 0 1 1 0

Type 1

0 0 0 0 1 1 1 0

Length 2

DataOfferedCommitted 3

DataOfferedExcess (Note 1)

7

VC Time (Note 2)

11

Note 1: Does not include frames within CIR or in excess of CIR+ Excess Burst. Note 2: 4-octet value indicating an approximate time offset (in ms) related to the counters. This value must

increase in successive polls. Set to zero by initiator to indicate a restart condition. See section 4.4.5.

Figure 14 - Data Delivery Ratio Sync Information Field Format

April 2007 Page 19


3.3.1.7 Data Delivery Ratio Results Information Field The data delivery ratio results information field is used to return the result of a DDR measurement. The format for this information field is shown in Figure 15 below:

Bits 8 7 6 5 4 3 2 1 Octet 0 0 0 0 0 1 1 1

Type 1

0 0 0 1 0 0 1 0

Length 2

∆DataDeliveredCommitted

(Note 1) 3

∆DataDeliveredExcess (Note 1, Note 2)

7

∆DataLostCommitted(Note 1) 11

∆DataLostExcess (Note 1, Note 2)

15

Note 1: These fields are 4 octets each. They are used to deliver the results of a Data Delivery measurement in the reverse direction.

Note 2: Does not include frames within CIR or in excess of CIR+ Excess Burst.

Figure 15 - Data Delivery Ratio Results Information Field Format

Page 20 April 2007


3.3.1.8 Non-Latching Loopback Information Field The non-latching loopback information field is used to perform minimally intrusive operational diagnostic actions. The format for this information field is shown in Figure 16 below:

Bits 8 7 6 5 4 3 2 1 Octet 0 0 0 0 1 0 0 0

Type 1

x x x x x x X x

Length 2

Non-Latching Loopback Code (Note 1)

3

Option Data (Note 2)

5

Note 1: Non-Latching Code Values are defined in Table 5. Note 2: Length of this field may be determined from length of the I.F. Option Data may

be present and content is not subject to standardization. Figure 16 - Non-Latching Loopback Information Field Format

Command Value

Usage

0x01 Non-latched Loop Frame Request 0x02 Non-latched Loop Frame Response

Table 5 - Non-Latching Loopback Code Values

April 2007 Page 21


3.3.1.9 Latching Loopback Information Field The latching loopback information field is used to perform service affecting operational diagnostic actions. The format for this information field is shown in Figure 17 below:

Bits 8 7 6 5 4 3 2 1 Octet 0 0 0 0 1 0 0 1

Type 1

0 0 0 0 0 0 1 1

Length 2

Latching Loopback Code (Note 1)

3

Note 1: 1-octet value. Latching Loopback Code Values are defined in Table 6. Figure 17 - Latching Loopback Information Field Format

Command Value

Usage

0x01 Latched Loop Enable Request 0x02 Latched Loop Disable Request 0xFF Latched Loop Denied

Table 6 - Latched Loopback Code Values

Page 22 April 2007


3.3.1.10 Diagnostic Indication Information Field The diagnostic indication information field is used to convey operational information to other OA&M devices. The format for this information field is shown in Figure 18 below:

Bits 8 7 6 5 4 3 2 1 Octet 0 0 0 0 1 0 1 0

Type 1

x x x x x x X x

Length 2

Event Type (Note 1)

3

Event Location (Note 2)

4

Note 1: See Table 7. Note 2: Length and Content of this field is not subject to standardization.

Figure 18 - Diagnostic Indication Information Field Format

Event Type Value

Usage

0x00 VC Latching Loopback Enabled 0x01 VC Latching Loopback Disabled 0x02 Phy down 0x03 Phy up

Table 7 - Event Types for Diagnostic Indication

April 2007 Page 23


3.3.1.11 Full Source Address Information Field The full source address information field may be used by an OA&M device to advertise a more complete identification of the device. This is for use by higher layer management. The format for this information field is shown in Figure 19 below:

Bits 8 7 6 5 4 3 2 1 Octet 0 0 0 0 1 0 1 1

Type 1

x x x x x x x x

Length 2

Address Type (Note 1)

3

Address information 4

Note 1: Address Type values are shown in Table 8.

Figure 19 - Full Source Address Information Field

Address Type Value

Usage

0x01 Clear Text (Null terminated string) 0xCC IPv4 Address (4-octet) 0xFD AESA Identified per X.36 [6] 0xFE E.164 Address per X.36 0xFF X.121 Address per X.36

Table 8 – Address Type Values

Page 24 April 2007


3.3.1.12 Opaque Information Field The opaque information field allows for vendor-specific extensions to the OA&M protocol. An implementation receiving an opaque information field may choose to process or ignore this information field based upon the organizationally unique identifier (OUI) contained in the field. The OUI information field may be repeated within an OA&M message. The format for this information field is shown in Figure 20 below:

Bits 8 7 6 5 4 3 2 1 Octet 1 1 1 1 1 1 1 0

Type 1

x x x x x x x x

Length 2

Organizationally Unique Identifier (OUI) (Note 1)

3

SubCode (Note 2)

6

Vendor-Specific Data (Note 3)

7

Note 1: OUIs are assigned by IEEE. Bit-8 is the most significant bit. Note 2: Content of SubCode field is not subject to standardization. Note 3: Length and contents of Vendor-Specific Data field are not subject to

standardization.

Figure 20 - Opaque Information Field Format

April 2007 Page 25


3.3.1.13 Pad Information Field The pad information field may be used to create an OA&M message with a specific length. The pad information field may be repeated within an OA&M message as needed. The format for this information field is shown in Figure 21 below:

Bits 8 7 6 5 4 3 2 1 Octet 1 1 1 1 1 1 1 1

Type 1

x x x x x x x x

Length (Note 1) 2

Padding (Note 2)

3

Note 1: Length may be from 2-255. Note 2: Contents of the Padding field is not subject to standardization.

Figure 21 - Pad Information Field Format

Page 26 April 2007


4 OA&M Procedures This section describes a set of rules for processing OA&M messages that use the formats described in section 3.

• Section 4.1 describes rules for the encoding and decoding of messages. • Section 4.2 provides the general rules for the processing of OA&M messages. • Procedures to discover peer FROMPs, and advertise capabilities, via the Hello message are covered in

section 4.3. • Service Level Measurement procedures using the Service Verification message are detailed in

section 4.4. • Procedures for the Non-Latching and Latching Loopback messages are in of section 4.5 and 4.6. • Procedures for the Diagnostic Indications message are covered in section 4.7.

4.1 Message Encoding/Decoding Rules Implementations of this IA should process the decoding of messages described in section 3 using the following general rules: • Improprieties in the message header, such as an ill-formed address, should cause the entire message to be

discarded. • Frames with known message types should be passed to the appropriate application for processing if the

application is supported, or should be forwarded without processing if the application is not supported. • An improperly formed Information Field should be ignored,, and the remainder of the message processed. One

example would be any information field with a length of zero or one. • A properly formed, but unknown, Information Field should be ignored and the remainder of the message

processed. • A properly formed Information field with an unexpected length should be ignored and the remainder of the

message processed. • If the last information field is not complete, this field should be ignored, however the remainder of the message

may be processed. OA&M messages passing through a FROMP are not subject to Information Field decoding and should be forwarded intact.

4.1.1 Order of transmission • Throughout this Implementation Agreement, multi-octet values shall be transmitted most significant byte to

least significant byte (MSB) order. • When bits are depicted in the formats, Bit-8 is the Most Significant Bit.

4.1.2 Order of Information Fields Information fields within an OA&M message must be presented in ascending order of information field type values. For example, the capabilities information field, when present, must be the first information field present in the message. Similarly, the pad information field must be the last element when present. Only the Opaque and Pad information fields are allowed to be repeated within an OA&M message.

4.1.3 Usage of Information Fields Each OA&M message must include at least one information field. The maximum number of information fields is limited by MTU size. Information fields are included in an OA&M message dependent upon the message type indicated in the OA&M header. Table 9 defines information fields that may be included for each message type. Fields marked N/A may not

April 2007 Page 27


be used in a message of the indicated message type. A message containing an Information Field that of an unknown Information Field Type, or containing an information field that is not allowed for the indicated message type will be ignored without affecting the processing of subsequent information fields.

I.F. Type Value

Usage Hello Message

Service Verification Message

Latching Loopback Message

Non-Latching Loopback Message

Diagnostic Indication Message

0x01 Capabilities Mandatory N/A N/A N/A N/A 0x02 Frame Transfer Delay N/A Optional N/A N/A N/A 0x03 Frame Transfer Delay Results N/A Optional N/A N/A N/A 0x04 Frame Delivery Ratio Sync N/A Optional N/A N/A N/A 0x05 Frame Delivery Ratio Results N/A Optional N/A N/A N/A 0x06 Data Delivery Ratio Sync N/A Optional N/A N/A N/A 0x07 Data Delivery Ratio Results N/A Optional N/A N/A N/A 0x08 Non-Latching Loopback N/A N/A N/A Mandatory N/A 0x09 Latching Loopback N/A N/A Mandatory N/A N/A 0x0A Diagnostic Indication N/A N/A N/A N/A Mandatory 0x0B Full Source Address Optional N/A N/A N/A N/A 0xFE Opaque Optional Optional Optional Optional Optional 0xFF Pad Optional Optional Optional Optional Optional

Table 9 - Information Fields by Message Type

4.1.4 Counters and Counter Wrap These procedures support the use of various fixed length counters that will wrap (roll over to zero). Implementations of these procedures must support normal counter-wrapping to occur. Computations using these counters take into consideration the maximum value, and upon receiving a lower value in a subsequent message assume the counter has wrapped once.

4.2 General Message Processing General rules for the transmission, reception, and forwarding of OA&M messages are described in this section.

4.2.1 Transmission of Messages A FROMP generating an OA&M message shall always provide valid domain identification, source location identifier, and destination location identifier data in the OA&M message header. The domain identification shall uniquely identify all administrations on the virtual circuit. Service Providers should use their X.121 or E.164 Network Identifiers. The domain identification must be one of the domains for which the transmitting OA&M device is a member. OA&M messages must not use the “all domain broadcast” domain identification plan. The source location identifier must be unique within this domain on this VC. The source location identifier used by a FROMP should be the same on a given VC for all domains. The destination location identifier can either be the global destination identifier (see section 3.2.4), or it can be the source location identifier received in a Hello message from another device (see section 4.3). The global destination address is used only for the Hello message type.

Page 28 April 2007


4.2.2 Reception and Forwarding of Messages OA&M messages arriving at an interface of a FROMP may be discarded, processed, and/or forwarded according to the rules in this section. Figure A - 1 provides an example flow chart depicting the decision-making logic that can be used. A FROMP must distinguish between arriving messages with domain identification matching a domain of which the FROMP is a member, and those that are not. These messages will be referred to as being “in the same domain” and “from a foreign domain” respectively.

4.2.2.1 Arriving OA&M Message From a Foreign Domain A FROMP must forward (local conditions permitting) any messages that do not match its domain identification.

4.2.2.2 Arriving OA&M Messages From Same Domain Messages arriving at an interface of a FROMP that match its domain identification are processed according to the rules of this section. In some cases, the messages are treated differently depending upon whether this FROMP terminates the administrative domain associated with this message.

4.2.2.2.1 Duplicate Location Identifier Detection At any FROMP, a message that contains a Domain Identification and Source Location Identifier that match those of the receiving entity shall be discarded. A FROMP detecting this condition should send an indication of the conflict to the network management layer.

4.2.2.2.2 Arriving at a Non-Boundary Device A FROMP that does not terminate a domain boundary must: • Receive for further processing, and not forward, messages with the same domain identification and a matching

destination location identifier. • Receive for further processing, and forward (subject to congestion), messages with the same domain

identification and the broadcast destination identifier. • Forward (subject to congestion), without receiving for further processing, messages with the same domain

identification and a destination location identifier that is neither matching nor the broadcast identifier.

4.2.2.2.3 Arriving at a Boundary Device A FROMP that does terminate a domain boundary must: • Discard without processing, or forwarding, all messages with the same domain identification that arrive on an

interface that is outside the domain boundary. For example, in Figure 3, for a device at location B1, messages arriving from the direction of location A1 are discarded if domain B is identified. The FROMP may send an indication of the conflict to the device’s network management layer.

• Receive for further processing, and not forward, messages with the same domain and a matching destination location identifier or broadcast location identifier arriving on an interface that is inside the domain boundary.

Discard without processing, or forwarding, all messages with the same domain identification and a destination identifier that is neither matching nor the broadcast identifier arriving on an interface that is inside the domain boundary.

4.2.3 Timers A number of timers are defined in these procedures. These timers are used per Domain/Interface in some cases, and Domain/Interface/Peer in others. Table 10 summarizes these timers, their ranges and defaults.

April 2007 Page 29


Name Purpose Range Default TIMER_HELLO_TX Send Hello Message (Discovery) 15-3600 seconds 900 Seconds TIMER_HELLO_RX Detect Lost Peer (Discovery) 60-14400 seconds 3200 Seconds TIMER_SLV Initiate SLV Measurement(s) 15-3600 seconds 900 Seconds

Table 10 - OA&M Timers

4.3 Hello Message Processing (Device Discovery) Peer FROMPs are discovered when a Hello message is received on the frame relay connection from another OA&M device in the same administrative domain. The Hello message contains information about the peer FROMP’s capabilities and are transmitted periodically based upon the TIMER_HELLO_TX timer.

If a FROMP is in the middle of an administrative domain (not a boundary device), two Hello messages are transmitted; one message towards each VC endpoint. If a FROMP is at the administrative boundary, the Hello messages will only be transmitted on the interface within the domain. Each Hello message applies to a single domain as encoded in the Domain Identification field of the message header. If a FROMP supports multiple domains (e.g., Figure 22 C1/F1) a separate message must be generated for each domain. A device may advertise a different capability set for each domain.

The following functions are provided by the discovery procedure: 1. Association of a FROMP with one or more administrative domains, 2. Association of a FROMP with a specific location identifier for an administrative domain, 3. Advertisement of OA&M capabilities supported by the device, and 4. Support for vendor extensions via the opaque field.

Figure 22 illustrates transmission of the Hello message from a number of hypothetical FROMPs located on the path of a single virtual connection.

Page 30 April 2007


AA

BB

CC

F

A c c e s s N e tw o rkM P M P

DD

F

F F

T ra n s it N e tw o rk M PM P

F

EE

F

F

A c c e s s N e tw o rk M PM P

F

P ro b e P ro b eD T E D T E

D o m a in A

D o m a in B

D o m a in F

D o m a in C D o m a in D D o m a in E

A 1 A 2B 1 B 2

F 1

C 1

F 2

C 2

F 3

D 1

F 4

D 2

F 5

E 1

F 6

E 2

D o m a in Id e n t if ic a t io n /L o c a t io n Id e n t if ie rL e g e n d

M e a s u re m e n t P o in tM e s s a g e s o u rc eM e s s a g e p a th a n d te rm in a t io n

FF

M P M PM P M P

M P

Figure 22 - Example of Hello Messages on a VC with multiple Administrative Domains

Appendix B.1 provides an example of message flows for Hello messages between two peer FROMPS in the same domain.

4.3.1 Sending the Hello Message For each virtual circuit for each domain that this FROMP is participating in, the following procedures apply. Implementations are encouraged to use techniques that prevent bursts of Hello messages from being transmitted.

4.3.1.1 Connection Initialization A FROMP may initiate the discovery process upon establishment of the connection. In the case of PVCs, establishment is indicated when Q.933 [10] signaling status messages report the virtual connection as "active". If the FROMP is positioned at the network-to-network interface then both networks need to report the virtual connection as "active" for the connection to be considered established. In the case of SVCs, establishment is indicated when the Q.933 CONNECT message is received.

Upon initiating the discovery process, the FROMP transmits a Hello message. The message shall be sent with a destination location identifier for the global destination. A FROMP at a domain boundary in a network may not send the Hello message on a segment of the connection that is not part of the domain. For example, location D2 in Figure 22sends a Hello message for Domain D towards location D1 but never towards location E1.

Capabilities advertised via the capabilities information field must remain available for the duration of the frame relay connection. Additional capabilities may be added in subsequent Hello messages (for example due to changes initiated by a higher layer management operation). Once added, the new capabilities must remain available for the duration of the frame relay connection. In the case of multi-octet time intervals advertised in the capabilities information field, the interval may not change in subsequent Hello messages.

April 2007 Page 31


4.3.1.2 Periodic Transmission Interval All FROMPs shall transmit the Hello message periodically. Upon transmitting a hello message for a domain on an interface, the device shall set a timer, TIMER_HELLO_TX.

Transmission of the Hello message may be suspended when the data link connection is not operational. Examples of causes include:

1. a failure of the link integrity verification mechanism, 2. the clearing of the "active" bit, 3. the setting of the "delete" bit, 4. the absence of the data link connection information element.

Transmission of the Hello message should resume upon connection initialization as described in section 4.3.1.1.

4.3.2 Processing the Received Hello Message The received Hello message shall be compared with previously recorded hello messages from this peer on this VC. The timer, TIMER_HELLO_RX, is (re)set for this peer. The Peer provides a recommended value for this timer in the Supports Hello Capability.

4.3.2.1 Discovery of a New Peer Receiving a valid Hello message from a new peer device enables this device to send OA&M messages of message types other than Hello directed towards this new peer. The capabilities listed in this Hello message shall be maintained and honored. OA&M communication to this peer may be initiated immediately upon receipt of a single Hello message from the peer.

4.3.2.2 Previously Recorded Peer Upon receiving a valid Hello message from an existing peer, the contents of the Capabilities Information Field shall be examined for new and/or improved capabilities.

4.3.3 TIMER_HELLO_RX Expiration A time-out algorithm for detecting that an OA&M device is no longer advertising its presence and willingness to participate in OA&M with the Hello message is recommended. It is further suggested that such an algorithm allow for implementations that use variable logic for their TIMER_HELLO_TX value. Upon detecting such a timeout expiration condition, procedures to initiate Service Level Verification measurements should be discontinued.

Page 32 April 2007


4.4 Service Level Verification Message Processing Service Level verification and segment-oriented quality of service measurement is performed by use of the Service Verification message. In most cases, a measurement requires multiple messages to be exchanged between two OA&M peer devices. In some cases, these measurements measure a service parameter in one direction, and a separate independent measurement may be needed in the reverse direction. There are three service measurements supported by the Service Verification message:

• Frame Transfer Delay • Frame Delivery Ratio • Data Delivery Ratio

The three measurements are implemented with independent information fields. These measurements are independent of each other, although in many cases they will be combined in a single message. Appendix B.2 and Appendix B.3 provide an example of message flows for FTD and FDR/DDR.

4.4.1 Sending the Service Verification Message The Service Verification message must be transmitted only using a specific (non-broadcast) destination location. A FROMP must receive at least one Hello message from a peer prior to transmission of a Service Verification message to this location.

4.4.1.1 Periodic Transmission Interval for Measurement Initiations Each type of service measurement may use an independent timer (designated TIMER_SLV_*), or share a single timer (designated TIMER_SLV). At the expiration of any TIMER_SLV, the FROMP may send the Service Verification message. The value of any TIMER_SLV is not subject to standardization. A FROMP must take the received maximum interval from a peer device into account in setting its TIMER_SLV. The recommended default interval for TIMER_SLV is 900 seconds.

4.4.2 Processing the Received Service Verification Message Processing of the received message is entirely dependent upon the information fields present. The presence of these information fields indicates which function(s) are to be performed. Sections 4.4.3, 4.4.4, and 4.4.5 describe procedures based upon the function being performed.

4.4.3 Procedures for Delay Measurement In this procedure, a round-trip delay measurement is made. This measurement is divided in half to obtain the FRF.13 one-way FTD measurement. A Frame Transfer Delay measurement requires a two-way exchange between initiator and receiver FROMPs. The initiator begins the measurement by sending a message with the frame transfer delay information field; the receiver loops the message back after filling in additional time-stamps. Optionally, the initiator may then deliver a copy of the results back to the receiver using the frame transfer delay results information field. This procedure uses the Frame Transfer Delay I.F., the Frame Transfer Results I.F., and the Pad I.F. An example of message flows between the initiator and receiver devices is shown in Figure B - 2.

April 2007 Page 33


4.4.3.1 Delay Initiation On the initiation of a delay measurement, the initiator device transmits the Frame Transfer Delay I.F. using the short form (6 octets). The initiator shall fill in the initiator TX time-stamp with a value representing the time the opening bit of the frame will begin transmission.

4.4.3.2 Delay Turnaround Upon receiving a Frame Transfer Delay I.F. of the short form, the receiver device responds to the initiator with the Frame Transfer Delay I.F. long form (12 octets). The responder shall copy the initiator Tx time-stamp, fill in the responder Rx time-stamp with a value representing the arrival time of the closing bit of the frame, and fill in the responder Tx time-stamp with a value representing the time the opening bit of the frame will begin transmission. This response shall be sent in an OA&M message padded to the same length as was received. The pad information field is available to be used for this purpose.

4.4.3.3 Delay Measurement Upon receiving a Frame Transfer Delay I.F. of the long form, the initiator device shall record a time-stamp with a value representing the arrival time of the closing bit of the frame. Calculation of FTD is performed using the following equation:

FTD = ((Initiator_Rx – Initiator_Tx) – (Responder_Tx – Responder_Rx))/2

4.4.3.4 Delivery of Delay Results Dependent upon provisioning, the initiator device may forward the calculated one-way FTD results to the receiver device using the Frame Transfer Delay Results I.F. Such forwarding may be done immediately, or held for inclusion in the next measurement interval.

4.4.3.5 Error Handling A lost or damaged FTD request or response message can result in a missed measurement period. Implementations may optionally time-out and retransmit to recover the period.

4.4.4 Procedures for Frame Delivery Ratio Measurement In this procedure, a one-way measurement is made of the delivery ratio from the initiator to the receiver. This measurement satisfies the requirements for FDR, FDRc, and FDRe of FRF.13. A complete Frame Delivery Ratio measurement requires multiple exchanges between the initiator and receiver. The beginning of a measurement session requires the initiator to send a sync indication. Measurements may then be made by the initiator sending a second FDR Sync I.F. message to the receiver. This creates a one-way measurement of the parameter. The receiver may send a copy of the results back to the initiator by using the frame delivery results information field. An independent measurement session may also be established in the reverse direction. This procedure uses the Frame Delivery Ratio Sync I.F., and the Frame Delivery Results I.F. An example of message flows between the initiator and receiver devices is shown in Figure B - 3. An example of a method to perform this measurement is shown in Appendix C.

4.4.4.1 Frame Delivery Ratio Initiation The Frame delivery ratio sync I.F. is used to initialize (or re-initialize) an FDR measurement session.

Page 34 April 2007


The initiator of this message shall fill in the VC Time (in milliseconds) to ensure that the receiver interprets the message to indicate a(n) (re-)initialization. A VC Time of zero is used to indicate initiation or re-initialization. The initiator of this message shall also fill in the current counters for this VC (FramesOfferedCommitted and FramesOfferedExcess) prior to this message being transmitted. OA&M messages must be included in these frame counters. When a Frame Delivery Ratio Sync I.F. is received with the VC Time value set to zero or less than the previous received value (taking into account normal counter-wrapping), the receiver shall terminate any previous session and restart a new session. A FROMP receiving this information field (regardless of the VC Time indicated) shall record the receiver frame counts representing the counters for this VC (FramesReceivedCommitted and FramesReceivedExcess) as they were prior to the reception of this frame.

4.4.4.2 Frame Delivery Ratio Measurement The Frame Delivery Ratio Sync I.F. is also used to complete a one-way measurement of the ratio of frames delivered to frames offered. The initiator device of this message shall fill in the current counters for this VC (FramesOfferedCommitted and FramesOfferedExcess) prior to this message being transmitted. When wrapping of the VC Time occurs, the initiator shall ensure that a value of zero is not sent. A FROMP receiving the frame delivery ratio sync I.F. shall record the receiver frame counts representing the counters for this VC (FramesReceivedCommitted and FramesReceivedExcess) as they were prior to the reception of this frame. The value of the VC Time shall be inspected for indications of a restart as described in the previous section. The receiving device shall determine if the recorded maximum interval has been exceeded.

• If the interval has been exceeded, the device shall not use the previous counters to calculate the FDR for the interval terminated by this message. The counters from this poll shall be stored such that the next poll in this measurement session will be valid if it is received within the allowable interval.

• If the interval has not been exceeded, the device shall use these counters to calculate the FDRs for the interval. FDRs for the receive direction are calculated using the following formulae:

∆ FramesOfferedCommitted = FramesOfferedCommitted2 - FramesOfferedCommitted1

∆ FramesOfferedExcess = FramesOfferedExcess2 – FramesOfferedExcess1

∆ FramesDeliveredCommitted = FramesReceivedCommitted2 - FramesReceivedCommitted1

∆ FramesDeliveredExcess = FramesReceivedExcess2 – FramesReceivedExcess1

∆ FramesLostCommitted = ∆FramesOfferedCommitted - ∆FramesDeliveredCommitted

∆ FramesLostExcess = ∆FramesOfferedExcess – ∆FramesDeliveredExcess

FDRC = ∆FramesDeliveredCommitted / ∆FramesOfferedCommitted

FDRE = ∆FramesDeliveredExcess / ∆FramesOfferedExcess

(∆FramesDeliveredCommitted + ∆FramesDeliveredExcess ) FDR = ----------------------------------------------------------------------------------

(∆FramesOfferedCommitted + ∆FramesOfferedExcess )

The device shall record the counters for use by the next “FDR Sync” message.

April 2007 Page 35


4.4.4.3 Delivery of Frame Delivery Ratio Results Dependent upon provisioning, the receiver device may forward the calculated one-way FDR results to the initiator device using the Frame delivery ratio results I.F. Such forwarding may be done immediately, or held for inclusion in the next measurement interval.

4.4.4.4 FDR Error Handling A lost or damaged FDR Sync message may result in one or more missed measurement intervals. If the maximum interval for counter-wrap (advertised by the peer in the capabilities information field) does not expire prior to the next successful FDR Sync message, this next complete measurement will span the period between the two received messages. If the maximum interval for counter-wrap occurs, the next successful FDR Sync message is treated as if it were a restart. In this case, the prior interval(s) are lost and FDR Results shall not be sent.

4.4.5 Procedures for Data Delivery Ratio Measurement In this procedure, a one-way measurement is made of the delivery ratio from the initiator to the receiver. This measurement satisfies the requirements for DDR, DDRc, and DDRe of FRF.13. A complete Data Delivery Ratio measurement requires multiple exchanges between the initiator and receiver. The beginning of a measurement session requires the initiator to send a sync indication. Measurements may then be made by the initiator sending a second DDR Sync I.F. message to the receiver. This creates a one-way measurement of the parameter. The receiver may send a copy of the results back to the initiator by using the frame delivery results information field. An independent measurement session may also be established in the reverse direction. This procedure uses the Data Delivery Ratio Sync I.F., and the Data Delivery Results I.F. An example of message flows between the initiator and receiver devices is shown in Figure B - 3. An example of a method to perform this measurement is shown in Appendix C.

4.4.5.1 Data Delivery Ratio Initiation The data delivery ratio sync I.F. is used to initialize (or re-initialize) a DDR measurement session. The initiator of this message shall fill in the VC Time (in milliseconds) to ensure that the receiver interprets the message to indicate a(n) (re-)initialization. A VC Time of zero is used to indicate initiation or re-initialization. The initiator of this message shall also fill in the current counters for this VC (DataOfferedCommitted and DataOfferedExcess) prior to this message being transmitted. OA&M messages must be included in these data counters. When a Data Delivery Ratio Sync I.F. is received with the VC Time set to zero, or a value less than the previous received value from the initiator, the receiver shall terminate any previous session and restart a new session. A FROMP receiving this information field (regardless of the VC Time indicated) shall record the receiver frame counts representing the counters for this VC (DataReceivedCommitted and DataReceivedExcess) as they were prior to the reception of this frame.

4.4.5.2 Data Delivery Ratio Measurement The Data Delivery Ratio Sync I.F. is also used to complete a one-way measurement of the ratio of octets delivered to octets offered. The initiator device of this message shall fill in the current counters for this VC (DataOfferedCommitted and DataOfferedExcess) prior to this message being transmitted. A FROMP receiving the data delivery ratio sync I.F. shall record the receiver octet counts representing the counters for this VC (DataReceivedCommitted and DataReceivedExcess) as they were prior to the reception of this frame. The value of the VC Time shall be inspected for indications of a restart as described in the previous section.

Page 36 April 2007


The receiving device shall determine if the recorded maximum interval has been exceeded.

• If the interval has been exceeded, the device shall not use the previous counters to calculate the DDR for the interval terminated by this message. The counters from this poll shall be stored such that the next poll in this measurement session will be valid if it is received within the allowable interval.

• If the interval has not been exceeded, the device shall use these counters to calculate the DDRs for the interval. DDRs for the receive direction are calculated using the following formulae:

∆ DataOfferedCommitted = DataOfferedCommitted2 - DataOfferedCommitted1

∆ DataOfferedExcess = DataOfferedExcess2 – DataOfferedExcess1

∆ DataDeliveredCommitted = DataReceivedCommitted2 - DataReceivedCommitted1

∆ DataDeliveredExcess = DataReceivedExcess2 – DataReceivedExcess1

∆ DataLostCommitted = ∆DataOfferedCommitted - ∆DataDeliveredCommitted

∆ DataLostExcess = ∆DataOfferedExcess – ∆DataDeliveredExcess

DDRC = ∆DataDeliveredCommitted / ∆DataOfferedCommitted

DDRE = ∆DataDeliveredExcess / ∆DataOfferedExcess

(∆DataDeliveredCommitted + ∆DataDeliveredExcess ) DDR = -------------------------------------------------------------------------------

(∆DataOfferedCommitted + ∆DataOfferedExcess )

The device shall record the counters for use by the next “DDR Sync” message.

4.4.5.3 Delivery of Data Delivery Ratio Results Dependent upon provisioning, the receiver device may forward the calculated one-way DDR results to the initiator device using the data delivery ratio results I.F. Such forwarding may be done immediately, or held for inclusion in the next measurement interval.

4.4.5.4 DDR Error Handling A lost or damaged DDR Sync message may result in one or more missed measurement intervals. • If the maximum interval for counter-wrap (advertised by the peer in the capabilities information field) does not

expire prior to the next successful DDR Sync message, this next complete measurement will span the period between the two received messages.

• If the maximum interval for counter-wrap occurs, the next successful DDR Sync message is treated as if it were a restart. In this case, the prior interval(s) are lost and DDR Results shall not be sent.

April 2007 Page 37


4.5 Non-Latching Loopback Message Processing Frame Relay OA&M Diagnostics may be performed on a segment of a VC between two OA&M devices belonging to the same domain. There are two forms of diagnostics supported, a latching VC loopback and a non-latching loopback: • The latching form is a service maintenance action that will remove the VC from service. • The non-latching form is used to echo an individual OA&M frame without taking the VC out of service. The Non-Latching Loopback procedures are contained in this section. The procedures for the Latching loopback are in section 4.6. Implementations may send either form of loopback prior to receiving a Hello message. The Non-Latching Loopback message causes only the non-latching loop message itself to be looped back to the initiator. An example of messaging between the initiator and the receiver is shown in Figure B - 4. The Non-Latching Loopback message must be transmitted using a specific (non-broadcast) destination location.

4.5.1 Initiating the Non-latching Loopback Request A FROMP initiates a request for a peer device to perform a non-latching loopback by using the Non-Latching Loopback message with the latched loopback code of the non-latching loopback information field set to request. The length and content of this option data is not subject to standardization.

4.5.2 Processing the Received Non-Latching Loopback Message A FROMP receiving the Non-Latching Loopback message must determine if the message's Domain Identification indicates membership within one of the domains supported at the receiving location and if the message’s Destination Location Indicator indicates this OA&M device.

If the message is addressed for this location and the device supports this capability, then the message is processed. If the non-latching loopback information field indicates a non-latched loopback request, the device must accept the request, and respond with a non-latching loopback message of identical length and content, except that:

1. The message source and destination locations are reversed. 2. The non-latching loopback code of the non-latching loopback information field is set to indicate a

response. If the non-latching loopback information field indicates a non-latched loopback response, the message is terminated.

Page 38 April 2007


4.6 Latching Loopback Message Processing The latched loopback causes all arriving frames on the VC to be looped back towards the transmitter of the latched loopback message. Other VCs passing through this device are not affected. It is a one-way loopback that will not forward received frames further along the VC while the loopback is active. OA&M frames shall not pass through the OA&M device while the loopback is active, however OA&M frames addressed to this device shall be processed (removing from the looped data when appropriate) and responded to (adding to the looped data). This loopback is shown in Figure 23: Receiving OA&M Device

Idle

Discarded

Discarded

Idle

TestFrames

Discarded

Initiating OA&M Device

Figure 23 – VC Latched Loopback

The Latching Loopback message must be transmitted using a specific (non-broadcast) destination location. An example of messaging between the initiator and receiver is given in Figure B - 5.

4.6.1 Initiating the Latching Loopback Request A FROMP initiates a request for a peer device to perform a latching loopback by using the Latching Loopback message with the latching loopback information field set to enable.

4.6.2 Processing the Received Latching Loopback Request A FROMP receiving the Latching Loopback message must determine if the message's Domain Identification indicates membership within one of the domains supported at the receiving location and if the message’s Location Indicator indicates this OA&M device. If the message is not addressed for this location, the message must be forwarded towards the connection terminus.

If the message is addressed for this location and the device supports this capability, then the message is processed.

If the latching loopback information field indicates a latched loopback enable request, the device may either accept the request or reject it. If the request is rejected, the receiver shall respond to the initiator with a Latching Loopback message and latching loopback information field indicating the rejection.

A VC latched loopback is an intrusive action that will disrupt the flow of data on the VC. If the receiving device also supports the Diagnostic Indications message, it must send a Diagnostic Indication message in each direction on the affected VC for each domain that it is a member of (see section 4.7). Such indications should be sent prior to enabling a VC loopback.

If the latching loopback information field indicates a latched loopback disable request, the device must accept the request. If the receiving device also supports the Diagnostic Indications message, it must send a Diagnostic Indication message in each direction on the affected VC for each domain that it is a member of (see section 4.7). Such indications should be sent after disabling a VC loopback.

4.6.3 Clearing a Latched Loopback A FROMP may request a peer to clear a latching loopback condition by issuing a Latching Loopback message with a latching loopback information field with a disable request. This disable request may be sent by any peer in the domain, and from any direction (not only from the peer that initiated the loopback). The loopback may also be cleared by local management action.

April 2007 Page 39


4.7 Diagnostic Indications Message Processing The Diagnostic Indications message is optionally used to signal peer FROMPs with indications of traffic affecting conditions. Devices should not rely upon the presence or absence of a Diagnostic Indications message. The ability of the network to deliver this message may be compromised due to the condition being signaled.

4.7.1 Initiating the Diagnostics Indication Message A FROMP may send the diagnostics indication message when conditions necessitate. The transmitting device may transmit the message to individual destinations or use the broadcast destination address for a given domain. The message shall use the diagnostic indications information field with the appropriate indication. PHY_UP and PHY_DOWN may be used to notify peer FROMPs of a service affecting change detected at the physical interface.

4.7.2 Processing the Received Diagnostic Indications Message A FROMP receiving the Diagnostic Indications message must determine if the message's Domain Identification indicates membership within one of the domains supported at the receiving location and if the message’s Destination Location Indicator indicates this OA&M device (or the broadcast address).

If the message is addressed for this location and the device supports this capability, then the message is processed. The actions to be taken upon reception of the Diagnostic Indications message are not subject to standardization.

Page 40 April 2007


A Appendix – General Receive Procedures (Informative)

The following flow chart is illustrative of a possible implementation for OA&M traffic arriving at an interface. If there is a conflict between this flow chart and the main text, implementations should follow the text.

Match Domain?

Forward(Note 1)

NO YES (unique)

BoundaryCondition? Interface is Inside

the boundaryfor this Domain

Interface is OutsideBoundary

for this Domain

Not ABoundary

for this Domain

MatchDestinationLocation?

BroadcastDestination

Destination

Matches

Destinationdoes not

match

Process MessageForward a copy

andProcess Message

Forward Message

Discard Message(Note 4)

MatchDestinationLocation?

BroadcastDestination

Destination

Matches

Destinationdoes not

match

Process Message Process Message Discard Message(Note 5)

Start

BroadcastDomain


Notes

1 - OA&M devices must forward OA&M messages addressed to foreign domains.2 - Protocol error. It should be blocked.3 - Duplicate Identifier within domain. Logging to higher layer management may be desired.4 - Security Intrusion Error. Logging to higher layer management may be desired.5 - May be due to removal of FROMP from the circuit.

DuplicateSource?

NO

YES


Figure A - 1 - General Receive Procedures

April 2007 Page 41


B Appendix – Message Flows (Informative)

This Appendix contains informational examples of message flows between two peer OA&M devices on a VC. If there is a conflict with the text of the main document, the main document will supersede these examples.

B.1 Discovery The Hello message is sent periodically; it contains the Capabilities I.F. Figure B - 1 below shows this sequence. Note that a subsequent message is allowed to add capabilities, but advertised capabilities are never withdrawn.

Initiator builds'HELLO' message

with supportedOA&M capabilities

Receiver recordsinitiator's capabilities forthis VC in local database

Initiator rebuilds'HELLO' message

with addedOA&M capabilities

Receiver re-recordsinitiator's capabilities forthis VC in local database

Hello time interval(900 seconds

default)Tim

e

Initiator Receiver

Figure B - 1 - Hello Message for Discovery

Page 42 April 2007


B.2 FTD Measurement The FTD measurement can be done periodically. It requires a response as shown in Figure B - 2.

Initiator constructs FTD I.F.using short form, filling in"Initiator TX Time-stamp" Receiver records "Receiver RX Time-

stamp" upon reception of last bit offrame.Receiver constructs FTD I.F. using longform, filling in "Receiver TX Time-stamp".

FTD interval

Initiator records FTD andoptionally sends results.

Tim

e

Initiator Receiver

Lost Message

Optional ResultsReceiver optionally recordsresults.

Initiator constructs FTD I.F.using short form, filling in"Initiator TX Time-stamp"

Response

FTD intervalInitiator constructs FTD I.F.using short form, filling in"Initiator TX Time-stamp" Receiver records "Receiver RX Time-


Measurement

Measurement

Lost Response

Initiator constructs FTD I.F.using short form, filling in"Initiator TX Time-stamp" Receiver records "Receiver RX Time-


Initiator records FTD andoptionally sends results. Optional Results

Receiver optionally records results.

Measurement

Response

FTD interval

Figure B - 2 - Frame Transfer Delay Measurement

April 2007 Page 43


B.3 FDR/DDR Measurement The FDR and DDR measurements may be performed periodically. An example of a FDR sequence is shown in Figure B - 3. The DDR measurement is done in the same fashion.

Initiator FROMP sends'HELLO' messagewith supported FDR capability

Receiver will now process received FDRSync messages

FDR interval

Initiator may commencemeasurement intervalsto this peer

Tim

e

Initiator Receiver

v

Initiator constructs "FDRSync" I.F., filling in currentframe counts

Lost Message

Normal Sync - Responder records countsand calculates FDR Use Rx2 = current rx count Use Tx2 = value from messageCalculate DDR with Rx2-Rx1 and Tx2-Tx1Set Rx1 = Rx2Set Tx1 = Tx2Optionally send results in FDR Result I.F.

Initiator optionally recordsFDR results.



Maximum interval exceeded - Responderrecords counts but doesn't calculate FDR Use Rx1 = current rx count Use Tx1 = value from messageDon't send results

FDR maximum interval(not exceeded)

Normal Sync - Responder records countsand calculates FDR Use Rx2 = current rx count Use Tx2 = value from messageCalculate FDR with Rx2-Rx1 and Tx2-Tx1Set Rx1 = Rx2Set Tx1 = Tx2Optionally send results in FDR Result I.F.


Initiator optionally recordsFDR results.

Optional Results

Optional Results

Sync

Sync

Hello

Sync

Hello

Sync

v

FDR interval

v

v

v

v

FDR maximum interval(exceeded)




Receiver records counts but doesn'tcalculate FDR (as there is no completeinterval) Use Rx1 = current rx count Use Tx1 = value from messageDon't send results

Receiver FROMP sends 'HELLO' messagewith supported FDR capability

Figure B - 3 - FDR and DDR Measurements

Page 44 April 2007


B.4 Non-Latching Loopback An example of the message sequencing for a device using the Non-Latching Loopback message is shown in Figure B - 4.

Initiator constructs non-latching diagnostic message

Initiator Receiver

Echo

Non-Latching

Responder builds echowith same length and data.

Initiator records or announcesreception of response.

Tim

e

Figure B - 4 - Using the Non-Latching Loopback Message

April 2007 Page 45


B.5 Latching Loopback Examples of message sequencing for a device using the Latching Loopback message are shown in Figure B - 5.

Initiator constructs diagnosticlatching loopback messagewith diagnostic latchingloopback I.F. containing aloopback activation request

Receiver refuses to accept latchingloopback request.

Initiator Receiver

Reject Latching

Loopback

Latching LoopbackActivation Request

Initiator constructs latchingloopback request

Latching LoopbackRequest Receiver accepts latching loopbackrequest and optionally sends a diagnosticindications message with a diagnosticstatus I.F. to all domains of which it is amember in each direction on the VCDiagnostic Indication - VC Latching

Loopback Enabled (Domain A)

Receiver activates laching loopback.Traffic received on this VC is loopedback.

Initiator constructs diagnosticlatching loopback messagewith diagnostic latchingloopback I.F. containing aloopback deactivation request

Latching LoopbackDeactivation RequestReceiver deactivates latching loopback

Receiver optionally sends a diagnosticindications message with a giagnosticstatus I.F. to all domains of which it is amember in each direction on the VC.

Diagnostic Indication - VC Latching

Loopback Enabled (Domain B)

Looped Traffic


Loopback Disabled (Domain B)


LoopbackDisabled (Domain A)

Traffic to be looped

Figure B - 5 - Using the Latching Loopback Message

Page 46 April 2007


C Appendix – Example of Delivery Ratio Calculation (Informative)

The method used for obtaining Frame Delivery Ratio and Data Delivery Ratio results depends upon implementation-specific choices beyond the scope of this IA. This Appendix presents one method of obtaining the data to calculate these ratios. Other methods are possible. Frame Relay Service Level Agreements (SLAs) include expectations for Frame Delivery Ratio and Data Delivery Ratio performance. Delivery success ratios are possible for several grades of traffic, as shown in Table C - 1.

Traffic Grade Description

Committed frames transmitted to the network within the CIR

Excess frames transmitted to the network in excess of CIR

Total all frames transmitted to the network.

Table C - 1

This Annex describes a procedure to calculate delivery success ratios for each of the grades using the messages defined by the frame relay OA&M protocol. The procedure evaluates one-way delivery success between two Measurement Points (MP) in a network. The point where the frames enter the network segment is called the ingress MP. The point where the frames exit the network segment is called the egress MP. Refer to Figure C - 1 for a reference diagram of a typical circuit where Location A1 is the ingress MP and Location A2 is the egress MP. The procedure is independently executed for the reverse one-way flow to produce delivery success ratios for both directions. In the example shown in Figure C - 1, Location A2 becomes the ingress MP for the reverse one-way flow.

Frame Relay Network

LocationA2

MP

TrafficSource

TrafficDestination

TrafficSource

TrafficDestination

LocationA1

MP

Frame RelayData LinkConnection

Figure C - 1

April 2007 Page 47


The operation of delivery success measurement occurs in time intervals determined by the ingress MP. The interval starts at T0 following successful completion of the restart procedure (sections 4.4.4.1 and 4.4.5.1) or at the conclusion of the previous interval. Interval duration (Td) is implementation-specific but bounded by counter-wrapping considerations. The egress MP uses received Service Verification messages containing a Frame Delivery Ratio Sync I.F. to detect the interval boundaries following completion of the restart procedure.

The following description of processing is focused on determination of Frame Delivery Ratio results. The technique is applicable to Data Delivery Ratio result calculation with the use of the appropriate Service Verification message information fields.

C.1 Ingress Processing The ingress MP determines the traffic grade of a frame. The method used to assign frames to particular traffic grades is implementation-specific. A discussion of traffic classification is provided in ITU I.370 [2]. This method does not rely upon an indication of the assigned traffic grade of each individual frame to the egress processor. The ingress MP maintains a frame count for each traffic grade. Upon detection of a frame within a given traffic grade, the frame count for that grade is incremented by one. At time Td, a Service Verification message containing a Frame Delivery Ratio Sync Information Field is transmitted from the ingress MP to the egress MP.

The Frame Delivery Ratio Sync I.F. contains two fields: FramesOfferedCommitted and FramesOfferedExcess. The fields contain the frame counts for the corresponding grades. The counts will wrap back to zero periodically, the frequency determined by physical access speed, frame sizes, and frame arrival rates.

C.2 Egress Processing The egress MP counts frames exiting the network during an interval. A single count of total frames exiting the network is maintained, as the frames are NOT identified by Traffic Grade.

Upon receipt of a Service Verification message containing a Frame Delivery Ratio Sync I.F., the egress MP performs the following actions:

1. The running count of total frames exiting the network during the interval is assigned to ∆FramesReceived.

2. The ∆FramesOfferedCommitted Count for the interval is computed by subtracting the value reported by the ingress MP at the end of the last interval from the value reported by the ingress MP in the just received Service Verification message. The calculation must detect and adjust for counter-wrap.

3. The ∆FramesOfferedExcess Count for the interval is computed by subtracting the value reported by the ingress MP at the end of the last interval from the value reported by the ingress MP in the just received Service Verification message. The calculation must detect and adjust for counter-wrap.

4. The Total Lost Frame Count for the interval just ended is calculated as follows:

∆FramesLost = (∆FramesOfferedCommitted + ∆FramesOfferedExcess ) – ∆FramesReceived

5. The counts of committed and excess frames delivered successfully are calculated as follows:

If ∆FramesLost >= ∆FramesOfferedExcess

∆FramesDeliveredExcess = 0

∆FramesDeliveredCommitted = ∆FramesReceived

If ∆FramesLost < ∆FramesOfferedExcess

∆FramesDeliveredExcess = ∆FramesOfferedExcess – ∆FramesLost

∆FramesDeliveredCommitted = ∆FramesOfferedCommitted

6. The Frame Delivery Ratio for the Committed Traffic Grade is calculated as follows:

Page 48 April 2007


FDRcommitted = ∆FramesDeliveredCommitted / ∆FramesOfferedCommitted

7. The Frame Delivery Ratio for the Excess Traffic Grade is calculated as follows:

FDRexcess = ∆FramesDeliveredExcess / ∆FramesOfferedExcess

8. The Frame Delivery Ratio for the Total Traffic Grade is calculated as follows:

FDRtotal = ∆FramesReceived / (∆FramesOfferedCommitted + ∆FramesOfferedExcess)

9. The counts of committed and excess frames lost are calculated as follows:

∆FramesLostCommitted = ∆FramesOfferedCommitted – ∆FramesDeliveredCommitted

∆FramesLostExcess = ∆FramesOfferedExcessd – ∆FramesDeliveredExcess

April 2007 Page 49

Documents

Frame Relay Operations, Administration, and Maintenance ... · FRF.19.1, Frame Relay Operations, Administration, and Maintenance Implementation Agreement Note: The user’s attention