Optical wavekey network and a method for distributing management information therein

Optical link related wavekey information and other vendor specific information is distributed in a WDM network using an extension of the standard OSPF routing protocol. The extension makes use of a vendor attribute Link State Advertisement (LSA) which is a new type of opaque LSA. The vendor attribute LSAs include a Vendatt Link State Identifier (ID) field in the LSA header, and a Vendatt Type/Length/Value (TLV) structure. The Vendatt TLV includes a Vendatt-type field identifying the TLV as a Vendatt TLV, and an enterprise code field identifying the vendor whose equipment (node or network element) generates vendor attribute LSAs or is able to receive vendor attribute LSAs by the identified vendor. Vendor attribute LSAs of a specific vendor are designed to be ignored by nodes or network elements of other vendors.

FIELD OF THE INVENTION

The invention relates to optical WDM networks, and in particular to such networks employing dither tones for channel identification.

DESCRIPTION OF THE RELATED ART

As communications networks become more complex, the task of network management becomes increasingly difficult. An important aspect of a network management system, or NMS, relates to determining and maintaining an accurate record of the topology or connectivity of the network. In optical Wavelength Division Multiplexing (WDM) communications networks this may involve knowledge of not only connections of optical fibers among nodes of the network, but also connections of optical fibers within the nodes, allocation of wavelengths to respective optical fibers, and arrangements and sequences of multiplexers and demultiplexers, or optical band filters, within the nodes. Tropic Networks Inc. U.S. patent application Ser. No. 09/963,501 to Obeda, P. D., et al, filed on 27 Sep. 2001 and entitled “Topology Discovery in Optical WDM Networks”, which is included by reference herein, provides an improved method of topology discovery which is particularly applicable to optical WDM networks.

Methods for tracking the topology in the data plane of such optical networks, i.e. the optical links, wavelength channels, and switched connections, may involve the identification of wavelength channels using dither tones. Tropic Networks Inc. U.S. patent application Ser. No. 10/263,959 to Wan, P. W., et al, filed on 4 Oct. 2002 and entitled “Channel Identification in Communications Networks”, which is also included by reference herein, provides an improved method of, and apparatus for, channel identification which can facilitate robust detection of dither tones for identification of large numbers of channels in a communications network, particularly an optical WDM network. Tropic Networks Inc. U.S. patent application Ser. No. 10/452,511 to Obeda, P. D., et al, filed on 3 Jun. 2003 and entitled “Method and System for Identification of Channels in an Optical Network”, which is also included by reference herein, provides further improvements in the area of flexible, cost-effective, and reliable channel identification in such networks.

The aforementioned methods provide the mechanisms for channel identification and their use in topology discovery in an optical WDM network. A network using these methods will be referred to as a “wavekey network”, and its nodes (or network elements) as “wavekey nodes”.

The operators of networks often rely on centralized Operational Support Systems (OSS) to manage a number of networks, including optical networks, using a standardized suite of protocols (ISO 8473, LAPD, TP4, TL1) for communicating with the network elements (nodes) of these networks. The optical networks may be Synchronous Optical Network (SONET) networks or other networks.

The concept of network management, using a Data Communications Network (DCN) between the OSS and the managed network, and an Embedded Data Communications Network (EDCN) within the managed network, is described in the Network and Services Integration Forum (NSIF) Document #SIF-AR-9806-088R11. The EDCN in a SONET network utilizes the International Standards Organization (ISO) communications standards, namely TP4, CNLP(ISO 8473), LAPD, etc. The Transaction Language 1 (TL1) is widely used in North America for management of SONET and access infrastructure. TL1 is a man-machine interface that is cross-vendor, cross-technology.

FIG. 1illustrates an arrangement of networks100, including an optical WDM network102(Network-1) comprising four nodes104,106,108, and110(network elements NE-1to NE-4), a data communications network (DCN)112, an OSS114, and other networks116(Network-2to Network-N).

The OSS is linked to the DCN112through a data link118. The DCN112is linked to the optical WDM network102(Network-1) through two data links120and122connected to the network elements104and106(NE-1and NE-2) respectively, and to the other networks116through additional data links124. The network elements104and106(NE-1and NE-2) are also termed “Gateway Network Elements” (GNE).

The four nodes (network elements NE-1to NE-4) of the optical WDM network102are interconnected with WDM links126, each WDM link126comprising a number of lambda-channels.

