Internet Draft Network Working Group Internet Draft <draft-koay-mpls-and-optical-00.txt> Expiration Date: May 2001 Helena Koay Yangguang Xu Lucent Nov. 2000 Automatic Neighbor Discovery for Optical Network <draft-koay-mpls-and-optical-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This I-D presents a procedure for performing Automatic Neighbor Discovery (AND)in optical only network. The protocol and message sequence diagram are provided. H. Koay, Y. Xu Expires May 2001 [Page 1] Internet Draft draft-koay-mpls-and-optical-00.txt Nov. 2000 1. Introduction In-fiber J0 neighbor discovery can help nodes automatically configure the primary control channels via LAN or Line DCC. For link connections between the same nodeID pairs, if neighbor's IP address is not reachable via LAN, enable Line DCC for the link connections with the lowest nodeID and portID. This document describes the automatic discovery of physical (transmission) link connections between Neighbor Nodes in an optical only network as well as in a SONET/SDH only network. The discovery is based on in-band communication as well as out-of-band communication between the nodes. For unidirectional links in an optical only network, the discovery of neighbors is done in two parts; an in-band identification signal (IDSIG) is sent with an out-of-band identification response (IDRESP) to the originator when the IDSIG is received. For bidirectional links in SONET/SDH, the IDSIG and IDRESP are sent in-band via the same physical media. The user is not involved in providing the neighbor end-point of a link connection to the local node. Once the neighbor's nodeID and portID has been discovered, the concatenated value can be used as the expected section trace identifier string. If the fiber is recabled to a different port, the trace identifier mismatch notification can be raised. 1.1 Scope of Document Requirements in this document will address the automatic discovery of neighbors via -- SONET/SDH overhead section trace J0 byte -- SONET/SDH overhead line DCC bytes 2. Automatic Physical Neighbor Discovery Automatic discovery of the physical neighbor by each network element (NE) refers to discovering the other end of a transmission link connection in terms of the neighbor's nodeID (and/or network address) and the neighbor's portID. 2.1 Network Control Neighbors Neighbors of interest to Network Controller are those NEs running the Network Control software and that have a switching capability. Regenerators are of no interest to Network Control and therefore should not to be discovered. 2.2 PortID Needed There is a general problem in accurately determining link connections. If the User does not manually type in the link information, NEs sharing more than one physical link with each other, cannot unambiguously determine the connectivity unless a data link message is exchanged in-band, over each shared link. H. Koay, Y. Xu Expires May 2001 [Page 2] Internet Draft draft-koay-mpls-and-optical-00.txt Nov. 2000 2.3 Bidirectional vs. Unidirectional Link Connections Link connections in a SONET/SDH network are bidirectional i.e. one pair of transmitting and receiving lasers from one port on one NE will be physically connected to a pair of receiving and transmitting lasers on the same other port, on another NE or the same NE. Link connections in an optical Network can be categorized as unidirectional link connections, where an optical transmitter can be installed for a unidirectional application but the corresponding optical receiver is not installed until there is a need for a bidirectional application. While unidirectional link connections allow for more optimal configurations (multicast/ video applications), the discovery of the end nodes of a link connection is more complex and up to twice as much information may be generated for the neighbor (transmit and receive neighbor id). [D]neighbor-portID information = local portID, neighbor portID, neighbor nodeID, directionality (Transmit, Receive, Bidirectional[default]). For unidirectional links, the discovery of neighbors is done in two parts; an in-band identification signal (IDSIG) is sent with an out-of-band identification response (IDRESP) to the originator when the IDSIG is received. The response can be sent via an in-band channel if one is available but an out-of-band channel has to be provided if the in-band channel is not available. The neighbor discovery is dependent on the availability of a robust out-of-band signaling channels. For bidirectional links, the IDSIG and IDRESP are sent in-band via the same physical media. This leads to a simpler and faster neighbor discovery procedure, without using the signalling channels for the IDRESP. The neighbor's IP address can be used to automatically set up a signalling channel between the two nodes. 3. In-band Physical Media This document proposes that the physical media used for neighbor discovery be via the J0 or DCC bytes in the SONET/SDH overhead bytes. The merits of using either type of overhead byte will be discussed. 3.1 Line DCC-MS Line DCC or Multiplex-section DCC are the D4-D12 bytes in the overhead of a SONET or SDH frame respectively. Being in the line or multiplex-section overhead, they are passed thru repeaters in the span. Hence, DCC-MS should be used for neighbor discovery when the link connection contains section terminating regenerators. SDH customers should already be familiar with enabling multiplex-section DCC for management traffic (ITU-T G.784 10/98). In this standard, Line DCC-MS is recommended for routing management traffic and for communication between two SONET/SDH line/MS terminating nodes when regenerators are in the span. H. Koay, Y. Xu Expires May 2001 [Page 3] Internet Draft draft-koay-mpls-and-optical-00.txt Nov. 2000 3.2 Section DCC-RS Section DCC or regenerator-section DCC are the D1-D3 bytes in the overhead of a SONET or SDH frame respectively. The section overhead bytes are terminated by regenerators. Since regenerators are not Network Control nodes, Section DCC-RS can be used only if there are no regenerators in the span. 3.3 J0 Section Trace Byte The SONET J0 section trace byte is one byte in the SONET section overhead which is repeated every 64th count, while the SDH J0 trace byte is one byte in the SDH regenerator section overhead which is repeated every 16th count. This allows a 64 byte message to be embedded in the SONET J0 trace byte and a 16 byte message in the SDH J0 trace byte. The J0 byte provides the operator a way to manually verify if node A is indeed connected to node B, by inserting a string at the upstream NE and extracting the (hopefully) same string at the downstream NE of a link connection. Using the J0 byte to automatically discover the neighboring node is still a consistent use of the J0 byte with the added benefit of freeing the User from being involved in verifying a neighbor link connection. The User no longer needs to manually (an error prone activity) enter section trace identifiers at each of the end points; instead, the User can view the neighbor information for actual fiber connectivity. Like the Section DCC-RS bytes, the J0 section trace byte can be used only if no regenerators are in the span. In addition, not every NE has the capability to process J0 bytes. On the other hand, one major advantage of using the J0 byte over the section DCC bytes is that it is a more efficient use of the overhead bytes for discovering the neighbor; one byte instead of 3 or 9 bytes. This reduces the need to enable DCC channel processing for every transmission link connection; very often the NE has much fewer DCC processing ports than transmission links. H. Koay, Y. Xu Expires May 2001 [Page 4] Internet Draft draft-koay-mpls-and-optical-00.txt Nov. 2000 3.4 Neighbor Discovery Strategy +------------------------------------------------------------------------------+ | Strategy for Neighbor Discovery | | | | | | | | V | | Bidirectional Link Connection? | | | | | +------------------+-----------------------+ | | yes, bidir | no unidir | | | | | | | V V | | (section-terminating) (section-terminating) | | Regenerator in the Span Regenerator in the Span | | | | | | +--------+--------+ +-------+-------+ | | yes | no | yes | no | | | V V V V | | use Line DCC 16 byte J0 Do not allow 16 byte J0 | | | regens?? | | +---------+---------+ | | yes | no | | | V V | | 16 byte J0 64 byte J0 | | | | | +------------------------------------------------------------------------------+ Figure 1. Automatic Neighbor Discovery Strategy 4. SDH J0 16 Byte: Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame | CmdType | NID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NID cont. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NID cont. | portID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | portID cont. | NeType | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. SDH J0 byte message H. Koay, Y. Xu Expires May 2001 [Page 5] Internet Draft draft-koay-mpls-and-optical-00.txt Nov. 2000 4.1 Frame Framing and CRC-7 byte per G.707 (3/96) section 9.2.2.2. 8 bit value with (bit 0) MSBit = 1 for frame identification, bit 1-7 for the CRC-7 over the pervious frame (CRC-7 calculation is specified in annex B of G.707). The SDH J0 byte message is a repeated 16 byte message with 1 frame byte (8- bit value) and 7-bit T.50 IRV (International Reference Version) characters used in the remaining 15 bytes. A T.50 character can be a printable ascii value from "space" to "delete" inclusive. A bit pattern of 00000001(absolute value of 1 per J0 byte) means that the Regenerator Section Trace is unspecified or unused. J0 bytes containing a value of 1 are discarded and frame processing begins at the next non-1 byte value. 4.2 CmdType Command type and implied version number. 7-bit NON-T.50 (printable ascii) values are used to identify upstream nodes which conform to traditional section TTI in the J0 byte. 4.3 NID or NodeID Node ID is currently the communication address (IP v4 address), unique within a network communication domain. 7-bit ascii value containing 1 hex ascii character per byte. Hence a 48-bit IP address can be represented in 8-bytes. Case insensitive comparisons. Alternatively, packing the 48 bits in 7-bit bytes following the CmdType is also acceptable. OIF2000.289 [2]. 4.4 PortID Port ID unique within the Node. This a generic physical location descriptor consisting of 4 bytes: bay/frame, shelf, slot/unit, and port. Each byte is represented by 7-bit ascii value where +-------------+-------------+ | J | charToInt(J)| +-------------+-------------+ | "0" - "9" | 0 - 9 | | "a" - "z" | 10 - 35 | | "A" - "Z" | 36 -61 | +-------------+-------------+ charToInt(P) = "0"-"9" mapped into 0-9, "a" - "z" mapped to 10-35, "A" - "Z" mapped to 36-61. [D] The OIF proposal does not use 0-9 hence is limited to 52 values. It also suggests that a 2 byte portID can be interpreted as: P1P2 = 52*(charToInt(P1)) + charToInt(P2) Range 0 to 2703 (52x52=2704). H. Koay, Y. Xu Expires May 2001 [Page 6] Internet Draft draft-koay-mpls-and-optical-00.txt Nov. 2000 The PortID can be interpreted as bay, shelf, slot, port. This will make the physical location of the port within the NE be more visible to the external user, thereby saving the User an extra step of having to retrieve a mapping of a 2-byte random number from each local NE to its physical location. The 2 byte mapping to physical port will not be available if the node is unreachable. If a limit of 62 for the bay, shelf, slot, port is too restrictive, then we should consider using all the printable values from space to delete (not including the delete char), which gives us 95 or 96 (delete char included). In this case charToInt = (Pvalue - 32) - 1 Alternatively, packing the 48 bits in 7-bit bytes following the CmdType is also acceptable. OIF2000.289 [2]. 4.5 NeType The NeType can be used to differentiate the optical switches from electrical switches, and the optical multiplexors (DWDM NEs) from the electrical multiplexors (ADM), especially if a common J0 byte scheme is used. If a DWDM NE originates the J0 test message towards the receiving DWDM NE, but the receiving DWDM NE is in the transparent mode, it is possible that the J0 test message is detected by an optical switch beyond the optical demultiplexor. The NEType will be useful for the optical switch to know that the originator of the message is not another optical switch. 5. SDH 16-byte J0 : Unidirectional Neighbor Discovery The unidirectional discovery is accomplished with an in-band datalink-layer identification signal (IDSIG) sent by a local node, followed by an identification response (IDRESP) from the peer node when it receives the IDSIG. The IDRESP is a network-layer message sent via whatever physical layer media is available (in-band or out-of-band) between the two communicating nodes. 5.1 Message Sequence Diagram +--------+ +--------+ | | | | | NE-X | <----------------> | NE-A | | | | | +--------+ +--------+ Figure 3: Network Scenario (1)The automatic neighbor discovery for a local target port is initiated when -- a port is newly registered -- or a pre-registered port is re-initialized (reset or recovery from equipment failure) H. Koay, Y. Xu Expires May 2001 [Page 7] Internet Draft draft-koay-mpls-and-optical-00.txt Nov. 2000 -- or a TxRetry Timer expires -- change from incoming J0 from "not used" to "my node information" is detected The transmitting node, NE-X, has to be sends an identification message via the SDH 16-byte J0 message from the local target port for the duration of the Recognition Timer. The Recognition Timer is a User configurable timer and is set to accommodate the worst case where a peer node has only transparent ports. Recognition Timer = IDSIG + PeerPollCycle + IDRESP received (2)The receiving node, NE-A, constantly polls each non-service port for a maximum of 1 second or until an IDSIG is detected on the received port. If an IDSIG is detected on the received port and -- the information for the neighbor is different from its view, -- or the originator (NE-X) has not yet indicated it has received the initial IDRESP NE-A will send an IDRESP to the originator (of the IDSIG) via a network- layer session (may be out-of-band). NE-A will use any communication session already established between the originating and peer node. NE-A then sets a Response Timer for receiving an echoed IDRESP from the originating node before moving onto the next transparent port to detect an IDSIG. The Response Timer is a User configurable timer. Response Timer = (2 x round-trip delivery) + IDRESP processing (3)If the transmitting node (NE-X) receives an IDRESP for the local target port, it -- cancels the Recognition Timer -- and acknowledges the receipt of this message back to the peer node. If the neighbor information in the IDRESP from the peer node (NE-A) is different from what is recorded in the local node's view for the target, NE-X informs the local control component about the change. (4)If the IDRESP acknowledged by the originating node (NE-X) is received by the peer node (NE-A), the neighbor discovery is complete and the Response Timer is cancelled. If the neighbor (NE-X) information received in this IDRESP message is different from what is recorded in the peer node's view (NE-A), this information will be given to local control component at NE-A. (5)If the Response Timer expires (session to neighbor failed or neighbor not responsive), the receiving node (NE-A) will send another IDRESP, again setting the Response Timer as before. H. Koay, Y. Xu Expires May 2001 [Page 8] Internet Draft draft-koay-mpls-and-optical-00.txt Nov. 2000 (6)If NE-X receives an IDRESP, it will acknowledge the message and cancel any pending Recognition or Retry Timers since neighbor discovery is complete. If the neighbor (NE-A) information in the IDRESP is different from its view, NE-X will inform the responsible control component. (7)The neighbor discovery is complete. See Step 4 for the action taken. (8)If the Response Timer expires a second time for this discovery cycle, notify the User regarding the failure to discover the neighbor for the local port. (9)If the Recognition Timer expires, set a TxRetry Timer for when to initiate the neighbor discovery cycle again. The TxRetry Timer is a User configurable timer. TxRetry Timer = 30 minutes [default] 6. Security Considerations This document raises no new security issues. 7. References [OIF2000.159] : Methods for Neighbor Discovery in SONET & SDH. August 3, 2000 proposal by Greg Bernstein of Ciena Corp., B.Rajagopalan and Debanjan Saha of Tellium. [OIF2000.289] : End System Discovery Using SONET Section J0 and Link Management Protocol (LMP). November 11, 2000. 8. Authors' Addresses Helena Koay 21-3C23, 1600 Osgood St. Lucent Technologies, Inc. N. Andover, MA 01845 Email: koay@lucent.com Yangguang Xu 21-2A41, 1600 Osgood St. Lucent Technologies, Inc. N. Andover, MA 01845 Email: xuyg@lucent.com H. Koay, Y. Xu Expires May 2001 [Page 9]