WO2002017544A2

WO2002017544A2 - Dynamic bandwidth allocation (dba) protocol

Info

Publication number: WO2002017544A2
Application number: PCT/US2001/026535
Authority: WO
Inventors: Gordon Lee; Kevin Huang; Wen-Lung Chen; Alan Lee
Original assignee: Geyser Networks, Inc.
Priority date: 2000-08-23
Filing date: 2001-08-23
Publication date: 2002-02-28
Also published as: WO2002017544A3; AU2001288406A1; WO2002017545A3; WO2002017546A3; WO2002017545A2; WO2002017546A2; WO2002017543A3; WO2002017543A2; AU2001288397A1; AU2001286758A1; WO2002017542A2; AU2001288396A1; AU2001290570A1; WO2002017542A3; WO2002017580A1; AU2001288398A1

Abstract

A dynamic bandwidth allocation (DBA) protocol is provided. In an exemplary embodiment, a dynamic bandwidth allocation protocol of synchronizing transmitting data and receiving data is provided and includes assigning at a transmitter side (212) a single connection identification to all VTs in a nxVT connection, mapping at the transmitter side (212) transmitting data from one connection to VTs allocated to the nxVT connection, marking at the transmitter side overhead of the VTs with the connection ID in an outgoing nxVT stream, looking at the receiver side (214) at the connection identification of VTs, and placing at the receiver side (214) all VTs with the same connection identification in the first-in-first-out buffer related to the nxVT connection. In an exemplary embodiment, a dynamic bandwidth allocation protocol of carrying a dynamic bandwidth allocation message and managing information is provided and includes placing the message in the overhead of VTs.

Description

DYNAMIC BANDWIDTH ALLOCATION (DBA) PROTOCOL

SPECIFICATION RELATED APPLICATIONS

This application is related to U.S. Provisional Application No. 60/228,008, filed on August 23, 2000, to U.S. Provisional Application No. 60/272,793 , filed on March 1, 2001, to co-pending and commonly assigned U.S. Patent Application No. (Number to be assigned) with Attorney Docket Number 55369-014, filed on August 23, 2001, and to co-pending and commonly assigned U.S. Patent Application No. (Number to be assigned) with Attorney Docket Number 55369-016, filed on August 23, 2001. The contents of U.S. Provisional Application No. 60/228,008, filed on August 23,

2000, of U.S. Provisional Application No. 60/272,793, filed on March 1,

2001, of co-pending and commonly assigned U.S. Patent Application No. (Number to be assigned) with Attorney Docket Number 55369-014, filed on August 23, 2001, and of co-pending and commonly assigned U.S. Patent Application No. (Number to be assigned) with Attorney Docket Number 55369-016, filed on August 23, 2001, are hereby incorporated by reference. This application claims priority to U.S. Provisional Application No. 60/228,008, filed on August 23, 2000, and to U.S. Provisional Application No. 60/272,793, filed on March 1, 2001.

FIELD OF THE INVENTION The present invention relates to optical networking. More particularly, the invention relates to a dynamic bandwidth allocation (DBA) protocol.

