tunnel oam requirements and considerations

Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTEI insert classification level © Nokia Siemens Networks

Tunnel OAM Requirements and Considerations

Nurit SprecherNokia Siemens [email protected]

Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks

Agenda

• OAM definition

• Tunnel characteristics

• Unified tunnel OAM:

• Requirements

• Architecture – principles and considerations

• Required OAM tools

• Conclusion


Operation Administration and Management (OAM)

A set of carrier-grade fault management and performance monitoring

capabilities (operating in the data plane) which are appropriate for packet networks

and support the network and services at different nested levels

•Mechanisms for monitoring the network infrastructure which enhance the general behavior

and performance level of the network

•Mechanisms for monitoring the services, enabling rapid response to a failure event and

verifying some of the SLA parameters

3

Benchmark set by TDM and other

legacy technologies


Tunnel (1)

• A tunnel is used to transparently carry multiple client services between two or

more endpoints:

• At the ingress end point of the tunnel, client services are:

• adapted and multiplexed into the tunnel

• encapsulated with the specific tunnel header.

• Intermediate points transparently forward the packets using the tunneling mechanism

and addresses.

• At the egress edge, the tunnel header is removed and the clients’ services are de-

multiplexed and processed appropriately.

• The tunnel can be regarded as a Virtual Link by the client layer.


• Tunnels can be used for different purposes, such as:

• Separation of the service delivery architecture from the underlying SP architecture –

providing scalability, efficiency and security

• Transport of client services over an incompatible delivery network

• Provision of a secure path through an untrusted network

• A tunnel can be one of the following types:

• point-to-point (unidirectional or bidirectional)

• unidirectional

• co-routed or associated* bidirectional

• point-to-multipoint

• multipoint-to-multipoint

Tunnel (2)

* Is this a real case?


Tunnel (3)

• A tunnel can be setup using connection-oriented or connectionless modes of

operation:

• In connection-oriented mode, the tunnel is set up before any data is sent

and the route is predetermined.

• A tunnel may have the following characteristics: QoS parameters, allocated BW,

resiliency capabilities, etc.

• In connectionless mode, packets are sent hop-by-hop without prior

arrangement and without having to ensure that the egress end point

(i.e. recipients) is available and ready to receive data. The route is not

constant and may change according to network convergence events.

• Since packets are forwarded individually and are not dependent on one

another, those associated with a specific tunnel may be transmitted along

different network paths.


Tunnel (4)

• OAM architecture may differ depending on whether a tunnel is operating in

connection-oriented or connectionless mode.

• Some OAM tools may be required more for one mode of operation but less for the

other.

• But, even when operating in connection-oriented mode, is it always necessary to support the entire

set of tools in every service provider’s network? The answer is No!

• However, the mechanisms may be implemented in a unified way, independent of

the tunnel type and mode of operation.

• Examples of tunnels: GRE, IPSEC, IP-in-IP, L2TP, LDP-established MPLS,

MPLS-TE, MPLS-TP, PWs, etc.


Unified Tunnel OAM

• Unified mechanisms and implementations

• Unified OAM frame format

• One operational experience (at least per mode of operation: connection-oriented,

connectionless)

• Smooth interworking between different tunneling technologies

Advantageous and profitable for:


Unified Tunnel OAM: Initiative

Hurrah!

Great initiative!(although it might be better if it

were taken before work on MPLS-TP OAM progresses)


Next steps

• Define requirements

• Define framework and architecture

• Design mechanisms. Consider:

• Compliancy with the requirements, alignment with the framework and architecture

• Optimization for packet environment

• Experience with existing tools. Consider operators’ reports detailing operational

experience with existing tools. Make a careful distinction between functionality and

specific implementation. Reuse functionality as far as reasonably possible.

• Unified operational experience; same look-and-feel

• Frame format definition which (1) can easily be encapsulated in any tunneling

technology, (2) is simple and can be efficiently parsed by HW

• Mechanisms which can be implemented in an efficient and scalable way with minimal

processing time


Requirements for Unified Tunnel

OAM


