Skip to main content

Optical Device Discovery
draft-geisler-optical-device-discovery-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Sarah Geisler , Fred Baker
Last updated 2016-08-08
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-geisler-optical-device-discovery-00
Network Working Group                                         S. Geisler
Internet-Draft                                                    Google
Intended status: Standards Track                                F. Baker
Expires: February 8, 2017                                  Cisco Systems
                                                          August 7, 2016

                        Optical Device Discovery
               draft-geisler-optical-device-discovery-00

Abstract

   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 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 February 8, 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
   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.

Geisler & Baker         Expires February 8, 2017                [Page 1]
Internet-Draft          Optical Device Discovery             August 2016

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Optical Device Discovery - Direct Injection . . . . . . . . .   4
   3.  Optical Device Discovery - Out of Band  . . . . . . . . . . .   4
   4.  TLVs Introduced . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Future Considerations . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     7.1.  Privacy Considerations  . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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

Geisler & Baker         Expires February 8, 2017                [Page 2]
Internet-Draft          Optical Device Discovery             August 2016

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

Geisler & Baker         Expires February 8, 2017                [Page 3]
Internet-Draft          Optical Device Discovery             August 2016

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:

   o  Turn off this functionality on a per port basis

   o  Turn off globally

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:

   o  The router can set the management IP TLV field in to its own
      management IP address (this is the default)

   o  The router can set the management IP TLV field in to a single IP
      address other than its own.

   o  The router can set the management IP TLV fields in to multiple IP
      addresses, including its own and others.

   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.

Geisler & Baker         Expires February 8, 2017                [Page 4]
Internet-Draft          Optical Device Discovery             August 2016

4.  TLVs Introduced

   The optical device should send the following TLVs:

   o  Platform type, chassis type

   o  Hostname

   o  Port Name

   o  Port Type

   o  Time to live

   o  Capability, eg: DWDM, SONET., Router, Switch

   o  Wavelength client port maps to

   o  Link aggregation information

   o  IP Management Address, one or multiple

   o  Alarms or Conditions (line or client side) affecting that port

   o  Performance monitoring of that port, eg: sent/received CRC errors
      in the optical discovery internal

   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

Geisler & Baker         Expires February 8, 2017                [Page 5]
Internet-Draft          Optical Device Discovery             August 2016

5.  Future Considerations

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

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

   o  Ability for optical nodes to alert a router when the Optical
      Supervisory Channel (OSC) is down, suggesting a fiber cut.

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

Geisler & Baker         Expires February 8, 2017                [Page 6]
Internet-Draft          Optical Device Discovery             August 2016

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

   [RFC4957]  Krishnan, S., Ed., Montavont, N., Njedjou, E., Veerepalli,
              S., and A. Yegin, Ed., "Link-Layer Event Notifications for
              Detecting Network Attachments", RFC 4957,
              DOI 10.17487/RFC4957, August 2007,
              <http://www.rfc-editor.org/info/rfc4957>.

9.2.  Informative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <http://www.rfc-editor.org/info/rfc791>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

Appendix A.  Change Log

   Initial Version:  July 2016

Authors' Addresses

   Sarah Geisler
   Google
   Kirkland, Washington  98033
   USA

   Email: sgeisler@google.com

Geisler & Baker         Expires February 8, 2017                [Page 7]
Internet-Draft          Optical Device Discovery             August 2016

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com

Geisler & Baker         Expires February 8, 2017                [Page 8]