author: Toshiyuki Fukushige$^*$
Piet Hut$^+$
Junichiro Makino$^*$
$*$ Department of Systems Sciences, College of Arts and Sciences,
University of Tokyo
$+$Institute for Advanced Study
title: **High-Performance Special-Purpose Computers in Science**

pt

The next decade will be an exciting time for computational physicists. After 50 years of being forced to use standardized commercial equipment, it will finally become relatively straightforward to adapt one's computing tools to one's own needs. The breakthrough that opens this new era is the now wide-spread availability of *programmable chips* that allow virtually every computational scientist to design his or her own special-purpose computer.

## Towards Real Numerical Laboratories

Unlike real laboratories, numerical laboratories have been constructed almost exclusively from commercial products, which gave little flexibility. Starting in the late seventies, after the first microchips became available, there have been some exceptions. However, only the bravest souls dared to design their own equipment (Bakker and Bruin 1988).

In those days, speeding up the most compute-intensive few lines of FORTRAN code, in a large-scale simulation project, required building a bulky piece of electronic hardware consisting of tens of large circuit boards. By the late eighties, things looked a lot better already, since it had become possible to integrate such circuits into a single custom chip. However, the barrier, real or perceived, against building your own hardware was still substantial.

By now, after another ten years, the barrier has almost disappeared. With programmable chips, the question is not so much whether to make one's hands dirty building a machine, but rather how to program: whether to program the existing central processing unit of a commercial machine, or whether to program a more generic set of distributed processing units. In both cases, the trick is to find the best map between the scientific problem and the layout of the computational hardware. What favors the programmable option over the use of standard CPUs are the facts that: 1) supercomputers, optimized for scientific calculations, are rapidly disappearing, leaving us with less-than-optimal vanilla-flavored computers; 2) generic CPU chips are now becoming so complex that the overwhelming fraction of silicon real estate is dedicated to the electronic equivalent of bureaucracy rather than raw computing.

Of course, there is still one major drawback to the use of programmable chips in computational science: habit. It takes a while for scientists to switch their approach to a problem, even when more efficient methods have become available. Therefore, in order to prepare for the future, it is useful to look back at the past, to see what has already been accomplished during the last ten years, using special-purpose computers. Anything that has been done in this area, relying on specially designed chips, can in principle be done now with programmable chips, at only a fraction of the effort involved. Let us focus on a specific case.

##  A Case Study: The GRAPE Project

Our GRAPE project, started 10 years ago, is one example in which computational physicists developed special-purpose computers successfully. Here, success means that the developed machine made it possible to solve problems which were impossible to solve on general-purpose computers.

One of these projects has resulted in the GRAPE (short for GRAvity PipE) family of special-purpose hardware, designed and built by a small group of astrophysicists at the University of Tokyo (Makino and Taiji 1998). Like a graphics accelerator speeding up graphics calculations on a workstation, without changing the software running on that workstation, the GRAPE acts as a Newtonian force accelerator, in the form of an attached piece of hardware. In a large-scale gravitational N-body calculation, almost all instructions of the corresponding computer program are thus performed on a standard work station, while only the gravitational force calculations, in innermost loop, are replaced by a function call to the special-purpose hardware.

The GRAPE-4, which was completed in 1995 for the total budget of 240 M JYE (around 2 M dollars), offered a peak speed of 1.08 Tflops. On practical problems, a significant fraction of this speed can be actually used. For example, the Grape-4 developers have won the Gordon Bell prize for high-performance computing for two years in a row. In 1995, the prize was awarded to Junichiro Makino and Makoto Taiji for a sustained speed of 112 Gflops, achieved using one-sixth of the full machine on a 128k particle simulation of the evolution of a double black-hole system in the core of a galaxy. The 1996 prize was awarded to Toshiyuki Fukushige and Junichiro Makino for a 332 Gflops simulation of the formation of a cold dark matter halo around a galaxy, modeled using 768k particles on three-quarters of the full machine. The first general-purpose computer to offer a similar level of the performance is the 9000-processor ASCI Red machine, with a price tag around 50 M dollars, completed in late 1997.

In addition, more than 40 copies of small (5-30 Gflops) GRAPE-3 and GRAPE-4 versions are now being used in a major astrophysical institutes in many different countries.

In a year from now, the GRAPE-6 will become available, at a speed that will be at least 100 times faster than that of the GRAPE-4. In addition, single board versions will become available (the 'GRAPE-6 junior'), that can be purchased by individual astrophysicists, to run at a speed of 500 Gflops, coupled to a normal workstation as a front-end. Such a single board will thus provide a speed-up of well over a factor $1,000$ for a price comparable to that of the workstation.

What is the main reason behind the success of the GRAPE? From a technological point of view, it is not overly difficult to design a special-purpose computer with a cost-performance better than that of commercially available general-purpose computers. The reason is simply that an ever diminishing fraction of the available transistors in the present-day microprocessors are actually used in arithmetic operations. In contrast, in GRAPE systems essentially all available transistors in a processor chip are used to implement arithmetic units.

This main reason behind the optimal usage of silicon real estate in the GRAPE is that the data flow in a GRAPE chip is fixed, while most of the transistors in present-day microprocessors are utilize to provide flexible data flow. In other words, the key trick to outperform general-purpose machines is to build a hardware accelerator for a specialized function, and not to build a programmable computer. To design a programmable computer is a difficult task, and you have a very little chance (unless you are a Seymour Cray) to outwit competent designers in large companies. However, designing a specialized piece of hardware for a single function is not something computer architects do. So there is essentially no competition.

##  Having it all

The interesting shift, alluded to in our opening statement, is that it is no longer necessary to choose between programming a computer and building a special-purpose computer. With the availability of increasingly efficient programmable chips, one can *program* an off-the-shelf chip, such as a FPGA (Field-Programmable Gate Array) chip, to *emulate a special-purpose chip*. It is like having your cake and eating it: you can emulate a fixed date flow. Before you program the chip, it is far more flexible than a standard CPU, in the sense that you are not bound by a given instruction set, providing all instructions yourself, from the bottom up. And after having programmed the chip, it has turned into a data flow machine, without any need to decode additional information on the fly.

Of course, there is a drawback to any new development. With current FPGAs, flexibility comes with a cost: more than 90% of the silicon resource is used to provide programmability. Even so, custom computing machines based on FPGA have become a viable alternative for both general-purpose computers and specialized hardwares, given the fact that standard CPUs tend to have lower and lower efficiency as well, while their complexity keeps increasing.

We have developed a small system with two FPGA chips to evaluate the potential of FPGA technology. The current FPGAs turned out to be large enough to house a complete GRAPE-3 chip (110K transistors). The chips available in next year will be large enough to house a GRAPE-4 chip and the effective performance would exceed 1 Gflops per chip.

##  Outlook

To summarize, FPGAs offer the possibility of combining the flexibility of conventional programmable computer and the high throughput of special-purpose hardware. To play the devil's advocate, one might argue that FPGAs could combine the difficulty of design of special-purpose hardware and the low efficiency of the programmable computer. To be honest, at present there still is that danger. To continue the devil's advocate argument: implementing a function onto an FPGA is analogous to programming a universal Turing machine, in the sense that it offers the maximum flexibility at the lowest level. Clearly, a more sensible design methodology is necessary. On the bright side, rapid advances are being made in the development of higher level tools for implementing algorithms on FPGAs. And the more the parallelization bottleneck, using general-purpose computers, will be felt, the larger the incentive will become to switch to a use of programmable chips.

Thus FPGAs are not a universal solution for all problems in computational physics. A full-custom chip offers clear advantages when its high initial development cost can be amortized by mass production. General-purpose computers are still better in developing sophisticated algorithms, and experimenting with them. But the use of FPGAs can be expected to increase rapidly, in computational science, for a wide range of problems, that are too complex to 'put in stone' in the form of a special-purpose chip, but not too complex to program onto a FPGA. In that way, problems which cannot be solved in a practical time on programmable computers, do not have to be shelved until commercial computers catch up and deliver the required speed. As the example of the GRAPE has shown us, even a small group of computational scientists can solve their particular computational problems years ahead of (the commercial) schedule.

## References

Bakker A. F. and Bruin C. (1988) Design and implementation of the Delft molecular-dynamics processor. In Alder B. J. (ed) Special Purpose Computers, pages 183–232. (Academic Press, San Diego)

Makino J. and Taiji M. (1998) Special Purpose Computers for Scientific Simulations – The GRAPE systems. (John Wiley and Sons, Chichester)


author: Marc Mosko
PARC
firstname.lastname@example.com; Ignacio Solis[^1]
LinkedIn
firstname.lastname@example.com; Christopher A. Wood
University of California Irvine
firstname.lastname@example.com
bibliography: references.bib
date: 2024-10-01
  Version: 1.0
title: **Content-Centric Networking**
  .
  .
  ------------------------------------------------------------------------
  .

  Architectural Overview and Protocol Description

# Overview

CCNx is a request and response protocol to fetch chunks of data using a name. The integrity of each chunk may be directly asserted through a digital signature or message authentication code (MAC), or, alternatively, indirectly via hash chains. Chunks may also carry weaker message integrity checks (MICs) or no integrity protection mechanism at all. Because provenance information is carried with each chunk (or larger indirectly protected block), we no longer need to rely on host identities, such as those derived from TLS certificates, to ascertain the chunk legitimacy. Data integrity is therefore a core feature of CCNx; it does not rely on the data transmission channel. There are several options for data confidentiality, discussed later.

As a request and response protocol, CCNx may be carried over many different transports. In use today are Ethernet, TCP, UDP, 802.15.4, GTP, GRE, DTLS, TLS, and others. While the specific wire format of CCNx may vary to some extent based on transport, the core principles and behaviors of CCNx outlined in this document should remain fixed.

