Upload
katen
View
34
Download
0
Embed Size (px)
DESCRIPTION
Tunnel OAM Requirements and Considerations. Nurit Sprecher Nokia Siemens Networks [email protected]. Agenda. OAM definition Tunnel characteristics Unified tunnel OAM: Requirements Architecture – principles and considerations Required OAM tools Conclusion. - PowerPoint PPT Presentation
Citation preview
Slide 1 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]
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
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
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.
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?
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.
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.
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:
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)
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
Slide 11 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTEI insert classification level © Nokia Siemens Networks
Requirements for Unified Tunnel
OAM
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
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
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)
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)
Slide 16 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTEI insert classification level © Nokia Siemens Networks
Architecture Principles and Considerations
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.
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.
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?
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
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.
Slide 22 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTEI insert classification level © Nokia Siemens Networks
Required OAM Tools
Slide 23 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTEI insert classification level © Nokia Siemens Networks
Continuity Check and Connectivity Verification
23
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
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
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.
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?
Slide 26 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTEI insert classification level © Nokia Siemens Networks
Alarm Notification
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
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
Slide 29 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTEI insert classification level © Nokia Siemens Networks
Diagnostic Testing
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.
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.
Slide 32 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTEI insert classification level © Nokia Siemens Networks
Performance Monitoring
32
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
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
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.
Slide 36 Tunnel OAM/ Nurit Sprecher / October 2010 Nokia Siemens Networks / CTO IE PTEI insert classification level © Nokia Siemens Networks
Thank You!