BACKGROUND OF THE INVENTION Both SONET (See Synchronous Optical Network (SONET)

Transport Systems: Common Generic Criteria. GR-253-CORE, Issue 2, Revision 1. December, 1997.) and SDH (See International Telecommunication Union. Network Node Interface for the Synchronous Digital Hierarchy. Recommendation G.707. March, 1996.) enable the use of virtual concatenation to support both the dynamic resizing of transport trunks and the grooming of traffic. More recently, advances in the transport of routed datagram traffic leveraging the research and experience of ATM has resulted in the standardization of MPLS (See Internet Engineering Task Force. Multiprotocol Label Switching Architecture. IETF Draft Document. August, 1999 and ht p://www.ietf.org/internet-drafts/draft-ietf-mpls-arch- 06.txt). This work allows network devices to employ a standards-based method by which packet traffic can traverse a network, while receiving a previously agreed upon Quality of Service.

Referring to prior art Figure 1, in standard SONET and SDH, (1) an external network manager must synchronize the transmission of data and the reception of data, (2) the path layer overhead of STS-ls carry messages, resulting in messages with long resolution of 500 ms per message and which require a long time to send one command, (3) an external network manager, typically a human operator, must enforce service level agreements (SLAs), which is a slow process, (4) an external network manager, typically a human operator, performs ring management, and (5) VT/CID Table maintenance is not performed. SUMMARY OF THE INVENTION

The present invention provides a dynamic bandwidth allocation (DBA) protocol. In an exemplary embodiment, a dynamic bandwidth allocation protocol of synchronizing transmitting data and receiving data is provided and includes (1) assigning at a transmitter side a single connection identification to all VTs in a nxVT connection, (2) mapping at the transmitter side transmitting data from one connection to VTs allocated to the nxVT connection, (3) marking at the transmitter side overhead of the VTs with the connection ID in an outgoing nxVT stream, (4) looking at a receiver side at the connection identification of VTs, and (5) placing at the receiver side all VTs with the same connection identification in the same first-in-first-out buffer related to the nxVT connection. In an exemplary embodiment, a dynamic bandwidth allocation protocol of carrying a dynamic bandwidth allocation message and managing information is provided and includes placing the message in the overhead of VTs.

In an exemplary embodiment, a dynamic bandwidth allocation protocol of setting up a service level agreement for a nxVT connection is provided and includes (1) setting a minimum VT number, (2) assigning a guaranteed VT number and (3) specifying a maximum VT number.

In an exemplary embodiment, a dynamic bandwidth allocation protocol of managing a data ring is provided and includes (1) managing VT connections, (2) providing VT connections in response to channel requests, (3) sending nxVT requests, (4) releasing VT connections, and (5) protecting ring management redundancy.

In an exemplary embodiment, a dynamic bandwidth allocation protocol of carrying dynamic bandwidth allocation commands, connection identification, and performance monitoring information is provide and includes (1) placing a connection identification across a first byte and a second byte of a VT overhead byte, (2) putting a node identification of a source network element of data in a third byte, and (3) storing a error information in a fourth byte. In an exemplary embodiment, a dynamic bandwidth allocation protocol of carrying dynamic bandwidth allocation commands, connection identification, and performance monitoring information is provided and includes (1) placing a request parameter across a first byte and a second byte, (2) putting a node identification of a source network element of data in a third byte, and (3) storing a error information in a fourth byte.

In an exemplary embodiment, a dynamic bandwidth allocation protocol of carrying information in path overhead bytes is provided and includes (1) allowing interoperability with an existing SONET network in a STS-1 level, (2) storing a heartbeat of a ring manager in an STS-1 POH byte, and (3) placing a bandwidth doubling status in an STS-1 POH byte.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates details of prior art, standard SONET and SDH. Figure 2A illustrates a heartbeat generator in accordance with an exemplary embodiment of the present invention.

Figure 2B illustrates a heartbeat detector in accordance with an exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION Introduction

The invention described in co-pending and commonly assigned U.S. Patent Application No. (Number to be assigned) with Attorney Docket Number 55369-014 provides a system and method of virtually concatenating VT1.5s and STS-ls over SONET and SDH and WDM. The virtual concatenation invention allows users to setup connections or pipes with configurable bandwidth over either nxSTS-l/nxAU-3/nxAU-4 or nxVT1.5/nxTU-ll/nxTU-12 within a nxSTS-l/nxAU-3/nxAU-4 pipe on an existing SONET/SDH network. This provides a connection or pipe of adjustable bandwidth with a granularity of close to 1.5 Mbps to fit the needs of applications. The resulting connection can be treated as a TDM like connection. By replacing "STS-1" with "AU-3" or "AU-4" and "VT" or "VT1.5" with "TU-11" or "TU-12", the virtual concatenation invention applies to nxAU-3/nxAU-4 and nxTU-1 l/nxTU-12 for SDH networks. For simplicity, these connections are called "nxVT" for both SONET and SDH networks. By replacing "STS-1" with "VT" or "VT1.5", the virtual concatenation invention applies to nxSTS-1 and nxAU-3/nxAU-4.

The virtual concatenation invention provides for virtual concatenation, which includes creating a logical connection or pipe by combining multiple, n (where n is a positive integer), STS-1 or VT connections or pipes, which may be contiguous or non-contiguous, into a single connection or pipe, nxSTS-1 or nxVT, respectively, in order to support a connection or pipe with a higher throughput than the throughput of the original STS-1 or VT pipes.

On top of the virtual concatenation invention, the present invention provides a dynamic bandwidth allocation (DBA) protocol and allows for dynamically changing the throughput of all nxVT connections, based on the real-time traffic loads of applications using the nxVT connections. The DBA protocol allows for the efficient use of the SONET/SDH bandwidth through statistical multiplexing. The same dynamic bandwidth allocation protocol applies to nxSTS- 1 and nxAU-3/nxAU-4.

General

The present mvention allows for the bandwidth of an nxVT connection within an nxSTS-1, called a data highway, to be dynamically changed in bandwidth with a minimum granularity of one VT. The change is based on the load of traffic flows through each nxVT connection. To do this, a the present invention communicates among nodes on a SONET ring. The present invention is based on a server/client model.

The present invention also provides a ring resource manager (Ring Manager, or RM), a server, in charge of allocating/recollect the VT resource based on the overall bandwidth usage/request from all nodes on the ring.

While all NEs at the two ends of the nxVT connections act as a client. They raise requests to the RM to request whatever bandwidth they need.

Connection Identification fCID) With the present invention, each nxVT connection is assigned a unique connection ID (CID) as the identifier of the connection. A CID is assigned to the VTs allocated to this connection in order to synchronize the transmitter and receiver side. The receiver will extract data from the VTs with the specified CID from the incoming data stream. The transmitter maps data to the payload of the VTs allocated to the nxVT with the interested CID in the VTs' DBA overhead bytes. Messages