Proposed OAM requirements (1)

Architectural requirements:

• Support any tunnel type (including future designs) and any connectivity type:

• Any tunnel which is defined by the IETF is in scope . Support any addressing type.

• Support bidirectionality; p2p, p2mp and mp2mp.

• OAM packets should run in-band and share their fate with data packets. It must be

possible to differentiate between OAM packets and data packets.

• It must be possible to operate OAM functions without relying on (1) the way in

which the network is configured or managed, and (2) specific network capabilities

(such as IP functionality).

• Ensure complete separation between OAM operations at the tunnel and client

levels. The tunnel should be regarded as a virtual link by the client layer.

• Ensure that the server layer is completely independent.

12



Architectural requirements (contd.):

• Ensure that the monitoring operation is consistent at different network levels –

end-to-end tunnel, and any segment of a tunnel.

– This may be applicable when a tunnel crosses multiple constituent networks which

belong to disparate organizations/companies, or when there is a particular segment

of the tunnel which may be prone to bad behavior, etc.

• Ensure simple and scalable OAM architecture.

• Ensure secured operations – OAM messages must be received from authorized

points.

13


Functional requirements:

• OAM toolset is required for *:

• Continuity Check and Connectivity Verification – for fault detection and

localization

• Alarm notification (alarm reporting, remote defect indication, client failure

indication)

• Diagnostics (route tracing, loopbacks, path locking)

• Performance monitoring (packet loss and packet delay measurement)

• Smooth OAM interoperability is required between domains implementing

different tunneling technologies.

* The full set of tools can be found later in this presentation.



Operational requirements:

• Ensure unified operational experience.

• Support uniform reporting to management systems.

• Ensure backward compatibility with existing mechanisms.

• Support interoperability with existing mechanisms?

• Others?



Architecture Principles and Considerations


Maintenance Domain (1)

• OAM should work in the context of an OAM maintenance domain which consists of

the following types of maintenance points:

• Two or more OAM endpoints

• Zero or more OAM intermediate points

Depending on the tunnel type and operational requirements, different

addressing types can be used to identify the OAM points.

• OAM maintenance domains can be nested but cannot overlap.



OAM endpoints

• OAM endpoints can (but do not have to) reside at the edges of the tunnel.

They can also deliminate a particular segment of the tunnel.

• A segment of a tunnel can be monitored by creating a sub-layer between the edges

of the segment through which the end-to-end traffic is transmitted, and over which

an OAM maintenance entity is defined.

• OAM endpoints are responsible for activating and controlling the proactive and

on-demand OAM monitoring functionality.

• Depending on the specific OAM message and mode of operation (proactive or on-

demand), messages may be destined to one or more of the peer OAM endpoints or

to an OAM intermediate node.

• OAM endpoints can notify one or more of their peer OAM endpoints of failure.



OAM intermediate points

• When operating in connection-oriented mode, the route of a tunnel is fixed and

its set of intermediate nodes is predetermined.

• Since each OAM intermediate point needs to be configured with information such

as authorization and privilege, not every tunnel’s intermediate node will be required

and authorized to function as an OAM intermediate node.

• When operating in connectionless mode, the intermediate nodes are not fixed

and can change during network convergence.

Can every node function as an OAM intermediate node? How are authorization and

privileges guaranteed?



OAM intermediate points (contd.)

• Any interface along the tunnel can function as an OAM intermediate node.

This may be:

• An ingress or egress interface of a network element, or it may be a network

element by itself

• Targeting an OAM monitoring message at an egress interface of a network

element can help to monitor the behavior of the cross-connect function, i.e. the

behavior of the switch fabric.

• OAM intermediate points are capable of:

• Reacting to OAM packets which have been specifically directed to them, while

forwarding all other OAM packets and ensuring that they receive the same

treatment as data packets forwarded within the tunnel

• Notifying the OAM endpoints of a failure


OAM messages

• In-band control channels should be defined in order to

– allow the OAM messages and data packets to be congruent and receive the same

treatment, and

– ensure that the OAM messages can be differentiated from the data packets.

