Internet DRAFT - draft-geisler-optical-device-discovery
draft-geisler-optical-device-discovery
Network Working Group S. Geisler
Internet-Draft Google
Intended status: Standards Track F. Baker
Expires: February 26, 2017 August 25, 2016
Optical Device Discovery
draft-geisler-optical-device-discovery-02
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 26, 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 26, 2017 [Page 1]
Internet-Draft Optical Device Discovery August 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Optical Device Discovery - Direct Injection . . . . . . . . . 3
3. Optical Device Discovery - Out of Band . . . . . . . . . . . 4
4. TLVs Introduced . . . . . . . . . . . . . . . . . . . . . . . 5
5. Comparisons to Link Management Protocol (LMP) . . . . . . . . 6
6. Target Use Cases . . . . . . . . . . . . . . . . . . . . . . 7
7. Future Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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. 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 . (Section 5) 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
Geisler & Baker Expires February 26, 2017 [Page 2]
Internet-Draft Optical Device Discovery August 2016
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).
2. Optical Device Discovery - Direct Injection
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.
Geisler & Baker Expires February 26, 2017 [Page 3]
Internet-Draft Optical Device Discovery August 2016
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:
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 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:
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.
Geisler & Baker Expires February 26, 2017 [Page 4]
Internet-Draft Optical Device Discovery August 2016
4. TLVs Introduced
TLVs that are sent should be configurable on all device types.
Both routers and optical devices must send the following TLVs:
o Platform type, chassis type
o Hostname
o Port ID
o Port Type
o Capability, eg: DWDM, SONET, Router, Switch
o IP Management Address, one or multiple
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:
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
Geisler & Baker Expires February 26, 2017 [Page 5]
Internet-Draft Optical Device Discovery August 2016
+------------+------------+------------+------------+------------+
| | | | | |
| Chassis | Hostname | Port ID | Port Type | Capability |
| Type | | | | TLV |
| | | | | |
+------------+------------+------------+------------+------------+
+------------+------------+------------+
| | | |
| IP Mgmt | Optional | ... |
| Address | TLV | |
| | | |
+------------+------------+------------+
Figure 2: Optical Device Discovery frame structure
5. Comparisons to Link Management Protocol (LMP)
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:
o LMP has many message types to verify links, and transmit
information, some of which require acknowledgements. This draft
has one message type with no acknowledgements.
o The LMP defined control channel has a state machine and passes
through mutliple states. This draft does not create a control
channel, and does not keep state. The frame with appropriate TLVs
is simply transmitted with a destination multicast link layer
address.
o LMP correlates alarms, correlates TE links in the functionality of
the protocol. This draft assumes that once the information is
available, operators require to use their own tools and automation
to use the information how they choose.
o Draftdraft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 [ctrl-fwk] proposes
LMP to adjust the output power of the single channel DWDM
interface, implying LMP controling device configuration. This
draft proposes purely a discovery and configuration is out of
scope and not a requirement for the applicable use cases.
Geisler & Baker Expires February 26, 2017 [Page 6]
Internet-Draft Optical Device Discovery August 2016
6. Target Use Cases
This draft targets the following scenarios and specific use cases:
o Networks where the transponder, line system, and router are
separated, and there is no requirement for integration of control
planes. Data Center Interconnect devices are an example of how
transponding is beginning to be decoupled from the line system.
o Networks where LMP is not supported, or there is no requirement
for link management, rather purely device discovery.
o Networks where LLDP snooping is supported. This draft recommends
to move to Optical discovery rather than using LLDP, which was
origionally inteded for link layer systems only. In the event an
optical device can send LLDP messages, the network device will see
the opposite network device, as well as the optical device. This
is not recommended and separating out the network layers is the
recommended approach.
7. 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.
8. IANA Considerations
A revision of this document will require a link layer address
reserved.
Geisler & Baker Expires February 26, 2017 [Page 7]
Internet-Draft Optical Device Discovery August 2016
9. 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.
Both sides must have the feature turned on to discover each other.
10. Normative References
[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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4204] IETF, "Link Management Protocol (LMP)", 2005.
[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>.
Appendix A. Change Log
Initial Version: July 2016
Geisler & Baker Expires February 26, 2017 [Page 8]
Internet-Draft Optical Device Discovery August 2016
Authors' Addresses
Sarah Geisler
Google
Kirkland, Washington 98033
USA
Email: sgeisler@google.com
Fred Baker
Santa Barbara, California 93117
USA
Email: FredBakerSBA@gmail.com
Geisler & Baker Expires February 26, 2017 [Page 9]