In addition to the CID, messages of the present invention are sent between applications and the RM to request/grant/re-collect the bandwidth for each nxVT. Each end of a nxVT connection has a client called an "application". The present invention takes traffic from one or multiple ports (logical or physical) from a line card and maps the traffic onto the nxVT. Similarly, the present invention de-maps data from the nxVT and send the traffic to one or multiple ports on the line card.

In the present invention, an application may monitor traffic load from the line card side, and issue DBA messages to adjust the bandwidth assigned to the nxVT associated with the application. In the present invention, a DBA message is carried on the POH (P/Q/U/V) of each VT within an nxVT. Some messages are carried within the POH of all VTs allocated to the specific application, while others are carried only through one pre-specified VT, called a root VT. For example, the Bandwidth Request Message (req) is always carried in the root_VT. The root VT is specified by the Ring- Manager when the nxVT is initially setup. Multiple nxVT applications can send their own DBA messages simultaneously at the same SONET super- frame through different VTs. One DBA message is fit into the POH of one super-frame. The superframe is further described in co-pending and commonly assigned U.S. Patent Application No. (Number to be assigned) with Attorney Docket Number 55369-014. Service Level Agreement

In the present invention's service level agreement (SLA) setup, the following three numbers are specified to every nxVT: (1) a minimum VT; (2) a guaranteed VT; and (3) a maximum VT. The minimum VT is the number of VT that will be assigned to an nxVT no matter whether there is any traffic running or not. The guaranteed VT is larger than the minimum VT and is the number of VTs that is not necessarily assigned at the beginning of the nxVT setup, however guaranteed by the service level agreement whenever the traffic load goes up. This number is exactly the number of in-profile VTs. The maximum VT is the maximum number of VTs that can be assigned to a nxVT no matter how much traffic load there is. The difference between the guaranteed VT and maximum VT is the out- profile VT of the nxVT. Ring Manager

The present invention provides a Ring Manager (RM) which manages available resource (VTs), and assign fairly to whoever requests additional resources. In the present invention, bandwidth increase requests from an application will go to the RM first, and the RM will grant a VT based on the available resources in the VT Tributary Table. Based on the SLA, some of the VT requests are for in-profile VTs (guaranteed VT) and some are for out- profile (best effort) VTs. The RM has to make sure that the VTs are available to all the in-profile VT requests. This may involve enforcing existing nxVTs to release their out-profile VTs. Only after all the guaranteed VT requests are served may the RM start to serve the out-profile VT requests.

In the present invention, the RM performs the following:

(1) resource maintenance;

(2) provisioning change request serving;

(3) nxVT Request serving; (4) VT enforce release; and

(5) RM Redundancy Protection. VT/CID Table Maintenance In the present invention, the RM will keep a table, called a VT table, to keep track of the usage of every VT in the data highway. Whenever an application release VTs, the RM uses the release command provided in the DBA protocol to confirm with its peer application at the other end of the nxVT. If both applications agree, the VT is released, and the CID in the VT POH is replaced with an "unused CID". The RM monitors the "unused CID" in every VT POH, and updates its VT tributary table accordingly.

Whenever a VT is assigned to an nxVT, the RM updates the table also. In addition, it keeps track of the CID that the VT is assigned to, and keeps a time stamp of when this VT is granted. It also specifies whether this VT is used as a in-profile VT or out-profile VT. If it is a out-profile VT, it may be enforced to release later to satisfy other requests.