• An OAM endpoint should direct OAM messages received via the control channels

to the appropriate entity for processing.

• Tunnel alert mechanisms should be used to allow exception handling at OAM

intermediate points to which OAM messages are routed. The messages should be

forwarded to the appropriate entity for processing.

• Depending on the tunnel’s connectivity type, responses to OAM messages can be

sent in-band via the return path or out-of-band using an alternate path.

Note: In multi-link scenarios, OAM messages are only congruent with some of the data

packets.


Required OAM Tools


Continuity Check and Connectivity Verification

23


Proactive fault detection: Continuity and Connectivity Monitoring (CC-V)

Functionality: Periodic messages between end points to verify continuity and correct connectivity

24

Two LSPs – (1) purple from A to B, and (2) gray from A to C

A

C

BCC-VCC-VA->B

Can be used to ensure rapid response (e.g. switchover) in the event of a failure.

More applicable to connection-oriented based tunnels


A B

On-demand fault verification and isolation

25

On Demand

Functionality: Ping the network elements and/or trace the path to identify the location of the fault.

PingRoute Tracing

For multiple sub-layers of the tunneling technology, is it necessary to know the full path over which data is transmitted through the network? Must an end-to-end path provide information on all of the network elements it traverses, even if they are at a different level?

or:

Do we want clear separation between the sub-layers?


Alarm Notification


Failure indications and alarm reporting

Alarm Reporting Functionality: When a fault is identified at the server level, it may be

required to prevent the generation of alarms at higher levels.

Client Fault Indication Functionality: When a client does not support Alarm Reporting and a

failure is identified at the client level, it is necessary to notify the peer OAM endpoint without

setting alarms at the client level?

EP B

EP a

EP C

EP D

Link failure detected by server end points

Alarm Reporting sent to end points of all

affected tunnels

Link failure detected by server end points

Alarms Reporting sent to end points of all affected tunnels


Remote Defect Indication

Functionality: Relevant to unidirectional failures in bi-directional tunnel. Must indicate (include in OAM packets) the existence of a

defect and notify the remote OAM end-point.

Unidirectional failure

Failure is NOT identified by transmitting end-point

Failure IS identified by receiving end-point

RDI


Diagnostic Testing


Lock Instruct and Loopback

Lock Instruct:

• Many diagnostic tests and performance measurement functions need to

be performed “out-of-service”.

• Functionality: Instruct the OAM end point to block the tunnel to data

packets.

• Support both lock and release instructions.

Loopback:

• Many tests may be performed where a single end point sends packets to

an intermediate point (or the far-end end point) and then the packets are

automatically sent back to the source end point.

• Functionality: Instruct the destination point (either intermediate or end) to

return the packets without processing.


Diagnostic Tests

Functionality:

Basic template function to create dummy data packets of varying

sizes and data patterns which may be sent at different rates. Used

to determine effective bandwidth and throughput for a given data

path.


Performance Monitoring

32


Packet Loss Measurement, Delay and Delay Variation Measurement

• Packet Loss Measurement Functionality: Uses packet counters to

determine the number of dropped data packets between the end

points of the path:

• unidirectional from ingress to egress end points

• bidirectional – counters maintained in both directions

• Delay Functionality: Packet delay and packet delay variation

between the OAM end points

• unidirectional – needs to synchronize the time stamps

• bidirectional – uses loopback functionality to determine delay

33


Throughput Measurement

• Functionality: Supports both in-service and out-of-service

throughput measurement to verify the bandwidth

34


Conclusion

• Excellent initiative!

• An agreement must be reached regarding the requirements, and the

framework and architecture supporting unified tunnel OAM operation

must be defined.

• Numerous issues and considerations must be discussed before work on a

specific solution can start.

• Both architecture and operation must be efficient and scalable.

• Existing technologies should be evaluated and their operational

performance should be assessed. Reuse of functionality should be

considered when feasible and efficient.

• Define simple messages which only include the required information, and

which are extensible and can be parsed efficiently in the HW.


Thank You!

tunnel oam requirements and considerations

Documents