The optical WDM network102may be a SONET network, that is a network where the wavelengths (lambda channels) of each WDM link carry optical signals formatted according to the SONET standard. The centralized OSS114is designed to handle the NEs of a SONET network, including the identification of NEs, their properties and status, and the connectivity of the lambda-channels (each lambda channel being in effect a SONET channel) through the network.

The SONET format includes overhead channels, among them a Section Datacom Channel and a Line Datacom Channel. The Datacom channels may be conveniently used to convey network management information between the NEs. The OSS114has access to the Datacom channels through the data link118, via the DCN112and the data links120and122, and thus through the nodes104and106(network elements NE-1and NE-2). The OSS is thus capable of communicating with every SONET node in the optical WDM network102. Through the nodes104and106, the OSS114further has access to the Section and a Line Datacom Channels of the SONET formatted lambda-channels of the WDM links126in the optical WDM network102. The SONET path carries a J1 bytes, which continuously transmits a repeating 64 bytes string used to verify continuity of the path while the Section Datacom Channels for example are commonly used to carry a text based “path name” from node to node, enabling the OSS to determine the integrity and continuity of a path (also termed a “trail”).

On the other hand, an optical WDM network may not be a SONET network, but a new type of optical packet network, for example a wavekey network.

A wavekey network has a number of advantages over a SONET network, primarily in lower hardware cost, more efficient carriage of user packet data (no SONET overhead), and also in other respects, for example the operator of the network may find it easier to obtain employees having the technical skills for maintaining and operating a network that is based on packet technology rather than SONET technology.

It is desirable that a wavekey network be able to function in the role of one of the networks ofFIG. 1, but this is only possible if there is a way to manage the wavekey network from the common OSS. However, lacking the SONET overhead channels, the wavekey network is not directly compatible with the existing OSS.

Thus, it is necessary to develop new methods of managing the wavekey network so that it is compatible with the OSS.

SUMMARY OF THE INVENTION

It is an objective of the present invention to provide an extension to the existing network protocol, which would be capable to distribute optical link related wavekey information and other vendor specific information in a wavelength division multiplexing (WDM) network.

According to one aspect of the invention there is provided an Open Shortest Path Found (OSPF) packet of an OSPF protocol used in a network having a plurality of nodes connected by optical links, the OSPF packet comprising an opaque Link State Advertisement (LSA), the LSA including:

an LSA header having a single Vendatt Link State Identification (ID) field instead of the Opaque Type and the Type-Specific ID fields of a standard LSA header; and

a set of Vendor Attribute Type/Length/Value (TLV) fields, the Value field including an Enterprise Code field and a Vendatt-Data section, and the Type field being a Vendatt-Type field indicating the presence of the Enterprise Code field in the Value field;

the Vendatt Link State ID field of the LSA header indicating the presence of the set of Vendor Attribute TLV fields.

The Vendatt Link State ID field of the LSA header has a numerical value, which is designed not to conflict with the numerical values of the Opaque Type and the Type-Specific ID fields of a standard LSA header. The numerical value of the Vendatt Link State ID field indicates the presence of Vendor specific link related information in the Vendatt-Data section of the set of Vendor Attribute TLV fields.

The numerical value of the Vendatt Link State ID field indicates the presence of Vendor specific node related information in the Vendatt-Data section of the set of Vendor Attribute TLV fields. Preferably, the Vendor specific link related information is a wavelength division multiplexing (WDM) link related information comprising one or more of the following:

frequencies of dither tones (a wavekey) modulated onto a wavelength of the WDM link;

a location field listing the physical shelf, card slot, and port location of the node terminating the WDM link;

a wavelength identifier of the wavelength of the WDM link;

a path name (trail name) assigned to the wavelength of the WDM link;

a direction of the WDM link; and

a working state of the wavelength of the WDM link.

Conveniently, the Vendatt-Data section comprises a sub-TLV field, the sub-TLV field comprising a sub-sub set of Vendor Attribute TLV fields, which contains said Vendor specific link related information.

Alternatively, the Vendor specific node related information may comprise one or more of the following:

a Node Name which includes a text string bearing the name of the node; and

a Software Version which includes a text string characterizing the current software load of the node.

Conveniently, the Vendatt-Data section comprises a sub-TLV field, the sub-TLV field comprising a sub-sub set of Vendor Attribute TLV fields, which contains said Vendor specific node related information.

Additionally, the sub-TLV field may comprise an Advertising Router ID field.

