1. Slide 1 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE I insert classification level © Nokia Siemens Networks Tunnel OAM Requirements and Considerations Nurit Sprecher Nokia Siemens Networks nurit.sprecher@nsn.com

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

3. Slide 3 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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

4. Slide 4 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 5 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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?

6. Slide 6 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 7 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 8 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 9 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks Unified Tunnel OAM: Initiative Hurrah! Great initiative! (although it might be better if it were taken before work on MPLS-TP OAM progresses)

10. Slide 10 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 11 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE I insert classification level © Nokia Siemens Networks Requirements for Unified Tunnel OAM

12. Slide 12 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 13 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 14 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Proposed OAM requirements (3)

15. Slide 15 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks Operational requirements: Ensure unified operational experience. Support uniform reporting to management systems. Ensure backward compatibility with existing mechanisms. Support interoperability with existing mechanisms? Others? Proposed OAM requirements (4)

16. Slide 16 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE I insert classification level © Nokia Siemens Networks Architecture Principles and Considerations

17. Slide 17 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 18 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 19 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 20 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 21 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 22 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE I insert classification level © Nokia Siemens Networks Required OAM Tools

23. Slide 23 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE I insert classification level © Nokia Siemens Networks Continuity Check and Connectivity Verification 23

24. Slide 24 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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 B CC-V A->B Can be used to ensure rapid response (e.g. switchover) in the event of a failure. More applicable to connection-oriented based tunnels

25. Slide 25 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. 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?

26. Slide 26 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE I insert classification level © Nokia Siemens Networks Alarm Notification

27. Slide 27 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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

28. Slide 28 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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

29. Slide 29 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE I insert classification level © Nokia Siemens Networks Diagnostic Testing

30. Slide 30 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 31 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 32 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE I insert classification level © Nokia Siemens Networks Performance Monitoring 32

33. Slide 33 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 34 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks Throughput Measurement Functionality: Supports both in-service and out-of-service throughput measurement to verify the bandwidth 34

35. Slide 35 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE © Nokia Siemens Networks 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. Slide 36 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE I insert classification level © Nokia Siemens Networks Thank You!