The RM also keeps a CH⁾ table that stores whether each CID is activated, how many VTs are already assigned to this CID, etc. Since the VT request command uses an absolute number of VTs needed, the RM use the CID table to find out the actual incremental VTs requested. Provisioning Change Request Serving In the present invention, the provisioning change requests come from the EMS system. It is not as dynamical as the nxVT bandwidth change, which happen in real time. The EMS may issue request to RM to change configuration to either change the nxSTS-1 pipe, or setup a new nxVT connections. nxSTS-1 Change In the present invention, nxSTS-1 pipe changes will be done hit-less such that the traffic is sent at the same time that the nxSTS-1 is changed without dropping any packets. This is done by first adding the new STS-ls into the data highway in all the nodes (including RM) without assigning any VT from the new STS-ls. The RM has full control to make sure the new STS-ls are not used until all nodes are configured and ready to use the new STS-1 s. Once this is done, any VT from the new STS-1 s granted by the RM is exactly the same as other VTs. NxVT setup In the present invention, in order to setup a new nxVT, the RM first assigns a CID to the new nxVT. A root VT is also specified as the very first VT in the nxVT. Once the root VT is available, the application at the two ends of the nxVT can start from the root VT and request bandwidth for normal operation.

NxVT Request In the present invention, once an nxVT is setup correctly, an application can start requesting more bandwidth. This is done by placing a "req" command in the root VT POH with an absolute number of VTs needed. The RM may receive many "req" commands in every super-frame. All the commands are put into the CID table. The design of the RM ensures that all the requests are served fairly. Also, the requests are either served or discarded in the current super-frame. The table can be updated with new requests in the next frame. The following is the procedure of serving the "req" commands: (1) serve all in-profile VT requests first:

(a) if there are enough VTs, serve all of the requests;

(b) if there are not enough VTs to serve all of the requests, serve whatever is available based on a first come first serve basis;

( ) at the same time, an enforce release command is issued to release some out-profile

VTs from existing nxVTs to make them available; and

(2) serve out-profile VT requests secondly:

(a) if there are enough VTs, serve all of the requests;

(b) if there are not enough VTs, serve whatever is available fairly based on the proportion of the requests of each CID :

(i) the more a node with a certain CID requests, the more will be granted even though not all are served as requested;

( ) at the same time, the out-profile n VTs assigned previously with a time stamp that has expired will be enforced to release:

(i) this is different from in-profile VT request, where the in-profile VT request will enforce release any out-profile VT without looking at the time stamp;

(ii) in this way, the fairness of out-profile VT is maintained while reducing the oscillation of granted out-profile VTs.

VT Enforce Release In the present invention, enforce release is performed whenever the number of VTs requested is more than the available unused VTs. In order to enforce release VT fairly, the RM keeps track of a FIFO (or link list) of all the out-profile VTs assigned. The sequence is based on the time when a VT was granted. A VT granted earliest will be enforced to release first. In addition to the sequence, a timestamp is associated with each VT in the FIFO to specify when the VT was assigned. Whenever the enforce release is triggered by a in-profile VT request, the VTs in the FIFO are enforced to release unconditionally until enough VT is available. Whenever the enforce release is triggered by a out-profile VT request, the time stamp is checked first against the current time stamp. Whatever VTs with ages older than a pre-specified threshold are enforced to release until enough VTs are available. No unexpired VTs are enforced release for out-profile VT requests.

Ring Manager Redundant Protection RM protection switching happens when the RM is not available due to fiber cut or equipment failure. For redundant protection, there are multiple RMs (one as active, others as backup) on the ring. The VT resources are managed by the active RM. The bandwidth allocation information such as VT-CID table is carried on the ring and backup RMs can retrieve this information from the ring. If the primary node crashes, the backup node takes control of the DBA protocol sitting on the ring in order to be the bandwidth manager. The correct bandwidth allocation information can be reconstructed from the overhead carried on the ring by the backup RM. In the present invention, the RM healthy status is determined by using the Heart-Beat signal sent from the F2 byte, bit 1, as shown in Figure 2 A. The RM detects Heart-Beat automatically, as shown in Figure 2B. Whenever the heart-beat is not detected, an interrupt is provided as an input to the Ring Election Protocol. The Ring Election Protocol is a software- based protocol. The backup RM elected as a new Secondary RM will recover VT table only after being elected as Primary RM. The ring manager protection scheme is further described in co-pending and commonly assigned U.S. Patent Application No. (Number to be assigned) with Attorney Docket Number 55369-016 .

NE nxVT/DBA Client In the present invention, a network element (NE) or node nxVT/DB A client includes the following two major components: (a) a nxVT mapper/de- mapper unit; and (b) a DBA message processing unit. nxVT Mapper/De-Mapper In the present invention, the nxVT mapper/de-mapper performs packet data mapping/de-mapping onto/from a nxVT connection. In order to do this, a fixed configured CID-PID table is maintained to map between the CID and the logical port ID on the node.

