| Network Working Group | S. Geisler |
| Internet-Draft | |
| Intended status: Standards Track | F. Baker |
| Expires: February 27, 2017 | August 26, 2016 |
Optical Device Discovery
draft-geisler-optical-device-discovery-02
This document introduces a method for Optical device discovery, by introducing a new multicast group for frames to be captured by optical nodes.
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 27, 2017.
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.
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. The industry is moving towards Data Center Interconnect options where the transponder, line system and router are completed separated, and could all be different vendors. In this case, end to end provisioning through some vendor specific protocol is not applicable.
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.
The interaction between optical, link and network layer devices has seen many solutions with IPoDWDM and Generalized MPLS (GMPLS). These solutions have introduced a single control plane for all devices through the use of MPLS or integrated transponders. However these solutions have proven troublesome for operators in multi vendor environments, and for large organizations who need the scale of a full optical system, IPoDWDM may not be suited.
Link Management Protocol (LMP) has been identified as a mechanism to solve this, LMP has had limited implementation on DCI devices, with these devices going towards LLDP snooping. The solution outlined in this document differs from LMP, this is covered in . [lmp] This solution aims to capitalize off existing LLDP implementations by alligning closely to is, but is a separated protocol in the interest of freedom to add Optical specific TLVs without hindering LLDP.
The requirement is for a lightweight, minimal configuration protocol, where TLVs are transmitted to a multicast address. Rather than a stateful messaging structure, this draft takes an LLDP approach of putting the information on the wire, and whatever is attached will receive it, unless the functionality is configured to not do so.
With various models and APIs being released by each vendor to configure optical devices, this protocol does not look at configuration of optical devices via routers and switches.
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. It does not propose a unified control plane. 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).
This solution requires an optical device to be able to inject a frame directly into the optical control plane. One way to achieve this is to insert a link layer system before the signals pass through the Digital Signal Processor (DSP) and are muxponded to go out to the colored line side WDM ports.
Whilst Routers listen to an 'all optical nodes' link layer multicast group, optical devices 'listen' by snooping on this multicast address. Every interval an Optical Discovery PDU (ODPDU) frame is sent with TLVs containing information about the sending participant, whether router or optical device. The capability of the sending device is communicated in a TLV in this frame.
Optical and Routers vendors can introduce configuration to:
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 through the DCN.
The router sends an optical discovery frame, which the optical node snoops. It sends a reply frame encapsulated in an IP header to the management IP address included in the management IP address TLV, meaning the IP address is discovered via the TLV and has no need to be configured manually as an 'expected value'. The router then receives this IP encapsulated packet, decapsulates the IP and sees the link layer multicast address in the destination link layer address field. The router processes this frame as a normal discovery frame.
There may be some requirement to send this ODPDUs to a centralized server for processing, to build a full view of the router to optical client port connectivity. The Management IP TLV field can be configured to allow this.
The following configuration options should exist:
TLVs that are sent should be configurable on all device types.
Both routers and optical devices must send the following TLVs:
It should be noted that the port ID must be the port name that is seen on the device, to be compliant. It should not be an SNMP ifindex or any other value.
Optical devices can send an additional Wavelength TLV to represent the wavelength the client port maps to on the line side.
Network devices can send an additional Link aggregation TLV to represent the ethernet aggregation bundle the interface is part of.
There are opportunities to extend the TLVs optical devices sent to communicate:
+------------+------------+------------+------------+------------+ | | | | | | | Chassis | Hostname | Port ID | Port Type | Capability | | Type | | | | TLV | | | | | | | +------------+------------+------------+------------+------------+ +------------+------------+------------+ | | | | | IP Mgmt | Optional | ... | | Address | TLV | | | | | | +------------+------------+------------+
Figure 2: Optical Device Discovery frame structure
RFC4204 [RFC4204] proposes Link Management Protocol (LMP) as a protocol to manage Traffic Engineering (TE) links. LMP verifies connectivity, correlates the link property information, and consolidates alarms for the network.
The differences between the LMP approach and this approach are summarized as follows:
This draft targets the following scenarios and specific use cases:
In future, the discovery mechanism can be moved to a standalone protocol to allow for extensions. Such as:
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.
A revision of this document will require a link layer address reserved.
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.
Both sides must have the feature turned on to discover each other.
| [ctrl-fwk] | IETF, "A framework for Management and Control of DWDM optical interface parameters", 2016. |
| [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. |
| [RFC4204] | IETF, "Link Management Protocol (LMP)", 2005. |
| [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. |