Protocol Design¶

This is a work in progress with a demo implementation to illustrate ideas and expectations on a tracing tool for SDN deployments.

Motivation¶

The project has been inspired by a requirements discussion during the TechExchange meeting of the Internet2 in October 2014.

A project charter has been created and shared with the Internet2 SDN workgroup to initiate participation from the community on the expectations from such a troubleshooting tool around the university campuses, particularly, for those deploying any SDN network devices: charter document

Current network troubleshooting tools such as ping, traceroute, and tcpdump help network engineers achieve some insight in conjunction with protocols such as the SNMP in legacy networks. However, deeper visibility into data plane behaviour in SDN may be possible. And, development of troubleshooting tools may address more such visibility of the networks.

Existing `traceroute` Tool¶

The protocol design evolves around the requirements by keeping in mind of the current functionality provided by the traceroute tool. Requirements from TechExchange encompasses a path tracing capability for L2 and above, with multiple domains of networks, and possibly some information on crossing the boundaries between SDN and non-SDN.

We examined the traceroute as a path tracing tool to baseline our goal with the SDNTrace protocol. In this respect, an SDNTrace tool should yield at least as much information as the traceroute tool. We identified many shortcomings of the traceroute tool. A useful presentation on this topic is in the NANOG on October 7, 2014.

SDNTrace Protocol Requirements¶

After identifying major shortcomings of current traceroute, we tried to address them with any opportunities we see may be possible with SDN and other means while addressing the requirements listed in the charter. Below is a high-level wish list on protocol design. However, we were able to only implement part of this list.

We are including the list here for open discussion on future participation:

A hop exists: What identifier do we want to know about the hop? E.g.: IP address, name, MAC, AS number, organization, description, who to call, DPID of the switch, etc., operator-specified stuff (up to the operators of the network)

Processing of probe packets in the data path: Any tracing method will have at least similar limitations to traceroute. In order to increase information about the datapath, a design decision has been made that trace probes will be processed as exception packets in the slow path.

Timestamping - not addressed in this implementation.

Reverse path determination: same routers may have different interface names/identifiers, and the reverse path may actually be physically different.

Multiple domain case: ??

Probes should look like data packets.

Repetitive measurements, sequence numbering of the probe packets, accumulate responses from the hops up to the point at the network. Building resiliency against packet loss in the network.

NTP - synchronize clocks at hops so data probe can be timestamped at hops. Removes the confusion created by the protocol support at tunnel points at MPLS, and the RTT being equal for many hops within the tunnel.

SDNTrace Protocol Design¶

Path is a list of hops on the way to the destination, each hop should be identified at L2 level (identifier: switch id-DPID, network admin tel. no, physical address, name of the device in SNMP, belonging to a domain/service provider)

Optimize/focus on the most common/important cases from our wish list above for this first stab at the protocol design

One domain with SDN devices to be traced for path

L2 and up is to be discovered

All packets to be processed in the CPU through an exception packet handling mechanism

Timestamp, reverse traceroute, hidden box, info about domains on the path, L2 devices - are key in making this better than traceroute: implementation of these elements will be a work in progress.

In essence, the protocol is composed of a probe message that carries the to-be-traced packet as payload.

Protocol messages are:

TraceRequest message (the probe sent by the originator host to the network)
TraceReply message (accumulates the hop object id’s of all nodes on the path of the packet being traced)

The header fields of these packets follow exactly the format of an Ethernet packet with a reserved destination MAC address to identify itself as a packet that needs special handling by the controller.

probe packet format: