Internet DRAFT - draft-janapath-opsawg-flowoam-req
draft-janapath-opsawg-flowoam-req
OPSAWG Working Group Janardhanan Pathangi
INTERNET-DRAFT Balaji Venkat Venkataswami
Intended Status: Proposed Standard DELL
Expires: November 2012 Richard Groves
MICROSOFT
Peter Hoose
FACEBOOK
May 8, 2012
Requirements for OAM tools that enable flow Analysis
draft-janapath-opsawg-flowoam-req-00
Abstract
This document specifies Operations and Management (OAM) requirements
that improve on the traditional OAM tools like Ping and Traceroute.
These requirements have arisen from the fact that more details than
given by Ping and Traceroute are required while troubleshooting or
doing performance and network planning. These requirements have been
gathered from network operators especially from data centers where
the networks have slightly different characteristics compared to
regular campus/carrier networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Janardhanan Pathangi Expires November 2012 [Page 1]
INTERNET DRAFT OAM Reqts. tools that enable flow Analysis May 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Flow tracing . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Fate sharing and actual flow interference . . . . . . . . . 5
2.2.1 Side effects of requirements 2.1 and 2.2 . . . . . . . . 5
2.3 Capability to send the response to a monitoring station . . 6
2.4 Terminating the trace on a transit device . . . . . . . . . 6
2.5 Flow monitoring . . . . . . . . . . . . . . . . . . . . . . 6
2.5.1 Parameters for monitoring . . . . . . . . . . . . . . . 6
2.5.1.1 Time-based and Monitor-till-stop monitoring . . . . 6
2.6 Loop Detection . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 Additional Information . . . . . . . . . . . . . . . . . . 7
2.7.1 Link statistics . . . . . . . . . . . . . . . . . . . . 7
2.7.2 Packet drops and their reasons . . . . . . . . . . . . . 7
2.8 Additional enhancements . . . . . . . . . . . . . . . . . . 7
2.8.1 Fat-Tree traversal. . . . . . . . . . . . . . . . . . . 7
2.8.2 Hash Algorithm Parameters . . . . . . . . . . . . . . . 8
2.9 Future Requirements . . . . . . . . . . . . . . . . . . . . 8
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 8
3.1 Securing Requests and Responses . . . . . . . . . . . . . . 8
3.2 Information hiding . . . . . . . . . . . . . . . . . . . . . 8
3.3 Rate limiting obviating attack vectors . . . . . . . . . . . 9
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 Normative References . . . . . . . . . . . . . . . . . . . 10
5.2 Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Janardhanan Pathangi Expires November 2012 [Page 2]
INTERNET DRAFT OAM Reqts. tools that enable flow Analysis May 2012
Janardhanan Pathangi Expires November 2012 [Page 3]
INTERNET DRAFT OAM Reqts. tools that enable flow Analysis May 2012
1 Introduction
Network operators have traditionally managed IP networks with classic
OAM tools like Ping and Traceroute. Operators typically use Ping to
perform end-2-end connectivity checks, and Traceroute to trace hop-
by-hop path to a given destination. Traceroute is also used to
isolate the point of failure along the path to a given destination.
Also, while these are useful for basic connectivity checks, they are
unable to provide sufficient information about the performance
aspects of a path (e.g. utilization levels).
In current networks especially data center networks, there are a
large number of redundant paths and existing OAM tools are unable to
identify flow specific problems and also do not provide sufficient
information on the various paths which includes performance
characteristics. What is needed is a set of tools that will perform
the OAM functions based on header fields of actual user traffic.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2 Acronyms
OAM Operations and Management
ECMP Equal Cost Multi-Path
LAG Link Aggregation Group
TRILL Transparent Connection of Lots of Links
SPB Shortest Path Bridging
L2 Layer 2
IP Internet Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
IDS Intrusion Detection System
IPS Intrusion Prevention System
ACL Access Control List
ARP Address Resolution Protocol
ICMP Internet Control Message Protocol
Janardhanan Pathangi Expires November 2012 [Page 4]
INTERNET DRAFT OAM Reqts. tools that enable flow Analysis May 2012
2. Requirements
The main requirement is being able to trace the exact path that a
particular flow will take through the network and obtain all relevant
information about the links along that path which provides the
network operator with enough information to troubleshoot a network
failure or quickly obtain performance data about that path.
Increasing number of networks are using multi-path configurations to
improve load-balancing and redundancy in their networks. These multi-
paths could be in the form of ECMP paths offered by the routing
protocols, but also Layer 2 ECMP paths (e.g. via TRILL [RFC 5556] or
SPB [IEEE SPB]) and LAGs between adjacent routers.
2.1 Flow tracing
Ideally, the OAM trace packet should undergo the same processing at
each node as would the actual application flow that is being traced.
The forwarding process in switches and routers typically includes
fields from the L2, IP, and transport (TCP/UDP) headers, to determine
which member of an ECMP or LAG to forward the packet on. The OAM
packets should also contain the flow entropy allowing for the same
processing that a typical data packet would go through.
Current tools like ping and Traceroute do not carry the application
flow information, and hence the path that those packets follow
through the network could differ from the packets of the specific
flow that is of interest.
2.2 Fate sharing and actual flow interference
OAM probes while sharing fate with the actual flow, should not affect
the real application in progress at the time of troubleshooting. The
OAM request originating from the sender should not interfere with the
actual application at the target host Likewise, the OAM response
should not go back to the real application at the originator of the
OAM query.
2.2.1 Side effects of requirements 2.1 and 2.2
To ensure that OAM packets share the same fate as that of the
Application's packets, and yet do not get delivered to the
application, it would be necessary to have an indication in the
packet to distinguish OAM packets from regular application flow
packets. The inclusion of such an indication in the packet should
still result in the formation of a legitimate packet, and should not
trigger security based drops or alarms at intermediate firewalls and
IDS/IPS appliances, due to, say, an incorrect checksum or invalid
Janardhanan Pathangi Expires November 2012 [Page 5]
INTERNET DRAFT OAM Reqts. tools that enable flow Analysis May 2012
fragment headers, that regular data packets would not normally
experience.
It would be useful for the operator to control which class of service
is used by an OAM packet. For example, when measuring one way or
round trip delays, it would be useful to send it in the same class of
service as regular data.
2.3 Capability to send the response to a monitoring station
When tracing the flow from node A to node B, it should be possible to
direct all the response packets to a third node C, which could be a
management station.
2.4 Terminating the trace on a transit device
The tool should have the capability to terminate the trace at a
specific hop specified by an IP address or by specifying a limit on
the number of hops. This helps in segmented tracing, where portions
of the path can be traced.
2.5 Flow monitoring
It should be possible to initiate flow monitoring on one or all of
the intermediate devices, and should have the following capabilities.
2.5.1 Parameters for monitoring
The tool should provide an extensible mechanism by which the
monitoring station can ask for monitoring of certain parameters for
the flow like input rate, packet drops, etc at a given network node.
It should also be possible to request for packet samples for external
monitoring tool to calculate statistics on the flow or interfaces
The requested device may honor the monitoring request based on its
policy, authentication of the requester and also the available
resources on the device. It should be able to indicate back in the
response if and what parts of the monitoring are activated.
The period for which this monitoring is activated could be...
2.5.1.1 Time-based and Monitor-till-stop monitoring
The OAM packet carries a time period and frequency of sampling, and
the requested devices send the samples at the specified frequency for
the specified time period. This could also be overridden by local
policy. In case of the Monitor-till-stop monitoring the OAM packet
will initiate the monitoring at a specific sampling rate. The
Janardhanan Pathangi Expires November 2012 [Page 6]
INTERNET DRAFT OAM Reqts. tools that enable flow Analysis May 2012
monitoring will continue till there is a new request for turning off
the monitoring. A local policy can also override this behavior and
restrict this to a maximum period that is locally defined.
2.6 Loop Detection
The tool should be capable of detecting that OAM packets are being
looped. If this happens the operation should be aborted. Appropriate
heuristics may be considered while implementing this feature.
2.7 Additional Information
Apart from reporting the incoming and outgoing interfaces, it would
be useful for the tool to report on the following
2.7.1 Link statistics
There is a necessity to collect useful information to enable
operators to perform more detailed problem analysis or network
optimization. The operator may need to know the utilization of the
links along the path in addition to the fan-out information. This
information could be for example be used by servers to selec source
ephemeral ports in such a way as to avoid over-utilized links. Also
disparities in LAG members with respect to over-utilization of some
links and under-utilization of others could help the operator to
tweak some of the available parameters or available hash functions
for better load distribution.
2.7.2 Packet drops and their reasons
Packets may get dropped due to a variety of reasons, and the OAM
mechanism should be able to indicate the actual reasons for drop. The
response OAM packet should indicate the error code appropriately for
various reasons why a packet may have been dropped.
2.8 Additional enhancements
Data center networks and applications have specialized needs. To
accomplish this the new tools provide certain additional information
for the data centers such as the following.
2.8.1 Fat-Tree traversal.
The tracing of a fat-tree (i.e. all paths) from the source to the
destination is a very important requirement from modern day
administrators running say a data-center. This could be done within
an administrative boundary and not beyond it.
Janardhanan Pathangi Expires November 2012 [Page 7]
INTERNET DRAFT OAM Reqts. tools that enable flow Analysis May 2012
2.8.2 Hash Algorithm Parameters
When choosing from a set of ECMP links or LAG members it is common
for a hash function to be performed on select header fields. This
hash algorithm is important with respect to which ECMP or LAG member
is chosen to forward the packet on. It would be useful to know which
fields play a part in the computation of this choice. The actual hash
function may be internal to the device and need not be returned since
it may be proprietary to the vendor but the header fields accounted
for in the hash function would provide enough information for the
system / network administrator to vary these parameters in order to
figure out a specific path through which the traffic for a flow or a
set of flows can be engineered.
2.9 Future Requirements
The requirements specified in this document relate to tools for
trouble shooting IP layer connectivity with respect to IP nodes in
the path from source to destination. This draft deals with tracing
the IP nodes such as transit devices and the end target destination.
A future version of this set of requirements would look at tracing
the intermediate network between IP nodes.
3 Security Considerations
This section discusses threats to which these new set of tools might
be vulnerable and discusses means by which those threats might be
mitigated.
The following are some of the security requirements that need to be
adhered to under this framework.
3.1 Securing Requests and Responses
Tool developed under this framework should require mechanisms to
secure the requests and responses. The security provided for these
requests and responses should ensure integrity of these packets and
ensure confidentiality if necessary. An administrator should be able
to select the information that will be sent in insecure messages,
should such secure mechanisms not be available. For example, the set
of information exchanged in that case could be limited to the
information obtainable via traditional Ping and Traceroute.
3.2 Information hiding
There is a concern that tools developed to satisfy the requirements
in this document might allow an external user to probe the detailed
path that a flow takes through a network. To address this the network
Janardhanan Pathangi Expires November 2012 [Page 8]
INTERNET DRAFT OAM Reqts. tools that enable flow Analysis May 2012
operator could associate multiple security levels with the different
types of information that may be included in the response to a
discovery packet coming from a legitimate tool. For example only the
"Next Hop Router" may be marked as publicly accessible information
whereas everything else may be marked as private information. On
receiving a flow discovery request packet originating outside the
local network, only the publicly accessible information should be
included in the response to the originator. However if the request
was originated by a legitimate, known source the device could include
all of the requested information in the response.
The Result and Additional Information types specified in the section
2.7 provide detailed information about the processing of the request
packet and may possibly leak information about the locally configured
policies. The amount of information to be included in these sets of
data should also depend on whether the request was originated from a
legitimate source. The network operator may choose to silently drop
the Flow Discovery Request packet without providing any indication of
the reason for doing so if the request was originated externally.
3.3 Rate limiting obviating attack vectors
Today most network operators throttle conventional OAM traffic (ping
and traceroute, and other ICMP messages) that is serviced by the
device to protect against Denial-of-Service attacks. Such mechanisms
should be employed for OAM packets under this framework for the same
reason.
4 IANA Considerations
This document does not need any consideration from IANA.
It is likely that tools under this framework may require new IANA
assigned protocol ports that signify the specific OAM protocol that
is to be implemented to satisfy such requirements. Tools developed to
satisfy will require such IANA assignments as the needs arise.
4.1 Acknowledgements
The authors would like to thank Ron Bonica for his thorough review
and critique of the traceflow proposal [2]. We also would like to
thank Melinda Shore for her direction and review of the traceflow
proposal which gave rise to this document.
The requirements presented in this document were a result of the
traceflow proposal submitted to the IETF by A. Viswanathan, S.
Krishnamurthy, R. Manur and V. Zinjuvadia.
Janardhanan Pathangi Expires November 2012 [Page 9]
INTERNET DRAFT OAM Reqts. tools that enable flow Analysis May 2012
5 References
5.1 Normative References
[RFC 792] "Internet Control Message Protocol", 2005.
[RFC 5556] "Transparent Interconnection of Lots of Links", May 2009.
[IEEE SPB] "IEEE Shortest path Bridging", IEEE 802.1aq
5.2 Informative References
[1] Zinjuvadia et.al, draft-zinjuvadia-traceflow-02.txt, Internet-
Draft, August 2008
[2] Shane Amante et.al, draft-amante-oam-ng-requirements-01.txt,
Internet-draft, February 2008.
Authors' Addresses
Janardhanan Pathangi,
Dell-Force10,
Olympia Technology Park,
Fortius block, 7th & 8th Floor,
Plot No. 1, SIDCO Industrial Estate,
Guindy, Chennai - 600032.
TamilNadu, India.
Tel: +91 (0) 44 4220 8400
Fax: +91 (0) 44 2836 2446
Email: Pathangi_janardhanan@dell.com
Balaji Venkat Venkataswami,
Dell-Force10,
Olympia Technology Park,
Fortius block, 7th & 8th Floor,
Plot No. 1, SIDCO Industrial Estate,
Guindy, Chennai - 600032.
TamilNadu, India.
Tel: +91 (0) 44 4220 8400
Fax: +91 (0) 44 2836 2446
Email: BALAJI_VENKAT_VENKAT@dell.com
Janardhanan Pathangi Expires November 2012 [Page 10]
INTERNET DRAFT OAM Reqts. tools that enable flow Analysis May 2012
Richard Groves,
Microsoft Corporation,
One Microsoft Way,
Redmond, WA 98052
Email: rgroves@microsoft.com
Peter Hoose,
Facebook,
1600, Willow Rd.,
Menlo Park, CA 94025
Email: phoose@fb.com
Janardhanan Pathangi Expires November 2012 [Page 11]