In addition, a VT-CID receive table and a VT-CID transmit table are updated in real time based on the VT POH overhead. In every super-frame, the VT POH reflects which CID it is associated with at both the receiving side and the transmitting side. The table is then used to demap/map the traffic data to the FIFOs associated with each of the CID. The major purpose is to keep the bandwidth of nxVT dynamically varying, and therefore the VT-CID table, from frame to frame without missing any single byte of the data in the nxVT.

DBA Message Processing Unit In the present invention, the DBA message processing unit (a) monitors the traffic load of each nxVT, (b) requests/releases VTs based on the traffic load, and (c) responds/processes incoming DBA messages. nxVT Traffic Monitoring In the present invention, the traffic load of each nxVT is measured based on the input rate of each nxVT. The input rate is measured by low pass filtering the number of bytes received in one super-frame period, divided by 212. This is equivalent to the number of VTs needed in 1 superframe, as given by the following formula:

X(t) = (1- α) * X(t-1) + α * R(t) / 212.

In the formula, R(t) is the number of bytes received in the pass super- frame period of time for the nxVT, X(t) is the number of VTs needed to support this input traffic. The α Efca low pass filtering parameter.

In order to avoid buffer overflow due to bandwidth adjustment based on rate only, a threshold is set to compare with the FIFO fullness. Whenever the nxVT FIFO fullness goes beyond the threshold, the X(t) will be set the maximum allowed by the specified SLA.

Request/release VTs In the present invention, once the number of VTs needed is known, the client compares this number with existing VTs available to this nxVT. If it is higher, then a "req" command is sent together with the X(t) derived. The number sent out is not the incremental amount needed. Instead, it is an absolute number of VT needed. In this case, the "req" command can be continuously sent without over-request.

If the number needed is less than the current existing number of VTs, some VTs will be identified to be released. The "rel" command will be sent on the POH of those VTs. When this is done, it does not mean that the VT is already released. The client will wait until the peer client agrees on the release of those VT before it is finally released. If the peer does not agree with the release, the current client can continue issuing the "rel" commands without actually releasing it. If the peer agrees, than it change the "rel" command to an "unused" command, and the VT is released. To avoid peer clients trying to release different VTs and eventually no agreement being reach even though both try to release some VTs, the client always releases the lowest VT ID of the out-profile VTs first, and then releases the lowest VT ID of the in-profile VT. The client will continue to release VTs until the available VTs reaches the minimum VT specified by the SLA. No release will be performed to make VTs lower than the minimum VT. Responses to RM messages In the present invention, the client also processes messages from RM, such as "grant", "en_rel", "roof, and "set_roof .

When the client sees a "grant" message, it acknowledges that a new VT is available to it, and changes the "grant" message to a"no_oρ". At the same time, the mapper starts to map data to the payload of that VT. When the client sees a "no_op" message, this VT was previously used by this nxVT, and is continuing to be available. The mapper continues to map data to the payload of this VT. The difference between "grant" and "no_op" is that "grant" carries no valid data in the payload, while "no_op" does. When the client sees a "roof, it recognizes that this is an existing root VT and updates the internal root VT flag. Also the mapper de-maps data from its payload.

The client reacts similarly with the "set_roof . When the client sees "set_roof , it recognizes that a new root VT is assigned. The internal root VT flag is updated. The only difference between "root" and "set_roof is that "root" carries valid data in the payload, while "set_roof does not. DBA messages

The present invention provides nine DBA commands used, which are defined as follows in Table 1.

TABLE 1

Applied VT SET ROOT 0x1

ROOT 0x4

Other than root_vt GRANT 0x3

REL 0x6

REL NACK 0x5

NO OP 0x8

Any VT ENF REL 0x2

Unused VT UNUSED 0x0

For each command, a 4-bit code word, stored in P [3:0], is assigned. As shown in Table 1, three commands are associated only with Root VT: req, set root, and

As shown in the table, three commands are associated only with Root VT: req, set_root, and root. Any of these messages showing in VT's DBA field indicates that the VT is a root_VT. It should not show up in non-Root VT. Four commands are associated only with non-Root VT: grant, rel, rel_nack, and no_op. enf_rel can be applied to any VT, and unused is only associate with unused VT. Note that enf_rel applies to root-vt only when a connection is deleted or a root-vt needs to be swapped to another STS-1. rea req messages are sent by applicant (NE) to apply for more VTs from RM. Request messages will be sent only on root VT of the CID. The RM detects the req message, record the request, and change the VT overhead to root_vt. (Or other messages if needed.)

Table 2 describes req messages.

TABLE 2

DBA message (4 bits) Profile ind (1 bit) CID/Request (11 bits)

