Network Working Group S. Geisler
Internet-Draft Google
Intended status: Standards Track F. Baker
Expires: February 9, 2017 Cisco Systems
August 8, 2016

Optical Device Discovery


This document introduces a method for Optical device discovery, by introducing a new multicast group for frames to be captured by optical nodes.

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 February 9, 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. Introduction

The specification [IEEE802.1AB] describes for link layer discovery of devices. Whilst this addresses discovery of other link layer and network layer devices in the same subnet, optical devices do not have the capability to capture these messages on the client ports to which routers connect. Whilst SDN seeks to allow easy of inventory collection and connectivity discovery, a method of discovery can make this information available to higher software layers.

The interaction between optical and link and network layer devices has seen many solutions with IPoDWDM and Generalized MPLS (GMPLS). These solutions have attempted a single control plane for all devices through the use of MPLS or routing protocols. However these solutions have proven troublesome for operators in multi vendor environments, and assume the presence of IP and MPLS in the network connecting to the optical nodes.

RFC4957 [RFC4957] identifies the challenge when network attachments change. Optical network operators have similar challenges. There is no view innate to Optical Network Management Systems that allows detection of devices.

Some vendors have opted for LLDP snooping to be a solution to this problem. However organizations that wish to have a 'plug and play' approach to optical networking without dedicated operational teams for optical systems may wish this information to be available from link and network layer systems.

A standalone protocol also gives room for extensions for the optical domain to use the discovery protocol to alert link and network layer systems of conditions inthe optical domain, that may affect traffic on the link and network layer, making fault correlation operationally easier between the two domains.

This proposal seeks discovery between two domains to make information to higher SDN abstraction layers easier. It does not propose a unified control plane, but discovery between devices operating at the link layer that are connected to optical transport through the use of .

In figure 1, the routers with configured would see device information of the other according to specifications, but Add/Drop ROADM A has no way to tell what is connected to the client side ports. The Network Network Management system has no visibility of which optical device it is connected to, or which wavelength it sits on the optical network. This gives operators a very limited view of the network and does not give any view to higher layer software abstractions. In networks where the optical network and IP network are owned by the same provider, discovery of the entire network is useful for operators who must troubleshoot the network end to end, as well as keep track of current connectivity and inventory.

+------------+           +---------+           +---------+           +------------+
|            |           |         |           |         |           |            |
|  Router A  |           |         |           |         |           | Router B   |
|            | +-------->|  DWDM   +-----------+  DWDM   | +-------->|            |
|            |           |ADD/DROP |           |ADD/DROP |           |            |
+------------+           |         |           |         |           +------------+
                         |         |           |         |
                         +---------+           +---------+

Figure 1: DWDM is transparent to Link layer discovery

This proposal seeks mutual discovery between two domains to make information to higher SDN abstraction layers easier. It does not propose a unified control plane, but discovery between devices operating at the link layer that are connected to optical transport through the use of. There are two proposals, one that requires packet injection from optical devices, and one that does not assume this functionality and assumes an out of band communication method via the Data Communication Network (DCN).

2. Optical Device Discovery - Direct Injection

This solution requires ability for direct injection of packets into the optical plane from the transponder system the router is connected to. One way to achieve this is to insert a link layer system before the signals pass through the Digital Signal Processor (DSP) and out to the colored line side WDM ports.

Routers and optical devices listen to an 'all optical nodes' link layer multicast group, and receive frames from routers from the attached router, with a destination MAC address the multicast MAC, every interval. This mechanism will allow discovery of routers attached to optical devices, and vice versa.

Optical and Routers vendors can introduce configuration to:

3. Optical Device Discovery - Out of Band

This solution does not require direct injection but assumes that the router management IP address is fully routed through the management network, such that it is reachable by the optical node.

The router sends an optical discovery frame, which the optical node snoops. It sends a reply frame to the management IP address included in the management IP address TLV, through the management network. The router discovers the optical node through an out of band mechanism.

The currently configurations options should exist:

Setting the IP TLV field to an IP address of a centralized management server means the optical nodes will send their connectivity information to a centralized system, which may interpret this information to build a view of the topology.

4. TLVs Introduced

The optical device should send the following TLVs:

The router will send similar TLVs to the TLVs used in the current LLDP standard.

|            |            |            |            |            |
|  Chassis   |  Hostname  |  Port ID   |  Port Type |  Optional  |
|   Type     |            |            |            |     TLV    |
|            |            |            |            |            |

|            |            |
|    ...     |  Optional  |
|            |    TLV     |
|            |            |

Figure 2: Optical Device Discovery frame structure

5. Future Considerations

In future, the discovery mechanism can be moved to a standalone protocol to allow for extensions. Such as:

  • Ability for optical nodes to alert a router when it hits a threshold PreFEC Bit Error Rate, or PostFEC bit errors, so correlation of outages is simplified between the optical and network domains.
  • Ability for optical nodes to alert a router when the Optical Supervisory Channel (OSC) is down, suggesting a fiber cut.
  • Ability for optical nodes to alert a router when it is receiving or transmitting Ethernet Cycle Redundancy Check (CRC) errors.

This extensions allow operators to see possible line side causes locally on the router. This can lead to Administratively shutting down router ports that are affected due to line side issues, or failing over to more reliable links earlier than without this information.

6. IANA Considerations

A revision of this document will require a link layer address reserved.

7. Security Considerations

In situations where long haul transport providers are leasing 10/100G circuits to clients, the proposed solution may cause issues on how providers would handle discovery of other networks.

When the client does not want the provider network to discover connectivity, the client can configure port by port, or on a global basis to stop sending optical discovery frames.

When the provider network does not want the client IP network to discover its transport network, the optical equipment should have an option implemented by the vendor to configure specific NMS IP addresses that can query this information from the controllers.

Basically, both sides must have the feature turned on to discover each other.

7.1. Privacy Considerations

8. Acknowledgements

9. References

9.1. Normative References

[IEEE802.1AB] IEEE, "Std 802.1AB-2005, "Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery"", 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S. and A. Yegin, "Link-Layer Event Notifications for Detecting Network Attachments", RFC 4957, DOI 10.17487/RFC4957, August 2007.

9.2. Informative References

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998.

Appendix A. Change Log

Initial Version:
July 2016

Authors' Addresses

Sarah Geisler Google Kirkland, Washington 98033 USA EMail:
Fred Baker Cisco Systems Santa Barbara, California 93117 USA EMail: