BDR provides asynchronous multi-master logical replication. This means that you can write to any server and the changes will, after they have been committed, be sent row-by-row to all the other servers that are part of the same BDR group.
Each database ("node") participating in a BDR group both receives changes from other members and can be written to directly by the user. This is distinct from hot or warm standby, where only the single master server that all others replicate from can be written to.
You don't have to use multi-master with BDR, it's possible to use it for one-way replication too.
If you're interested in BDR's multi-master features it's important to understand some of the concepts behind multi-master, both in general and as BDR implements it. Application developers must be aware that applications may need changes for multi-master BDR and cannot be written exactly as if they are talking to a standalone or single-master system. See BDR: Weakly coupled multi-master replication.
Changes made on one BDR node are not replicated to other nodes before they are committed locally. As a result the data is not exactly the same on all nodes at any given time; some nodes will have data that has not yet arrived at other nodes. PostgreSQL's block-based replication solutions default to asynchronous replication as well.
Support for synchronous writes may be added to a future BDR release and some support for synchronous replication already exists for one-way (single-master) replication.
When combined with multi-master, asynchronous replication is often called an "eventually consistent" architecture. At any given time the data can look different when viewed from different nodes, but over time the nodes sync with each other. If writes stop then after a while all nodes will be the same. BDR ensures that constraints (unique constraints, check constraints, foreign keys, etc) are always consistent within any given node, so it's stricter than many eventually consistent designs.
Logical (row-based) replication is replication using individual row values. It contrasts with physical (block-based) replication where changes to data blocks are sent. Logical replication is at a different level - it's a lot like the difference between sending a set of files and sending the hard drive the files are on. Logical replication has both advantages and disadvantages compared to physical replication; see Differences between logical and physical replication.
Replication is the process of copying data from one place to another. In BDR refers to the fact that BDR is not a shared-storage architecture; each node has its own copy of the database, including all relevant indexes etc. Nodes can satisfy queries without needing to communicate with other nodes, but must also have enough storage space to hold all the data in the database.
BDR is built on the logical decoding features developed by the BDR project and added to PostgreSQL 9.4. It also relies on other core PostgreSQL features that were added with BDR in mind, like background workers.
Because BDR needs some features that didn't make it into PostgreSQL by the time 9.4 was released, it needs a modified PostgreSQL to run. See BDR and UDR requirements. The UDR variant can run on an unmodified PostgreSQL - see Section 1.5.
We'd say "cluster", but PostgreSQL has historically used that term for a different and confusing purpose, to mean a particular PostgreSQL instance's collection of databases.