0111: req (root_vt) 0 : in-profile-vt or Request_VT_#

1 : out-profile-vt

D in-profile-vt: minimum number of VTs allocated to this application, this bandwidth is guaranteed in the network operation. D out-profile-vt: extra bandwidth allocated to this application based on SLA (service level agreement), this bandwidth is served at best effort in the network operation.

D Request_VT_#: The number of VTs the nxVT needs. This number is not the additional number of VTs on top of existing VTs assigned. It is an absolute number of VTs to be used in the nxVT. Using an absolute number, the "req" command can be send/receive multiple times without causing problem. set root The "set_roof message is used by the RM to specify the root VT in nxVT. It is needed when: (1) a connection is initially set up by the EMS, and (2) the root VT is to be replaced/swapped out of the data highway. Another command "root" is also used to specify the root VT. The difference is that "roof implies the VT payload carries valid data, while "setjroof implies the VT payload does not carry valid data.

To setup a new connection, the EMS first configures the RM and two NEs associated with this connection by specifying the CID and setup the PID-CID tables at the two NEs, etc. Once the setup is done, the RM specifies an unused VT as the root VT using "setjroof . To swap a root_VT, the RM issues the "enfjrel" command to the original root VT and send "setjroof on a new VT simultaneously to enforce release the original root VT and enable new root VT at the same time. The swapping of root VT may be used for removing one STS-1 from the nxSTS- 1 data highway. EMS sends the STS-1 number to be removed to RM. RM Swaps root VT to any remaining STS-ls, and enforce release all the VTs belonging to the STS-1 to be deleted.

Whenever the RM sends a "setjroof command, it will continue sending this command until it sees the corresponding VT at the receiving side changes from "unused" to "root". Till this time, the "setjroof operation is done. The RM will bypass the "root" command and continue sending the "roof command at the transmitting side. This takes the frame to go one round trip around the ring. When nodes other than the RM receives the "setjroof command, they bypassed it to the transmit side unless it is an NE associated with nxVT. At this time, it sets the internal root VT flag, and replaces this message with a "root" message at the transmitting side. At the same time, it starts mapping valid data onto this VT.

Table 3 describes the setjroot message.

TABLE 3

DBA message (4 bits) Profile ind (1 bit) CID/Request (11 bits)

0001: set root 0 : in-profile-vt CID # (Connection ID #)

root

The "roof message is used to represent the "no_op" state of the root VT. RM does nothing with this message. NE will update their table to reflect root VT for the CID. The payload associated with this command carries valid data. Table 4 describes the root message.

TABLE 4

>BA message (4 bits) Profile ind (1 bit) CID/Request (11 bits)

0100: root 0: in-profile-vt CID # (Connection ID #)

grant

The "grant" messages are sent by the RM to NEs. Each newly granted VT carries this message. The NE receives this message, checks whether this CID# is in it's table. If it is, it will recognize this VT to belong to this connection. It will then replace the "grant" message with "no_op", and start mapping data to this VT. The VT with "grant" command carries no valid data in its payload. Similar to the "setjroof message, the "grant" and "enfjrel" issued simultaneously can be used to swap VT for non-root VTs. Table 5 describes the grant message.

TABLE 5

DBA message (4 bits) Profile ind (1 bit) CID/Request (11 bits)

0011: grant 0 : in-profile-vt or CID # (Connection ID #)

1 : out-profϊle-vt

rel

"rel" messages are sent by NEs to release unused VTs by applications. This message is sent from NE to NE to inform the peer of the connection for bandwidth release. An NE receiving this message will decide whether itself does not need this VT. If yes, then it will change the CID to OOOh and the command to "unused". If no, then it will change the message to "rel_nack" to deny the release. The original sender seeing the "rel_nack" either changes "rel iack" to "no_op" or continue sending "rel".

RM bypasses the "rel" message without terminating it. When the both NEs agree to release, and change the "rel" to "unused" and the CID is OOOh, the RM removes this VT from the busy link list and added to the unused link list of VTT table. The payload of the VT with "rel" carries valid data.

Table 6 describes the rel message.

TABLE 6

DBA message (4 bits) Profile ind (1 bit) CID/Request (11 bits)

0110: rel 0 : in-profile-vt or CDD # (Connection ID #)

1 : out-profile-vt

rel nack This message is used by an NE to deny the rel request from its peer NE. RM will do nothing on this command. The payload of the VT with "rel nack" carries valid data. Table 7 describes the reljiack message.

TABLE 7

DBA message (4 bits) Profile ind (1 bit) CID/Request (11 bits)

0101: rel nack 0 : in-profile-vt or CID # (Connection ID #)

