Transcript G.8032 Ethernet Ring Protection

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