CCNx uses hierarchical names to identify bytes of payload. The Name combines a routable prefix with an arbitrary application-dependent suffix assigned by the publisher to a piece of content. The result is a "named payload". This is different from other systems that use only self-certifying names, where the payload name is intrinsically derivable from the payload or its realization in a network object (e.g., a SHA-256 hash of the payload or network object). In human- readable form, we represent names as a "ccnx:" scheme URI , though the canonical encoding should be octet strings. In this respect, we speak of a name being made up of hierarchical path segments, which is the URI terminology.

This document only defines the general properties of CCNx names. In some isolated environments, CCNx users may be able to use any name they choose and either inject that name (or prefix) into a routing protocol or use other information foraging techniques. In the Internet environment, there will be policies around the formats of names and assignments of names to publishers, though those are not specified here.

The key concept of CCNx is that a subjective name is (cryptographically) bound to a fixed payload. These (publisher- generated) bindings can therefore be (cryptographically) verified. For example, a publisher could compute a cryptographic hash over the name and payload, sign the hash, and deliver the tuple Name, Payload, Validation. Consumers of this data can check the binding integrity by re-computing the same cryptographic hash and verifying the digital signature in Validation. Additional information would be included as needed by specific validation mechanisms. Therefore, we divide Validation in to a ValidationAlgorithm and a ValidationPayload. The ValidationAlgorithm has information about the crypto suite and parameters. In particular, the ValidationAlgorithm usually has a field called KeyId which identifies the public key used by the validation, when applicable. The ValidationPayload is the output of the validation algorithm, such as a CRC value, an HMAC output, or an RSA signature.

In addition to the essential Name, Payload, and Validation sections, a CCNx user may need to include some other signaling information. This could include a hint about the type of Payload (e.g., application data, a cryptographic key, etc.) or cache control directives, etc. We will call this extra signaling information ExtraFields.

A named payload is thus the nested tuple $$((\mathsf{Name}, \mathsf{ExtraFields}, \mathsf{Payload}, \mathsf{ValidationAlgorithm}), \mathsf{ValidationPayload}),$$ where all fields in the inner tuple are covered by the value in the validation payload.

CCNx specifies a network protocol around Interests (request messages) and Content Objects (response messages) to move named payloads. An Interest includes the Name – which identifies the desired response – and two optional limiting restrictions. The first restriction on the KeyId to limit responses to those signed with a ValidationAlgorithm KeyId field equal to the restriction. The second is the ContentObjectHash restriction, which limits the response to one where the cryptographic hash of the entire named payload is equal to the restriction.

The hierarchy of a CCNx Name is used for routing via the longest matching prefix in a Forwarder. The longest matching prefix is computed name segment by name segment in the hierarchical path name, where each name segment must be exactly equal to match. There is no requirement that the prefix be globally routable. Within a deployment any local routing may be used, even one that only uses a single flat (non-hierarchical) name segment.

Another concept of CCNx is that there should be flow balance between Interest messages and Content Object messages. At the network level, an Interest traveling along a single path should elicit no more than one Content Object response. If some node sends the Interest along more than one path, that node should consolidate the responses such that only one Content Object flows back towards the requester. If an Interest is sent broadcast or multicast on a multiple-access media, the sender should be prepared for multiple responses unless some other media-dependent mechanism like gossip suppression or leader election is used.

As an Interest travels the forward path following the Forwarding Information Base (FIB), it establishes state at each forwarder such that a Content Object response can trace its way back to the original requester(s) without the requester needing to include a routable return address. We use the notional Pending Interest Table (PIT) as a method to store state that facilitates the return of a Content Object. The PIT table is not mandated by the specification.

The notional PIT table stores the last hop of an Interest plus its Name and optional restrictions. This is the data required to match a Content Object to an Interest (see Section ). When a Content Object arrives, it must be matched against the PIT to determine which entries it satisfies. For each such entry, at most one copy of the Content Object is sent to each listed last hop in the PIT entries.

If multiple Interests with the same Name, KeyIdRestriction, ContentObjectHashRestriction tuple arrive at a node before a Content Object matching the first Interest comes back, they are grouped in the same PIT entry and their last hops aggregated (see Section 2.4.2). Thus, one Content Object might satisfy multiple pending Interests in a PIT.

In CCNx, higher-layer protocols often become so-called "name-based protocols" because they operate on the CCNx Name. For example, a versioning protocol might append additional name segments to convey state about the version of payload. A content discovery protocol might append certain protocol-specific name segments to a prefix to discover content under that prefix. Many such protocols may exist and apply their own rules to Names. They may be layered with each protocol encapsulating (to the left) a higher layer's Name prefix.

This document also describes a control message called an InterestReturn. A network element may return an Interest message to a previous hop if there is an error processing the Interest. The returned Interest may be further processed at the previous hop or returned towards the Interest origin. When a node returns an Interest it indicates that the previous hop should not expect a response from that node for the Interest, i.e., there is no PIT entry left at the returning node for a Content Object to follow.

There are multiple ways to describe larger objects in CCNx. Some options may use the namespace while others may use a structure such as a Manifest. This document does not address these options at this time.

The remainder of this document describes a named payload as well as the Interest and Content Object network protocol behavior in detail.

# Protocol

CCNx is a request and response protocol. A request is called an Interest and a response is called a ContentObject. CCNx also uses a 1-hop control message called InterestReturn. These are, as a group, called CCNx Messages.

## Message Grammar

The CCNx message ABNF grammar is show in Figure 1. The grammar does not include any encoding delimiters, such as TLVs. Specific wire encodings are given in a separate document. If a Validation section exists, the Validation Algorithm covers from the Body (BodyName or BodyOptName) through the end of the ValidationAlg section. The InterestLifetime, CacheTime, and Return Code fields exist outside of the validation envelope and may be modified.

The various fields – in alphabetical order – are defined as:

-   AbsTime: Absolute times are conveyed as the 64-bit UTC time in milliseconds since the epoch (standard POSIX time).

-   CacheTime: The absolute time after which the publisher believes there is low value in caching the content object. This is a recommendation to caches (see Section 4).

-   ConObjField: These are optional fields that may appear in a Content Object.

-   ConObjHash: The value of the Content Object Hash, which is the SHA256-32 over the message from the beginning of the body to the end of the message. Note that this coverage area is different from the ValidationAlg. This value SHOULD NOT be trusted across domains (see Section 5).

-   ExpiryTime: An absolute time after which the content object should be considered expired (see Section 4).

-   HopLimit: Interest messages may loop if there are loops in the forwarding plane. To eventually terminate loops, each Interest carries a HopLimit that is decremented after each hop and no longer forwarded when it reaches zero. See Section 2.4.

-   InterestField: These are optional fields that may appear in an Interest message.

-   KeyIdRestr: The KeyId Restriction. A Content Object must have a KeyId with the same value as the restriction.

-   ObjHashRestr: The Content Object Hash Restriction. A content object must hash to the same value as the restriction using the same HashType. The ObjHashRestr MUST use SHA256-32.

-   KeyId: An identifier for the key used in the ValidationAlg. For public key systems, this should be the SHA-256 hash of the public key. For symmetric key systems, it should be an identifer agreed upon by the parties.

-   KeyLink: A Link (see Section 6) that names how to retrieve the key used to verify the ValidationPayload. A message SHOULD NOT have both a KeyLink and a PublicKey.

-   Lifetime: The approximate time during which a requester is willing to wait for a response, usually measured in seconds. It is not strongly related to the network round trip time, though it must necessarily be larger.

-   Name: A name is made up of a non-empty first segment followed by zero or more additional segments, which may be of 0 length. Path segments are opaque octet strings, and are thus case-sensitive if encoding UTF-8. An Interest MUST have a Name. A ContentObject MAY have a Name (see Section 9). The segments of a name are said to be complete if its segments uniquely identify a single Content Object. A name is exact if its segments are complete. An Interest carrying a full name is one which specifies an exact name and the ObjHashRestr of the corresponding Content Object.

-   Payload: The message's data, as defined by PayloadType.

-   PayloadType: The format of the Payload. If missing, assume DataType. DataType means the payload is opaque application bytes. KeyType means the payload is a DER-encoded public key. LinkType means it is one or more Links (see Section 6).

-   PublicKey: Some applications may wish to embed the public key used to verify the signature within the message itself. The PublickKey is DER encoded. A message SHOULD NOT have both a KeyLink and a PublicKey.

-   RelTime: A relative time, measured in milli-seconds.

-   ReturnCode: States the reason an Interest message is being returned to the previous hop (see Section 10.2).

-   SigTime: The absolute time (UTC milliseconds) when the signature was generated.

-   Hash: Hash values carried in a Message carry a HashType to identify the algorithm used to generate the hash followed by the hash value. This form is to allow hash agility. Some fields may mandate a specific HashType.

## Consumer Behavior

To request a piece of content for a given $$(\mathsf{Name}, [\mathsf{KeyIdRest}], [\mathsf{ObjHashRestr}])$$ tuple, a consumer creates an Interest message with those values. It MAY add a validation section, typically only a CRC32C. A consumer MAY put a Payload field in an Interest to send additional data to the producer beyond what is in the Name. The Name is used for routing and may be remembered at each hop in the notional PIT table to facilitate returning a content object; Storing large amounts of state in the Name could lead to high memory requirements. Because the Payload is not considered when forwarding an Interest or matching a Content Object to an Interest, a consumer SHOULD put an Interest Payload ID (see Section Section 3.2) as part of the name to allow a forwarder to match Interests to content objects and avoid aggregating Interests with different payloads. Similarly, if a consumer uses a MAC or a signature, it SHOULD also include a unique segment as part of the name to prevent the Interest from being aggregated with other Interests or satisfied by a Content Object that has no relation to the validation.

The consumer SHOULD specify an InterestLifetime, which is the length of time the consumer is willing to wait for a response. The InterestLifetime is an application-scale time, not a network round trip time (see Section 2.4.2). If not present, the InterestLifetime will use a default value (TO_INTERESTLIFETIME).

The consumer SHOULD set the Interest HopLimit to a reasonable value or use the default 255. If the consumer knows the distances to the producer via routing, it SHOULD use that value.

A consumer hands off the Interest to its first forwarder, which will then forward the Interest over the network to a publisher (or replica) that may satisfy it based on the name (see Section 2.4).

Interest messages are unreliable. A consumer SHOULD run a transport protocol that will retry the Interest if it goes unanswered, up to the InterestLifetime. No transport protocol is specified in this document.

The network MAY send to the consumer an InterestReturn message that indicates the network cannot fulfill the Interest. The ReturnCode specifies the reason for the failure, such as no route or congestion. Depending on the ReturnCode, the consumer MAY retry the Interest or MAY return an error to the requesting application.

If the content was found and returned by the first forwarder, the consumer will receive a ContentObject. The consumer SHOULD:

-   Ensure the content object is properly formatted.

-   Verify that the returned Name matches a pending request. If the request also had KeyIdRestr and ObjHashRest, it should also validate those properties.

-   If the content object is signed, it SHOULD cryptographically verify the signature. If it does not have the corresponding key, it SHOULD fetch the key, such as from a key resolution service or via the KeyLink.

-   If the signature has a SigTime, the consumer MAY use that in considering if the signature is valid. For example, if the consumer is asking for dynamically generated content, it should expect the SigTime to not be before the time the Interest was generated.

-   If the content object is signed, it should assert the trustworthiness of the signing key to the namespace. Such an assertion is beyond the scope of this document, though one may use traditional PKI methods, a trusted key resolution service, or methods like schematized trust .

-   It MAY cache the content object for future use, up to the ExpiryTime if present.

-   A consumer MAY accept a content object off the wire that is expired. It may happen that a packet expires while in flight, and there is no requirement that forwarders drop expired packets in flight. The only requirement is that content stores, caches, or producers MUST NOT respond with an expired content object.

## Publisher Behavior

This document does not specify the method by which names populate a Forwarding Information Base (FIB) table at forwarders (see Section 2.4). A publisher is either configured with one or more name prefixes under which it may create content, or it chooses its name prefixes and informs the routing layer to advertise those prefixes.

When a publisher receives an Interest, it SHOULD:

-   Verify that the Interest is part of the publishers namespace(s).

-   If the Interest has a Validation section, verify the ValidationPayload. Usually an Interest will only have a CRC32C unless the publisher application specifically accommodates other validations. The publisher MAY choose to drop Interests that carry a Validation section if the publisher application does not expect those signatures as this could be a form of computational denial of service. If the signature requires a key that the publisher does not have, it is NOT RECOMMENDED that the publisher fetch the key over the network, unless it is part of the application's expected behavior.

-   Retrieve or generate the requested content object and return it to the Interest's previous hop. If the requested content cannot be returned, the publisher SHOULD reply with an InterestReturn or a content object with application payload that says the content is not available; this content object should have a short ExpiryTime in the future.

## Forwarder Behavior

A forwarder routes Interest messages based on a Forwarding Information Base (FIB), returns Content Objects that match Interests to the Interest's previous hop, and processes InterestReturn control messages. It may also keep a cache of Content Objects in the notional Content Store table. These functions are shown in Figure . These and other external behaviors are described in the remainder of this section.

In this document, we will use two processing pipelines, one for Interests and one for Content Objects. Interest processing is made up of checking for duplicate Interests in the PIT (see Section 2.4.2), checking for a cached Content Object in the Content Store (see Section 2.4.3), and forwarding an Interest via the FIB. Content Store processing is made up of checking for matching Interests in the PIT and forwarding to those previous hops.

### Interest HopLimit

Interest looping is not prevented in CCNx. An Interest traversing loops is eventually discarded using the hop-limit field of the Interest, which is decremented at each hop traversed by the Interest. Every Interest MUST carry a HopLimit.

When an Interest is received from another forwarder, the HopLimit MUST be positive. A forwarder MUST decement the HopLimit of an Interest by at least 1 before it is forwarded. If the HopLimit equals 0, the Interest MUST NOT be forwarded to another forwarder; it MAY be sent to a publisher application or serviced from a local Content Store.

### Interest Aggregation

Interest aggregation is when a forwarder receives an Interest message that could be satisfied by another Interest message already forwarded by the node so the forwarder suppresses the new Interest; it only records the additional previous hop so a Content Object sent in response to the first Interest will satisfy both Interests.

CCNx uses an interest aggregation rule that assumes the InterestLifetime is akin to a subscription time and is not a network round trip time. Some previous aggregation rules assumed the lifetime was a round trip time, but this leads to problems of expiring an Interest before a response comes if the RTT is estimated too short or interfering with an ARQ scheme that wants to re-transmit an Interest but a prior interest over-estimated the RTT.

A forwarder MAY implement an Interest aggregation scheme. If it does not, then it will forward all Interest messages. This does not imply that multiple, possibly identical, Content Objects will come back. A forwarder MUST still satisfy all pending Interests, so one Content Object could satisfy multiple similar interests, even if the forwarded did not suppress duplicate Interest messages.

A RECOMMENDED Interest aggregation scheme is:

-   Two Interests are considered 'similar' if they have the same Name, KeyIdRestr, and ObjHashRestr.

-   Let the notional value InterestExpiry (a local value at the forwarder) be equal to the receive time plus the InterestLifetime (or a platform-dependent default value if not present).

-   An Interest record (PIT entry) is considered invalid if its InterestExpiry time is in the past.

-   The first reception of an Interest MUST be forwarded.

-   A second or later reception of an Interest similar to a valid pending Interest from the same previous hop MUST be forwarded. We consider these a retransmission requests.

-   A second or later reception of an Interest similar to a valid pending Interest from a new previous hop MAY be aggregated (not forwarded).

-   Aggregating an Interest MUST extend the InterestExpiry time of the Interest record. An implementation MAY keep a single InterestExpiry time for all previous hops or MAY keep the InterestExpiry time per previous hop. In the first case, the forwarder might send a ContentObject down a path that is no longer waiting for it, in which case the previous hop (next hop of the Content Object) would drop it.

### Content Store Behavior

The ContentStore is a special cache that sits on the fast path of a CCNx forwarder. It is an optional component. It serves to repair lost packets and handle flash requests for popular content. It could be pre-populated or use opportunistic caching. Because the Content Store could serve to amplify an attach via cache poisoning, there are special rules about how a Content Store behaves.

1.  A forwarder MAY implement a ContentStore. If it does, the Content Store matches a Content Object to an Interest via the normal matching rules (see Section 9).

2.  If an Interest has a KeyIdRestr, then the ContentStore MUST NOT reply unless it knows the signature on the matching ContentObject is correct. It may do this by external knowledge (i.e., in a managed system pre-populating the cachine) or by having the public key and cryptographically verifying the signature. If the public key is provided in the ContentObject itself (i.e., in the PublicKey field) or in the Interest, the ContentStore MUST verify that the public key's SHA-256 hash is equal to the KeyId and that it verifies the signature. A ContentStore MAY verify the digital signature of a Content Object before it is cached, but it is not required to do so. A ContentStore SHOULD NOT fetch keys over the network. If it cannot or has not yet verified the signature, it should treat the Interest as a cache miss.

3.  If an Interest has an ObjHashRestr, then the ContentStore MUST NOT reply unless it knows the the matching ContentObject has the correct hash. If it cannot verify the hash, then it should treat the Interest as a cache miss.

4.  It must object the Cache Control directives (see Section 4).

### Interest Pipeline

1.  Perform the HopLimit check (see Section 2.4.1).

2.  Determine if the Interest can be aggregated, as per Section 2.4.2. If it can be, aggregate and do not forward the Interest.

3.  If forwarding the Interest, check for a hit in the Content Store, as per Section 2.4.3. If a matching Content Object is found, return it to the Interest's previous hop. This injects the ContentStore as per Section 2.4.5.

4.  Lookup the Interest in the FIB. Longest prefix match (LPM) is performed name segment by name segment (not byte or bit). It SHOULD exclude the Interest's previous hop. If a match is found, forward the Interest. If no match is found or the forwarder choses to not forward due to a local condition (e.g., congestion), it SHOULD send an InterestReturn message, as per Section 10.

### Content Object Pipeline

1.  It is RECOMMENDED that a forwarder that receives a content object check that the ContentObject came from an expected previous hop. An expected previous hop is one pointed to by the FIB or one recorded in the PIT as having had a matching Interest sent that way.

2.  A Content Object MUST be matched to all pending Interests that satisfy the matching rules (see Section 9). Each satisfied pending Interest MUST then be removed from the set of pending Interests.

3.  A forwarder SHOULD NOT send more then one copy of the received Content Object to the same Interest previous hop. It may happen, for example, that two Interest ask for the same Content Object in different ways (e.g., by name and by name an KeyId) and that they both come from the same previous hop. It is normal to send the same content object multiple times on the same interface, such as Ethernet, if it is going to different previous hops.

