[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 http://datatracker.ietf.org/drafts/current/.

   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
   (http://trustee.ietf.org/license-info) in effect on the date of

Turaga & Raszuk          Expires March 18, 2017                 [Page 1]

Internet-Draft   draft-turaga-lmap-special-loop-address   September 2016

   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
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  IPv4/IPv6 Special Purpose Loop Addresses  . . . . . . . . . .   4
   5.  Operation of test suite using Special Purpose IP Loop Address   5
   6.  Comparison with stated test requirements  . . . . . . . . . .   6
   7.  Probe size and rate calculation . . . . . . . . . . . . . . .   7
   8.  Probe's QOS marking . . . . . . . . . . . . . . . . . . . . .   7
   9.  Bandwidth Considerations for link under test  . . . . . . . .   7
   10. I2RS and YANG modelling . . . . . . . . . . . . . . . . . . .   7
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   12. Security Considerations . . . . . . . . . . . . . . . . . . .   8
   13. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   8
   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     15.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     15.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Terminology

   o  RTT - Round Trip Time
   o  TTL - Time to Live
   o  BFD - BiDirectional Failure Detection
   o  LFM - Link Fault Management
   o  ICMP - Internet Control Message Protocol

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

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

Turaga & Raszuk          Expires March 18, 2017                 [Page 2]

Internet-Draft   draft-turaga-lmap-special-loop-address   September 2016

   o  Link anomalies may not occur at the same uniform rate or be of the
      same constant and continuous pattern.  This transient
      characteristic maybe a function of load or other temporary
      problems for example transport network over-subscription.
   o  Encountered degradated service behavior may not translate to link
      errors or packet discards on either end of the suspected link
      because the emulated link consisting of multiple independent L2
      segments in the carrier's network.

   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:

   o  Creating hardware or software loops manually - this results in the
      actual link under test to be taken out of service.  Test traffic
      is then sent through the link and based on the results of the
      test, link quality issues are detected.
   o  Regular pings/probes on directly connected links between routers/
      network devices - Depending on the size of the probe packets and
      the rate at which they are sent between the network devices and
      the loss, the link issues are detected.  The issue with this
      approach is that network processor on the router has to process
      all these packets.  This causes an additional processing load on
      the routers.
   o  BFD, IP protocol hellos etc are based on detecting neighbor state
      based on tiny and lightweight hellos.  Such probes were designed
      for fast detection of end-to-end link state events ..  not to
      evaluate link quality.  If say N hellos send in T interval are
      lost it is an indication about link or peer down event.
   o  The layer 2 OAM tools are not capable of addressing the
      requirements since by definition an emulated link consists of
      number of different L2 links hidden by the emulation layer and its
      encapsulation.  L2 OAM could only indicate potential problems
      within single layer 2 link.  They are light weight and some of
      these issues can only be detected at various levels of data rates
      (within agreed SLAs) transiting via such links.

3.  Requirements

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

   o  The testing should be atomic in nature - the UUT in this document
      is a single p2p link.
   o  The test should not be subject to any alterations by externally
      injected packets
   o  The probe packets should never be able to transit L3 node to any
      other L3 node

Turaga & Raszuk          Expires March 18, 2017                 [Page 3]

Internet-Draft   draft-turaga-lmap-special-loop-address   September 2016

   o  The level of diagnostics data should be configurable such that
      operator is able to inject anywhere from 0.1% to 100% of test load
      of a given max link capacity with build in automatic consideration
      of existing average of production traffic load (unless link is
      considered as taken out-of-service).
   o  The duration of the test traffic should be either configurable by
      the operator or controlled by built-in detection heuristics.
   o  The frequency of the test traffic should be either configurable by
      the operator or controlled by built-in detection heuristics.
   o  Probes should not be subject to process switching by the route
      processors on either end of the link during the burst.
   o  The solution should strive to minimize amount of required protocol
      extensions for as easy as possible inter-operability
   o  In the topologies where Link Aggregation is used, the aggregated
      bandwidth of the link should be considered instead of the
      individual links.  The probe accounting should be recorded as
      total of all link members.  Probe's hashing should follow normal
      data plane load balancing rules as configured on the directly
      connected peering routers.

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

Turaga & Raszuk          Expires March 18, 2017                 [Page 4]

Internet-Draft   draft-turaga-lmap-special-loop-address   September 2016

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

   The following is considered as a high level description of proposed

   o  Two routers R1 and R2 connected together by link L1
   o  Average RTT between R1 and R2 on link L1 is 5ms
   o  R1 and R2 have IP connectivity with each other on
      numbered link.  R1 has been configured with IP an address of and R2 has been configured with an IP address of
   o  For the purpose of a test an IP loop address is configured on R1
      and R2 to create local link loops.  For the purpose of this
      illustration the loop address has been named as L.O.O.P/32

   The following IPv4 packet has been injected from R1:

   o  Source IP address:
   o  Destination IP address: L.O.O.P
   o  TTL = 254
   o  payload optional ... (to be discussed by WG)

   Test sequence:

   o  Packet arrives at R2 and TTL is decremented following by
      destination IP lookup and re-injection towards R1
   o  Packet keeps looping till the TTL expires on R1.
   o  Upon TTL expiration an ICMP TTL EXPIRED error message is being
      sent to the source of the original packet (  The ICMP
      message contains the header information of the original packet


   o  A test probe packet has been amplified 254 times for a short time
   o  An ICMP TTL expired message is indicative that result of the test
      can be described as: probe packets were not dropped
   o  No ICMP TTL message implies that one copy of the original packet
      was lost while it was looping between two routers.  No reception
      of ICMP TTL indicates potential issues with the link provided that
      test sequence was assured never exceed agreed SLAs for a given
   o  Ability to send multiple packets of different sizes on the link
      with inherently controlled TTL loop can results in expected burst
      of control/probe traffic on the link under test
   o  Such probe burst can be programmed to get to a certain % of the
      link speed for a short time

Turaga & Raszuk          Expires March 18, 2017                 [Page 5]

Internet-Draft   draft-turaga-lmap-special-loop-address   September 2016

   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:

   o  Provides means to potentially fill up the part of link bandwidth
      very rapidly due to inherent amplification especially with high
      initial TTL value.  The fill level of the test traffic is a
      function of: Initial packet size (higher the packet size the
      higher the fill level), Initial TTL value (higher the TTL value,
      higher the multiplicative factor for packets and hence higher the
      fill level), Initial number of packets sent (the more the packets
      sent the more the fill level) and MTU of the probe packets.
   o  Test can be run together with production traffic.  There is no
      impact on production traffic neither there is any requirement to
      stop production traffic in order to perform the test.
   o  The amplification of the packets and looping happens as a part of
      inherent forwarding in the routers.  This solution does not
      require a special process in software or hardware to send the test
      probes between the two routers as special purpose loop address
      would be part of standard FIB tables.
   o  This mechanism is light-weight and does not require any new
      software implementations.  Potential for local vendor's

Turaga & Raszuk          Expires March 18, 2017                 [Page 6]

Internet-Draft   draft-turaga-lmap-special-loop-address   September 2016

      optimizations however is still there in the area of segmenting TTL
      equal zero errors of probes from other transit uses of TTL equal
      zero errors or in the space of result presentation to the

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

Turaga & Raszuk          Expires March 18, 2017                 [Page 7]

Internet-Draft   draft-turaga-lmap-special-loop-address   September 2016

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,

Turaga & Raszuk          Expires March 18, 2017                 [Page 8]

Internet-Draft   draft-turaga-lmap-special-loop-address   September 2016

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, <http://www.rfc-editor.org/info/rfc4291>.

Authors' Addresses

   Partha Turaga
   Bloomberg LP
   731 Lexington Ave
   New York City, NY  10022

   Email: pturaga@bloomberg.net

   Robert Raszuk
   Bloomberg LP
   731 Lexington Ave
   New York City, NY  10022

   Email: robert@raszuk.net

Turaga & Raszuk          Expires March 18, 2017                 [Page 9]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/