idnits 2.17.1 draft-geisler-optical-device-discovery-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 25, 2016) is 2800 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 345, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1AB' ** Downref: Normative reference to an Informational RFC: RFC 4957 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Geisler 3 Internet-Draft Google 4 Intended status: Standards Track F. Baker 5 Expires: February 26, 2017 August 25, 2016 7 Optical Device Discovery 8 draft-geisler-optical-device-discovery-02 10 Abstract 12 This document introduces a method for Optical device discovery, by 13 introducing a new multicast group for frames to be captured by 14 optical nodes. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on February 26, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Optical Device Discovery - Direct Injection . . . . . . . . . 3 52 3. Optical Device Discovery - Out of Band . . . . . . . . . . . 4 53 4. TLVs Introduced . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Comparisons to Link Management Protocol (LMP) . . . . . . . . 6 55 6. Target Use Cases . . . . . . . . . . . . . . . . . . . . . . 7 56 7. Future Considerations . . . . . . . . . . . . . . . . . . . . 7 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 60 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 63 1. Introduction 65 The specification [IEEE802.1AB] describes for link layer discovery of 66 devices. Whilst this addresses discovery of other link layer and 67 network layer devices in the same subnet. The industry is moving 68 towards Data Center Interconnect options where the transponder, line 69 system and router are completed separated, and could all be different 70 vendors. In this case, end to end provisioning through some vendor 71 specific protocol is not applicable. 73 RFC4957 [RFC4957] identifies the challenge when network attachments 74 change. Optical network operators have similar challenges. There is 75 no view innate to Optical Network Management Systems that allows 76 detection of devices. 78 The interaction between optical, link and network layer devices has 79 seen many solutions with IPoDWDM and Generalized MPLS (GMPLS). These 80 solutions have introduced a single control plane for all devices 81 through the use of MPLS or integrated transponders. However these 82 solutions have proven troublesome for operators in multi vendor 83 environments, and for large organizations who need the scale of a 84 full optical system, IPoDWDM may not be suited. 86 Link Management Protocol (LMP) has been identified as a mechanism to 87 solve this, LMP has had limited implementation on DCI devices, with 88 these devices going towards LLDP snooping. The solution outlined in 89 this document differs from LMP, this is covered in . (Section 5) This 90 solution aims to capitalize off existing LLDP implementations by 91 alligning closely to is, but is a separated protocol in the interest 92 of freedom to add Optical specific TLVs without hindering LLDP. 94 The requirement is for a lightweight, minimal configuration protocol, 95 where TLVs are transmitted to a multicast address. Rather than a 96 stateful messaging structure, this draft takes an LLDP approach of 97 putting the information on the wire, and whatever is attached will 98 receive it, unless the functionality is configured to not do so. 100 With various models and APIs being released by each vendor to 101 configure optical devices, this protocol does not look at 102 configuration of optical devices via routers and switches. 104 In figure 1, the routers with configured would see device information 105 of the other according to specifications, but Add/Drop ROADM A has no 106 way to tell what is connected to the client side ports. The Network 107 Network Management system has no visibility of which optical device 108 it is connected to, or which wavelength it sits on the optical 109 network. This gives operators a very limited view of the network and 110 does not give any view to higher layer software abstractions. In 111 networks where the optical network and IP network are owned by the 112 same provider, discovery of the entire network is useful for 113 operators who must troubleshoot the network end to end, as well as 114 keep track of current connectivity and inventory. 116 +------------+ +---------+ +---------+ +------------+ 117 | | | | | | | | 118 | Router A | | | | | | Router B | 119 | | +-------->| DWDM +-----------+ DWDM | +-------->| | 120 | | |ADD/DROP | |ADD/DROP | | | 121 +------------+ | | | | +------------+ 122 | | | | 123 +---------+ +---------+ 125 Figure 1: DWDM is transparent to Link layer discovery 127 This proposal seeks mutual discovery between two domains. It does 128 not propose a unified control plane. There are two proposals, one 129 that requires packet injection from optical devices, and one that 130 does not assume this functionality and assumes an out of band 131 communication method via the Data Communication Network (DCN). 133 2. Optical Device Discovery - Direct Injection 135 This solution requires an optical device to be able to inject a frame 136 directly into the optical control plane. One way to achieve this is 137 to insert a link layer system before the signals pass through the 138 Digital Signal Processor (DSP) and are muxponded to go out to the 139 colored line side WDM ports. 141 Whilst Routers listen to an 'all optical nodes' link layer multicast 142 group, optical devices 'listen' by snooping on this multicast 143 address. Every interval an Optical Discovery PDU (ODPDU) frame is 144 sent with TLVs containing information about the sending participant, 145 whether router or optical device. The capability of the sending 146 device is communicated in a TLV in this frame. 148 Optical and Routers vendors can introduce configuration to: 150 o Turn off this functionality on a per port basis 152 o Turn off globally 154 3. Optical Device Discovery - Out of Band 156 This solution does not require direct injection but assumes that the 157 router management IP address is fully routed through the management 158 network, such that it is reachable by the optical node through the 159 DCN. 161 The router sends an optical discovery frame, which the optical node 162 snoops. It sends a reply frame encapsulated in an IP header to the 163 management IP address included in the management IP address TLV, 164 meaning the IP address is discovered via the TLV and has no need to 165 be configured manually as an 'expected value'. The router then 166 receives this IP encapsulated packet, decapsulates the IP and sees 167 the link layer multicast address in the destination link layer 168 address field. The router processes this frame as a normal discovery 169 frame. 171 There may be some requirement to send this ODPDUs to a centralized 172 server for processing, to build a full view of the router to optical 173 client port connectivity. The Management IP TLV field can be 174 configured to allow this. 176 The following configuration options should exist: 178 o The router can set the management IP TLV field in to its own 179 management IP address (this is the default) 181 o The router can set the management IP TLV field in to a single IP 182 address other than its own. 184 o The router can set the management IP TLV fields in to multiple IP 185 addresses, including its own and others. 187 4. TLVs Introduced 189 TLVs that are sent should be configurable on all device types. 191 Both routers and optical devices must send the following TLVs: 193 o Platform type, chassis type 195 o Hostname 197 o Port ID 199 o Port Type 201 o Capability, eg: DWDM, SONET, Router, Switch 203 o IP Management Address, one or multiple 205 It should be noted that the port ID must be the port name that is 206 seen on the device, to be compliant. It should not be an SNMP 207 ifindex or any other value. 209 Optical devices can send an additional Wavelength TLV to represent 210 the wavelength the client port maps to on the line side. 212 Network devices can send an additional Link aggregation TLV to 213 represent the ethernet aggregation bundle the interface is part of. 215 There are opportunities to extend the TLVs optical devices sent to 216 communicate: 218 o Alarms or Conditions (line or client side) affecting that port 220 o Performance monitoring of that port, eg: sent/received CRC errors 221 in the optical discovery internal 223 +------------+------------+------------+------------+------------+ 224 | | | | | | 225 | Chassis | Hostname | Port ID | Port Type | Capability | 226 | Type | | | | TLV | 227 | | | | | | 228 +------------+------------+------------+------------+------------+ 230 +------------+------------+------------+ 231 | | | | 232 | IP Mgmt | Optional | ... | 233 | Address | TLV | | 234 | | | | 235 +------------+------------+------------+ 237 Figure 2: Optical Device Discovery frame structure 239 5. Comparisons to Link Management Protocol (LMP) 241 RFC4204 [RFC4204] proposes Link Management Protocol (LMP) as a 242 protocol to manage Traffic Engineering (TE) links. LMP verifies 243 connectivity, correlates the link property information, and 244 consolidates alarms for the network. 246 The differences between the LMP approach and this approach are 247 summarized as follows: 249 o LMP has many message types to verify links, and transmit 250 information, some of which require acknowledgements. This draft 251 has one message type with no acknowledgements. 253 o The LMP defined control channel has a state machine and passes 254 through mutliple states. This draft does not create a control 255 channel, and does not keep state. The frame with appropriate TLVs 256 is simply transmitted with a destination multicast link layer 257 address. 259 o LMP correlates alarms, correlates TE links in the functionality of 260 the protocol. This draft assumes that once the information is 261 available, operators require to use their own tools and automation 262 to use the information how they choose. 264 o Draftdraft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-02 [ctrl-fwk] proposes 265 LMP to adjust the output power of the single channel DWDM 266 interface, implying LMP controling device configuration. This 267 draft proposes purely a discovery and configuration is out of 268 scope and not a requirement for the applicable use cases. 270 6. Target Use Cases 272 This draft targets the following scenarios and specific use cases: 274 o Networks where the transponder, line system, and router are 275 separated, and there is no requirement for integration of control 276 planes. Data Center Interconnect devices are an example of how 277 transponding is beginning to be decoupled from the line system. 279 o Networks where LMP is not supported, or there is no requirement 280 for link management, rather purely device discovery. 282 o Networks where LLDP snooping is supported. This draft recommends 283 to move to Optical discovery rather than using LLDP, which was 284 origionally inteded for link layer systems only. In the event an 285 optical device can send LLDP messages, the network device will see 286 the opposite network device, as well as the optical device. This 287 is not recommended and separating out the network layers is the 288 recommended approach. 290 7. Future Considerations 292 In future, the discovery mechanism can be moved to a standalone 293 protocol to allow for extensions. Such as: 295 o Ability for optical nodes to alert a router when it hits a 296 threshold PreFEC Bit Error Rate, or PostFEC bit errors, so 297 correlation of outages is simplified between the optical and 298 network domains. 300 o Ability for optical nodes to alert a router when the Optical 301 Supervisory Channel (OSC) is down, suggesting a fiber cut. 303 o Ability for optical nodes to alert a router when it is receiving 304 or transmitting Ethernet Cycle Redundancy Check (CRC) errors. 306 This extensions allow operators to see possible line side causes 307 locally on the router. This can lead to Administratively shutting 308 down router ports that are affected due to line side issues, or 309 failing over to more reliable links earlier than without this 310 information. 312 8. IANA Considerations 314 A revision of this document will require a link layer address 315 reserved. 317 9. Security Considerations 319 In situations where long haul transport providers are leasing 10/100G 320 circuits to clients, the proposed solution may cause issues on how 321 providers would handle discovery of other networks. 323 When the client does not want the provider network to discover 324 connectivity, the client can configure port by port, or on a global 325 basis to stop sending optical discovery frames. 327 When the provider network does not want the client IP network to 328 discover its transport network, the optical equipment should have an 329 option implemented by the vendor to configure specific NMS IP 330 addresses that can query this information from the controllers. 332 Both sides must have the feature turned on to discover each other. 334 10. Normative References 336 [ctrl-fwk] 337 IETF, "A framework for Management and Control of DWDM 338 optical interface parameters", 2016. 340 [IEEE802.1AB] 341 IEEE, "Std 802.1AB-2005, "Standard for Local and 342 metropolitan area networks - Station and Media Access 343 Control Connectivity Discovery"", 2005. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 [RFC4204] IETF, "Link Management Protocol (LMP)", 2005. 352 [RFC4957] Krishnan, S., Ed., Montavont, N., Njedjou, E., Veerepalli, 353 S., and A. Yegin, Ed., "Link-Layer Event Notifications for 354 Detecting Network Attachments", RFC 4957, 355 DOI 10.17487/RFC4957, August 2007, 356 . 358 Appendix A. Change Log 360 Initial Version: July 2016 362 Authors' Addresses 364 Sarah Geisler 365 Google 366 Kirkland, Washington 98033 367 USA 369 Email: sgeisler@google.com 371 Fred Baker 372 Santa Barbara, California 93117 373 USA 375 Email: FredBakerSBA@gmail.com