1 : out-profile-vt

no op VT with the no_op message is carrying valid data payload with destination indicated by CID. Table 8 describes the no_op message.

TABLE 8

DBA message (4 bits) Profile ind (1 bit) CID/Request (11 bits)

1000: no op 0 : in-profile-vt or CID # (Connection ID #)

1 : out-profile-vt

enf rel "enfjrel" is issued by RM via the VT to enforce release from the nxVT. The first node associated with the CTD seeing the "enfjrel" will terminate "enfjrel" and put "unused" to the VT in transmitting side. After "enfjrel" is issued, there is at least one "unused" super-frame before this VT is granted to a new connection. This command is also used for swapping one root_VT. RM gets another VT as root VT and sends "setjroof command, while putting "enfjrel" to the releasing root VT. Table 9 describes the enfjrel command.

TABLE 9

DBA message (4 bits) Profile ind (1 bit) CID/Request (11 bits) 0010: enf rel 0 : in-profile-vt or CJD # (Connection ID #)

1 : out-profile-vt

unused VT with the unused message is unused by any nxVT. It carries no valid data in the payload. Table 10 describes the unused message.

TABLE 10

)BA message (4 bits) Profile ind (1 bit) CID/Request (11 bits)

0000: unused X = Don't care CID # (Connection ID #) = 0

DBA Overhead Bvtes

Path Overhead Bvte (POH)

In the present invention, four undefined GR-253 STS-1 POH overhead bytes are specified in the nxSTS-1 frame. C2 is specified for interoperability with existing SONET. F2/Z3/Z4 are used for nxSTS- 1 signaling channel to carry DBA ring management messages. nxSTS-1 signaling channel has a super-frame structure with 24x64kb/s bandwidth. The following are the POH bytes:

(1) C2=01 (equipped non-specific) to specify there is no GR-253 VTl .5 structure and the non-geyser SONET system shall bypass the entire NxSTS-1 as one entity, i.e. do not de-multiplex NxSTS-1 into VTl.5s;

(2) F2: Heart beat for the RM alive;

(3) Z3: Bandwidth Doubling status/signaling; and

(4) Z4: Reserved. F2 Bvte

The F2 byte is defined as in Table 11.

TABLE 11

The RM_Node_ID is the active RM's node ID. This is sent by the RM and used by all NEs to identify the RM node.

The Heart _Beat is a PRBS (Pseudo-Random Bit Stream) generated by the RM. It is used to show that the RM is alive and acting. Each node will detect and decode the incoming HeartjBeat on each super-frame (8 Heart _Beat bits are received in one super-frame). If the error rate is greater than certain threshold, then Active Ring Manager is determined to be failed.

The Even_Parity is an even parity check of the F2 byte to verify F2 is not corrupted. For the Heart-Beat, any PRBS can be used. OSM4800 uses the PRBS pattern generator shown in Figure 2A.

Figure 2B is a diagram of a Heart-Beat detector of the present invention. Z3 Bvte

The Z3 byte is used for the protection switching in bandwidth doubling mode (BDM). The description of the BDM is out of the scope of this document. Table 12 describes the Z3 byte.

TABLE 12

