Patent Application
20060067314
Networks such as the Internet, Local Area Networks (LANs), and Wide Area Networks (WANs) typically transmit data between devices via packets or frames of data. Packets and frames typically include overhead and payload portions. Overhead portions can carry a variety of control and status information needed to maintain the well being of the network. Payload portions may carry data. As frame transmission rates in networks increase, it is desirable for network equipment to more rapidly process frames received from the network and prepare frames for transmission to the network.
Note that use of the same reference numbers in different figures indicates the same or like elements.
Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrase “in one embodiment” or “an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in one or more embodiments.
As used herein, a “packet” means a sequence of one or more symbols and/or values that includes overhead and payload portions. As used herein, a “frame” means a sequence of one or more symbols and/or values that includes overhead and payload portions. As used herein, “overhead” means one or more symbols and/or values that may be added to a digital signal that can be used to provide information relating to network operation and be used in the processing of packets or frames, including information such as, but not limited to, destination address, source address, administration, and maintenance. As used herein, a “payload” means data, such as a data field, block, or stream as well as packets and frames of any protocol format. As used herein, “encapsulation” means any packet or frame format for transporting information between source and destination devices. As used herein, “egress units” means any packet or frame to be transmitted to a network. As used herein, “ingress units” means any packet or frame received from a network.
Host-control plane controller 105 may control and configure operations of all devices in system 100 (including but not limited to system fabric 130 and line cards 110 and 120). For example, host-control plane controller 105 may program/provision data processor 124 of line card 120 to control the arrangement of content in egress units and the processing of content of ingress units. Host-control plane controller 105 may communicate with devices in system 100 using bus 135. Host-control plane controller 105 may be implemented using a line card.
Bus 135 may provide intercommunication among host-control plane controller 105, overhead processing resource 150, line card 110, line card 120, and system fabric 130. Bus 135 may comply with Peripheral Component Interconnect (PCI) Local Bus Specification, Revision 2.2, Dec. 18, 1998 available from the PCI Special Interest Group, Portland, Oreg., U.S.A. (as well as revisions thereof); PCI Express described in The PCI Express Base Specification of the PCI Special Interest Group, Revision 1.0a (as well as revisions thereof); or PCI-X Specification Rev. 1.0a, Jul. 24, 2000, available from the aforesaid PCI Special Interest Group, Portland, Oreg., U.S.A., although other standards may be used.
Line card 110 may be implemented as a SONET/SDH add-drop multiplexer, a Fibre Channel compatible line input, an Ethernet line input, a SONET/SDH line input, or a line card similar to line card 120, although line card 110 may provide other operations.
Line card 120 may be implemented as a transceiver capable of transmitting egress units to a network and receiving ingress units from a network in compliance with SONET/SDH as well as other protocols such as OTN, although other standards may be used. For example, the network may be any network such as the Internet, an intranet, a local area network (LAN), storage area network (SAN), a wide area network (WAN). For example, SONET/SDH and OTN are described for example in: ITU-T Recommendation G.709 Interfaces for the optical transport network (OTN) (2001); ANSI T1.105, Synchronous Optical Network (SONET) Basic Description Including Multiplex Structures, Rates, and Formats; Bellcore Generic Requirements, GR-253-CORE, Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria (A Module of TSGR, FR-440), Issue 1, December 1994; ITU Recommendation G.872, Architecture of Optical Transport Networks, 1999; ITU Recommendation G.825, “Control of Jitter and Wander within Digital Networks Based on SDH” March, 1993; ITU Recommendation G.957, “Optical Interfaces for Equipment and Systems Relating to SDH”, July, 1995; ITU Recommendation G.958, Digital Line Systems based on SDH for use on Optical Fibre Cables, November, 1994; and/or ITU-T Recommendation G.707, Network Node Interface for the Synchronous Digital Hierarchy (SDH) (1996).
One embodiment of line card 120 may include physical layer processor 122, data processor 124, and network processor 126, and bus 127. Physical layer processor 122 may receive optical or electrical signals from a network and prepare the signals for processing by downstream elements such as data processor 124. For example, for ingress units, physical layer processor 122 may convert an optical signal to electrical format, perform physical layer processing, and/or remove jitter from signals from the network. For egress units, physical layer processor 122 may remove jitter from signals provided by upstream devices such as data processor 124, perform physical layer processing, and prepare signals for transmission to the network, which may be optical or electrical format.
Data processor 124 may utilize embodiments of the present invention to construct egress units in formats such as SONET/SDH and/or OTN (although other formats may be used). For ingress units, data processor 124 may utilize embodiments of the present invention to process such ingress units in compliance with formats such as SONET/SDH and/or OTN (although other formats may be used).
Network processor 126 may provide payloads to data processor 124 for encapsulation and transmission to a network in egress units. Network processor 126 may receive payloads from ingress units from data processor 124. For example, data processor 124 and network processor 126 may intercommunicate using an interface compatible for example with SPI-4 (described for example in the Optical Internetworking Forum document OIF-SPI4-02.1), although interfaces compatible with other standards may be used.
Network processor 126 may perform layer 2 or layer 3 (as well as other higher layer level) processing on payloads provided by and to data processor 124 as well as operations such as, but not limited to, classification, metering and policing, queue management, transmit scheduling, and traffic shaping in conformance with applicable protocols. For example, network processor 126 also may perform traffic management at the internet protocol (IP) layer (described for example in RFC 791 (1981) available from the Defense Advanced Research Projects Agency). Network processor 126 may intercommunicate with switch fabric 130 using backplane interface 140 to transfer and receive packets/frames having formats such as, but not limited to, High Level Data Link Control (HDLC), internet protocol (IP), Asynchronous Transfer Mode (ATM), Generic Framing Procedure (GFP), and Ethernet.
Bus 127 may provide intercommunication among physical layer processor 122, data processor 124, and network processor 126. Bus 127 may be compliant with the same standards as those of bus 135.
In one embodiment, components of line card 120 may be implemented among the same integrated circuit. In one embodiment, components of line card 120 may be implemented among several integrated circuits that intercommunicate using, for example, a bus or conductive leads of a motherboard. In one embodiment, components of line card 120 may be implemented as any or a combination of: hardwired logic, software stored by a memory device and executed by a microprocessor, firmware, an application specific integrated circuit (ASIC), and/or a field programmable gate array (FPGA).
Overhead processing resource 150 may provide overhead for inclusion in egress units to line cards 110 and 120 as well as other line cards which are not depicted. Overhead processing resource 150 may receive overhead from ingress units for processing. Overhead processing resource 150 may intercommunicate with line cards 110 and 120 as well as other line cards which are not depicted using, for example, at least one serial or parallel optical or electrical link. In one embodiment, overhead processing resource 150 may intercommunicate with host control plane controller 105, line cards 110 and 120 as well as other line cards which are not depicted using system fabric 130 and/or bus 135. In one embodiment, overhead processing resource 150 may intercommunicate with line cards 110 and 120 as well as other line cards which are not depicted using an Advanced Telecom Computing Architecture (ATCA) compliant motherboard. In one embodiment, overhead processing resource 150 may be implemented using one or more integrated circuits interconnected and accessible using a single line card.
Backplane interface 140 may be implemented as a single or multi-pin interface and may be used by line cards to intercommunicate with system fabric 130 or to intercommunicate with other line cards. For example, backplane interface 140 may be compatible with TFI-5 (described, for example, in TDM Fabric to Framer Interface Implementation Agreement (2003) available from the Optical Internetworking Forum (OIF)) or CSIX (described in CSIX-L1: Common Switch Interface Specification-L1 (2000)), although other standards may be used. System fabric 130 may transfer payloads as well as other information among line cards based on relevant address and header information. System fabric 130 can be implemented as a packet switch fabric or a time domain multiplexing (TDM) cross connect.
With respect to ingress units, data processor 205 may process a portion of overhead and transfer a portion of the overhead to overhead processor 215 for processing. With respect to payload received by data processor 205 and to be transmitted through a network to a destination device in an egress unit, data processor 205 may provide a portion of overhead and combine a portion of the overhead with overhead received from overhead processor 215 to form such egress unit.
In one embodiment, data processor 205 and overhead processor 215 may divide responsibility for processing or generating overhead. For example, in one embodiment, data processor 205 may generate or process overhead that is more time critical than that generated or processed by overhead processor 215. For example, in one embodiment, data processor 205 may generate or process overhead that can be generated or processed within a time period to generate or process an associated ingress or egress unit (i.e., generating or processing of the overhead tracks generation or processing of the associated ingress or egress unit). For example, in one embodiment, overhead processor 215 may generate or process overhead that can lag formation or processing of an associated egress or ingress unit, such as within a time to generate a next sequential ingress or egress unit, although other latency periods may be used.
For example, in one embodiment, data processor 205 may generate or process overhead relating at least to packet or frame delineation, payload delineation, as well as bit error monitoring and counting. For example, in one embodiment, overhead processor 215 may generate or process overhead related to management of nodes such as control channels, user channels, and user side band communication channels. For example, for SONET/SDH, data processor 205 may generate or process: (1) delineation overhead bytes A1, A2; (2) pointer overhead bytes H1, H2, H3; (3) state monitoring overhead bytes B1, B2, M0, M1; (4) trace identification overhead byte J0; and (5) protection signaling and alarm indication overhead bytes K1, K2; whereas overhead processor 215 may process or generate control channel overhead bytes D1-D12, E1, E2, F1, F2, F3, K3, and a portion of the N1 byte, although other allocations may be used. For example, J0, K1, and K2 bytes may be processed or generated by data processor 205 or overhead processor 215.
For example, in one embodiment of the present invention, for ingress units, data processor 205 may transfer overhead to overhead processor 215 using payload portions of a standardized transport packet or frame, which can be Ethernet, TFI-5, OTN or SONET/SDH compliant, although other formats may be used. Similarly, in one embodiment of the present invention, overhead processor 215 may transfer overhead to data processor 205 for inclusion in egress units, using payload portions of a standardized transport packet or frame, which can be Ethernet, TFI-5, OTN or SONET/SDH compliant, although other formats may be used. In one embodiment, the standardized transport packet or frame carrying overhead in its payload portion may be transmitted according to timing specified in the relevant standard (e.g., periodically). In one embodiment, the standardized transport packet or frame carrying overhead in its payload portion may be transmitted prior to filling of the payload portion.
In one embodiment, overhead transported in the payload portions of standardized transport packets or frames from multiple data processors or overhead processors may be combined together and provided into a single standardized transport packet or frame. For example, a cross connect device (not depicted) may be used to groom overhead transported in payload portions of multiple standardized transport packets or frames and combine the overhead into a payload portion of a single standardized transport packet or frame. Conversely, the cross connect device may be used to disaggregate overhead transported in a payload portion of a single standardized transport packet or frame for transmission among payload portions of multiple standardized transport packets or frames. In one embodiment, the cross connect device may be implemented as part of a switch fabric.
In one embodiment, overhead may be provided into a payload portion of a standardized frame in accordance with the examples described with respect to
In one embodiment, overhead in a payload portion of a standardized transport packet or frame may be arranged based on an associated aggregation unit. For example, an aggregation unit may be a link or destination. For example, to provide overhead associated with a specified aggregation unit, data processor 205 and overhead processor 215 can instruct each other (or be instructed by host control plane controller 105) where overhead is to be positioned in a payload of a standardized transport packet or frame for a given aggregation unit and how to encapsulate and de-encapsulate the overhead. Each column of a frame can be allocated for a specific aggregation unit, although other schemes may be used. For example,
Data processor 205 may be implemented as any or a combination of: hardwired logic, software stored by a memory device and executed by a microprocessor, firmware, an application specific integrated circuit (ASIC), and/or a field programmable gate array (FPGA).
In one embodiment, data processor 205 may transfer overhead in the payload portion of a standardized transport packet or frame to overhead processor 215 using communications link 210. In one embodiment, overhead processor 215 may transfer overhead in the payload portion of a standardized transport packet or frame to data processor 205 using communications link 210. In one embodiment, communications link 210 may be implemented as an electrical or optical transfer line of serial or parallel capability. For example, communications link 210 may be compatible with XAUI (described in IEEE 802.3ae) or current-mode logic (CML), although other techniques may be used.
In one embodiment, communications link 210 may be implemented using a backplane interface and switch fabric or a network, although other implementations may be used. For example, data processor 205 may transfer overhead in the payload portion of a standardized transport packet or frame to overhead processor 215 by providing the packet or frame to backplane interface 140 for transfer to the appropriate line card (or device) using system fabric 130. Similarly, in one embodiment, overhead processor 215 may transfer overhead in the payload portion of a standardized transport packet or frame to data processor 205 by providing the packet or frame to backplane interface 140 for transfer to the appropriate line card (or device) using system fabric 130.
Overhead request line 212 may be used to control overhead insertion into payload portions of standardized transport packets or frames. For example, data processor 205 may use overhead request line 212 to request overhead processor 215 to provide overhead at a specified time or in specified bit location(s) in a payload portion of a standardized transport packet or frame. For example, data processor 205 may use overhead request line 212 to request overhead processor 215 to provide overhead for transmission in an egress unit or to an aggregation unit at a specified time or in specified bit locations in a payload portion of a standardized transport packet or frame. Similarly, overhead processor 215 may use overhead request line 212 to request data processor 205 to provide overhead at a specified time or in specified bit location(s) in a payload portion of a standardized transport packet or frame. Overhead processor 215 may use overhead request line 212 to request overhead from data processor 205 from specific ingress units or aggregation units at specified times or specified bit locations in a payload portion of a standardized transport packet or frame. Overhead processor 215 may use overhead request line 212 to request data processor 205 not to transfer overhead generally or not to transfer overhead from specific aggregation units. For example, a decision not to transfer overhead may be based on the storage capacity of overhead processor 215.
In one embodiment, a master synchronizer (not depicted) distinct from data processor 205 and overhead processor 215 may be used to control data processor 205 and overhead processor 215 to synchronize overhead generation timing and placement for specified aggregation units in a payload portion of a standardized transport packet or frame. In one embodiment, overhead request line 212 may be implemented as a link such as a TTL I/O compatible link, although other techniques may be used. In one embodiment, overhead request line 212 may be implemented by communications using packets or frames transmitted using system fabric 130. For example, the packets or frames may be Ethernet, TFI-5, OTN or SONET/SDH compliant, although other formats may be used.
For example,
For example, input groomer 302, POH generator 304, pointer generator 306, TOH generator 308, and frame generator 310 may prepare egress units for transmission to a network. For example, frame delineator 312, TOH processor 314, pointer interpreter 316, POH processor 318, and output groomer 320 may process ingress units from the network.
With reference first to ingress units, frame delineator 312 may search for an ingress unit boundary and mark the boundary. With respect to ingress units encoded according to SONET/SDH, frame delineator 312 may process A1 and A2 bytes from the ingress units. For example, TOH processor 314 may filter and accept messages carried in the transport overhead. Based on analysis of line and section overhead, TOH processor 314 may indicate line or section overhead errors to TOH generator 308. TOH processor 314 may also communicate line and section overhead errors to overhead processor 215 for processing. In one embodiment, for SONET/SDH, TOH processor 314 may provide overhead bytes D1-D12, E1, E2, and/or F1 bytes from ingress units for transfer to overhead processor 215. In one embodiment, for SONET/SDH, TOH processor 314 may process J0, K1, and K2 bytes from ingress units. In one embodiment, for SONET/SDH, TOH processor 314 may transfer J0, K1, and/or K2 bytes from ingress units to overhead processor 215 for processing.
For example, pointer interpreter 316 may interpret pointers contained in line and section overhead in order to find the start of a payload portion. With respect to SONET/SDH, pointer interpreter 316 may process H1, H2, H3 bytes from ingress units. For example, POH processor 318 may filter and accept messages carried in path overhead. Based on analysis of path overhead, POH processor 318 may indicate path overhead errors to POH generator 304. Further, POH processor 318 may communicate path overhead errors to overhead processor 215. For example, for SONET/SDH, POH processor 318 may process B1, B2, M0, and M1 bytes from ingress units. For example, for SONET/SDH, POH processor 318 may provide overhead bytes F2, F3, K3, and/or portions of N1 bytes from ingress units to overhead processor 215.
For example, output groomer 320 may groom and cross connect payloads of ingress units in accordance for example with applicable standards such as SONET/SDH and OTN. Output groomer 320 may transfer payloads to the system fabric or a network processor. The payload may include data, information, or packets and frames having formats such as, but not limited to, HDLC, IP, ATM, GFP, and Ethernet.
Multiplexer 350 may encapsulate overhead and information at least from TOH processor 314 and POH processor 318 for transport to overhead processor 215 in a payload portion of a standardized transport frame, which can be a Ethernet, TFI-5, OTN, or SONET/SDH compliant frame, although other formats may be used.
De-multiplexer 355 may de-encapsulate overhead and information from overhead processor 215 provided in a payload portion of a standardized transport frame, which can be a Ethernet, TFI-5, OTN, or SONET/SDH compliant frame, although other formats may be used. De-multiplexer 355 may transfer overhead and information to at least POH generator 304 and TOH generator 308.
For example, input groomer 302 may sort and organize data, information, packets, and/or frames from the system fabric or network processor. For example, based on path overhead error communication from POH processor 318 as well as path overhead provided by overhead processor 215, POH generator 304 may generate messages to communicate path overhead error in the path overhead bytes to the appropriate destination device, such as to the appropriate aggregation unit. For example, for SONET/SDH, POH generator 304 may receive overhead bytes F2, F3, K3, and/or portion of N1 bytes from overhead processor 215 for inclusion in an egress unit. In one embodiment, for SONET/SDH, POH generator 304 may generate B1, B2, M0, and M1 bytes for inclusion in an egress unit.
Pointer generator 306 may generate pointers to allow the appropriate destination device to find the start of the payload portion in an egress unit. In one embodiment, for SONET/SDH, pointer generator 306 may generate H1, H2, H3 bytes for inclusion in an egress unit.
For example, based on line or section overhead error communication from TOH processor 314 as well as overhead provided by overhead processor 215, TOH generator 308 may generate the messages in line or section overhead to communicate line or section overhead errors to the appropriate destination device. For example, in SONET/SDH, line or section overhead errors may cause insertion of Alarm Indication Signal (AIS) into a frame to be transferred to a downstream device. For example, for SONET/SDH, TOH generator 308 may receive overhead bytes D1-D12, E1, E2, and/or F1 from overhead processor 215 for inclusion in an egress unit. In one embodiment, for SONET/SDH, TOH generator 308 may generate J0 and K1, K2 bytes for inclusion in an egress unit; however, in one embodiment, for SONET/SDH, overhead processor 215 may provide J0, K1, and/or K2 bytes for inclusion in an egress unit.
For example, frame generator 310 may provide overhead for an egress unit and identify each egress unit boundary. In one embodiment, for SONET/SDH, frame generator 310 may generate A1 and A2 bytes for inclusion in an egress unit.
Reference will now be made to
Overhead processor 215 may be implemented as any or a combination of: hardwired logic, software stored by a memory device and executed by a microprocessor, firmware, an application specific integrated circuit (ASIC), and/or a field programmable gate array (FPGA).
For example,
For example, input interface 402 extracts overhead from a payload portion of a standardized transport packet or frame from data processor 205 and stores overhead into memory 408, which is accessible by processor 406. For overhead received from input interface 402, processor 406 processes overhead and updates the host-control plane controller in compliance with the relevant specifications or protocols such as SONET/SDH, OIF UNI 1.0 Signaling Specification, or OTN. For example, for SONET/SDH, processor 406 may process D1-D12, E1, E2, F1, F2, F3, K3, and a portion of N1 bytes as well as J0, K1, and/or K2 bytes.
Processor 406 may generate overhead for transfer through output interface 404 to data processor 205. For example, processor 406 may generate overhead using control plane applications that at least uses a database of I/O protocols, network topology, contents of overhead contents, filters, states, network port configurations, encounters, network topology, and latency information from memory 408 in accordance with commands from the host-control plane controller and in compliance with the relevant specifications or protocols such as SONET/SDH, OIF UNI 1.0 Signaling Specification, or OTN. For example, for SONET/SDH, processor 406 may generate control channel overhead bytes D1-D12, E1, E2, F1, F2, F3, K3, and a portion of N1 bytes as well as J0, K1, and/or K2 bytes. For example, according to fill instructions from processor 406, output interface 404 may insert overhead into payload portions of standardized transport packets or frames, which can be TFI-5, OTN or SONET/SDH compliant, although other formats may be used. The standardized transport packets or frames can be transported to a data processor 205.
Action 515 may include the data processor transferring a first portion of overhead from the ingress unit to an overhead processor using a payload portion of a standardized transport packet or frame, which can be a TFI-5, OTN, or SONET/SDH compliant frame, although other frame formats may be used. In one embodiment, the first portion of overhead may relate to: (1) coordination among network nodes of content and positional placement in the payload as well as payload encapsulation schemes for ingress and egress units based on messages carried in the overhead; (2) maintenance of control channels; and (3) network topology discover (e.g., location of nodes). In one embodiment, for SONET/SDH, the first portion of overhead may include the D1-D12, E1, E2, F1, F2, F3, K3, and/or a portion of N1 bytes, although other allocations may be used. For example, the first portion of overhead may further include the J0, K1, and/or K2 bytes. In one embodiment, overhead may be provided into a payload portion of a standardized transport packet or frame in accordance with the examples described with respect to
Action 520 may include the overhead processor extracting and processing the first portion of overhead. For example, the overhead processor may extract and process the first portion of overhead in accordance with applicable standards such as SONET/SDH, OIF UNI 1.0 Signaling Specification, or OTN.
Action 525 may include the data processor processing a second portion of overhead. The second portion of overhead can be related to packet or frame delineation, payload delineation, as well as bit error monitoring and counting. For example, for SONET/SDH, the second portion of overhead may include: (1) delineation overhead bytes A1, A2; (2) pointer overhead bytes H1, H2, H3; (3) state monitoring overhead bytes B1, B2, M0, M1; (4) trace identification overhead byte J0; and (5) protection signaling and alarm indication overhead bytes K1, K2, although other overhead bytes may be processed. For example, the second portion of overhead may further include the J0, K1, and/or K2 bytes. Action 525 may include the data processor grooming and cross connecting payloads of ingress units in accordance for example with applicable standards such as SONET/SDH and OTN.
Action 530 may include the data processor and overhead processor transferring results of the overhead processing for example to a host-control plane controller for processing. Action 530 may also include the data processor transferring the payload for example to a network processor unit. For example, the payload may include packets and frames having formats such as, but not limited to, HDLC, IP, ATM, GFP, and Ethernet as well as SONET/SDH payload.
Action 555 may include generating in an overhead processor a first portion of overhead. The first portion of overhead may relate to: (1) network node coordination of content and placement in the payload as well as payload encapsulation schemes for ingress and egress units based on the messages carried in the overhead; (2) maintenance of control channels; and (3) network topology discover (e.g., location of nodes) in compliance with relevant standards such as SONET/SDH and OIF. In one embodiment, for SONET/SDH, the first portion of overhead may include D1-D12, E1, E2, F1, F2, F3, K3, and/or a portion of N1 bytes, although other allocations may be used. For example, the first portion of overhead may further include the J0, K1, and/or K2 bytes.
Action 560 may include transferring the first portion of overhead to the data processor using a payload section of a standardized transport frame, which can be an TFI-5, OTN, or SONET/SDH compliant frame, although other frame formats may be used. In one embodiment, overhead may be provided into a payload portion of a standardized transport packet or frame in accordance with the examples described with respect to
Action 565 may include the data processor generating a second portion of overhead and performing cross connecting and grooming of payload contents that are to be provided in an egress unit. The second portion of overhead can be related to packet or frame delineation, payload delineation, as well as bit error monitoring and counting in accordance with applicable standards. For example, for SONET/SDH, the second portion of overhead may include: (1) delineation overhead bytes A1, A2; (2) pointer overhead bytes H1, H2, H3; (3) state monitoring overhead bytes B1, B2, M0, M1; (4) trace identification overhead byte J0; and (5) protection signaling and alarm indication overhead bytes K1, K2, although other allocations may be used. For example, the second portion of overhead may further include the J0, K1, and/or K2 bytes. For example, payload contents may include packets and frames having formats such as, but not limited to, HDLC, IP, ATM, GFP, and Ethernet as well as SONET/SDH payload. For example, grooming and cross connecting may be performed in accordance with applicable standards such as SONET/SDH and OTN.
Action 570 may include assembling an egress unit from the first and second portions of overhead and groomed and cross connected payload in compliance with applicable standards such as SONET/SDH and/or OTN.
Action 575 may include transmitting the egress unit to a network.
The drawings and the forgoing description gave examples of the present invention. While a demarcation between operations of elements in examples herein is provided, operations of one element may be performed by one or more other elements. The scope of the present invention, however, is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of the invention is at least as broad as given by the following claims.
