Network Working Group P. Turaga
Internet-Draft R. Raszuk
Intended status: Standards Track Bloomberg LP
Expires: March 18, 2017 September 14, 2016

Special Loop Address


This document describes a method for automatic detection of link quality issues between two devices connected together by any standard link in an IP based network. This document focuses on inline detection in any network attached device (ie server, router, switch etc..)

Requirements Language

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].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

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."

This Internet-Draft will expire on March 18, 2017.

Copyright Notice

Copyright (c) 2016 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 ( 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. Terminology

2. Introduction

Real time monitoring of WAN or MAN link quality presents a real operational challenge. The common use of circuit emulation techniques by carriers makes detection of the circuits degradation difficult. Very often such reduced link quality results in increased queuing times or packet drops beyond SLA guarantees. Furthermore, the characteristics of link degradation is different from link to link.

The problem space described above is further complicated due to the following reasons:

Currently available tools on the circuit endpoints (usually routers) do not allow easy way to diagnose circuit health. Tools used today to detect link issues include:

3. Requirements

The following are some of the key considerations required to be addressed in an alternative diagnostics solutions:

4. IPv4/IPv6 Special Purpose Loop Addresses

The mechanism for the set of proposed requirements can be constructed by combining two standards based protocol elements: TTL field processing and special purpose IPv4 or IPv6 loop addresses.

Special purpose loop address will allow to setup a scoped link based loop and TTL field can be used to limit the loop duration.

The special purpose loop address for this purpose can be subset of the link local range - 169.254/16 for IPv4 [RFC 3927] or FE80::/64 for IPv6 [RFC 4291] or it could be taken from an alternative pool if IETF process suggests so. Selected and allocated special purpose loop address would be therefor kept and maintained by IANA IPv4 or IPv6 Special-Purpose Address Registries.

Routers must not forward any packets with loop source or destination addresses to links other then the link packet arrived on.

The IPv4/IPv6 loop address MAY BE associated with numbered IP addresses for the given link or with link local addresses. The resolution to MAC address of L2 rewrites would be resolved locally through corresponding L3 adjacency addresses.

IPv4/IPv6 test packet is directed towards L3 neighbor with even TTL value.

5. Operation of test suite using Special Purpose IP Loop Address

The following is considered as a high level description of proposed solution:

The following IPv4 packet has been injected from R1:

Test sequence:


Based on fine tuned testing scenario allowing to fill the bandwidth up to a certain % of link capacity the count of packets originally sent by router R1 should be the same as the number of ICMP TTL expired messages. If the count of packets originally sent by router is the same as the number of ICMP TTL expired messages then the test is successful. If however the number of ICMP TTL expired messages is less than the count of packets originally sent by the router then the test is unsuccessful proving potential problems with the link.

A test probe packet with even initial TTL value will generate a TTL time expired ICMP message on the originating router. A test probe packet with odd initial TTL value will generate a TTL time expired ICMP message on the neighboring router. It is RECOMMENDED that the test probe is sent with even initial TTL value. So, ICMP messages are not traversing the link under test.

It is RECOMMENDED that a special payload structure is used for these test probes with sequence numbers. When the TTL expires and an ICMP message is generated, the IP header + 64 bits from original packet gets copied to ICMP message [RFC792]. This can be used for associating the ICMP message and the test.

The MTU of the test probes can be adjusted up to maximum MTU value of the link. Fragmentation of probe packets SHOULD be avoided.

6. Comparison with stated test requirements

Analysis of the proposed solution against the actual new test methodology requirements:

7. Probe size and rate calculation

Initial packet size and rate are important to determine the test fill level for the link. The test packet loops the same number of times as the original TTL value of the original packet. The time it takes for the original packet to come back to the original router is the RTT (Round Trip Time) value between two routers.

Under the assumptions that: RTT of link under test is 1ms, link speed 1 Gb/s, packet size of test packet is 1536 bytes, TTL on original packet is set to 254, would result in the test packets looping for 254 ms.

Under the above assumptions it is easy to calculate that in order fill 1 Gb/s link to 100% 81 such probe packets need to be injected. Likewise in order to fill such link to 20% of its capacity 16 probe packets are required.

8. Probe's QOS marking

Since injected test packets are regular IP packets they can be marked with any class of service. As a result the test probes similar to actual data will be processed based on the real QoS configuration and will be subject to treatment defined for a given packet class.

That allows both prioritization as well as de-prioritization of a given set of test probes.

9. Bandwidth Considerations for link under test

The payload of the test packets can be of any IP protocol.

The link fill levels is also a function of Inter-packet gap of the test and the RTT of that link. Deterministic fill levels can only be derived by accounting for RTT of the link under test.

10. I2RS and YANG modelling

It is expected that link testing methodology described in this document will be accessible by I2RS channel as well as extensions to YANG models will be defined for both setting and retrieval of the data.

11. IANA Considerations

This document requires IANA to allocate and maintain following Special Purpose IP Addresses:

IPv4 Special Purpose Loop Address and maintain it the IANA IPv4 Special-Purpose Address Registry [RFC5735]

IPv6 Special Purpose Loop Address and maintain it the IANA IPv6 Special-Purpose Address Registry [RFC5156]

12. Security Considerations

While the proposed mechanism does not define any new protocols nor protocol extensions of already existing specifications it does relay on the TTL-expiry notifications.

Such notifications must be enabled and must not be limited in any way for the specific class of probe packets.

It is highly recommended that test destinations LOOP addresses are not routeable beyond their locally attached links. Using IPv4/IPv6 special purpose loop addresses will address that.

13. Contributors

Authors would like to thank Truman Boyes and Leo Pang for their valuable input.

14. Acknowledgments

15. References

15.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, DOI 10.17487/RFC5156, April 2008.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", RFC 5735, DOI 10.17487/RFC5735, January 2010.

15.2. Informative References

[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006.

Authors' Addresses

Partha Turaga Bloomberg LP 731 Lexington Ave New York City, NY 10022 USA EMail:
Robert Raszuk Bloomberg LP 731 Lexington Ave New York City, NY 10022 USA EMail: