Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Tunnel OAM Requirements and Considerations Nurit Sprecher Nokia Siemens Networks [email protected] I insert classification level Slide 1 © Nokia Siemens Networks Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE Agenda • OAM definition • Tunnel characteristics • Unified tunnel OAM: • Requirements • Architecture – principles and considerations • Required OAM tools • Conclusion © Nokia Siemens Networks Slide 2 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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 © Nokia Siemens Networks Slide 3 Tunnel OAM/ Nurit Sprecher / October 2010 3 Nokia Siemens Networks / CTO IE PTE 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 demultiplexed and processed appropriately. • The tunnel can be regarded as a Virtual Link by the client layer. © Nokia Siemens Networks Slide 4 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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? © Nokia Siemens Networks Slide 5 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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. © Nokia Siemens Networks Slide 6 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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. © Nokia Siemens Networks Slide 7 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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: © Nokia Siemens Networks Slide 8 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE Unified Tunnel OAM: Initiative Great initiative! Hurrah! (although it might be better if it were taken before work on MPLS-TP OAM progresses) © Nokia Siemens Networks Slide 9 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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 © Nokia Siemens Networks Slide 10 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE Requirements for Unified Tunnel OAM I insert classification level Slide 11 © Nokia Siemens Networks Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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. © Nokia Siemens Networks Slide 12 Tunnel OAM/ Nurit Sprecher / October 2010 12 Nokia Siemens Networks / CTO IE PTE 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. © Nokia Siemens Networks Slide 13 Tunnel OAM/ Nurit Sprecher / October 2010 13 Nokia Siemens Networks / CTO IE PTE 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) * The full set of tools can be found later in this presentation. • Smooth OAM interoperability is required between domains implementing different tunneling technologies. © Nokia Siemens Networks Slide 14 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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? © Nokia Siemens Networks Slide 15 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE Architecture Principles and Considerations I insert classification level Slide 16 © Nokia Siemens Networks Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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. © Nokia Siemens Networks Slide 17 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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 ondemand), 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. © Nokia Siemens Networks Slide 18 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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? © Nokia Siemens Networks Slide 19 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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 © Nokia Siemens Networks Slide 20 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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. © Nokia Siemens Networks Slide 21 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE Required OAM Tools I insert classification level Slide 22 © Nokia Siemens Networks Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE Continuity Check and Connectivity Verification I insert classification level Slide 23 © Nokia Siemens Networks Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 23 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 CC-V A->B 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 © Nokia Siemens Networks Slide 24 Tunnel OAM/ Nurit Sprecher / October 2010 24 Nokia Siemens Networks / CTO IE PTE On-demand fault verification and isolation On Demand Functionality: Ping the network elements and/or trace the path to identify the location of the fault. 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? © Nokia Siemens Networks Slide 25 Tunnel OAM/ Nurit Sprecher / October 2010 25 Nokia Siemens Networks / CTO IE PTE Alarm Notification I insert classification level Slide 26 © Nokia Siemens Networks Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE Failure indications and alarm reporting Link failure detected by server end points Link failure detected by server end points EP C EP a Alarm Reporting sent to end points of all affected tunnels Alarms Reporting sent to end points of all affected tunnels EP B EP D 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? © Nokia Siemens Networks Slide 27 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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. Failure is NOT identified by transmitting end-point Unidirectional failure RDI Failure IS identified by receiving end-point © Nokia Siemens Networks Slide 28 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE Diagnostic Testing I insert classification level Slide 29 © Nokia Siemens Networks Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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. © Nokia Siemens Networks Slide 30 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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. © Nokia Siemens Networks Slide 31 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE Performance Monitoring I insert classification level Slide 32 © Nokia Siemens Networks Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE 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 © Nokia Siemens Networks Slide 33 Tunnel OAM/ Nurit Sprecher / October 2010 33 Nokia Siemens Networks / CTO IE PTE Throughput Measurement • Functionality: Supports both in-service and out-of-service throughput measurement to verify the bandwidth © Nokia Siemens Networks Slide 34 Tunnel OAM/ Nurit Sprecher / October 2010 34 Nokia Siemens Networks / CTO IE PTE 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. © Nokia Siemens Networks Slide 35 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE Thank You! I insert classification level Slide 36 © Nokia Siemens Networks Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTE