Tunnel OAM Requirements and Considerations

1. Tunnel OAM Requirements and Considerations Nurit SprecherNokia Siemens Networksnurit.sprecher@nsn.com

2. Agenda • OAM definition • Tunnel characteristics • Unified tunnel OAM: • Requirements • Architecture – principles and considerations • Required OAM tools • Conclusion

3. 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 Benchmark set by TDM and other legacy technologies 3

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

5. Tunnel (2) • 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 • * Is this a real case?

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

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

8. 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:

9. Unified Tunnel OAM: Initiative Great initiative! (although it might be better if it were taken before work on MPLS-TP OAM progresses) Hurrah!

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

11. Requirements for Unified Tunnel OAM

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

13. Proposed OAM requirements (2) 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

14. Proposed OAM requirements (3) 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.

15. Proposed OAM requirements (4) Operational requirements: • Ensure unified operational experience. • Support uniform reporting to management systems. • Ensure backward compatibility with existing mechanisms. • Support interoperability with existing mechanisms? • Others?

16. Architecture Principles and Considerations

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

18. Maintenance Domain (2) 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.

19. Maintenance Domain (3) 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?

20. Maintenance Domain (4) 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

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

22. Required OAM Tools

23. Continuity Check and Connectivity Verification 23

24. Proactive fault detection: Continuity and Connectivity Monitoring (CC-V) Functionality: Periodic messages between end points to verify continuity and correct connectivity Misconnection is identified (CC-V is uniquely identified) C Error in forwarding table causes misdirection of packets to second LSP Loss of Continuity Declaration A CC-V A->B CC-V B Two LSPs – (1) purple from A to B, and (2) gray from A to C Can be used to ensure rapid response (e.g. switchover) in the event of a failure. More applicable to connection-oriented based tunnels 24

25. On-demand fault verification and isolation Functionality: Ping the network elements and/or trace the path to identify the location of the fault. On Demand B A Ping Route 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? 25

26. Alarm Notification

27. Link failure detected by server end points Link failure detected by server end points Alarm Reporting sent to end points of all affected tunnels Alarms Reporting sent to end points of all affected tunnels 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 C EP a EP B EP D

28. Failure is NOT identified by transmitting end-point Unidirectional failure Failure IS identified by receiving end-point 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. RDI

29. Diagnostic Testing

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

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

32. Performance Monitoring 32

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

34. Throughput Measurement Functionality: Supports both in-service and out-of-service throughput measurement to verify the bandwidth 34

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

36. Thank You!