Z3I71 Z3 f6:41 Z3[3:ll Z3[0]

Valid_n Ring_Status Ring OperationjMode Valid_n

The Valid jn is 0 if the Z3 byte carries valid information, and 1 if it does not. The reason why Valid_n is located in both bit 7 and bit 0 is to protect it from card plug/yanking that cause portion of the byte invalid without actually setting this Valid_n bit.

The Ring_Status is described in Table 13.

TABLE 13

Ring Status Command

000 Protect jMode

001 Protect jMode_Confirm 010 DBMjMode 011 DBMjMode Confirm Others Reserved The Ring_Operation_Mode is described in Table 14.

TABLE 14

Ring Operation Status Command

000 Don't care

001 No_Op

100 Polling no Last Command in Abnormal

Others Reserved

VT Overhead Bvtes

The present invention uses the first 1 and 1/3 row of every nxSTS-1 super frame as VT overhead bytes. The resolution of DBA event is one per super-frame (two multiple frames). The following 4 consecutive overhead bytes for each VT in each super frame are defined to carry DBA commands, CID, and performance monitoring bits:

(i) P;

(2) Q;

(3) U; and (4) V.

P Bvte

Table 15 describes the P byte.

TABLE 15

The CID/Request[10:8] are bits 10 through 8 of CID or # of VT requested.

The Profile_Ind is a Profile indicator, equally 0 for in-profile, and 1 for out-profile.

The DBA Command is as described. The CID/Request field is across P and Q bytes. This field is used for two purposes. It is either the NxVT connection ID (CID), or the request parameter for number of VTs associated with the request command.

When used as the CID, it can support up to 1344 connections, numbered from 1 to 540H, in OC-48 applications. CID=0H represents an unused VTl.5. Other CID numbers are considered invalid. Using Growth field in V byte (V[7:2]), more CIDs can be supported when the link rate is OC- 192 or higher.

When used as the Request Parameter, it indicates the number of VTl.5 required by the connection. Valid numbers are from 1 to 540H.

O Bvte

Table 16 describes the Q byte.

TABLE 16

The CID/Request[7:0] are bits 7 through 0 of CID or # of VT requested. These parameters are across byte P and byte Q.

U Bvte

Table 17 describes the U byte.

TABLE 17

EuiBαl

Node D [7:0] The NodejID is the NodejTD of the source NE of the payload data. This is used in case of source data strip is needed.

V Bvte

Table 18 describes the V byte.

TABLE 18

The Growth is reserved for future use. The OddjBit Parify is a Parity Check Exclusive OR of all odd bits of P, Q, U. The Even_Bit_Parify is a Parity Check Exclusive OR of all even bits of P, Q, U.

Conclusion

The present invention relates to optical networking. More particularly, the invention relates to a dynamic bandwidth allocation (DBA) protocol. Having fully described a preferred embodiment of the invention and various alternatives, those skilled in the art will recognize, given the teachings herein, that numerous alternatives and equivalents exist which do not depart from the invention. It is therefore intended that the invention not be limited by the foregoing description, but only by the appended claims.

Claims

CLAIMSWe claim:

1. A dynamic bandwidth allocation protocol method of synchronizing transmitting data and receiving data comprising:

assigning at a transmitter side a single connection identification to all VTs in a nxVT connection;

mapping at the transmitter side transmitting data from one connection to VTs allocated to the nxVT connection;

marking at the transmitter side overhead of the VTs with the connection ID in an outgoing nxVT stream;

looking at a receiver side at the connection identification of VTs; and

placing at the receiver side all VTs with the same ponnection identification in the same first-in-first-out buffer related to the nxVT connection.

2. A dynamic bandwidth allocation protocol method of carrying a dynamic bandwidth allocation message and managing information comprising placing the message in the overhead of VTs.

3. A dynamic bandwidth allocation protocol method of setting up a service level agreement for a nxVT connection comprising:

setting a minimum VT number;

assigning a guaranteed VT number; and

specifying a maximum VT number.

4. The method of claim 3 wherein the setting comprises setting a quantify of root VT connections to be assigned to the nxVT connection whether or not there is any data traffic running on the nxVT connection.

5. The method of claim 3 wherein the assigning comprises assigning a quantity of VT connections which is guaranteed to be provided whenever data traffic increases.

6. The method of claim 3 wherein the specifying comprises specifying a maximum quantity of VT connections that can be assigned to the nxVT connection.

7. A dynamic bandwidth allocation protocol method of managing a data ring comprising:

managing VT connections;

providing VT connections in response to channel requests;

sending nxVT requests;

releasing VT connections; and

protecting ring management redundancy.

8. The method of claim 7 wherein the managing comprises keeping track of the usage of every VT connection in the data ring.

9. A dynamic bandwidth allocation protocol method of carrying dynamic bandwidth allocation commands, connection identification, and performance monitoring information, comprising: placing a connection identification across a first byte and a second byte of a VT overhead byte;

putting a node identification of a source network element of data in a third byte; and

storing a error information in a fourth byte.

10. The method of claim 9 wherein the placing comprises placing a nxVT connection identification across the first byte and the second byte.

11. The method of claim 9 wherein the storing comprises storing a parity check in the fourth byte.

12. The method of claim 9 wherein the storing comprises storing a check sum in the fourth byte.

13. A dynamic bandwidth allocation protocol method of carrying dynamic bandwidth allocation commands, connection identification, and performance monitoring information, comprising:

placing a request parameter across a first byte and a second byte;

storing a error information in a fourth byte.

14. The method of claim 13 wherein the placing comprises placing a request parameter of a request command for a number of VT connections associated with the request command.

15. The method of claim 13 wherein the storing comprises storing a parity check in the fourth byte.

16. The method of claim 13 wherein the storing comprises storing a check sum in the fourth byte.

17. A dynamic bandwidth allocation protocol method of carrying information in path overhead bytes comprising:

allowing interoperability with an existing SONET network in a STS-1 level;

storing a heartbeat of a ring manager in an STS-1 POH byte; and

placing a bandwidth doubling status in an STS-1 POH byte.