According to another aspect of the invention there is provided a protocol for distributing vendor specific information for a WDM optical network based on the Open Shortest Path Found (OSPF) protocol, wherein the OSPF protocol is extended to provide an OSPF packet, the OSPF packet comprising an opaque Link State Advertisement (LSA), the LSA including:

an LSA header having a single Vendatt Link State Identification (ID) field instead of the Opaque Type and the Type-Specific ID fields of a standard LSA header; and

a set of Vendor Attribute Type/Length/Value (TLV) fields, the Value field including an Enterprise Code field and a Vendatt-Data section, and the Type field being a Vendatt-Type field indicating the presence of the Enterprise Code field in the Value field;

the Vendatt Link State ID field of the LSA header indicating the presence of the set of Vendor Attribute TLV fields.

The Vendatt Link State ID field of the LSA header has a numerical value, which is designed not to conflict with the numerical values of the Opaque Type and the Type-Specific ID fields of a standard LSA header. The numerical value of the Vendatt Link State ID field indicates the presence of Vendor specific link related information in the Vendatt-Data section of the set of Vendor Attribute TLV fields.

The numerical value of the Vendatt Link State ID field indicates the presence of Vendor specific node related information in the Vendatt-Data section of the set of Vendor Attribute TLV fields.

Beneficially, the Vendor specific link related information is a wavelength division multiplexing (WDM) link related information comprising one or more of the following:

frequencies of dither tones (a wavekey) modulated onto a wavelength of the WDM link;

a location field listing the physical shelf, card slot, and port location of the node terminating the WDM link;

a wavelength identifier of the wavelength of the WDM link;

a path name (trail name) assigned to the wavelength of the WDM link;

a direction of the WDM link; and

a working state of the wavelength of the WDM link.

Conveniently, the Vendatt-Data section comprises a sub-TLV field, the sub-TLV field comprising a sub-sub set of Vendor Attribute TLV fields, which contains said Vendor specific link related information.

Alternatively, the Vendor specific node related information may comprise one or more of the following:

a Node Name which includes a text string bearing the name of the node; and

a Software Version which includes a text string characterizing the current software load of the node.

Conveniently, the Vendatt-Data section comprises a sub-TLV field, the sub-TLV field comprising a sub-sub set of Vendor Attribute TLV fields, which contains said Vendor specific node related information. Additionally, the sub-TLV field may comprise an Advertising Router ID field.

According to yet another aspect of the invention there is provided a method for distributing wavelength identification information for a WDM optical network using a known routing protocol, where the known routing protocol is extended to provide a packet for transmitting vendor specific information related to wavelength identification, the packet comprising a Vendatt-type field, a Vendatt-length field, an Enterprise Code field, and a Vendatt-data section, wherein the Vendatt-Data section includes the wavelength identification information to be distributed.

Preferably, the known routing protocol is the OSPF protocol, and the packet includes a Link State Advertisement (LSA), comprising a set of Type/Length/Value (TLV) fields including said Vendatt-type, Vendatt-length, Enterprise Code fields, and the Vendatt-data section.

According to one more aspect of the invention there is provided a WDM optical network, using a protocol for distributing wavelength identification information for the WDM optical network, the protocol being based on a known routing protocol, which is extended to provide a packet for transmitting vendor specific information related to wavelength identification, the packet comprising a Vendatt-type field, a Vendatt-length field, an Enterprise Code field, and a Vendatt-data section, wherein the Vendatt-Data section includes the wavelength identification information to be distributed.

Beneficially, the known routing protocol is OSPF, and the packet includes a Link State Advertisement (LSA), comprising a set of Type/Length/Value (TLV) fields, including said Vendatt-type, Vendatt-length, Enterprise Code fields, and the Vendatt-data section.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 2illustrates a wavekey network200according to an embodiment of the invention.

The wavekey network200comprises four network elements (NE-A to NE-D)202,204,206, and208. Each of the NEs202-208is a wavekey node.

The wavekey network200is connected to an OSS (not shown) via a management link218from the NE204.

One purpose of the invention is to enable the wavekey network200to be administered from the OSS.

A solution might be to upgrade the OSS to make it compatible with the features of the wavekey network. But this would require a considerable amount of work and delay in establishing compatibility, and is thus not feasible in the short term.

Conversely, compatibility between the OSS and the wavekey network200may be achieved by utilizing the special capabilities of the wavekey network200to provide functions that are analogous to those provided by the SONET standard for managing the lambda-channels of an optical WDM network.

