Network Working Group R. Hayashi Internet Draft K. Shiomoto Intended Status: Standards Track Expires: January 6, 2011 NTT July 5, 2010 Link Management Protocol extensions for optical plug and play draft-hayashi-ccamp-lmp-pnp-ext-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 6, 2011. Copyright Notice Copyright (c) 2010 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. Hayashi Expires January 6, 2011 [Page 1] Internet-Draft LMP extension for optical PnP July 2010 Abstract Generalized Multiprotocol Label Switching (GMPLS) control plane (c-plane) is expected to reduce operational expenditure (OPEX). Currently we need to, however, manually configure interface addresses of links before we advertise the link-state using a GMPLS routing protocol for an automatic topology discovery mechanism. Especially in Wavelength Division Multiplexing (WDM) networks, there are a number of optical fibers between neighbor nodes, each of which again carries a bunch of wavelength links. It is a tedious task to configure interface addresses of wavelength links between neighbor nodes. In order to suppress the tasks of configuring addresses of wavelength links between neighbor nodes, an optical plug and play (PnP) technique is effective. Optical PnP includes automatic assignment of interface addresses, parameter information exchange between neighbor nodes, database construction, and so on. This document assumes to use extended version of LMP (link management protocol) for information exchange and describes LMP extension necessary for applying to the optical PnP. Table of Contents 1. Introduction.................................................2 2. Requirement..................................................3 3. Proposal: LMP extension......................................4 3.1 Optical Plug and Play with LMP...........................4 3.2 Link Verification extension..............................4 3.2.1 Test message extension .............................4 3.2.2 Omission of BeginVerify/EndVerify synchronization...5 3.3 Extended LMP procedure...................................5 4. Future Plans.................................................7 5. Security Considerations......................................7 6. IANA Considerations..........................................7 7. References...................................................8 7.1 Normative References.....................................8 Author's Addresses..............................................8 1. Introduction Currently we need to manually configure interface addresses of links before we advertise the link-state using a GMPLS [RFC 3945] routing protocol for an automatic topology discovery mechanism. It is a tedious task to configure interface addresses. Additionally, manual configuration is error-prone process. Hayashi Expires January 6, 2011 [Page 2] Internet-Draft LMP extension for optical PnP July 2010 In order to do without the tasks of configuring addresses of TE- links between neighbor nodes, an optical plug and play (PnP) technique will be effective. Optical PnP enables automatic construction of necessary information related to control-plane (c- plane) and data-plane (d-plane) as a trigger of fiber cable injection to an interface. Specifically, optical PnP includes automatic assignment of interface addresses, parameter information exchange between neighbor nodes, database construction, and so on. It eliminates a need for setting lots of parameters manually, which leads to operation labor reduction, configuration mistake avoidance, and fast network construction. This document proposes to use extended version of LMP (link management protocol) [RFC 4204] for optical PnP information exchange. In the optical PnP procedure, extended LMP makes no synchronization with BeginVerify/EndVerify messages and a node sends a Test message immediately after notifying d-plane interface link-up (i.e., a node notifies that a cable is connected to an interface). Moreover, this document proposes to add LOCAL NODE ID object to a Test message in order to identify a node by which a Test message is sent and with which a cable is just connected. 2. Requirement Optical PnP enables automatic construction of c-plane and d-plane as a trigger of cable connection to node interfaces. Specifically, optical PnP includes automatic assignment of interface addresses, parameter information exchange between neighbor nodes, database construction, and so on. Automatic assignment of interface addresses is done when a cable is connected to an interface and a node notifies it (link-up). An interface address is assigned to the interface. TE-link address is also assigned if necessary. Parameter information is exchanged between link-up nodes. Here, parameter information includes node ID which is assigned previously, interface addresses, TE-link addresses, and so on. Extended LMP is used for information exchange. Database including local and remote node information is constructed automatically after PnP information exchange. Nodes advertise local and remote parameters through the c-plane for carrying to all of the network nodes. This document assumes c-plane is either in-band or out-of-band, and interfaces are organized in advance to be used as c-plane or d-plane. Link-up and down should be detected as soon as possible. Additionally, the amount of messages for optical PnP should be as minimum as possible. Hayashi Expires January 6, 2011 [Page 3] Internet-Draft LMP extension for optical PnP July 2010 3. Proposal: LMP extension 3.1 Optical Plug and Play with LMP In order to suppress the tasks of configuring addresses of wavelength links between neighbor nodes, an optical PnP technique is effective. Optical PnP enables automatic construction of necessary information for c-plane and d-plane as a trigger of cable connection to a node interface. LMP is used to exchange information between local and remote nodes necessary for constructing a network. LMP has control channel management procedure and link verification procedure. Control channel management is used to establish control channels between adjacent nodes. This is done by exchanging Config/ConfigAck messages. On the other hand, link verification is used to establish data channels and TE-links between adjacent nodes. Test message is used to check not only regular physical connectivity verification but also whether a cable is just connected between any local and remote node interfaces. 3.2 Link Verification extension This document proposes to extend LMP in order to exchange information as a trigger of link-up. There are two main extensions. One is an addition of LOCAL NODE ID object to a Test message during link-up detection. The other is an omission of BeginVerify/EndVerify messages in link verification process. 3.2.1 Test message extension VERIFY_ID object is used to uniquely identify the Verification process from multiple LMP neighbors and/or parallel Test procedures between the same LMP neighbors. The VERIFY_ID object contains a node-unique value that is assigned by the generator of the BeginVerifyAck message. A node identifies an interface and a node from which a Test message is sent by checking both VRIFY ID and LOCAL INTERFACE ID included in the Test message. Following problems occur when a node tries to identify a PnP neighbor among multiple LMP neighbor nodes. Assumption is that node A exchanges LMP between node B and C for link construction by PnP. Node A receives Test messages from both node B and C, and both Test messages have same description (LOCAL INTERFACE ID=1, VERIFY ID=1). When receiving a Test message, Node A needs to reply a TestStatusSuccess message including LOCAL LINK ID as TE-link information. Node A, receiving same two Test messages, is able to understand these two Test messages come from different nodes and Hayashi Expires January 6, 2011 [Page 4] Internet-Draft LMP extension for optical PnP July 2010 replies TestStatusSuccess messages with different LOCAL LINK ID to each node. A problem is, if Node A receives two Test messages with (LOCAL INTERFACE ID=1, VERIFY ID=1) and (LOCAL INTERFACE ID=2, VERIFY ID=1), respectively, meaning same VERYFY ID and different LOCAL INTERFACE ID, it is impossible for Node A to identify which node sent each Test message. Node A, therefore, does not understand with who a cable is connected, and is not able to assign LOCAL LINK ID for a TestStatusSuccess message. This document proposes to add a LOCAL NODE ID to a Test message in order to identify a node by which a Test message is sent and with which a cable is just connected. Here, Test message to be extended is a one used for PnP procedure. Extension does not apply to Test message used during regular link verification process for physical connectivity verification. ::= 3.2.2 Omission of BeginVerify/EndVerify synchronization For the purpose of LMP procedure defined in [RFC 4204], the number of data channel has to be set in advance. In the network based on optical PnP, the number of data channel to be set up is not known. This means that the setting of data channel in advance is not possible and the timing to finish link verification for data channels as a trigger of link-up is not recognizable. This document proposes not to use BeginVerify/BeginVerifyAck/EndVerify messages. When a node notifies any data channel link-up, it immediately sends a Test message to an LMP neighbor. The omission of BeginVerify/BeginVerifyAck leads to faster link-up detection and identification of PnP neighbors. 3.3 Extended LMP procedure Figure 1 illustrates LMP procedure when links are constructed by optical PnP. First, a cable for one of control channels is connected between two nodes and they detect link-up. After the control channel link-up, procedures for Control Channel Management follow. Messages are transmitted through the control channel. In the Control Channel Management procedure, a Config message is sent from one node to another. And then, corresponding ConfigAck message is replied. After that, hello messages are exchanged periodically. There is no LMP extension in this procedure. Hayashi Expires January 6, 2011 [Page 5] Internet-Draft LMP extension for optical PnP July 2010 After the Control Channel Management procedure, nodes get information necessary to activate control channels such as ccid and node id of both local and remote nodes. Next, a cable for one of data channels is connected between two nodes and they detect link-up. When a data channel link-up is detected, Link Verification procedure follows. LMP messages are transmitted through a corresponding control channel except for a Test message which is transmitted through a data channel. There are extended LMP messages for optical PnP in this procedure. At the beginning, a Test message is sent from one node to another without BeginVerify/BeginVerifyAck exchange. By adding NODE ID to a Test message, with INTERFACE ID in a Test message, a node receiving the Test message recognizes correspondence relationship between its interface which is just link-uped, and adjacent node's interface. After receiving the Test message, corresponding TestStatusSuccess message is replied. Moreover, TestStatusAck message is used to acknowledge receipt of the TestStatusSuccess. When Test, TestStatusSuccess, and TestStatusAck message exchange in one direction finishes, the same messages are exchanged in opposite direction. After the Link Verification procedure, nodes get information necessary to activate data channels such as link id and interface id of both local and remote nodes. When link-up of other control channels or data channels are detected, same procedures work. After these procedures, node configuration is automatically made and network construction is automatically completed. +--------+ +--------+ | Node A | | Node B | +--------+ +--------+ | | | <--------- Control channel link-up --------->| | | | | | ------------- Config message ------------> | | | | <------------- ConfigAck message --------- | | | | -------------- Hello message ------------> | | | | <-------------- Hello message ------------ | | | | | Hayashi Expires January 6, 2011 [Page 6] Internet-Draft LMP extension for optical PnP July 2010 | <---------- Data channel link-up ----------> | | | | | | -------------- Test message --------------> | | | | <--------- TestStatusSuccess message ------> | | | | ---------- TestStatusAck message ---------> | | | | | | <-------------- Test message ------------- | | | | -------- TestStatusSuccess message ------> | | | | <----------- TestStatusAck message ------- | | | Figure 1. Extended LMP procedure in optical PnP. 4. Future Plans Some mechanisms are necessary if interfaces for c-plane or d-plane are chosen among link-up interfaces after optical PnP process. At present, target of optical PnP is in-band interface. To find an out-of-band c-plane interface by optical PnP, some mechanisms are necessary. 5. Security Considerations This document has the same security framework as [RFC 4204]. However, an opportunity of LMP information exchange increases if network infrastructure is constructed by optical PnP based on LMP. Additionally, since no security mechanism may be set when network infrastructure is constructed, careful attention is necessary. 6. IANA Considerations This draft does not currently require any consideration from IANA. Hayashi Expires January 6, 2011 [Page 7] Internet-Draft LMP extension for optical PnP July 2010 7. References 7.1. Normative References [RFC 3945] E. Mannie, "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC 4204] J. Lang, "Link Management Protocol (LMP)", RFC 4204, October 2005. Author's Addresses Rie Hayashi NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585, Japan Email: hayashi.rie@lab.ntt.co.jp Kohei Shiomoto NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585, Japan Email: shiomoto.kohei@lab.ntt.co.jp Hayashi Expires January 6, 2011 [Page 8]