4.  A Content Object SHOULD only be put in the Content Store if it satisfied an Interest (and passed rule \#1 above). This is to reduce the chances of cache poisoning.

# Names

A CCNx name is a composition of name segments. Each name segment carries a label identifying the purpose of the name segment, and a value. For example, some name segments are general names and some serve specific purposes, such as carrying version information or the sequencing of many chunks of a large object into smaller, signed Content Objects.

There are three different types of names in CCNx: prefix, exact, and full names. A prefix name is simply a name that does not uniquely identify a single Content Object, but rather a namespace or prefix of an existing Content Object name. An exact name is one which uniquely identifies the name of a Content Object. A full name is one which is exact and is accompanied by an explicit or implicit ConObjHash. The ConObjHash is explicit in an Interest and implicit in a Content Object.

The name segment labels specified in this document are given in the table below. Name Segment is a general name segment, typically occurring in the routable prefix and user-specified content name. Other segment types are for functional name components that imply a specific purpose.

A forwarding table entry may contain name segments of any type. Routing protocol policy and local system policy may limit what goes into forwarding entries, but there is no restriction at the core level. An Interest routing protocol, for example, may only allow binary name segments. A load balancer or compute cluster may route through additional component types, depending on their services.

| **Name** | **Description** |
|:---|:---|
| Name Segment | A generic name segment that includes arbitrary octets. |
| Interest Payload ID | An octet string that identifies the payload carried in an Interest. As an example, the Payload ID might be a hash of the Interest Payload. This provides a way to differentiate between Interests based on the Payload solely through a Name Segment without having to include all the extra bytes of the payload itself. |
| Application Components | An application-specific payload in a name segment. An application may apply its own semantics to these components. A good practice is to identify the application in a Name segment prior to the application component segments. |

CCNx Name Segment Types

At the lowest level, a Forwarder does not need to understand the semantics of name segments; it need only identify name segment boundaries and be able to compare two name segments (both label and value) for equality. The Forwarder matches paths segment-by-segment against its forwarding table to determine a next hop.

## Name Examples

This section uses a URI representation of CCNx names. Each component of a name has a type and value. Examples of this encoding are in Table .

| **Name** | **Description** |
|:---|:---|
| ccnx:/ | A 0-length name, corresponds to a default route. |
| ccnx:/NAME= | A name with 1 segment of 0 length, distinct from ccnx:/. |
| ccnx:/NAME=foo/APP:0=bar | A 2-segment name, where the first segment is of type NAME and the second segment is of type APP:0. |

CCNx Name Examples

## Interest Payload ID

An Interest may also have a Payload which carries state about the Interest but is not used to match a Content Object. If an Interest contains a payload, the Interest name should contain an Interest Payload ID (IPID). The IPID allows a PIT table entry to correctly multiplex Content Objects in response to a specific Interest with a specific payload ID. The IPID could be derived from a hash of the payload or could be a GUID or a nonce. An optional Metadata field defines the IPID field so other systems could verify the IPID, such as when it is derived from a hash of the payload. No system is required to verify the IPID.

# Cache Control

CCNx supports two fields that affect cache control. These determine how a cache or Content Store handles a Content Object. They are not used in the fast path, but only to determine if a ContentObject can be injected on to the fast path in response to an Interest.

The ExpiryTime is a field that exists within the signature envelope of a Validation Algorithm. It is the UTC time in milliseconds after which the ContentObject is considered expired and MUST no longer be used to respond to an Interest from a cache. Stale content MAY be flushed from the cache.

The Recommended Cache Time (RCT) is a field that exists outside the signature envelope. It is the UTC time in milliseconds after which the publisher considers the Content Object to be of low value to cache. A cache SHOULD discard it after the RCT, though it MAY keep it and still respond with it. A cache is MAY discard the content object before the RCT time too; there is no contractual obligation to remember anything.

This formulation allows a producer to create a Content Object with a long ExpiryTime but short RCT and keep re-publishing the same, signed, Content Object over and over again by extending the RCT. This allows a form of "phone home" where the publisher wants to periodically see that the content is being used.

# Restrictions

## Content Object Hash

CCNx allows an Interest to restrict a response to a specific hash. The hash covers the Content Object message body and the validation sections, if present. Thus, if a Content Object is signed, its hash includes that signature value. The hash does not include the fixed or hop-by-hop headers of a Content Object. Because it is part of the matching rules (see Section 9), the hash is used at every hop.

There are two options for matching the content object hash restriction in an Interest. First, a forwarder could compute for itself the hash value and compare it to the restriction. This is an expensive operation. The second option is for a border device to compute the hash once and place the value in a header (ConObjHash) that is carried through the network. The second option, of course, removes any security properties from matching the hash, so SHOULD only be used within a trusted domain. The header SHOULD be removed when crossing a trust boundary.

## Key ID Restriction

In addition to content restrictions, CCNx allows an Interest to also restrict a response to a content object which can be authenticated using a specific public key. This is done by specifying the identity of the verifying public key in a header (KeyIdRestr) that is carried through the network. An Interest with a KeyIdRestr only matches a Content Object if the latter carries a public key whose identity matches the KeyIdRestr value. An Interest may carry both a content object hash restriction and a key ID restriction. The former simply subsumes the latter since, by design, the public key in a matching Content Object would be included in the hash computation input.

# Link

A Link is the tuple $${\mathsf{Name}, [\mathsf{KeyIdRestr}], [\mathsf{ContentObjectHashRestr}]}.$$ The information in a Link comprises the fields the fields of an Interest which would retrieve the Link target. A Content Object with PayloadType = "Link" is an object whose payload is one or more Links. This tuple may be used as a KeyLink to identify a specific object with the certificate wrapped key. It is RECOMMENDED to include at least one of KeyIdRestr or ContentObjectHashRestr. If neither restriction is present, then any Content Object with a matching name from any publisher could be returned.

# Hashes

Several protocol fields use cryptographic hash functions, which must be secure against attack and collisions. Because these hash functions change over time, with better ones appearing and old ones falling victim to attacks, it is important that a CCNx protocol implementation support hash agility.

In this document, we suggest certain hashes (e.g., SHA-256), but a specific implementation may use what it deems best. The normative CCNx Messages specification should be taken as the definition of acceptable hash functions and uses.

# Validation

The Validator consists of a ValidationAlgorithm that specifies how to verify the message and a ValidationPayload containing the validation output, e.g., the digital signature or MAC. The ValidationAlgorithm section defines the type of algorithm to use and includes any necessary additional information. The validation is calculated from the beginning of the CCNx Message through the end of the ValidationAlgorithm section. The ValidationPayload is the integrity value bytes, such as a MAC or signature.

Some Validators contain a KeyId, identifying the publisher authenticating the Content Object. If an Interest carries a KeyIdRestriction, then that KeyIdRestriction MUST exactly match the Content Object's KeyId.

Validation Algorithms fall into three categories: MICs, MACs, and Signatures. Validators using MIC algorithms do not need to provide any additional information; they may be computed and verified based only on the algorithm (e.g., CRC32C). MAC validators require the use of a KeyId identifying the secret key used by the authenticator. Because MACs are usually used between two parties that have already exchanged secret keys via a key exchange protocol, the KeyId may be any agreed-upon value to identify which key is used. Signature validators use public key cryptographic algorithms such as RSA, DSA, ECDSA. The KeyId field in the ValidationAlgorithm identifies the public key used to verify the signature. A signature may optionally include a KeyLocator, as described above, to bundle a Key or Certificate or KeyLink. MAC and Signature validators may also include a SignatureTime, as described above.

A PublicKeyLocator KeyLink points to a Content Object with a DER- encoded X509 certificate in the payload. In this case, the target KeyId must equal the first object's KeyId. The target KeyLocator must include the public key corresponding to the KeyId. That key must validate the target Signature. The payload is an X.509 certificate whose public key must match the target KeyLocator's key. It must be issued by a trusted authority, preferably specifying the valid namespace of the key in the distinguished name.

# Interest to Content Matching

A Content Object satisfies an Interest if and only if (a) the Content Object name, if present, exactly matches the Interest name, and (b) the ValidationAlgorithm KeyId of the Content Object exactly equals the Interest KeyIdRestriction, if present, and (c) the computed ContentObjectHash exactly equals the Interest ContentObjectHashRestriction, if present.

The matching rules are given by this predicate, which if it evaluates true means the ContentObject matches the Interest. $N_i$ = Name in Interest (may not be empty), $K_i$ = KeyIdRestriction in the interest (may be empty), $H_i$ = ContentObjectHashRestriction in Interest (may be empty). Likewise, $N_o$, $K_o$, $H_o$ are those properties in the ContentObject, where $N_o$ and $K_o$ may be empty; $H_o$ always exists.

As a special case, if the ContentObjectHashRestriction in the Interest specifies an unsupported hash algorithm, then no ContentObject can match the Interest so the system should drop the Interest and MAY send an InterestReturn to the previous hop. In this case, the predicate below will never get executed because the Interest is never forwarded. If the system is using the optional behavior of having a different system calculate the hash for it, then the system may assume all hash functions are supported and leave it to the other system to accept or reject the Interest.

$$(\neg N_o \lor (N_i=N_o)) \land (\neg K_i \lor (K_i=K_o)) \land (\neg H_i \lor (H_i=H_o)) \land (\exists N_o \lor \exists H_i)$$

As one can see, there are two types of attributes one can match. The first term depends on the existence of the attribute in the ContentObject while the next two terms depend on the existence of the attribute in the Interest. The last term is the "Nameless Object" restriction which states that if a Content Object does not have a Name, then it must match the Interest on at least the Hash restriction.

If a Content Object does not carry the ContentObjectHash as an expressed field, it must be calculated in network to match against. It is sufficient within an autonomous system to calculate a ContentObjectHash at a border router and carry it via trusted means within the autonomous system. If a Content Object ValidationAlgorithm does not have a KeyId then the Content Object cannot match an Interest with a KeyIdRestriction.

# Interest Return

This section describes the process whereby a network element may return an Interest message to a previous hop if there is an error processing the Interest. The returned Interest may be further processed at the previous hop or returned towards the Interest origin. When a node returns an Interest it indicates that the previous hop should not expect a response from that node for the Interest – i.e., there is no PIT entry left at the returning node.

The returned message maintains compatibility with the existing TLV packet format (a fixed header, optional hop-by-hop headers, and the CCNx message body). The returned Interest packet is modified in only two ways:

-   The PacketType is set to InterestReturn to indicate a Feedback message.

-   The ReturnCode is set to the appropriate value to signal the reason for the return

The specific encodings of the Interest Return are specified in .

A Forwarder is not required to send any Interest Return messages.

A Forwarder is not required to process any received Interest Return message. If a Forwarder does not process Interest Return messages, it SHOULD silently drop them.

The Interest Return message does not apply to a Content Object or any other message type.

An Interest Return message is a 1-hop message between peers. It is not propagated multiple hops via the FIB. An intermediate node that receives an InterestReturn may take corrective actions or may propagate its own InterestReturn to previous hops as indicated in the reverse path of a PIT entry.

## Message Format

The Interest Return message looks exactly like the original Interest message with the exception of the two modifications mentioned above. The PacketType is set to indicate the message is an InterestReturn and the reserved byte in the Interest header is used as a Return Code. The numeric values for the PacketType and ReturnCodes are in .

## ReturnCode Types

This section defines the InterestReturn ReturnCode introduced in this RFC. The numeric values used in the packet are defined in .

| **Name** | **Description** |
|:---|:---|
| No Route | The returning Forwarder has no route to the Interest name. |
| HopLimit Exceeded | The HopLimit has decremented to 0 and need to forward the packet. |
| Interest MTU too large | The Interest's MTU does not conform to the require minimum and would require fragmentation. |
| No Resources | The node does not have the resources to process the Interest. |
| Path error | There was a transmission error when forwarding the Interest along a route (a transient error). |
| Prohibited | An administrative setting prohibits processing this Interest. |
| Congestion | The Interest was dropped due to congestion (a transient error). |
| Unsupported Content Object Hash Algorithm | The Interest was dropped because it requested a Content Object Hash Restriction using a hash algorithm that cannot be computed. |
| Malformed Interest | The Interest was dropped beause it did not correctly parse. |

## Interest Return Protocol

This section describes the Forwarder behavior for the various Reason codes for Interest Return. A Forwarder is not required to generate any of the codes, but if it does, it MUST conform to this specification.

If a Forwarder receives an Interest Return, it SHOULD take these standard corrective actions. A forwarder is allowed to ignore Interest Return messages, in which case its PIT entry would go through normal timeout processes.

-   Verify that the Interest Return came from a next-hop to which it actually sent the Interest.

-   If a PIT entry for the corresponding Interest does not exist, the Forwarder should ignore the Interest Return.

-   If a PIT entry for the corresponding Interest does exist, the Forwarder MAY do one of the following:

    -   Try a different forwarding path, if one exists, and discard the Interest Return, or

    -   Clear the PIT state and send an Interest Return along the reverse path.

If a forwarder tries alternate routes, it MUST ensure that it does not use same same path multiple times. For example, it could keep track of which next hops it has tried and not re-use them.

If a forwarder tries an alternate route, it may receive a second InterestReturn, possibly of a different type than the first InterestReturn. For example, node A sends an Interest to node B, which sends a No Route return. Node A then tries node C, which sends a Prohibited. Node A should choose what it thinks is the appropriate code to send back to its previous hop

If a forwarder tries an alternate route, it should decrement the Interest Lifetime to account for the time spent thus far processing the Interest.

### No Route

If a Forwarder receives an Interest for which it has no route, or for which the only route is back towards the system that sent the Interest, the Forwarder SHOULD generate a "No Route" Interest Return message.

How a forwarder manages the FIB table when it receives a No Route message is implementation dependent. In general, receiving a No Route Interest Return should not cause a forwarder to remove a route. The dynamic routing protocol that installed the route should correct the route or the administrator who created a static route should correct the configuration. A forwarder could suppress using that next hop for some period of time.

### HopLimit Exceeded

A Forwarder MAY choose to send HopLimit Exceeded messages when it receives an Interest that must be forwarded off system and the HopLimit is 0.

### Interest MTU Too Large

If a Forwarder receives an Interest whose MTU exceeds the prescribed minimum, it MAY send an "Interest MTU Too Large" message, or it may silently discard the Interest.

If a Forwarder receives an "Interest MTU Too Large" is SHOULD NOT try alternate paths. It SHOULD propagate the Interest Return to its previous hops.

### No Resources

If a Forwarder receives an Interest and it cannot process the Interest due to lack of resources, it MAY send an InterestReturn. A lack of resources could be the PIT table is too large, or some other capacity limit.

### Path Error

If a forwarder detects an error forwarding an Interest, such as over a reliable link, it MAY send a Path Error Interest Return indicating that it was not able to send or repair a forwarding error.

### Prohibited

A forwarder may have administrative policies, such as access control lists, that prohibit receiving or forwarding an Interest. If a forwarder discards an Interest due to a policy, it MAY send a Prohibited InterestReturn to the previous hop. For example, if there is an ACL that says /parc/private can only come from interface e0, but the Forwarder receives one from e1, the Forwarder must have a way to return the Interest with an explanation.

### Congestion

If a forwarder discards an Interest due to congestion, it MAY send a Congestion InterestReturn to the previous hop.

### Unsupported Content Object Hash Algorithm

If a Content Object Hash Restriction specifies a hash algorithm the forwarder cannot verify, the Interest should not be accepted and the forwarder MAY send an InterestReturn to the previous hop.

### Malformed Interest

If a forwarder detects a structural or syntactical error in an Interest, it SHOULD drop the interest and MAY send an InterestReturn to the previous hop. This does not imply that any router must validate the entire structure of an Interest.

[^1]: Work done while at PARC.


abstract: #### Background:
  .
  Gene expression in a cell entails random reaction events occurring over disparate time scales. Thus, molecular noise that often results in phenotypic and population-dynamic consequences sets a fundamental limit to biochemical signaling. While there have been numerous studies correlating the architecture of cellular reaction networks with noise tolerance, only a limited effort has been made to understand the dynamic role of protein-protein interactions.
  .
  #### Results:
  .
  We have developed a fully stochastic model for the positive feedback control of a single gene, as well as a pair of genes (toggle switch), integrating quantitative results from previous *in vivo* and *in vitro* studies. In particular, we explicitly account for the fast binding-unbinding kinetics among proteins, RNA polymerases, and the promoter/operator sequences of DNA. We find that the overall noise-level is reduced and the frequency content of the noise is dramatically shifted to the physiologically irrelevant high-frequency regime in the presence of protein dimerization. This is independent of the choice of monomer or dimer as transcription factor and persists throughout the multiple model topologies considered. For the toggle switch, we additionally find that the presence of a protein dimer, either homodimer or heterodimer, may significantly reduce its random switching rate. Hence, the dimer promotes the robust function of bistable switches by preventing the uninduced (induced) state from randomly being induced (uninduced).
  .
  #### Conclusions:
  .
  The specific binding between regulatory proteins provides a buffer that may prevent the propagation of fluctuations in genetic activity. The capacity of the buffer is a non-monotonic function of association-dissociation rates. Since the protein oligomerization *per se* does not require extra protein components to be expressed, it provides a basis for the rapid control of intrinsic or extrinsic noise. The stabilization of regulatory circuits and epigenetic memory in general is of direct implications to organism fitness. Our results also suggest possible avenues for the design of synthetic gene circuits with tunable robustness for a wide range of engineering purposes.
address: Microbial Systems Biology Group, Biosciences and Biotechnology Division, Lawrence Livermore National Laboratory, 7000 East Avenue Livermore, CA 94550, USA
author: Cheol-Min Ghim and Eivind Almaas
bibliography: dimer.bib
title: Genetic noise control via protein oligomerization

\[1995/12/01\]

# Background

Recent experiments on isogenic populations of microbes with single-cell resolution  have demonstrated that stochastic fluctuations, or noise, can override genetic and environmental determinism. In fact, the presence of noise may significantly affect the fitness of an organism . The traditional approach for modeling the process of molecular synthesis and degradation inside a cell is by deterministic rate equations, where the continuous change of arbitrarily small fractions of molecules is controlled instantaneously and frequently represented through sigmoidal dose-response relations. However, the rate-equation approaches can not explain the observed phenotypic variability in an isogenic population in stable environments. In particular, when molecules involved in feedback control exist in low copy numbers, noise may give rise to significant cell-to-cell variation as many regulatory events are triggered by molecules with very low copy numbers $\lesssim100$ . A well known example is the regulation of inorganic trace elements , such as iron, copper, and zinc. While these trace elements are essential for the activity of multiple enzymes, their presence may quickly turn cytotoxic unless their concentrations are carefully controlled.

Although the presence of phenotypic variation due to stochastic fluctuations need not be detrimental for a population of cells , elaborate regulatory mechanisms have evolved to attenuate noise . Several systems-biology studies have recently focused on a select set gene-regulatory circuits, in particular those with feedback control. Feedback control circuits have been identified as important for multiple species and proven responsible for noise reduction and increased functional stability in many housekeeping genes through negative autoregulation , long cascades of ultrasensitive signaling , bacterial chemotaxis , and the circadian clock . Additionally, recent studies on iron homeostasis  in *E. coli* highlight the noise-reducing capability mediated by small RNAs.

Here, we study reversible protein-protein binding as a novel source for genetic noise control. In particular, we have quantitatively analyzed the effects of protein oligomerization on noise in positive autoregulatory circuits as well as a simple toggle-switch . The all-or-none threshold behavior of positive-feedback circuits typically improves robustness against "leaky" switching. However, due to their functional purposes, gene circuits involved in developmental processes or stress responses that often accompany genome-wide changes in gene expression are intrinsically noisier than negative feedback circuits.

It is frequently observed that transcription factors exist in oligomeric form , and protein oligomerization is an important subset of protein-protein interactions, constituting a recurring theme in enzymatic proteins as well as regulatory proteins. Well studied examples include the $\lambda$-phage repressor, ${\lambda}$CI (dimer), the TrpR (dimer), LacR (tetramer), and Lrp (hexadecamer or octamer). While many of the RNA-binding proteins dimerize exclusively in the cytosol, the LexA repressor , the leucine-zipper activator , and the Arc repressor  have been shown to form an oligomer either in the cytosol ("dimer path") or on the DNA by sequential binding ("monomer path"). Previously, the efficacy of monomer and dimer transcription-regulation paths to reduce noise was separately studied for a negative-feedback autoregulatory circuit . In contrast, we have focused on oligomerization in positive-feedback autoregulatory circuits, as well as genetic toggle switches based on the mutual repression of genes. We find that cytosolic transcription-factor oligomerization acts as a significant buffer for abundance-fluctuations in the monomer, overall reducing noise in the circuit. Additionally, the noise-power spectral density is shifted from the low- to the high-frequency regime. In the toggle switch, cytosolic oligomerization may significantly stabilize the functional state of the circuit. This is especially evident for heterodimerization.

Yet another interesting case of ligand-binding-mediated receptor oligomerization has been reported , where the formation of various structures of oligomers may act to buffer the intracellular signaling against noise. Although our modeling and analysis is based on prokaryotic cells, we expect our main findings to be organism independent since protein oligomers, especially homodimers, is such a common occurrence across the species , with homodimers comprising 12.6% of the high-fidelity human proteome .

# Results and Discussion

## Dimerization breaks long-time noise correlations in autogenous circuit

To evaluate the dynamic effects of protein-protein binding in positive-autoregulation gene circuits, we construct several alternative models of positive autogenous circuits. Each model emphasizes a different combination of possible feedback mechanisms, and the network topologies considered can be grouped into the two classes of monomer-only (MO) and dimer-allowed (DA) circuits, according to the availability of a protein-dimer state (color coding in Fig. 1). We further group the DA circuits into three variations, DA1 through DA3, depending on which form of the protein is the functional transcription factor (TF) and where the dimerization occurs. For DA1, we only allow the dimer to bind with the DNA-operator sequence (dimeric transcription factor, DTF), while for DA2 dimerization occurs through sequential binding of monomers on the DNA. In DA3, the protein-DNA binding kinetics is the same as in the MO circuit, hence monomeric transcription factor (MTF), with the addition of a cytosolic protein dimer state. While we will only present results for DA1 in this paper, there is no significant difference for DA2 and DA3 \[Additional file 1\].

Note that the feedback loop is not explicit in Fig. 1 but implicitly included through the dependence of RNAp-promoter binding equilibrium on the binding status of the TF-operator pair. The sign (positive or negative) and strength of the feedback control is determined by the relative magnitude of the dissociation constants between RNAp and DNA which is either free or TF-bound. For instance, topology DA1 has positive feedback control if $K_{30}= k_{30}/q_{30} >
K_{32} = k_{32}/q_{32}$, and $K_{30}$ corresponds to the level of constitutive transcription (transcription initiation in the absence of bound transcription factor). For each topology, we study the dependence of noise characteristics on the kinetic rates by varying the dimer lifetime, binding affinity, and the individual association/dissociation rates (see Table  and Fig. 1). While we only discuss positive feedback control of the autogenous circuit in this paper, we have obtained corresponding results for negative feedback control \[Additional file 1\].

Fig. 2 shows a sample of ten representative time courses for the protein abundance. The effect of stochastic fluctuations is marked in the MO circuit. However, in all the DA circuits where the protein may form a cytosolic dimer we observe a significantly reduced level of noise in the monomer abundance. The suppression of fluctuations persists throughout the range of kinetic parameters that (so far) is known to be physiologically relevant (see Table 1).

Calculating the steady-state distribution for the monomer and dimer abundances (Fig. 3) we observe a clear trend that the monomer Fano factor (variance-to-mean ratio) is reduced as the binding equilibrium is shifted towards the dimer. This trend is conserved for all the investigated DA topologies (see *Supplementary Information*). As long as dimerization is allowed in the cytosol, the fast-binding equilibrium absorbs long-time fluctuations stemming from bursty synthesis or decay of the monomer. When a random fluctuation brings about a sudden change in the monomer copy number, dimerization provides a buffering pool that absorbs the sudden change. Otherwise, random bursts in the monomer abundance will propagate to the transcriptional activity of the promoter, leading to erratic control of protein expression. It should be emphasized that this has nothing to do with the sign of regulation and is in agreement with the observations of Ref.  for negative autoregulation. Surprisingly, the magnitude of noise reduction in the positive autoregulatory circuit is nearly the same as that for negative autoregulation which is typically considered a highly stable construct \[Additional file 1\].

A heuristic explanation can be found from Jacobian analysis of a deterministic dynamical system, which is justified for small perturbations around a steady state. When a random fluctuation shifts the monomer copy number away from its steady-state value, the decay toward the steady state can be described by the system Jacobian. The disparity in the magnitude of the (negative) eigenvalues of the Jacobian matrix for the MO versus the DA circuits signifies that the perturbed state is buffered by fast settlement of the monomer-dimer equilibrium. This buffering occurs before random fluctuation can accumulate, possibly with catastrophic physiological effects, explaining the coarse long-time patterns observed in the MO model in contrast with the DA circuits (Fig. 2).

## Frequency-selective whitening of Brownian noise

The dimerization process itself generates stochastic fluctuations on a short time scale. However, since this time scale is essentially separated from that of monomer synthesis and decay (orders of magnitude faster), dimerization effectively mitigates monomer-level fluctuations. The frequency content of the fluctuations is best studied by an analysis of the power spectral density (PSD), which is defined as the Fourier transform of the autocorrelation function , originally introduced for signal processing. Fig. 4 shows the noise power spectra of DA1, and the distinction between the MO circuit and the DA topology is immediately evident. In particular, we note the following two features. (i) A power-law decay with increasing frequency and (ii) a horizontal plateau for the DA circuits. The power-law feature is explained by the "random walk" nature of protein synthesis and decay: The power-law exponent is approximately 2, which is reminiscent of Brownian motion (a Wiener process) in the limit of large molecular copy numbers. Compared to other commonly observed signals, such as white (uncorrelated) noise or $1/f$ noise, protein synthesis/decay has a longer correlation time. If the autocorrelation function of a time course is characterized by a single exponential decay, as is the case for Brownian noise, the PSD is given by a Lorentzian profile, and thus, well approximated by an inverse-square law in the low-frequency regime. We do not observe a saturation value for the MO circuit, and it is likely not in the frequency window of physiological interest. This may especially be the case for circuits where the correlation times are long.

The noise reduction is in the physiologically relevant low-frequency regime, and in Fig. 4 we have indicated the typical values for a cell cycle and mRNA lifetime. Although stochastic fluctuations impose a fundamental limit in cellular information processing, multiple noise sources may affect cellular physiology non-additively. For a living cell, fluctuations are especially relevant when their correlation time is comparable to, or longer than, the cell cycle. At the same time, short-time scale fluctuations (relative to the cell cycle) are more easily attenuated or do not propagate . Additionally, the observed flat region in the PSD of the DA circuits implies that as far as mid-range frequency fluctuations are concerned, we can safely approximate them as a white noise. This insight may shed light on the reliability of approximation schemes for effective stochastic dynamics in protein-only models.

## Increased lifetime of dimer plays an important role

The virtue of the cytosolic dimer state is also directly related to the extended lifetime of proteins when in a complex. Except for the degradation tagging for active proteolysis, a much slower turnover of protein oligomers is the norm. This is partly explained by the common observation that monomers have largely unfolded structures, which are prone to be target of proteolysis . It has also been pointed out that the prolonged lifetime of the oligomeric form is a critical factor for enhancing the feasible parameter ranges of gene circuits . As seen from Fig. 3 (also Table 2), the fold change of the noise reduction, while still significant, is not as strong for the (hypothetical) case of dimer lifetime being the same as that of the monomer ($\gamma_2/\gamma_1=1/2$). However, the low-frequency power spectra still exhibit almost an order-of-magnitude smaller noise power than in the MO circuit with the same rate parameters (Fig. 4). Hence, the noise reduction capability holds good as long as the dimer lifetime is kept sufficiently long compared with the monomer-dimer transition.

## Effects of homo-dimerization in genetic toggle switch

The exceptionally stable lysogeny of the phage $\lambda$, for which the spontaneous loss rate is $\lesssim10^{-7}$ per cell per generation , has motivated the synthesis of a genetic toggle switch . Toggle switch is constructed from a pair of genes, which we will denote as gene $A$ and $B$, that transcriptionally repress each other's expression. This mutual negative regulation can be considered an effective positive feedback loop and provides the basis for the multiple steady states. The existence of multistability, in turn, may be exploited as a device for epigenetic memory or for decision making .

As the general attributes of positive feedback with cooperativity suggest, a genetic toggle switch responds to external cues in an ultrasensitive way: When the strength of a signal approaches a threshold value, the gene expression state can be flipped by a small change in the signal. For example, the concentration of protein $A$ ($B$) may rapidly switch from high to low and vice versa. However, previous studies of a synthetic toggle switch have shown that the noise-induced state switching is a rare event . In the ensuing analysis, we aim to delineate the origin of this exceptional stability.

In a simple model, the monomer-only (MO) toggle, regulatory proteins only exist in monomeric form. Although an external signal is not explicitly included, random fluctuations in the abundance of the circuit's molecular components will occasionally flip the toggle-state for the two protein species. Drawing on the results from our analysis of positive autoregulatory gene circuits, we hypothesize that dimerization in the regulatory proteins of the toggle switch will serve to stabilize its performance against noise. We allow the protein products of each gene to form a homodimer, being either $AA$ or $BB$, which is similar to the cI-cro system in phage $\lambda$ . The dissociation constant for the dimers is defined as $K_1=q_1/k_1$, where $k_1$ is the rate of two monomers forming a complex, and $q_1$ the rate of the complex breaking up into its two constituents.

We evaluate the effect of the fast protein binding-unbinding dynamics on the toggle switch performance by using either (i) the monomers or (ii) the homodimers as the functional form of the repressor. Fig. 5 shows, for selected values of the dissociation constant $K_1$, representative time series of the protein monomer (left) and dimer (right) abundances for the case of (a) monomeric or (b) dimeric transcription factors, respectively. A careful analysis of the phase space (in presence of noise) for our chosen set of parameters confirms that the studied toggle-switch systems are in the bistable region .

When monomer is the functional form of the repressor molecule (Fig. 5(a)) and $K_1$ is large (limit of low dimer affinity), the protein populations are dominated by monomers. Hence, the circuit effectively behaves as an MO toggle. As $K_1$ decreases, we see that the level of random switching is suppressed: Analogous to the autogenous circuit, the dimer pool stabilizes the protein monomer population. However, the noise suppression is not monotonic with increasing dimer binding affinity. Indeed, for very large binding affinities (small $K_1$), the number of random switching events is increased since the monomer is only available in low copy numbers. Consequently in this limit, it becomes more likely that a small fluctuation in the monomer abundance can cause a dramatic change in the overall gene expression profile. The noise-stabilizing effect of dimerization is also reflected in the corresponding PSDs \[Additional file 1\]. For instance, we observe a marked suppression of low-frequency fluctuations in the monomer abundance with increasing $K_1$.

In Fig. 5(b) we show corresponding sample time series for the case of a dimeric repressor, all other properties being the same as in (a). While the overall trends are similar, we do note the following difference. Contrary to the monomeric repressor case, there are very few toggle events in the strong binding limit: Since the signaling molecules (dimers) of the dominant gene (the "on"-gene) tend to exist in large copy numbers, a significant fluctuation is needed to flip the state of the toggle switch. In the case of monomeric repression, the signaling molecule exists in low abundance in this limit. Thus, the dominant protein species in the dimeric-repressor system is able to maintain much better control over the state of the toggle switch.

In Fig. 6, we show the distribution $(N_A-N_B)$, the difference in molecule abundance for the two protein species in the case of monomeric (left) and dimeric (right) transcription factor. The asymmetry with respect to the zero axis is caused by our choice of initial conditions (protein species $A$ in high concentration and species $B$ in low concentration), as well as the finite length of the time series. For monomeric transcription, the presence of dimers with moderate binding affinity sharpens the monomer abundance distribution while accentuating its bimodal character. This is in agreement with the qualitative observation from Fig. 5 on switching stability. For dimeric transcription, we clearly observe that the symmetry of the system is broken for small values of $K_1$, indicating that the state of the toggle switch is extremely stable, and hence, likely determined by the choice of the initial conditions.

To systematically quantify our observations on the interplay between dimer-binding affinity and the functional stability of the toggle switch, we generated long time series ($\approx3\cdot10^7$ sec) to measure the average spontaneous switching rate. In Fig. 7, we show the average toggle frequency relative to that of the MO toggle for the binding affinities $K_1/\textrm{nM}=\{2, 20, 100,1000\}$, and the average MO switching rate is $7.5\times10^{-6}$/hour. As expected, we find that intermediate values of $K_1$ are able to stabilize the toggle switch. Fig. 7 also highlights the increased stability of the toggle switch for a dimeric versus monomeric transcription factor, the dimeric switching rates always being lower and approaching zero for strong dimer binding.

## Heterodimerization in genetic toggle switch

We have also considered the case of heterodimerization in the toggle switch, since the noise- and functional stabilization of the switch may be directly affected by the composition and source of the dimers. Note that, the gene-regulation activity is conferred by the two monomer proteins $A$ and $B$ and not the heterodimer $AB$. However, we find that the presence of (inactive) heterodimers gives rise to very similar noise-stabilizing effects as that of homodimers (Fig. 7). In fact, the existence of heterodimer state allows the dominant protein species to effectively suppress the (active) monomers of the minority species. Thus the heterodimer circuit shows dramatically enhanced functional stability as compared to the case of homodimeric repressors, not sharing the discussed vulnerability of MO circuit to intrinsic noise. Although, to our knowledge, this is a purely hypothetical toggle-switch design, it provides a general strategy for noise control in synthetic gene circuits, along with previously proposed approach of overlapping upstream regulatory domains .

# Conclusions

Cells have evolved distinct strategies to combat the fundamental limits imposed by intrinsic and environmental fluctuations. We investigated the role of protein oligomerization on noise originating from the random occurrence of reaction events and the discrete nature of molecules. Recent efforts to correlate network structure with functional aspects may provide valuable insights into approaches for network-level noise control . While negative feedback is one of the most abundantly observed patterns to achieve the goal of stability, it begs the question of how cells reliably change the expression of genes from one state to another. The ultrasensitive response circuit, exemplified by the ubiquitous signal transduction cascades in eukaryotic cells, has been proposed as an answer to this question .

In addition to the combinatorial expansion of functional specificity, we argue that the availability of oligomeric states contributes to the attenuation of stochastic fluctuations in protein abundance. In positive autoregulatory gene circuits, where the abundance of an expressed protein controls its own synthesis rate, dimerization provides a buffer serving to mitigate random fluctuations associated with the bursty transcription-translation process. We find that short-time binding-unbinding dynamics reduce the overall noise level by converting potentially pathological low-frequency noise to physiologically unimportant, and easily attenuated, high-frequency noise .

Noise-induced switching generally signals a defect in cellular information processing. Untimely exit from latency in the lambda-phage system directly implies, as the immediate consequence to viruses, increased chance of being targeted by a host immune system. In the case of a bacterium, the expression of a specific set of sugar uptake genes when the sugar is absent from the external medium is a considerable waste of cellular resources. For example, *lac* operon of *E. coli* can be considered to have the circuitry of mutual antagonism between the gene and lactose uptake-catabolic genes . A difference lies in the non-transcriptional deactivation of the allosteric transcription factor LacI. LacY, lactose permease, indirectly regulates LacI by increasing lactose uptake, which in turn catalytically deactivates LacI. Likewise, many pili operons of Gram-negative bacteria are also known to utilize heritable expression states, which are of crucial role in pathogenesis .

We expect that the random flipping of gene expression states in the examples of positive-feedback-based genetic switches may very well be closely coupled with the fitness of an organism. Phenomenological models relating the fitness of an organism to random phenotypic switching in fluctuating environments have provided important insights into the role of noise , but still many questions remain unanswered.

Applying these insights to the design of a synthetic gene switch demonstrates the potential use of affinity-manipulation for synthetic biology, where the construction of genetic circuits with tunable noise-resistance is of central importance. In particular, our analysis highlights the potential utility of heterodimerization to stabilize ultrasensitive switches against random fluctuations. In practice, small ligand molecules may be employed to regulate and tune the binding affinity of regulatory proteins, being either monomers or dimers. Our results further suggest that the structure of the protein-interaction network  may provide important insights on methods for genome-level noise control in synthetic and natural systems.

# Methods

## Model construction

To evaluate the general role of protein oligomerization in a broad functional context, we studied the two most common motifs found in genetic regulatory circuits: positive autoregulation and the bistable switch. The reaction scheme studied is summarized in Fig. 1, where the binding/unbinding reactions between RNAp and promoter or between TF and operator are made explicit. Each distinct binding status of DNA is associated with a unique transcription initiation rate, and then the overall rate of mRNA synthesis is a weighted average of the initiation rates for distinct binding status, where the weights are given by the relative abundance of each configuration at equilibrium, determined by the calculation of binding energy . Note that, neither binding equilibrium nor empirical Hill-type cooperativity is assumed *ad hoc*. In particular, we split the lumped transcription process into two separate events, (i) isomerization of closed RNAp-promoter complex to its open form and (ii) transcription elongation followed by termination. This is to reflect the availability of the free promoter while the transcription machinery proceeds along the coding sequence of a gene as soon as the promoter region is cleared of the RNAp holoenzyme. Otherwise, the promoter would be inaccessible during a whole transcription event, altering the random mRNA synthesis dynamics.

To realize the genetic toggle switch in a stochastic setting, we keep track of the microscopic origin of cooperativity that gives rise to bistability. Among various strategies, we employ multiple operator sites which have the same binding affinity with the repressor. The resultant circuitry is, in essence, two autogenous circuits, $A$ and $B$, which are connected through the active form of their expressed proteins (the active form being either monomer or dimer). The connection is implemented by allowing the active form of proteins $A$ ($B$) to bind the operator sites of gene $B$ ($A$). In order to make the interaction between the two genes repressive, unlike positive autogenous circuits, $K_{31}$ and $K_{32}$ in Fig. 1 are now greater than $K_{30}$, making the protein transcriptional repressors. For reasons of analytical simplicity, we have studied the symmetric toggle switch, where the reaction descriptions of each component follow those of the autogenous circuit. Again, the quantitative characteristics of macromolecular binding-unbinding are chosen based on the phage lambda-*E. coli* system. The only exception is related to the multiple operator sites, where the second repressor binds an operator site with higher binding affinity when the first site is already occupied by the repressor protein . We introduce three different dimerization schemes. Three different dimerization scheme have been introduced: (i) homodimerization with monomeric repressor, (ii) homodimerization with dimeric repressor, and (iii) heterodimerization with monomeric repressor. By solving for the stationary states of the deterministic rate equations, we could identify the bistability region in parameter space to which all the model systems under consideration belong.

## Stochastic simulation

While the deterministic rate equation approach or Langevin dynamics explicitly gives the time-evolution of molecular concentration in the form of ordinary differential equations, chemical master equation (CME) describes the evolution of a molecular number state as a continuous-time jump Markov process. To generate the statistically correct trajectories dictated by CME, we used the Gillespie direct  and Next Reaction (Gibson-Bruck)  algorithms, both based on the exact chemical master equation. The Dizzy package  were used as the core engine of the simulations. To ensure that calculations were undertaken in a steady state, we solved the deterministic set of equations for steady state using every combination of parameters investigated. We employed these deterministic steady-state solutions as initial conditions for the stochastic simulations. For each model system, we generated $10^5$ ensemble runs with identical initial conditions and used the instantaneous protein copy number at a fixed time point $t=5000$ sec. To achieve high-quality power spectra in the low- and high-frequency limits, we ran time courses ($\sim 10^5$ sec) with higher sampling frequency (20 measure points per sec).

To calculate the average switching rate, we generated time series of minimum length $3\cdot10^7$ sec (approximately corresponding to 1 year). We identify a state change in the toggle switch by monitoring the ratio of the monomer and dimer abundance for the two protein species. In order to avoid counting short-time fluctuations that do not correspond to a prolonged change of the toggle state, we a applied sliding-window average to the time series, using a window size of $1000$ sec.

# Authors' contributions

CMG and EA designed the study. CMG performed the computations. CMG and EA analyzed the results and wrote the paper. Both authors have read and approved the final version of the paper.

# Acknowledgments

The authors thank Dr. Navid for thoughtful discussion and suggestions. This work was performed under the auspices of the U. S. Department of Energy by Lawrence Livermore National Laboratory under Contract DE-AC52-07NA27344 and funded by the Laboratory Directed Research and Development Program (project 06-ERD-061) at LLNL.

Tables

**Table 1 - Probability rates for positive autogenous circuit.**

| Category | Symbol |      Reaction |   Value (s$^{-1}$) |    Ref. |
|:--:|:--:|:---|:---|:---|
| protein dimerization | $k_1$ | P$_1$ $+$ P$_1 \rightarrow$ P$_2$ | 0.001-0.1 |  |
|  | $q_1$ | P$_2 \rightarrow$ P$_1$ $+$ P$_1$ | 0.1-1 |  |
| TF-operator int | $k_{20}$ | P$_2$ $+$ D00 $\rightarrow$ D20 | 0.012 |  |
|  | $q_{20}$ | D20 $\rightarrow$ P$_2$ $+$ D00 | 0.9 |  |
|  | $k_{21}$ | P$_1$ $+$ D00 $\rightarrow$ D10 | 0.038 |  |
|  | $q_{21}$ | D10 $\rightarrow$ P$_1$ $+$ D00 | 0.3 |  |
|  | $k_{22}$ | P$_1$ $+$ D10 $\rightarrow$ D20 | 0.011 |  |
|  | $q_{22}$ | D20 $\rightarrow$ P$_1$ $+$ D10 | 0.9 |  |
| RNAp-promoter int | $k_{30}$ | R $+$ D00 $\rightarrow$ D01 | 0.038 |  |
|  | $q_{30}$ | D01 $\rightarrow$ R $+$ D00 | 0.3 |  |
|  | $k_{31}$ | R $+$ D10 $\rightarrow$ D11 | 0.038$^\dagger$, 0.38$^\ddagger$ |  |
|  | $q_{31}$ | D11 $\rightarrow$ R $+$ D10 | 0.3$^\dagger$, 0.03$^\ddagger$ |  |
|  | $k_{32}$ | R $+$ D20 $\rightarrow$ D21 | 0.38$^{*\dagger}$ |  |
|  | $q_{32}$ | D21 $\rightarrow$ R $+$ D20 | 0.03$^{*\dagger}$ |  |
| Isomerization | $v$ | Dx1 $\rightarrow$ C $+$ Dx0 | 0.0078 |  |
| tsx-tsl elongation & decay | $\alpha$ | C $\rightarrow$ M $+$ R | 0.03 |  |
|  | $\beta$ | M $\rightarrow$ P$_1$ $+$ M | 0.044 |  |
|  | $\gamma_0$ | M $\rightarrow \varnothing$ | 0.0039 |  |
|  | $\gamma_1$ | P$_1 \rightarrow \varnothing$ | 7$\times$`<!-- -->`{=html}10$^{-4}$ |  |
|  | $\gamma_2$ | P$_2 \rightarrow \varnothing$ | 0.7-3.5$\times$`<!-- -->`{=html}10$^{-4}$ |  |

Kinetic rates for the positive autogenous circuit. Experimentally available rates are all taken from lambda phage-*E. coli* complex. The values with superscript correspond to the circuit topologies DA1 (\*), DA2 ($\dagger$), and DA3 ($\ddagger$) in Fig. 1.

**Table 2 - Relative Fano factors of protein abundance distributions**

| $K_1$ (nM) | $\gamma_2=\gamma_1/10$ |       | $\gamma_2=\gamma_1/2$ |       |
|:----------:|:----------------------:|:-----:|:---------------------:|:-----:|
|    2-5     |        monomer         | dimer |        monomer        | dimer |
|     1      |         0.127          | 0.809 |         0.132         | 0.679 |
|     20     |         0.209          | 0.936 |         0.230         | 0.716 |
|    500     |         0.866          | 0.478 |         0.826         | 0.426 |

The Fano factor of protein abundance distribution for the autogenous circuits (topology DA1), relative to that of the monomer-only (MO) circuit, $8.729$.

Figures

**Figure 1. Schematic of model autoregulation gene circuit.**
The DNA binding status is indicated by Dxy, where x corresponds to the operator region (empty=0, monomer=1, dimer=2), and y to the promoter region (empty=0, RNA polymerase bound=1). C represents the open complex of DNA-RNAp holoenzyme with the promoter sequence just cleared of RNAp and is subject to transcription elongation. Finally, M, P1 and P2 correspond to mRNA, protein monomer, and dimer, respectively. The network topologies can be grouped into two classes, monomer-only (MO) or dimer-allowed (DA) circuits. We have studied DA1 (red lines), which only allows the dimer to bind with the DNA-operator sequence, DA2 (green) with sequential binding of monomers on the DNA, and DA3 (blue), which shares protein-DNA binding kinetics with MO while allowing dimerization in the cytosol. Note that for topology DA2, we have chosen $K_{31}=K_{30}$ (see text for details) We have assumed cells to be in the exponential growth phase and the number of RNAp (R) constant.

**Figure 2. Ten independent time courses of the abundance of protein monomers in the (positive) autoregulatory circuit.**
The availability of a cytosolic dimer state (red, using circuit topology DA1) significantly reduces the copy-number fluctuations of the monomer compared to the monomer-only (MO) circuit (blue). All corresponding MO and DA1 parameters have the same values. In the ensuing simulations initial conditions are chosen to be the steady state solution of the corresponding deterministic rate equation so that the transient behavior should be minimized.

**Figure 3. Stationary state distribution of monomer (black) and dimer (orange) protein abundance in the positive autogenous circuits.**
The left (right) column corresponds to a ratio of the dimer and monomer decay rates of $\gamma_2/\gamma_1=1/10$ ($\gamma_2/\gamma_1=1/2$). The molecular copy numbers are collected at a fixed time interval ($5\cdot10^3$ sec) after the steady state has been reached. Here $K_1\equiv q_1/k_1$ is the dissociation constant of the protein dimer. As the binding equilibrium is shifted towards the dimer state (decreasing $K_1$), the noise level is monotonically reduced (see Table 2). Note that the prolonged protein lifetime due to the complex formation (left column) affects the noise level.

**Figure 4. Power spectral density (PSD) of fluctuations in protein abundance.**
The PSD of the MO circuit clearly displays a power-law behavior. All other model systems with an available cytosolic protein dimer state (DA1 shown here) develop a plateau in the mid-frequency region regardless of the model details (see *Supplementary Information*). As the dimer binding affinity increases, the noise level is further reduced. We have included the MO result in the dimer panel (right) for reference. Datasets with solid (empty) symbols correspond to $\gamma_2/\gamma_1=1/10$ ($\gamma_2/\gamma_1=1/2$).

**Figure 5. Sample time series of monomer and dimer copy numbers in genetic toggle switch.**
(a) MTF circuit, where monomer is the functional form of the repressor. (b) DTF circuit, where dimer is the functional form of the repressor. The left (right) column shows the number of the two monomer molecules $A$ and $B$ (dimers $AA$ and $BB$), and the initial state is always with species $A$ (red) in high abundance. Note that the switching frequency depends on the binding affinity of protein dimer.

**Figure 6. Distribution of monomer abundance differences between protein species $A$ and $B$.**
The asymmetry with respect to the zero axis is due to the choice of initial state (species $A$ high) and the finite time span of simulations.

**Figure 7. Random switching rates of genetic toggle switches.**
Ordinate is the ratio of the random switching rates of various toggle switches to that of the monomer-only (MO) circuit, $7.5\times 10^{-6}$/hour. MTF, monomeric transcription factor; DTF, dimeric transcription factor; Het-MTF, monomeric transcription factor with deactivated heterodimer state.

Additional Files

**Additional file 1. Supplementary results for the positive autoregulatory circuits with various topology.**
Protein abundance distribution and power spectral density of autogenous DA2 and DA3 circuits are presented.