EP1266476A4 - Hybrid data transport scheme over optical networks - Google Patents
Hybrid data transport scheme over optical networksInfo
- Publication number
- EP1266476A4 EP1266476A4 EP01916564A EP01916564A EP1266476A4 EP 1266476 A4 EP1266476 A4 EP 1266476A4 EP 01916564 A EP01916564 A EP 01916564A EP 01916564 A EP01916564 A EP 01916564A EP 1266476 A4 EP1266476 A4 EP 1266476A4
- Authority
- EP
- European Patent Office
- Prior art keywords
- packet
- packets
- data
- sonet
- frame
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 230000003287 optical effect Effects 0.000 title description 7
- 239000012634 fragment Substances 0.000 claims abstract description 31
- 238000000034 method Methods 0.000 claims description 26
- 238000012545 processing Methods 0.000 claims description 15
- 238000012546 transfer Methods 0.000 claims description 7
- RGNPBRKPHBKNKX-UHFFFAOYSA-N hexaflumuron Chemical compound C1=C(Cl)C(OC(F)(F)C(F)F)=C(Cl)C=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F RGNPBRKPHBKNKX-UHFFFAOYSA-N 0.000 description 172
- 239000000835 fiber Substances 0.000 description 42
- 238000009432 framing Methods 0.000 description 23
- 230000005540 biological transmission Effects 0.000 description 22
- 238000010586 diagram Methods 0.000 description 22
- 238000013459 approach Methods 0.000 description 20
- 230000001360 synchronised effect Effects 0.000 description 14
- 230000008859 change Effects 0.000 description 7
- 238000005538 encapsulation Methods 0.000 description 7
- 238000013461 design Methods 0.000 description 6
- 238000013467 fragmentation Methods 0.000 description 5
- 238000006062 fragmentation reaction Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000012423 maintenance Methods 0.000 description 3
- 239000002699 waste material Substances 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 125000004122 cyclic group Chemical group 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 238000011144 upstream manufacturing Methods 0.000 description 2
- 239000011800 void material Substances 0.000 description 2
- 239000000969 carrier Substances 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000008672 reprogramming Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000000348 solid-phase epitaxy Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0061—Error detection codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/16—Time-division multiplex systems in which the time allocation to individual channels within a transmission cycle is variable, e.g. to accommodate varying complexity of signals, to vary number of channels transmitted
- H04J3/1605—Fixed allocated frame structures
- H04J3/1611—Synchronous digital hierarchy [SDH] or SONET
- H04J3/1617—Synchronous digital hierarchy [SDH] or SONET carrying packets or ATM cells
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for error control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
- H04Q11/0071—Provisions for the electrical-optical layer interface
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J2203/00—Aspects of optical multiplex systems other than those covered by H04J14/05 and H04J14/07
- H04J2203/0001—Provisions for broadband connections in integrated services digital network using frames of the Optical Transport Network [OTN] or using synchronous transfer mode [STM], e.g. SONET, SDH
- H04J2203/0073—Services, e.g. multimedia, GOS, QOS
- H04J2203/0082—Interaction of SDH with non-ATM protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J2203/00—Aspects of optical multiplex systems other than those covered by H04J14/05 and H04J14/07
- H04J2203/0001—Provisions for broadband connections in integrated services digital network using frames of the Optical Transport Network [OTN] or using synchronous transfer mode [STM], e.g. SONET, SDH
- H04J2203/0089—Multiplexing, e.g. coding, scrambling, SONET
- H04J2203/0094—Virtual Concatenation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
- H04Q11/0066—Provisions for optical burst or packet networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
- H04Q2011/0064—Arbitration, scheduling or medium access control aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
- H04Q2011/0077—Labelling aspects, e.g. multiprotocol label switching [MPLS], G-MPLS, MPAS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
- H04Q2011/0086—Network resource allocation, dimensioning or optimisation
Definitions
- the present invention relates to a method and/or architecture for hybrid data transportation generally and, more particularly, to sending a mix of different data types over a fiber optic network running
- MAN communications rely on short-haul and long haul fiber optic networks to transport data and telephony traffic.
- One conventional way to transmit data in fiber networks is through a Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) protocol.
- SONET/SDH Synchronous Optical Network/Synchronous Digital Hierarchy
- data travels in fixed size envelopes that repeat every 125 microseconds.
- every byte e.g., 8 bits of data
- every byte e.g., 8 bits of data
- every byte e.g., 8 bits of data
- 64 Kbps channel has the same rate as supported by current telephone channels (also called DS0 channels).
- SONET was designed to efficiently carry telephony Plesiochronous Digital Hierarchy (PDH) channels such as T1/T3. This was easily achieved by dividing the payload area in fixed slots called virtual tributaries (VT). These virtual tributaries are then grouped together to form higher-rate channels. These fixed slots are efficient for carrying fixed-bandwidth telephony channels because any one or more channels can be added or removed from a bundle without processing an entire payload of channels. Because SONET frames repeat at fixed intervals, these virtual tributaries have fixed locations and time intervals, and it is easy to extract T1/T3 or fractions of Tl without processing the entire SONET payload.
- PDH Digital Hierarchy
- SONET/SDH networks must now carry a significantly large number of data packets - such as ATM (Asynchronous Transfer Mode - 53 bytes each) and IP (Internet Protocol -variable-size packets) in addition to traditional T1/T3 channels.
- ATM Asynchronous Transfer Mode - 53 bytes each
- IP Internet Protocol -variable-size packets
- SONET/SDH has an inefficient utilization of fiber bandwidth for data packets.
- some of the virtual tributaries are created for transporting fixed-bandwidth T 1 traffic while others are used for transporting packet data packets such as ATM and IP. Since an individual virtual tributary has a limited bandwidth, extra mechanisms have to be used for sending data packets of higher bandwidth using virtual tributaries.
- a 10Mbps data packet channel for example, is inverse-multiplexed into smaller bandwidth streams and then sent on many virtual tributaries. At the other end, these streams are integrated to reconstruct the full 10Mbps channel.
- many of the virtual tributaries are concatenated using hardware to create a higher-bandwidth virtual tributary for transmitting the high- bandwidth data packet.
- SONET/SDH lacks of support for data mixing.
- a SONET fiber link carrying frames containing ATM cells cannot carry POS, because ATM cells frequently carry QoS-sensitive data such as CES (Circuit Emulation Service) or multimedia traffic.
- CES Circuit Emulation Service
- Introduction of SONET frames containing POS will cause significant delays (e.g., 125 ⁇ S for each POS frame inserted in the link).
- a unique Path Signal Label (PSL) value in the POH (Path Over-Head) field of the SONET frame identifies the type of data transmission inside the payload.
- the payload area is also referred to as SPE (Synchronous Payload Envelope). Because a PSL value identifies contents of the entire SONET payload envelope, only one type of transmission can be supported at a time in a SONET frame.
- One method for data transmission is to use the entire SONET SPE for data packets.
- the SONET payload area is filled with IP packets using Packet-over-SONET (POS) packets.
- POS packets are packets deliminated by 0x7E (Hexadecimal) at both ends of a packet, with a framing using PPP (Point-to- Point Protocol).
- PPP Point-to- Point Protocol
- Many packets can be put inside a single SONET SPE.
- This method can only support variable-lengthpacket protocol such as IP.
- a SONET fiber containing these packets cannot transport T1/T3 channels or real-time streams using ATM cells. The reason for this limitation is that each SONET SPE containing IP packets, for example, introduces a delay of 125 microseconds.
- Another method for data transmission is to use the entire SONET SPE for ATM cells.
- a SONET SPE is filled with ATM Cells.
- ATM cells are delimited by their fixed length, and are tracked by doing a hunt for their header checksum byte. Services such as Tl, Frame Relay, Ethernet, etc. are transported over ATM using standard protocols. This requires complex implementations in hardware and incorporation of ATM service interworking at each service boundary.
- Another method for data transmission is to use the virtual tributaries (VT) for data packets and ATM cells.
- VT virtual tributaries
- VT virtual tributaries
- VT virtual tributaries
- some of these virtual tributaries may contain T1/T3 type of fixed- bandwidth traffic while others are used for transporting packet data packets such as ATM and IP.
- a 1 OMbps data packet channel for example, is inverse-multiplexed into smaller bandwidth streams and then sent on many virtual tributaries. At the other end, these streams are integrated to reconstruct the full 10Mbps channel.
- many of the virtual tributaries are concatenated using hardware to create a higher- bandwidth virtual tributary for transmitting the high-bandwidth data packet.
- Each of these methods uses a fixed-bandwidth channel or a set of channels for transmitting network data packets.
- bandwidth capacity of the fiber is poorly utilized since network data packets are bursty in nature and average bandwidth utilization is quite low.
- a set of time-division- multiplexed (TDM) packets 12a-12n, a set of ATM packets 14a-14n and a set of POS packets 16a-16n are shown in connection with a SONET fiber line 18.
- TDM time-division- multiplexed
- ATM ATM
- POS POS
- 16a-16n POS packets 16a-16n
- PSL path signal label
- SONET/SDH was developed for efficiently transporting telephony signals over long links.
- SONET/SDH frames are generated using fixed length packets repeated at intervals of 125 ⁇ S.
- each byte of a SONET/SDH frame represents a basic telephony channel, often represented as DS0.
- a number of such bytes are reserved to form higher-order PDH signals (such as Tl) which use 28 DS0 channels.
- One such method for supporting telephony channels is by dividing the payload into a number of virtual tributaries (VT).
- VT virtual tributaries
- PDH bytes must begin at the same offset inside a SONET SPE 22a-22n. If data packets are transmitted along with the PDH channels, the data must be sent in the fixed length slots. Allocation of PDH channels at different locations inside the SONET SPE 22a-22n creates fragments of unused bytes all over the SPE. If the slots B D/F/G H/I are used for variable-length data packets, the slots cannot be fully used because the fixed bandwidth slots, such as C and E, do not allow the packets to continue without fragmenting while crossiing slot boundaries.
- a first conventional approach is virtual concatenation.
- a second conventional approach is inverse multiplexing.
- FIG. 3 an example of a conventional virtual concatenation approach is shown.
- the SONET SPE payload area is divided into fixed timeslots (i.e., virtual tributaries).
- An example of a virtual tributary is the standard VT 1.5.
- AVT1.5 can carry 1.5Mbps of information for each tributary, which is equal to a Tl channel.
- Virtual concatenation combines several VT channels into bigger virtual pipes to carry higher bandwidth traffic.
- some virtual tributaries can carry T1/T3 data as usual while others are concatenated for transport of higher bandwidth data traffic such as 10/100Mbps.
- a fatter pipe of a higher bandwidth may be generated that can carry the entire bandwidth of a LAN.
- splitting a higher bandwidth into smaller VT channels and having to regroup them to get the LAN traffic can be avoided.
- virtual concatenation has one or more of the following disadvantages:
- bursty LAN traffic bandwidth usage is typically quite low, which can result in significant waste when used over a fixed bandwidth pipe (e.g., the average use of a 1 OMbps link is 20% and, if an entire STS-1 is used, the efficiency becomes about 4%); and/or
- Inverse multiplexing is similar to the virtual concatenation. However, different SONET virtual tributaries (e.g., LINK#1-LINK#N) are not concatenated but are used as separate conduits of data transfer.
- SONET virtual tributaries e.g., LINK#1-LINK#N
- Data from a high bandwidth pipe such as a 10Mbps Ethernet LAN
- a high bandwidth pipe such as a 10Mbps Ethernet LAN
- the data is later recovered using standardinversemultiplexingprotocols.
- Inverse multiplexing suffers from the sameproblems ofbandwidth maximization as the virtual concatenation approach. In particular, bandwidth needs to be reserved in advance and all of the available bandwidth is not usable.
- inverse multiplexing suffers from one or more of the following disadvantages :
- bursty LAN traffic bandwidth usage is typically quite low, resulting in a significant waste when used over a fixed bandwidth pipe (e.g., if the average use of a 10Mbps link is 20% and if an entire STS-1 is used, then the efficiency becomes about 4%).
- VT e.g., LINK#1
- other VTs e.g., LINK#2-LINK#N
- the bandwidth cannot be dynamically adjusted on different VT channels.
- ATM VP multiplexing provides another conventional approach to attempt to fully utilize SONET bandwidth.
- ATM VP multiplexing fills the payload area with ATM cells, where packets are encoded in ATM cells and then placed inside a SONET SPE.
- CES ATM Circuit Emulation Service
- ATM network routing and switch-to-switch signaling of data paths are different from IP network routes, resulting in network operational complexity;
- a high percentage of network traffic consists of IP packets with small packet sizes of around 40 bytes.
- IP over ATM e.g., rfc2684 - Multiprotocol Encapsulation over ATM AAL5
- payload size slightly exceeds what can fit inside a single ATM cell.
- Such an excess results in transmission of two ATM cells, with the second cell that is mostly ATM overhead and stuffing bytes.
- the transmission of two ATM cells, along with other ATM overhead, requires allocating extra SONET bandwidth for IP transport.
- a SONET synchronous payload envelope SPE
- POH SONET synchronous payload envelope
- the node must now wait 125 ⁇ S for the partially filled packet to transfer down the link 32b-32n.
- the SONET ring 30 cannot handle Tl or T3 channels entirely in a payload space. The only way it can simultaneously support T1/T3 channels is by using virtual tributaries and by using some of the tributaries for non-Tl/T3 traffic.
- a significant percentage of network traffic comprises IP packets that are quite small in size. Because higher-speed concatenated SONET frames are large in size, many times a SONET SPE may not be completely filled with packets or cells at the origin. Because a SONET SPE carries only one type of data, the originating SONET node or other nodes downstream will not be able to add any different type of data to the SPE, and the SONET frame may be heavily underutilized. Such an under- utilization of the SONET frame degrades the overall bandwidth utilization of fiber capacity with
- FIG. 7 a system 50 is shown implementing multiple fiber optic networks.
- the system 50 is shown implementing aTl network 52, an ATM network 54 and a POS network 56.
- FIG. 8 a timing diagram illustrating transfer times of the multiple data types of FIG. 7 is shown.
- PDH channels are created by strict timing relationships between consecutive Synchronous Transport Signal, Level 1 (STS-1) frames (to form a superframe). Any intervening STS-1 frames containing ATM or POS packets will violate such timing specifications.
- STS-1 Synchronous Transport Signal
- Virtual concatenation concatenates several VT channels into bigger virtual pipes to carry higher bandwidth traffic. With such a protocol, while some virtual tributaries carry T1/T3 data as usual, others are concatenated for transport of higher bandwidth data traffic such as 10/100Mbps links.
- virtual concatenation allocates a fixed bandwidth for LAN. Virtual tributaries cannot dynamically adjust bandwidth usage on a packet-by-packet basis. While it is possible to change the concatenated bandwidth through software, such an implementation does not yield much for bandwidth utilization. Bursty LAN traffic bandwidth usage is typically quite low, resulting in significant waste when used over a fixed bandwidth virtual pipe (average use of a 10Mbps link is 20%, and if an entire STS-1 is used the efficiency becomes about 4%).
- Another problem with virtual concatenation is that while one virtual pipe may be overloaded with traffic, others may be underutilized. Virtual concatenation cannot dynamically adjust network loads on different channels.
- ATM VP multiplexing encodes packets in ATM cells and then inserts the cells inside a SONET SPE.
- the ATM VP multiplexing typically utilizes CES to carry DSO/1 PDH traffic.
- Network traffic statistics monitoring has shown that a significant percentage (about 45%) of network traffic comprises IP packets with small packet sizes (e.g., around 40 bytes).
- EP over ATM rfc2684 - Multiprotocol Encapsulation over ATM AAL5
- payload size slightly exceeds what can fit inside a single ATM cell.
- Such an arrangement results in transmission of two ATM cells, with the second cell that is mostly ATM overhead and stuffing bytes.
- This, with other ATM overheads means having to allocate extra SONET bandwidth for IP transport if ATM is used as a transport protocol.
- using ATM for sending different services requires implementation of ATM transport protocols and interworking for all related protocols (such as IP-over- ATM, Frame Relay- ATM
- IP packets that form the majority of data network traffic on the Internet.
- Data network traffic comprises variable-length IP packets and fixed-length ATM cells (i.e., 53 bytes).
- SONET/SDH rings As more and more data is being transported on SONET/SDH rings, there is a need to send variable-length packets on pre-existing SONET/SDH networks. These packets originate out of routers and other data access devices. While SONET/SDH networks must transport these data packets, they must also continue to support TDM-style fixed length packets for telephony and leased line applications.
- IP packets are constrained to go through some pre-configured
- VT channels while other VT channels may be under-utilized.
- VT channels Once a VT channel is dedicated for a particular traffic and is put on a specific circuit-switched path, the topology does not change, even if traffic conditions change.
- Conventional approaches have the following disadvantages (i) ATM and Packets are implemented on different rings because of QoS and timing issues; (ii) very high cost for new fiber and SONET equipment for Telco/ISP/MAN; (iii) only one type of packet goes inside a SONET SPE at one time (the remaining bytes of the frame with conventional SONET are wasted) (SONET packets go around the entire SONET ring, limiting bandwidth); and or (iv) the only way to support telephony channels along with data packets is to allocated part of SONET frame for packet data transmissions (which results in an inefficient bandwidth usage).
- One aspect of the present invention concerns a frame configured to (i) be transmitted on a network and (ii) store data packets in a pluraUty of channels.
- One or more of the plurality of channels may be configured to store one or more fragments of the data packets.
- Another aspect of the present invention comprises an apparatus comprising one or more nodes coupled to a network.
- Each node may be configured to receive and/or transmit one or more of a plurality of frames.
- Each of the plurality of frames may be configured to store data packets in a plurality of channels.
- One or more of the channels may be configured to store one or more fragments of the data packets separated by an offset pointer.
- the objects, features and advantages of the present invention include providing a method and/or architecture that may (i) provide a single SONET ring to carry a number of forms of data; (ii) allow a number of forms of data types to operate inside a single SONET SPE; (iii) permit filling of a fixed size payload area of a SONET/SDH network with data packets along with fixed bandwidth channels, (iv) allow fine-tuning of the available bandwidth of SONET/SDH to get exactly the T1/T3 bandwidth (or a fraction thereof, down to DSO bandwidth of 64kbps) required while using all of the remaining bandwidth for data packets, (v) provide bandwidth reuse at various nodes of a network; (vi) allow SONET sub-sections to run at full speed, effectively boosting SONET bandwidth; and or (vii) provide a significant savings in equipment and fiber optic infrastructures.
- FIG. 1 is a detailed block diagram of conventional fiber optics transmission data types
- FIG. 2 is a block diagram illustrating conventional transportation of higher bandwidth data packets
- FIG. 3 is a block diagram illustrating conventional transportation of higher bandwidth data packets
- FIG.4 is a block diagram illustrating inverse multiplexing for transporting higher bandwidth data packets
- FIG. 5 is a block diagram illustrating conventional transportation of higher bandwidth data packets
- FIG. 6 is a more detailed block diagram of the circuit of FIG. 4;
- FIG. 7 is a block diagram illustrating a conventional multiple fiber optic network system;
- FIG. 8 is a detailed block diagram illustrating a conventional timing operation
- FIG. 9 is a block diagram of a preferred embodiment of the present invention.
- FIG. 10 is a more detailed block diagram of the circuit of FIG. 9;
- FIG. 11 is a block diagram of a HDT frame inside a SONET SPE
- FIG. 12 is a block diagram illustrating transportation of higher bandwidth data packets
- FIG. 13 is a detailed block diagram of an operation of the present invention.
- FIG. 14 is a detailed block diagram of a variable length envelope
- FIG. 15 is a block diagram of a packet of FIG. 11;
- FIG. 16 is a more detailed block diagram of a header of FIG. 9;
- FIG. 17 is a flow chart illustrating an operation of the present invention.
- FIG. 18 is a flow chart illustrating an operation of the present invention.
- FIG. 19 is a flow chart illustrating an operation of the present invention.
- FIG. 20 is a block diagram illustrating an implementation of the present invention.
- FIG. 21 is a block diagram, illustrating an operation of the present invention.
- the present invention may provide a Hybrid Data Transport (HDT) protocol that may allow transmission of fixed bandwidth channels (e.g., T1/T3), variable-bandwidth data sources (e.g., ATM), IP and any other protocol data in a single SONET frame using a single fiber network.
- the protocol of the present invention may work seamlessly across a mix of SONET and non-SONET networks, and may yield cost savings in fiber infrastructure, equipment, and operation.
- an existing fiber network may be fully utilized to transport a number of different types of traffic.
- the present invention may additionally dynamically manage bandwidth usage on a packet-by-packet basis.
- the present invention may provide spatial reuse of bandwidth, allocation of PDH bandwidth in 64Kbps increments, protocol-independent MPLS (Multi-Protocol Label Switching) support, and/or seamless operation over point-to-point and ring networks with SONET/SDH, direct data-over-fiber configurations or other network configurations.
- the present invention may also be applicable to Synchronous Digital Hierarchy (SDH).
- SDH Synchronous Digital Hierarchy
- SONET is used as a general description for SONET/SDH networks with similar implementation for SDH networks. Additional details of the operation of the HDT protocol are also described in connection with direct data-over-fiber networks.
- FIG. 9 a block diagram of a system 100 is shown in accordance with a preferred embodiment of the present invention.
- the system 100 may comprise a number of devices 102a-102n connected to a network backbone 104.
- FIG. 10 illustrates the addition of a number of chips 106a-106n.
- the devices 102a- 102n may receive T1/T3 signals, ATM signals, and POS signals.
- the devices 102a- 102n may receive data in one or more of the following data transmission media: SONET, SDH, direct data over fiber (e.g., both in point-to-point or ring configuration) with or without SONET/SDH framing and other transmission methods needed to meet the design criteria of a particular implementation.
- SONET SONET
- SDH direct data over fiber
- the system 100 may provide an increase in the data traffic handling capabilities of SONET/SDH networks.
- the system 100 may implement a design of a SONET/SDH add drop multiplexer
- IP or other protocol packets of different lengths may be (i) added to a SONET/SDH SPE and (ii) terminated at a different network node (e.g., devices 102a-102n).
- the present invention may embed a header (and/or footer) 202 (e.g., a 32-bit packet header) to create a deterministic packet transport protocol.
- the packet header may comprise a 32-bit payload header 204a-204n that may precede each frame, regardless of the particular packet type stored within the frame.
- the protocol identification may be implemented as a few header bits configured to denote the particular type of packet (e.g., ATM, IP , PPP, Frame Relay, etc.) embedded within the payload portion of a particular frame.
- Bandwidth maximization may be implemented with another bit in the header 202 that may specify whether the packet may be reused by the intermediate SONET nodes 102a- 102n.
- the SONET framing may be left unchanged by implementing a single PSL (Path Signal Label) value 206 in a SONET Path Over Head (POH) 208 that is generally able to specify the various types of packets embedded within the payload of a particular frame.
- PSL Pulth Signal Label
- POH SONET Path Over Head
- the system 100 may be directly applicable to WDM/DWDM Fiber because individual packet framing is independent of SONET.
- the system 100 may be also used in IP-over-Fiber networks.
- FIG. 12 a more detailed example of the frame 200 is shown illustrating packet fragmentation across fixed bandwidth channels in accordance with the present invention.
- the frame 200 leverages the fact that SONET/SDH frames are normally synchronous in nature and that frame bytes are normally transferred in a single sequence within a timed window.
- An optical node may receive bytes from a synchronous frame (e.g., the frame 200) and generally have access to all the bytes in the particular SONET/SDH frame.
- the particular frame is generally of a fixed size (e.g., for a given SONET/SDH speed and type).
- the frames may be clearly marked and are normally accessible in a definitive manner using path overhead and line overhead markers.
- the system 100 may have different types of packets to span over available spaces inside particular SONET/SDH frame.
- the system 100 may provide an encapsulation 210 around the payload 212 that generally contains additional information about the packet.
- Available space may be filled in with data packets as usual.
- a particular packet cannot beplaced fully in the available space (e.g., because of an impending fixedbandwidth channel) the particular packet may be fragmented and may be continued in the next available space.
- a packet (or a packet fragment) generally contains an offset (to be described in more detail in connection with FIG. 13) that may point to the beginning of the next frame where the remainder of the packet is stored.
- the offset may be implemented, in one example, as a 32-bit offset field at the end of the packet. The offset may mark the particular location where the packet is continued after the current end of frame.
- a particular frame may be complete inside a SONET payload comprising outside framing bytes.
- any fragmentation may require each fragment to carry most of the IP header bytes with sequencing information.
- the sequence information allows the fragments to be reassembled.
- Internet protocol may allow a plain offset value to link the next packet fragment to the previous packet fragment within the frame.
- the continuing packet fragments) do not generally need internal header data repeated since the packet fragment(s) reside in a single SONET/SDH frame 100 and are transmitted in sequence within a synchronous frame.
- the frame 200 may permit filling of a fixed size payload area of SONET/SDH with data packets along with fixed bandwidth channels such as T1/T3.
- the frame 100 may reduce and/or eliminate bandwidth limitations imposed on data packets in fixed bandwidth channels.
- the frame 200 may provide a savings in equipment and fiber optic infrastructures.
- the frame 200 may permit fine-tuning of the available bandwidth of SONET/SDH to provide the bandwidth required for T 1/T3 while using the remaining bandwidth for data packets without requiring complex inverse multiplexing or virtual concatenation techniques.
- the frame 200 may provide advantages that may (i) permit filling of a fixed sizepayload area of a SONET/SDH network with data packets along with fixed bandwidth channels, (ii) allow fine-tuning of the available bandwidth of SONET/SDH to get exactly the T1/T3 bandwidth required while using all of the remaining bandwidth for data packets, and/or (iii) provide a significant savings in equipment and fiber optic infrastructures.
- the SONET/SDH payload envelope 200 (e.g., transmitted every 125 ⁇ S) maybe divided into variable length packets.
- the header 202 may comprise one or more of the following parameters: (i) packet length, (ii) length of CRC (Cyclic Redundancy Check), (iii) payload identifier header to describe the nature of packet, (iv) route labels that may help route packet inside network, (v) payload header CRC, (vi) actual payload, and/or (vii) payloads CRC.
- a basic unit of transmission is a Synchronous Transport Signal Level 1 (STS-1) or Optical Carrier Level 1 (OC1) signal. Both operate at 51.84 Mbit/s.
- STS-1 describes electrical signals, and OC1 refers to the same traffic after being converted into optical signals.
- SONET also allows channels to be multiplexed.
- An OC12 circuit for instance, may carry traffic from four OC3 links.
- An OC12 circuit may also carry a single channel, in which case the line is said to be concatenated.
- Such circuits may be described as OC3c, OC12c, and so on.
- SDH Synchronous Digital Hierarchy
- ITU International Telecommunication Union
- G.707 G.707
- interconnection of SONET and SDH networks may be relatively rare, several new transoceanic telecommunications projects make use of such links.
- the system 100 may maximize fiber bandwidth by implementing the Hybrid Data Transport
- the HDT protocol may allow dynamic management of packets to maximize bandwidth.
- the system 100 may allow the transport of different types of data over a single fiber link. With the system 100, IP (or other protocol) packets, Packet-Over-SONET (POS), ATM cells, G.702-based PDH (T1/T3), SRP, Frame Relay, and other types of data may be mixed inside a SONET payload and dynamically and sent on a single fiber (as shown in FIGS. 9 and 10).
- the system 100 may provide robust scrambling and unified packet transport over ring and point-to-point networks and may be well suited for non-SONET configurations such as point-to-point WDM networks.
- the SONET SPE 200 may be filled with HDT frames that may carry a wide mix of fixed and variable bandwidth data.
- the Simple Data Link (SDL) framing protocol prefixes a payload with a 32-bit word, 16 bits of which hold the length of the packet and the other 16 bits contain CRC (Cyclic Redundancy Check) for the length field.
- SDL may provide a robust CRC- 16 based framed boundary delineation mechanism compared to hybrid mix of point-to-point and ring topologies.
- the system 100 may implement a single fiber link that may be used for sending different kinds of traffic to use the full capacity of the link.
- the system 100 may allow VT or sub-VT channels to be eliminated.
- ATM cells, IP (and other protocols) packets, PPP, frame relay, NxDSO, T1/T3 and others may be mixed inside the SPE on a packet-by-packet basis.
- PDH channels (such as Tl/El) maybe dynamically allocated anywhere inside the SONET payload in 64Kbps bandwidth increments. Bandwidth may be reusable in fine granularity in 64Kbps increments, with any type of data. For example, an IP packet maybe dropped at a node (e.g., B) where the node B may reuse the packet area for inserting ATM cells, frame relay, PDH traffic, or any other data type.
- the system 100 may transport many packets of one or more different data types. The particular type of data may be placed inside a single SONET SPE or data-over-fiber frame while preserving time dependency of data packets, such as PDH.
- the system 100 may be implemented without terminating the whole link capacity at each node.
- Destination nodes may indicate a start of the packet inside a SONET payload. Other packets may pass through the node. Direct data-over-fiber configurations (e.g., without SONET framing) may be easily supported with full link monitoring and management. Support may also be provided for variable-size packet SONET add/drop multiplexer (SONET ADM) devices. Variable-size packets may be transported inside a SONET SPE and nodes may cross-connect and add/drop the packets on different ports.
- SONET ADM variable-size packet SONET add/drop multiplexer
- the system 100 may provide protocol-independent transport of MPLS labels.
- the HDT may provide for transmission of MPLS labels outside of protocol frame (rather than embedding such labels between data link and network layers as in conventional approaches).
- Intermediate SONET and optical fiber nodes may be used to create switching and add drop systems without having to become protocol-aware.
- the HDT may allow setting up of fast-reroute fail-switchover paths over a hybrid of ring and point-to-point networks using MPLS labels, without requiring nodes to be protocol-sensitive. Such an implementation may eliminate the need to provision and reserve completely unused backup paths on SONET rings.
- the payload headers 204a-204n may precede every packet to carry the information to support HDT.
- a uniform structure of the header across a variety of packet types generally simplifies design of optical nodes for packet processing for both SONET and direct data-over-fiber networks.
- the headers 204a-204n may also contain a reusability bit that is set by the sending node. If the reusability bit is cleared, a destination node may reset the data identification bits to free up the packet area for reuse by new data packet. The packet area may be reused at either at the destination node or other downstream nodes.
- An offset locator operation 230 for a next packet fragment location is shown.
- An offset pointer 232 may point to a header location 234 in the frame where the next portion of the packet is stored.
- a packet may have a number of offset pointers if the packet is stored in a number of locations.
- HDT framing may show the offset word at the end of frame.
- the HDT is generally able to extend data identification beyond PSL-based SPE-level data typing and put multiple data types inside a SONET SPE.
- a value of 0000 may indicate the packet area (e.g., the length of the packet area is given by the length value in the outside SDL framing) that does not generally contain any useful data and can be reused for storing new data.
- HDT may easily support traditional PDH and other guaranteed bandwidth channels.
- a frame repeats every 125 ⁇ S, resulting in abandwidth of 64KHz for every byte in the payload.
- the SONET SPE 200 may comprise anumber of packets 220a-220n and anumber of empty packets 222a-222n.
- the packet payload header 204a of the packet 220a may identify the packet/protocol.
- the packet payload header 204a may identify a packet type of the packet 220a stored (or transported).
- the payload header 204a may tell what kind of packet/protocol (such as Ethernet, PPP, IP, Frame Relay, ATM cells, Tl, etc.) is inside a payload of the packet 220a.
- packet/protocol such as Ethernet, PPP, IP, Frame Relay, ATM cells, Tl, etc.
- Different protocols may be supported at two ends (e.g., the devices 102a-l 02n) of a network without the need for provisioning in advance.
- conventional approaches use a protocol over WAN which is usually negotiated between two parties at the ends devices 102a-102n of the WAN link.
- the payload header 204a maybe used to tell whether one or more of the empty packets 222a-
- a receiver may mark the SONET SPE 200 as reusable. Nodes on the fiber network 100 may mark different sections of the SONET SPE 200 as reusable by the other nodes 102a-102n. Provisioning of TDM channels may provide the ability to mark a portion (or many portions) of a SONET SPE payload area as non-reusable. With a non-reusable area, even when a receiver receives the packet, another receiver cannot reuse the packet area. However, the same receiver may reuse the non- reusable area.
- Any packet may be marked in any fashion to support, for example, a dynamic mix of data and voice (TDM) traffic on a
- SONET/SDH network Such an implementation is not possible with current technologies.
- the present invention may solve the problem of mixed value and data transmissions faced by telephone carriers and data providers.
- intermediate nodes may detect these packets (e.g., the reusability bit is reset), note the offsets of these packets, and preserve the respective offsets when recreating the frame (e.g., after adding packets from local input ports) for outbound traffic.
- An SDL framing 262 may be in the first 16 bits and may contain the length of the entire payload, including SDL framing bytes.
- a 16 bits of CRC-16 264 may be provided on the length field (e.g., xl6 + xl2 + x5 + 1).
- a next fragment offset 270 may be a 16-bit value showing the location offset of a next packet fragment (if any) of the packet. The next fragment offset 270 is generally taken from the start of a current packet.
- a header CRC 272 may be computed over payload header bytes only, with same scrambling polynomial used for SDL framing.
- a payload area 274 may contain the actual packet to be transmitted over the WDM or SONET link.
- the payload area 274 may contain one of a number of types of protocol packets, such as Ethernet, ATM, GR.702, PPP, Frame Relay, etc.
- a payload CRC 276 may be user-controlled value and may be computed for the payload bytes only.
- the payload CRC 276 is generally either a 16 or 32-bit value, depending on mutual negotiation between sending and receiving stations. Referring to FIG. 16, various parameters of the packet header 204a are shown. The particular bit width of the payload header 204a may be varied accordingly to meet the design criteria of a particular implementation.
- a packet identifier 280 (e.g., D3: DO) generally identifies the type of packet in the payload. For example, a value of 0000 may represent a null packet. A null packet may indicate that the payload area may be reused. When a packet is dropped at a node, the length field does not generally need to be modified for the packet, only the D3 : DO bits need to be cleared.
- a header data area 282 may carry MPLS labels (e.g., outside of payload area). Operation administration and maintenance (OAM) bytes 282 may be used for link management, or any other data separately from the payload.
- a reusability area 284 (e.g., D7) may be a "1". If a SONET node can reuse a particular packet area, the size of the packet area may be given by the packet length field 264 of the SDL header. If the bit D7 is set to a "0", then a node will not generally mark the packet area as re-usable, even after apacket has been dropped.
- the particular nodes of the various configuration bits may be varied (e.g., inverted) accordingly to meet the design criteria of a particular implementation.
- a header length area 286 may include, in one example, a 32-bit payload header.
- a fragment identifier area 288 (e.g., D17: D16) maybe implemented as a two word value.
- a value of "00” may indicate that the payload area contains a complete packet.
- a value of "01 " may indicate the beginning packet of a fragmentation sequence.
- a value of "10” may indicate a continuation of packets.
- a value of "11” may mark the last fragment in the series.
- Other particular bit patterns maybe implemented accordingly to meet the design criteria of a particular implementation.
- a padding area 290 may indicate a minimum packet length.
- the minimum packet length may be 4 bytes (e.g., 2 bytes length + 2 bytes CRC). Idle bytes at the end of packets and elsewhere may be marked by a length field of "0000". In instances there may be less than 4 bytes left between packets. In this case, it may be impossible to place a SDL null packet. Such idle bytes are shown as tail-end padding for the preceding packet.
- An unused area 292 (e.g., D31:20) may be used for additional expansion.
- a node may receive a frame at a block 300.
- a block 302 may determine if the received frame is an HDT frame. The block 302 may use the PSL value in the POH to determine the type of protocol carried inside the SPE. If the PSL shows POS, ATM, or PDH traffic, the receive operation may proceed to the block 304. If no HDT packets are present, a block 306 handles the POS/ATM/PDH packet. If in the block 302, the PSL shows the SPE contains HDT frames, the node uses additional logic for HDT processing to detect and route different types of packets embedded in the SONET SPE 200.
- a block 308 may read the POH.
- a block 310 may determine a first packet of the SONET SPE 200.
- a block 312 may read a length and CRC of the first packet.
- Ablock 314 may determine a match of the length and the CRC. If a non-match of the length and CRC occurs, the receive operation is generally set to ablock 316. The block 316 may read a next word of thepacket from the SONET SPE 318. If amatch occurs, the receive operation may process the packet.
- hardware e.g., implemented in the system 100
- ATM cells are generally retrieved by first looking at the PSL value to determine their presence and then reaching the SONET SPE to get fixed byte ATM cells, either with or without HEC-based cell delineation. For example, if the payload header in the HDT shows the payload contains ATM cells, the hardware device generally retrieves payload bytes (up to number of bytes specified in length field) and sends the byte stream to an existing ATM cell processing logic. The ATM cell processing logic may then work on the byte stream using HEC hunting just as if the SPE contained only ATM cells in its payload. Referring to FIG. 18, an example of a processing operation 320 is shown.
- a device supporting Hybrid Data Transport HDT protocol generally operates much the same as a normal SONET/SDH transport operates.
- HDT adds a header to packets to allow their mixing within the same SPE 200.
- Much of the HDT processing is generally related to processing of the header to identify the type of packet and thenpassing the starting address of data bytes to standard logic for handling the individual packet type.
- Support of PDH-type channel typically requires a fixed starting location for the channel in every frame. If PDH support is not needed, packets of any mix may be put anywhere inside the SPE 200 to achieve excellent bandwidth utilization without much operational complexity. When fixed bandwidth channels are carried, some data packets may need to be fragmented when the packet hits a static location. Fragmentation of a packet, however, is generally easily achieved in SONET networking because all bytes in the SPE 200 are transmitted sequentially. Additionally, recovering fragments and putting the fragment together may be simply accomplished.
- a device supporting HDT may receive a packet to be transmitted from a system side.
- a node may take inputs from different sources 402, encapsulate the packets with an SDL length/CRC fields 404, add an HDT header 406 to each of the packets, and then store the packets inside the SPE.
- the node may not send a fresh frame on the network in order to transmit the packets.
- a TDM channel check 408 may determine a reusability of the SPE 200.
- the transmit operation 400 may reuse available space in an incoming SPE (containing HDT frames).
- the transmit operation 400 may then may proceed to a length check 410 to see if there is any space available to insert the packet to be sent. If there is enough space, the entire packet is stored (with proper SDL framing and HDT header bytes). Any remaining bytes, depending on the size, are generally either (i) filled with a null HDT packet (e.g., the payload header identification bits are 0000), (ii) filled with SDL null packets (e.g., pairs of length/CRC with a null length field), or (iii) accounted for as tail- end padding (e.g., if the size is less than 4 bytes).
- a null HDT packet e.g., the payload header identification bits are 0000
- SDL null packets e.g., pairs of length/CRC with a null length field
- tail- end padding e.g., if the size is less than 4 bytes.
- the packet is generally fragmented.
- a portion of the packet may be stored at one place and other fragments may be stored at another free location.
- the first fragment offset pointer may contain the starting location of second fragment. Because bytes are transmitted sequentially in the SPE 200, reassembling fragments may be easily achieved.
- the node checks the frame to see if there are unused/reusable areas in the incoming/queued frame that can be used for sending data. If there is enough space available in the frame, the node fills the space with additional data before sending the frame out.
- PDH channels of any bandwidth may be provisioned anywhere inside the SONET SPE.
- PDH bytes must begin at the same offset inside the SONET SPE.
- allocation of PDH channels at different locations inside a SONET SPE may create fragments of unused bytes all over the SONET SPE. For efficient transport of variable-size IP packets, these unused bytes may be utilized for IP data.
- an operation 500 for CRC error checking is shown. If bit errors occur at an upstream node that receives a packet with a correct CRC, the downstream node will never learn about the bit errors if the upstream node recomputed CRC for the packet before transmission.
- a node that receives the packet usually swaps the label with a different value, pops the label, or adds a new label to the stack. If MPLS is embedded inside a packet, payload CRC will change at each node.
- One solution would be to check for CRC for ingress, but not to re-compute the CRC on egress.
- An efficient way to implement such CRC computation is to separate header CRC from payload CRC. This way, header CRC is recomputed easily and quickly at intermediate nodes while the payload CRC is preserved end-to-end. With HDT, all header labels and other temporary information for the packet may be carried outside of the payload so the payload data/CRC is not modified at any of the intermediate nodes.
- a SONET node may be a data-aware add/drop multiplexer, a digital cross-connect, or a router/access multiplexer sitting on a SONET ring.
- Such devices may implement HDT protocol for data encapsulation and transport over SONET and WDM networks.
- Traditional circuitry for ATM cell delineation, PPP processing and other protocol handling may be implemented similar to conventional approaches, with some additional added circuitry for HDT encapsulation and decapsulation.
- the path signal label (PSL) value proposed for use with the HDT may be the same as the one for SDL frames. Referring to FIG. 21, an example of spatial reuse with HDT is shown.
- Spatial reuse of bandwidth across anumber of network nodes may be achieved by permitting full or partial termination of individual packets at any node. Spatial reuse of bandwidth reclaimed from the terminated packet may increase performance. HDT may provide an ideal way to achieve spatial reuse of SONET bandwidth. Using add/drop of hybrid data, nodes can reuse released bandwidth for transmission of any of the various kinds of data.
- initial bytes may be placed in a small transit buffer.
- a particular node A, B, C, D may be able to determine whether the packet belongs to the node. If the packet does not belong to the node, the bytes are streamed out of transit buffer to the output port. However, the packet may belong to the node A, B, C, D if, for example, (i) the D7 bit is set in the payload header, (ii) the packet area has been reserved for a fixed bandwidth channel such as a PDH, and/or (iii) in this case, the D3 : DO bits are not cleared.
- the node may clear the D3: DO field to mark the packets void and reusable, where the bytes belonging to the packet are sent to system.
- the number of bytes sent to the system may be specified in the length field of the SDL header. If the header shows fragmentation then a packet is received in many fragments and sent out to the system until the last fragment is received. Packets may be added either using a fresh SONET SPE or by reusing bytes inside an incoming or previously queued frame.
- the decision of which packet to add to a void or reusable packet area inside an SPE can be made on following lines by (a) selecting a packet (or a collection of packets) that will fit inside the reusable area, (b) selecting all packets that can fit inside the reusable space, or (c) selecting a packet based on QoS parameters or packet priority. Since SONET frames repeat at 125ms intervals, packet transmission may be arranged to achieve a desired rate. Once a packet is selected for addition to the SPE, the node creates a payload header by setting payload type, reusability and other bits for the packet. The circuit 100 may then add the header to the payload.
- the SDL framing mechanism may use length CRC pair information as a header and a frame delimiter.
- SDL provides a robust scrambling and frame locator technique and may be used for direct data-over- fiber networks where SONET framing may not be used.
- Implementing OAM packets may eliminate the need for complex SONET framing and link management overheads.
- the HDT protocol structure may operate unmodified. Point-to-point WDM networks and ring-based SONET networks (or any other network) may easily be mixed and connected to each other. With a powerful support for MPLS (that may be transported independently of payload), networks may be designed that may have alternative LSP (Label Switched Paths) links for a highly robust redundancy.
- LSP Label Switched Paths
- nodes on a SONET ring may be connected through another network that may be entirely different from the ring.
- the backup path could be a high-speed point-to-point link or a ring network that may be geographically quite diverse.
- the HDT protocol may permit configuration of these networks quite easily without requiring complex protocol translation logic for different network configuration.
- the present invention may use a packet payload header to identify the kind of packet inside. These identifier bits tell what kind of packet/protocol (e.g., such as Ethernet, PPP, IP, Frame Relay, ATM cells, Tl, etc.) is inside the payload. Using such a technique, different protocols may be supported at two ends without the need for advanced provisioning. Using conventional methods, the use of a single protocol over a WAN needs to be negotiated.
- the identifier may indicate whether one or more packet areas inside SONET SPE may be reused at an intermediate node. Conventional SONET networks require the SONET frame to travel around the ring until removed by the sender. Even when the receiving node received a packet, the frame went around the network, wasting bandwidth. With the present invention, not only may a receiver mark a SONET SPE as reusable, but differentreceivers on the fiber network may mark different sections of SONET
- SPE area as reusable when a packet is received by different receivers.
- the present invention may provide the ability to mark a portion (or many portions) of a
- SONET SPE payload area as non-reusable.
- the packet area is not generally reused by another receiver/transmitter.
- the same receiver may reuse the markedpayload area for add/drop applications. Allowing the same receiverto re-use apacket may help TDM channels and packet data within a single SPE.
- bit definitions inside a payload header may change as further research is conducted on the fiber data protocol operation. Such changes in bit definitions are common in data communication protocols and do not change the nature and content of present invention.
- the present invention often refers specifically to SONET.
- SDH Hierarchy Protocol
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Time-Division Multiplex Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Applications Claiming Priority (11)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US535890 | 1974-12-23 | ||
US523476 | 2000-03-10 | ||
US09/523,476 US6771663B1 (en) | 2000-02-23 | 2000-03-10 | Hybrid data transport scheme over optical networks |
US09/523,576 US6778561B1 (en) | 2000-02-23 | 2000-03-10 | Hybrid data transport scheme over optical networks |
US523576 | 2000-03-10 | ||
US09/535,717 US6973084B1 (en) | 2000-02-23 | 2000-03-27 | Hybrid data transport scheme over optical networks |
US09/535,889 US6847644B1 (en) | 2000-02-23 | 2000-03-27 | Hybrid data transport scheme over optical networks |
US09/535,890 US7006525B1 (en) | 2000-02-23 | 2000-03-27 | Hybrid data transport scheme over optical networks |
US535889 | 2000-03-27 | ||
US535717 | 2000-03-27 | ||
PCT/US2001/007780 WO2001069834A1 (en) | 2000-03-10 | 2001-03-09 | Hybrid data transport scheme over optical networks |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1266476A1 EP1266476A1 (en) | 2002-12-18 |
EP1266476A4 true EP1266476A4 (en) | 2009-08-05 |
Family
ID=27541837
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP01916564A Withdrawn EP1266476A4 (en) | 2000-03-10 | 2001-03-09 | Hybrid data transport scheme over optical networks |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1266476A4 (en) |
AU (1) | AU2001243574A1 (en) |
WO (1) | WO2001069834A1 (en) |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2838005B1 (en) * | 2002-03-28 | 2004-12-24 | Cit Alcatel | DYNAMIC METHOD OF INSERTING DATA TO THE NODES OF AN OPTICAL TRANSMISSION NETWORK |
US7616637B1 (en) | 2002-04-01 | 2009-11-10 | Cisco Technology, Inc. | Label switching in fibre channel networks |
FR2846185B1 (en) * | 2002-10-21 | 2005-02-25 | Cit Alcatel | IMPROVED ROUTER WITH INSERTION AND / OR EXTRACTION OF RESOURCES |
KR100547864B1 (en) * | 2003-08-02 | 2006-01-31 | 삼성전자주식회사 | Data Processing Method in GPON |
US7535930B2 (en) | 2003-04-10 | 2009-05-19 | Samsung Electronics Co., Ltd. | GEM frame structure showing payload type of frame and method for processing data thereof |
FR2864395B1 (en) * | 2003-12-23 | 2006-04-21 | Cit Alcatel | PACKET SWITCHING SYSTEM FOR COMMUNICATION NETWORK NODE |
DE602007004713D1 (en) | 2007-05-10 | 2010-03-25 | Nokia Siemens Networks Spa | Method for transmitting multistandard data over a communications network |
US8416770B2 (en) * | 2009-07-20 | 2013-04-09 | Futurewei Technologies, Inc. | Universal service transport transitional encoding |
CN102014063A (en) * | 2010-11-30 | 2011-04-13 | 北京华环电子股份有限公司 | Method and device for multiplexing multichannel universal asynchronous receiver/transmitter (UART) to time-division multiplexing (TDM) |
CN116418734B (en) * | 2023-06-09 | 2023-08-18 | 湖北微源卓越科技有限公司 | Low-delay packet sending method and device |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5796944A (en) * | 1995-07-12 | 1998-08-18 | 3Com Corporation | Apparatus and method for processing data frames in an internetworking device |
EP0982969A2 (en) * | 1998-08-27 | 2000-03-01 | Nortel Networks Corporation | Payload mapping in synchronous networks |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA2243359A1 (en) * | 1996-01-31 | 1997-08-07 | Ipsilon Networks, Inc. | Improved method and apparatus for dynamically shifting between routing and switching packets in a transmission network |
US5912895A (en) * | 1996-05-01 | 1999-06-15 | Northern Telecom Limited | Information network access apparatus and methods for communicating information packets via telephone lines |
US6097720A (en) * | 1998-04-07 | 2000-08-01 | 3Com Corporation | Enabling multicast distribution efficiencies in a dialup access environment |
US6212185B1 (en) * | 1998-10-14 | 2001-04-03 | Nortel Networks Corporation | Multiple network address resolution |
-
2001
- 2001-03-09 EP EP01916564A patent/EP1266476A4/en not_active Withdrawn
- 2001-03-09 WO PCT/US2001/007780 patent/WO2001069834A1/en active Application Filing
- 2001-03-09 AU AU2001243574A patent/AU2001243574A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5796944A (en) * | 1995-07-12 | 1998-08-18 | 3Com Corporation | Apparatus and method for processing data frames in an internetworking device |
EP0982969A2 (en) * | 1998-08-27 | 2000-03-01 | Nortel Networks Corporation | Payload mapping in synchronous networks |
Non-Patent Citations (2)
Title |
---|
DOSHI B T ET AL: "A SIMPLE DATA LINK PROTOCOL FOR HIGH-SPEED PACKET NETWORKS", BELL LABS TECHNICAL JOURNAL, WILEY, CA, US, vol. 4, no. 1, 1 January 1999 (1999-01-01), pages 85 - 104, XP000870423, ISSN: 1089-7089 * |
See also references of WO0169834A1 * |
Also Published As
Publication number | Publication date |
---|---|
AU2001243574A1 (en) | 2001-09-24 |
EP1266476A1 (en) | 2002-12-18 |
WO2001069834A1 (en) | 2001-09-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6771663B1 (en) | Hybrid data transport scheme over optical networks | |
US6847644B1 (en) | Hybrid data transport scheme over optical networks | |
US7006525B1 (en) | Hybrid data transport scheme over optical networks | |
US7515605B2 (en) | Efficient transport of TDM services over packet networks | |
US6636529B1 (en) | Semi transparent tributary for synchronous transmission | |
US6999479B1 (en) | Hybrid data transport scheme over optical networks | |
US6704326B2 (en) | Payload mapping in synchronous networks | |
US20020083190A1 (en) | Apparatus and method for GFP frame transfer | |
US20020176450A1 (en) | System and methods for selectively transmitting ethernet traffic over SONET/SDH optical network | |
US7656910B2 (en) | Add drop multiplexing method, apparatus and system based on GFP | |
US20040184450A1 (en) | Method and system for transport and routing of packets over frame-based networks | |
US8416770B2 (en) | Universal service transport transitional encoding | |
US20040252688A1 (en) | Routing packets in frame-based data communication networks | |
US6778561B1 (en) | Hybrid data transport scheme over optical networks | |
US7133415B2 (en) | SONET circuit emulation with VT compression | |
CN100493075C (en) | Method for hybrid transmission of variable-length data packet and fixed length cell, and adaptation device | |
US6973084B1 (en) | Hybrid data transport scheme over optical networks | |
WO2001069834A1 (en) | Hybrid data transport scheme over optical networks | |
EP1339183B1 (en) | Method and device for transporting ethernet frames over a transport SDH/SONET network | |
US20040105453A1 (en) | Capacity re-use in data communication networks | |
US8532137B1 (en) | Network architecture for a packet aware transport network | |
US6987766B2 (en) | Transport of SONET signals over an optical communications network | |
US20010015980A1 (en) | Mapping of dynamic synchronous transfer mode network onto an optical network | |
Jha | A hybrid data transport protocol for SONET/SDH and direct data over optical networks | |
Yang et al. | Channel statistical multiplexing in SDH/SONET networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20021009 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR |
|
AX | Request for extension of the european patent |
Free format text: AL;LT;LV;MK;RO;SI |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20090707 |
|
17Q | First examination report despatched |
Effective date: 20090924 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: PURLIEU WIRELESS LTD. LLC |
|
APBK | Appeal reference recorded |
Free format text: ORIGINAL CODE: EPIDOSNREFNE |
|
APBN | Date of receipt of notice of appeal recorded |
Free format text: ORIGINAL CODE: EPIDOSNNOA2E |
|
APBR | Date of receipt of statement of grounds of appeal recorded |
Free format text: ORIGINAL CODE: EPIDOSNNOA3E |
|
APAF | Appeal reference modified |
Free format text: ORIGINAL CODE: EPIDOSCREFNE |
|
APBT | Appeal procedure closed |
Free format text: ORIGINAL CODE: EPIDOSNNOA9E |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20151001 |