At the same time, a lower cost development is achieved if it is largely based on existing protocols and capabilities, and extends these as necessary. One such existing protocol is the Open Shortest Path Found (OSPF) protocol commonly used in routed data networks [Internet Engineering Task Force (IETF) document RFC 2328]. The OSPF protocol provides a reliable method for distributing routing information (so called Link State Advertisements or LSAs) in an Internet Protocol (IP) network.

A well-known result of using the OSPF protocol for the distribution of information among the nodes of a network is, that every node has exactly the same information about itself and every other node. In other words, there is a database of information, and every node has a complete copy of the database. A LSA describes properties (the link state) of a link between the nodes of a network. In a routed network, link states and their changes are immediately distributed to all other nodes, thus each node has up-to-date information about all links in the routed network (within the delay constraints imposed by the protocol and the node-to-node communication).

However, the OSPF protocol is not used by the OSS to communicate with network elements. The OSS uses a protocol suite comprising the standard TP4 protocol, and is based on the standard TL1 language.

The OSS to GNE communication (through the DCN) is typically TL1 over TCP/IP. In a SONET network the GNEs terminate the TCP session and launch TL1 over TP4/CNLP sessions for each activated Target Identifier (TID) [NSIF Document #SIF-AR-9806-088R11]. Briefly, the invention is based on using the OSPF protocol with an enhancement for distributing information among the nodes (network elements202-208) of the wavekey network200, while interfacing to the OSS using the standard TL1 language through a TL1 gateway node. InFIG. 2, the NE204is designated as a TL1 gateway node.

Consequently, by using the OSPF protocol in the wavekey network200the TL1 gateway node204, the TL1 gateway node204will be in possession of all distributed information. Thus an interrogation from the OSS to the TL1 gateway node208is able to extract information about any of the network elements202-208in the wavekey network200where that information is distributed within the wavekey network through the OSPF protocol, and where the TL1 gateway node204comprises means to adapt (translate) the format of the information to the TL1 language as required.

However, the existing OSPF protocol is only defined for distributing specific types of information in LSAs. To allow the OSPF protocol to be used for distributing information that is wavekey network specific, or other similar vendor specific information, the OSPF protocol must be extended.

An embodiment of the invention will now be described in detail, including a wavekey network, and the specific extensions to the OSPF protocol to carry new types of LSA, suitable for encoding wavekey information and other information that is vendor specific.

The wavekey network200ofFIG. 2, is shown in greater detail inFIG. 3.

The network element NE-A202has a number of access ports302; similarly, the network elements (NE)204,206, and208each have a number of access ports304,306, and308respectively.

The WDM link210comprises a number of lambda-channels divided into a group of user data channels310and a control channel312. As is common in WDM systems, each lambda-channel in a link utilizes a different optical wavelength (lambda), but shares a common fiber (the WDM link210). In addition, specific to this embodiment, each lambda channel is encoded with dither tones as described in Tropic Network Inc. U.S. patent application Ser. No. 10/452,511 filed on 3 Jun. 2003 (noted in Paragraph No. 4 above) The data signal of the control channel312preferably follows the Ethernet standard and comprises Internet Protocol (IP) packets.

The WDM link216similarly comprises lambda-channels divided into a group of user channels316and a control channel318. The WDM links212and214are similarly constructed (not shown in detail).

The network elements (NE-A to NE-D)202to208further include controllers320to326respectively.

The control channel312of the WDM link210provides a data connection between the controller320of NE-A202and the controller322of the NE-B204. The control channels of the other links similarly provide data connections between the associated controllers, forming an IP network in a known manner, including the use of the OSPF protocol. The IP network is a control network of the wavekey network200.

The user data channels (examples310and316) of the WDM links (210to216), of the wavekey network200, together with the NEs202to208, provide a transport network between the access ports302to308, to carry data between users that are attached to the network. Shown in a dashed heavy line is a single exemplary connection328between one of the access ports304of the NE-B204, and one of the access ports308of the NE-D208, and passing through the NE-A202. The connection328is also known as a path328. Each path in the wavekey network200is assigned a wavekey (set of dither tones), as described in Tropic Network Inc. U.S. patent application Ser. No. 10/452,511 filed on 3 Jun. 2003 (noted in Paragraphs No. 4 and 86 above).

Generally, the controllers (320-326) set up connections within each node, and communicate over the control channels of the WDM links (210-216) to set up paths between the access ports (302-308) of the wavekey network200in a known manner.

In the case of the exemplary path328, the controller326in the NE-D208(for example) further assigns a wavekey to the path328. Because each wavekey used in the wavekey network200is preferably unique, the controller326must have the information about wavekeys that are already in use, not only on paths crossing the NE-D208, but in all NEs of the wavekey network200. The OSPF protocol running in the controllers320-326, and communicating over the control channels of the WDM links (210-216), is exploited to maintain a common database of wavekeys that are in use. The extension proposed to the OSPF protocol to enable it to carry wavekey information is described further below.

The node (NE-B)204of the wavekey network200terminates the management link218to the OSS (not shown). The NE204is also known as a TL1 gateway204. TL1 is a standard control language, commonly used by network operators for administering network elements. The management link218thus carries TL1 commands from the OSS to the wavekey network200, and provides responses back to the OSS. The controller322of the NE204(the TL1 gateway204) includes the additional functionality to interpret TL1 commands and provide responses. In this way, a connection (the path328for example) may be set up as a result of a TL1 command received over the management link218from the OSS by the TL1 gateway204.

However, the repertory of TL1 commands from the OSS does not include wavekey related functions. It does however include many SONET related functions, for example a function to associate a path name (a human readable text string, also referred to as a “trail”) with a connection (such as the path328), and to subsequently monitor the connection based on the associated path name.

In a SONET network, the trail name would be received from the OSS, and the transmitted in the overhead of the SONET signals (user channels) of each lambda channel as the human readable text string.

In the wavekey network200, there is no user channel overhead capable of carrying the human readable text string in each lambda channel (user channels310or316). Instead, paths (including the path328) are identified by wavekeys (combinations of dither tones of different frequencies). The controller322of the NE204(the TL1 gateway204) thus includes the additional functionality of associating trail names with wavekeys, in effect translating a trail name received from the OSS into a corresponding wavekey.

While only one TL1 gateway (the NE204with the management link218) is shown in the wavekey network200for clarity, it is understood that there are preferably more than one TL1 gateway (NE with a management link) in an actual wavekey network, for reliability.

OSPF Packet

The format of a typical OSPF packet400is shown inFIG. 4. The OSPF packet400comprises an IP header402, an OSPF header404, and one or more OSPF data fields406. The IP header402includes a Protocol Field408identifying the packet as an OSPF packet. The OSPF header404includes an OSPF Packet Type field410identifying the type of the OSPF data406. The type of OSPF data of concern in the present invention includes “Link State Advertisements” (LSA), and the first OSPF data field406is shown as an LSA412. Also shown inFIG. 4in dotted outline is an Ethernet header414representing a layer 2 protocol header. OSPF packets may be carried over (encapsulated in) different layer 2 protocols. Ethernet is the preferred layer 2 protocol of the embodiment of the invention. The OSPF protocol is described in the IETF “Request For Comment” (RFC) document “OSPF Version 2” RFC2328.

A number of different types of LSA are defined in the RFC2328. Additional types of LSAs are described in the IETF documents RFC2370 (“The OSPF Opaque LSA Option”) and RFC3630 (“Traffic Engineering (TE) Extensions to OSPF Version 2”).

The format of a specific type of opaque LSA (a Traffic Engineering LSA (TE-LSA))500of the prior art is shown inFIG. 5.

The TE-LSA500comprises an LSA header502, and the LSA payload504.

The LSA header502of the TE-LSA500comprises a number of fields. The fields of particular interest in this application are shown in bold, and with reference numerals. The other fields are shown in italics only.

The fields of the LSA header502of the TE-LSA500include:an Age field;an Options field;a Type Field506, set to the value of “10”, indicating an opaque Traffic Engineering LSA;a Link-State Identifier (ID) field divided into an Opaque type field508and a type-specific ID510;an Advertising Router field;a LS Sequence field;a Checksum field; and

a Length field.

These fields are described in detail in the IETF documents cited above.

The LSA payload504comprises one or more Type/Length/Value (TLV) blocks511, where each TLV block511comprises a TLV Type field512, a TLV Length field514, and a variable length TLV Value field516. The TLV Length field514specifies the length of the TLV Value field516. The TLV Value field516contains information, the structure of which depends on the contents of the TLV Type field512.

According to current practice [see reference RFC3630], a TE-LSA contains only a single Type/Length/Value (TLV) block511(a “top level” TLV block). TLV blocks may be nested. The TLV Value field516of the top level TLV block511shown inFIG. 5, may itself contain one or more TLV blocks, each having a sub-TLV type field, a sub-TLV length field and a sub-TLV value field. The sub-TLV value field may then again contain TLV blocks, and so on.

The current practice provides two top-level TLV types, a “Router Address TLV” and a “Link TLV”. Within these top level TLVs are provided a number of sub-TLV types.

It should be noted that the TLV type identifiers and sub-TLV type identifiers are assigned by the Internet Assigned Numbers Authority (IANA), and additional identifiers (numbers) may be assigned through standards setting processes.

While the OSPF protocol was originally designed to support routing, and more recently to support network traffic engineering, the availability of standard “opaque” LSAs suggests that other information in the form of TLV blocks511may also be distributed using the OSPF protocol.

As part of the embodiment of the invention, the OSPF protocol is extended and used to distribute additional information, as described in detail below. The additional information will be contained in TLV blocks of TE-LSAs (vendor specific LSAs). In order to differentiate the vendor specific LSAs from the standard TE-LSAs of the prior art, yet remain compatible with these, two schemes for creating vendor specific LSAs are defined, a “Vendor Attribute TLV” as a sub-TLV of a standard TE-LSA (a scheme “A”) and a “Vendor Attribute LSA' as a new type of TE-LSA incorporating a “Vendor Attribute TLV” (a scheme “B”).

Vendor Attribute TLV

FIG. 6shows a Vendor Attribute TLV600(similar to the TLV block516in the TE-LSA500, but with an added field), comprising a Vendatt-type field602, a Vendatt-length field604, an enterprise code field606, and a variable length Vendatt-Data section608.

The enterprise code field612is set to the Organizationally Unique Identifier (OUI, or vendor's code) of the vendor. Organizationally Unique Identifiers are defined in the IETF document “Structure of Management Information (SMI)” RFC2578. For example the SMI-OUI of the applicant's organization is hexadecimal 0x00001D3B. In this manner, the Vendatt-Data section608of the Vendor Attribute TLV600may contain any vendor specific information, formatted and defined according to the vendor's design, and easily distinguished from another Vendor Attribute TLV600of a different vendor.

In this embodiment, the distribution of vendor specific data, using the OSPF protocol, is enabled by the definition of one additional sub-TLV type identifier for each of the standard two top level TLV types (the Router Address TLV and the Link TLV, described in RFC3630).

This allows the Value field516of a standard TLV504of a standard TE-LSA500, to carry a sub-TLV that is a Vendor Attribute TLV600. The Vendatt-type field602of the Vendor Attribute TLV600is set to one of the two additional sub-TLV type identifiers that would be defined (standardized).

The embodiment of the Vendor Attribute TLV600thus defines an encoding that uniquely identifies the organization, so that there is no risk of collision in picking a type identifier value from the type range reserved for vendor specific extensions. The unique identifier specified (in the enterprise code field606) to distinguish a particular vendor, is the vendor's or the organization's SMI Network management enterprise code. This encoding method for vendor specific data simplifies the process of defining the Vendor Attribute TLV600by eliminating the need of an Expert Review and the redundant registration of the vendor with the IANA (which would be required if a separate sub-TLV type identifier had to be allocated for every vendor). Only the two additional sub-TLV type identifiers need to be standardized and registered.

The Vendor Attribute TLV600can be used as a sub-TLV in the Router Address TLV (top level type field512inFIG. 5set to “1”). The (as yet unassigned) sub-TLV type identifier “1” may be assigned for the Vendatt-type field602.

The Vendor Attribute TLV606can also be used as a sub-TLV in the Link TLV (top level type field512inFIG. 5set to “2”). In this case, the (as yet unassigned) sub-TLV type identifier “17” may assigned for the Vndatt-type field602.

The Scheme “A” is also described in the IETF draft “draft-udo-ospf-Vendatt-00.txt” which is included herein by reference.

While the scheme “A” is the preferred embodiment for a generic vendor specific capability to be standardized (relying only on two sub-TLV type identifiers to be assigned by the IANA), a Scheme “B” is provided as an alternative embodiment that does not rely on standardization.

In the Scheme “B”, the Vendor Attribute TLV600is used as the top level TLV in an LSA, i.e. at the level of the TLV block516in the TE-LSA500. This is the basic idea behind a new “Vendor Attribute LSA”. However, in order to distinguish the “Vendor Attribute LSA” more securely from standard TE-LSAs (and possible other vendors' non-standard LSAs), an additional safeguard is proposed. It is not sufficient to rely simply on selecting a different TLV type identifier, since a number of organizations already use identifiers that are not assigned, and may be unpublished.

Thus in order to reduce the risk of false detection, a Vendor Attribute LSA700(shown inFIG. 7) is defined.

The Vendor Attribute LSA700is similar to the standard TE-LSA500, with different elements indicated in bold lettering. The Vendor Attribute LSA700comprises an LSA header702, the LSA header702comprising a number of fields unchanged from the standard TE-LSA500(indicated in italics), and a Vendatt Link State ID field704(in place of the Opaque-Type field508, and the Type-Specific ID510of the standard TE-LSA500). The Vendor

Attribute LSA700further comprises an instance of the Vendor Attribute TLV600(in place of the TLV block511of the standard TE-LSA500).

The Vendor Attribute LSA700is thus distinguished from the standard TE-LSA500in two ways:the value assigned to the Vendatt Link State ID field704is chosen to be different from the standard values of the Opaque-Type field508, and of the Type-Specific ID510of the standard TE-LSA500; and

the top level TLV is a Vendor Attribute TLV600comprising an enterprise code field606identifying the vendor, as described above (FIG. 6).

Two instance types of the Vendor Attribute LSA700that have been defined for use in a wavekey network of the applicant, a Wavekey LSA and a Node Name LSA, will now be described as examples of the application of the Vendor Attribute LSA700concept.

A Wavekey LSA800is illustrated inFIG. 8. The Wavekey LSA800is an instance type of the Vendor Attribute LSA700in which the LSA header702includes the Vendatt Link State ID field704having the assigned value of hexadecimal value 0x81000008. The Wavekey LSA800further comprises an instance of a Vendor Attribute TLV600in which the Vendatt-type field602has the value of 1, the enterprise code field606has the hexadecimal value 0x00001D3B, and the Vendatt-Data section608comprises a nested set of TLVs. The value of the enterprise code field606is the SMI-OUI of the applicant's organization, since the wavekey concept is specific to this vendor.

The Vendatt-Data section608is itself a second level TLV having a sub-type field802(set to the value 2), a sub-length field804, and a sub-data section806.

The sub-data section806in turn is a third level TLV (a “Wavekey TLV”806), structured in the format of a Vendor Attribute TLV600, comprising a Vendatt-type field602(labeled a “subsub-type”808inFIG. 8, set to the value253), a Vndatt-length field604(labeled a “subsub-length”810inFIG. 8), and a second enterprise code field812, also set to the hexadecimal value 0x00001D3B.

The Vendatt-Data section608of the Wavekey TLV806is labeled a “Wavekey-Data” section814inFIG. 8, and includes a number of fourth level TLV blocks containing wavekey information. The wavekey-data section814is illustrated in further detail inFIG. 9below.

The Wavekey LSA800illustrated inFIG. 8comprises a number of fields indicating the lengths of certain blocks, including a Length field816in the LSA header702, the Vendatt-length field604, the sub-length field804, and the subsub-length field810. The values to be set in these fields all depend on the length of the wavekey-data section814in the following way:

Let “L” be the actual length of the wavekey-data section814.

the subsub-length field810is set to L+4 (accounting for the additional length of the second enterprise code field812);the sub-length field804is set to L+8 (accounting for the additional lengths of the subsub-type field808and subsub-length field810);the Vendatt-length field604is set to L+16 (accounting for the additional lengths of the enterprise code field606as well as lengths of the sub-type field802and the sub-length field804);the length field816in the LSA header702is set to L+40 (accounting for the additional lengths of the Vendatt-type field602and the Vendatt-length field604, as well as the complete length of the LSA header702itself).

The values of the other fields of the LSA header702(shown in italics) are set according to standard OSPF practice.

Wavekey Data Section

The wavekey-data section814is shown inFIG. 9. It comprises a number of TLV blocks, similar to the standard TLV block511(seeFIG. 5). Each TLV block has a type field, a length field, and a data section, where the type fields are shown with specific type identifiers indicated, and the data sections are labeled so as to indicate the nature of data being carried. The data carried in the wavekey-data section814relates to a single lambda channel on a specific optical WDM link (e.g. one of the user data channels310of the WDM link210inFIG. 3):a TLV block820, type1, comprising a Wavekeys section822listing the frequencies of the dither tones of the wavekey;a TLV block824, type3, comprising a Location section826listing the physical shelf, card slot, and port location of the equipment terminating the WDM link;a TLV block828, type4, comprising a Wavelength section830indicating the wavelength identifier of the lambda channel;a TLV block832, type5, comprising a Trail section834which includes the path name (trail name) assigned to the lambda channel;a TLV block836, type6, comprising a Direction section838indicating the direction of the optical link, for example East or West in an optical ring; anda TLV block840, type7, comprising a State section842indicating the state of the lambda channel, for example working or non-working.

The length fields of each of the TLV blocks820,824,828,832,836, and840contain the lengths (number of octets) of the corresponding data sections (822,826,830,834,838, and842).

Node Name LSA

A Node Name LSA900is illustrated inFIG. 10. The overall format of the Node Name LSA900is very similar to the format of the Wavekey LSA800; fields that are unchanged are shown in italic lettering, while only the new or changed fields are shown in bold. The Node Name LSA900is an instance of the Vendor Attribute LSA700in which the LSA header702includes the Vendatt Link State ID field704having the assigned value of hexadecimal value 0x81FFFFFF (which differs from that of the Wavekey LSA800). The Node

Name LSA900further comprises a specific instance of a Vendor Attribute TLV600in which the Vendatt-type field and the enterprise code field are unchanged from the Wavekey LSA800. The Vendatt-Data section608similarly comprises a nested set of TLVs.

The Vendatt-Data section608is itself a second level TLV having a sub-type field802(set to the value 1), a sub-length field804, and a sub-data section902.

The sub-data section902in turn comprises an “advertising router ID” field904and a third level TLV (a “Node Name TLV”906). The node name TLV906is structured in the format of a Vendor Attribute TLV600, comprising a Vendatt-type field602(labeled a “subsub-type”808inFIG. 8set to the value253and unchanged inFIG. 10), a Vendatt-length field604(labeled a “subsub-length”810inFIG. 8and also unchanged inFIG. 10), and a second enterprise code field812(FIG. 8) also unchanged inFIG. 10.

The second Vendatt-Data section608(labeled a “Node Name Data” section908inFIG. 10) includes a number of fourth level TLV blocks containing node name information. The node name data section908is illustrated in further detail inFIG. 11below.

The Node Name LSA900comprises a number of fields indicating the lengths of certain blocks, including the Length field816in the LSA header702, the Vendatt-length field604, the sub-length field804, and a subsub-length field910. The values to be set in these fields all depend on the length of the node name data section908in the following way:

Let “K” be the actual length of the node name data section908.

the subsub-length field910is set to K+4 (accounting for the additional length of the second enterprise code field);the sub-length field804is set to K+12 (accounting for the additional length of the advertising router ID field904as well as the lengths of the subsub-type field and the subsub-length field910);the Vendatt-length field604is set to K+20 (accounting for the additional lengths of the first enterprise code field as well as the lengths of the sub-type field802and the sub-length field804);the length field816in the LSA header702is set to K+44 (accounting for the additional lengths of the Vendatt-type field and the Vendatt-length field604, as well as the complete length of the LSA header702itself).
Node Name Date Section

The node name data section908is shown inFIG. 11. It comprises two TLV blocks, similar to the standard TLV block511(seeFIG. 5). Each TLV block has a type field, a length field, and a data section, where the type fields show specific type identifiers, and the data sections are labeled so as to indicate the nature of data being carried. The data relates to the node sending the LSA (the advertising router, as specified in the advertising router ID field904, for example the node NE-A202ofFIG. 3):a TLV block911, type1, comprising a Node Name section912which includes a text string bearing the name of the node; and

a TLV block914, type2, comprising a Software Version section916which includes a text string characterizing the current software load of the node.

The length fields of each of the TLV blocks911and914contain the lengths (number of octets) of the corresponding data sections (912and916).

CONCLUSION

Through the development of a vendor specific protocol element type (the Vendor Attribute TLV) and schemes (the schemes “A” and “B”) for incorporating such protocol elements into OSPF LSAs, a method is provided by which (otherwise standard) OSPF can be used to distribute wavekey data and other vendor specific information in an optical network. In this way a distributed database of such information can be created, making it possible to access this information from selected gateway nodes (TL1 gateways) in a manner that permits the optical network to be managed from a conventional OSS, using existing management protocols. Furthermore, the development of the Vendor Attribute TLV for OSPF creates an opportunity for using that protocol (OSPF) to distribute many other types of vendor specific information in a network, including the coexistence of several vendors, each distributing their specific information reliably, and without mutual interference.