Internet DRAFT - draft-hayashi-ccamp-lmp-pnp-ext
draft-hayashi-ccamp-lmp-pnp-ext
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.
<Extended Test Message> ::= <Common Header> <LOCAL NODE ID>
<LOCAL_INTERFACE_ID> <VERIFY_ID>
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]
