Skip to content

B
babeld
Commit 34cb26e0 authored by Juliusz Chroboczek's avatar Juliusz Chroboczek
Browse files
Options

Documentation updates.

parent b1dc0f29
Hide whitespace changes
Inline Side-by-side
Showing with 282 additions and 130 deletions
babel.text
View file @ 34cb26e0
...@@ -3,36 +3,50 @@ ...@@ -3,36 +3,50 @@
Juliusz Chroboczek Juliusz Chroboczek
<jch@pps.jussieu.fr> <jch@pps.jussieu.fr>
2 January 2008 12 February 2008
1. Introduction 1. Introduction
Babel is a distance vector protocol that is designed to be robust both on Babel is a distance vector protocol that is designed to be robust both on
classical wired networks and on wireless mesh networks. By robust, we mean classical wired networks and on wireless mesh networks.
that Babel has the following properties:
Babel operation is similar to that of familiar distance-vector routing
protocols, such as RIP and RIPng. Unlike these protocols, Babel decorates
each update with two additional pieces of data,
(i) the router-id of the originating router, which uniquely identifies
the router that injected this route into the Babel routing domain;
(ii) the sequence number of this update, a small integer that is
non-decreasing (modulo 2^16) for all updates originated by this
router.
These two pieces of data allow Babel to avoid the infamous ``counting to
infinity'' phenomenon familiar in classical distance-vector protocols by
using a feasibility condition similar to the one used by the DUAL algorithm
[DUAL] used by Cisco's EIGRP [EIGRP]. Unlike DUAL, however, Babel doesn't
use any hard state to make routes feasible; instead, it uses sequenced
updates in a manner similar to DSDV [DSDV] and AODV [RFC3561].
More precisely, Babel's feasibility condition ensures the following
properties:
(i) in the absence of multiple gateways to the same destination, Babel (i) in the absence of multiple gateways to the same destination, Babel
never causes rooting loops, not even transient ones; never causes rooting loops, not even transient ones;
(ii) in the presence of multiple gateways to the same destination, loops (ii) in the presence of multiple gateways to the same destination,
can only appear if multiple gateways loose external connectivity at transient loops may appear; however, such loops disappear after
the same time; such loops disappear after n updates at most, where n successful updates at most, where n is the size of the loop;
n is the size of the loop (there is no ``counting to infinity''); additionally, none of the nodes in that loop can participate in
(iii) any black holes disappear after at most n updates, where n is the a loop involving the same prefix and the same gateways for the
diameter of the network. duration of the router-id garbage collection timer.
These robustness properties are achieved by using a feasibility condition
similar to the one used by the DUAL algorithm [DUAL] used by Cisco's EIGRP
[EIGRP]. Unlike DUAL, however, Babel doesn't use any hard state to make
routes feasible; instead, it uses sequenced updates in a manner similar to
DSDV [DSDV] and AODV [RFC3561].
Additionally, Babel is designed to be a flexible protocol. A large number Additionally, Babel is designed to be a flexible protocol. A large number
of parameters are left to the implementer's discretion, such as the of parameters are left to the implementer's discretion, such as the
frequency of link quality sensing ``Hello'' messages, the frequency of frequency of link quality sensing ``Hello'' messages, the frequency of
periodic updates, the link quality estimation algorithm, or the route periodic updates, the link quality estimation algorithm, or the route
selection policy. Two implementations with widely differing parameters selection policy. This flexibility makes it possible to implement Babel
will interoperate reliably. simply and efficiently on ``simple'' link-layer technologies, while using
more complex techniques on wireless links.
2. Protocol operation 2. Protocol operation
...@@ -224,9 +238,9 @@ If the metric is infinite, the update is in fact a retraction. ...@@ -224,9 +238,9 @@ If the metric is infinite, the update is in fact a retraction.
2.3.1 Feasibility condition 2.3.1 Feasibility condition
A source is a pair (id, prefix). A reference distance is a pair (seqno, A source is a pair (id, prefix). A distance is a pair of a sequence number
metric), ordered lexicographically, with the first component inverted. In and a metric; we say that a distance (seqno, metric) is better than
other words, a distance (seqno', metric'), written
(seqno, metric) < (seqno', metric') (seqno, metric) < (seqno', metric')
...@@ -234,6 +248,9 @@ when ...@@ -234,6 +248,9 @@ when
seqno > seqno' or (seqno = seqno' and metric < metric'). seqno > seqno' or (seqno = seqno' and metric < metric').
In other words, distances are pairs of the form (seqno, metric), ordered
lexicographically, with the first component inverted.
The reference distance of a source is the minimum, according to the The reference distance of a source is the minimum, according to the
previous order, of the reference distances of all the updates ever sent for previous order, of the reference distances of all the updates ever sent for
that source. that source.
...@@ -253,7 +270,6 @@ source table entry is updated according to the following rules: ...@@ -253,7 +270,6 @@ source table entry is updated according to the following rules:
reset; reset;
- otherwise, the garbage collection timer for the entry is reset. - otherwise, the garbage collection timer for the entry is reset.
An entry in the table of sources is purged when its garbage collection An entry in the table of sources is purged when its garbage collection
timer hasn't been reset for 200 seconds. timer hasn't been reset for 200 seconds.
...@@ -269,6 +285,7 @@ feasible when one of the following conditions is true: ...@@ -269,6 +285,7 @@ feasible when one of the following conditions is true:
* seqno' > seqno or * seqno' > seqno or
* seqno' = seqno and metric' < metric. * seqno' = seqno and metric' < metric.
2.3.2 The Routing Information Base 2.3.2 The Routing Information Base
Every node maintains a Routing Information Base (RIB), a table of recently Every node maintains a Routing Information Base (RIB), a table of recently
...@@ -416,9 +433,9 @@ octets per destination; and the RIB takes about 50 bytes per entry. In ...@@ -416,9 +433,9 @@ octets per destination; and the RIB takes about 50 bytes per entry. In
other words, a single Ethernet packet can carry roughly 50 route updates, other words, a single Ethernet packet can carry roughly 50 route updates,
and a megabyte of memory can contain a 20000-entry RIB. and a megabyte of memory can contain a 20000-entry RIB.
Babel is also a simple protocol. The current sample implementation Babel is also a simple protocol. The first implementation consisted of
consists of less than 5000 lines of C code, and compiles to less than less than 4000 lines of C code, and compiled to less than 30 kB of code on
32 kB of code on a 32-bit CISC architecture. a 32-bit CISC architecture.
However, in some very constrained environments, such as PDAs, microwave However, in some very constrained environments, such as PDAs, microwave
ovens or abacuses, it may be desirable to have subset implementations of ovens or abacuses, it may be desirable to have subset implementations of
...@@ -440,8 +457,10 @@ An update (id, prefix, seqno', metric') is DSDV-feasible when ...@@ -440,8 +457,10 @@ An update (id, prefix, seqno', metric') is DSDV-feasible when
- seqno > seqno'; or - seqno > seqno'; or
- seqno = seqno' and metric < metric'. - seqno = seqno' and metric < metric'.
Note that the correctness of this condition is dependent on the fact that The correctness of this condition is dependent on the fact that retracted
retracted routes are not garbage collected too early. routes are not garbage collected too early. In other words, an implementation
that uses DSDV-feasibility MUST keep a RIB entry for a route for at least
a few minutes after it is retracted.
2.6.2 Parasitic implementations 2.6.2 Parasitic implementations
...@@ -473,125 +492,210 @@ meaning of a received message does not depend on the transport being used. ...@@ -473,125 +492,210 @@ meaning of a received message does not depend on the transport being used.
A Babel packet has the following structure: A Babel packet has the following structure:
- magic: 1 octet; 0 1 2 3
- version: 1 octet; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- reserved: 6 octets; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- body: n * 24 octets. | Magic | Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Body ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
The magic octet has the arbitrary but carefully chosen value 42; packets Fields:
with a first octet different from 42 MUST be silently ignored. Version has
the value 1; packets with a second octet different from 1 MUST be silently
ignored. The reserved field MUST be sent as 0, and ignored upon reception.
The body consists of an arbitrary number of messages (up to the link MTU or Magic This octet has an arbitrary but carefully chosen value 42;
the minimum maximum datagram size, whichever is more) of 24 octets each. packets with a first octet different from 42 MUST be
silently ignored.
Version This document specifies version 1 of the Babel protocol.
Packets with a second octet different from 1 MUST be
silently ignored.
3.2 Message format Reserved This field MUST be sent as 0, and ignored upon reception.
All Babel messages have the same format: Body This field consists of an arbitrary number of messages (up
to the link MTU or the minimum maximum datagram size,
whichever is more) of 24 octets each.
type: 1 octet;
h1: 1 octet;
s1: 2 octets;
s2: 2 octets;
s3: 2 octets;
a: 16 octets.
The interpretation of the fields h1, s1, s2, s3 and a depends on the value 3.2 Message format
of the type field, and is described in the following paragraphs.
All Babel messages have a length of 24 octets, and follow the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | |
+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ body +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field indicates the type of the message, and governs the
interpretation of the body.
Except for Hello messages (Section 3.2.1), all messages can be sent using Except for Hello messages (Section 3.2.1), all messages can be sent using
unicast or multicast, and their semantics does not depend on the transport unicast or multicast, and their semantics does not depend on the transport
being used. Hello messages may be sent using multicast only. being used. Hello messages may be sent using multicast only.
This document defines the interpretation of messages having a type field All implementations of Babel MUST be able to interpret messages of types
between 0 and 4 inclusive; unknown messages MUST be silently ignored. 0 to 4; unknown messages MUST be silently ignored.
3.2.1 Hello messages 3.2.1 Hello messages
type: 1 octet; 0 1 2 3
reserved: 3 octets; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
seqno: 2 octets; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
hello interval: 2 octets; | Type = 0 | Reserved |
id: 16 octets. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Hello Interval |
The type field is 0, indicating a Hello message. Seqno indicates the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
sequence number of this hello message; it is incremented by one (modulo | |
2^16) every time a hello is sent. The hello interval indicates a time in + +
centiseconds after which the next hello will be scheduled; the sending node | |
MAY send the next hello earlier than that, but MUST NOT send the next hello + Router ID +
later then after 1.5 times this interval. The id field indicates the | |
router id of the router sending this hello; it MUST be unique within the + +
routing domain, and SHOULD NOT change over time. | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type Set to 0 to indicate a Hello message.
Reserved The reserved field must be set to 0 on emission, and
ignored on reception.
Seqno Indicates the sequence number of this hello message; it is
incremented by one (modulo 2^16) every time a hello is sent
by this router on this subnet.
Hello Interval
Indicates the interval in centiseconds after which the next
hello will be scheduled; the sending node MAY send the next
hello earlier than that, but MUST NOT send it later than
after 1.5 times this interval has expired.
Router ID Indicates the router ID of the sender.
In order to allow accurate link quality measurement, hello messages MUST In order to allow accurate link quality measurement, hello messages MUST
NOT be sent using unicast. NOT be sent using unicast.
3.2.2 IHU messages 3.2.2 IHU messages
type: 1 octet; 0 1 2 3
reserved: 3 octets; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
IHU interval: 2 octets; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
txcost: 2 octets. | Type = 1 | Reserved |
id: 16 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IHU Interval | Txcost |
The type field is 1 to indicate an IHU (``I Heard You'') message. The IHU +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
interval field indicates the interval in centiseconds after which the next | |
scheduled multicast IHU message will be sent by this router; an IHU MAY be + +
sent earlier than that, but MUST NOT be sent later than after this interval | |
plus half the hello interval. + Destination Router ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type Set to 1 to indicate an IHU (``I Heard You'') message.
IHU Interval
Indicates the interval in centiseconds after which the next
scheduled multicast IHU message will be sent by this
router; an IHU MAY be sent earlier than that, but MUST NOT
be sent later than after this interval plus half the hello
interval.
Txcost This fixed-point number in 8.8 bit format specifies the
cost, as estimated by the sender, of sending a link-layer
frame from the router identified by the Destination Router
ID field to the sender of this message. The value 0xFF.0xFF
(infinity) indicates that the link is not operational.
Destination Router ID
This field specifies the router-id of the router to whom
this message is addressed.
The txcost field expresses the cost of sending messages from the router
identified by the id field to the router sending this message. It is
specified as a fixed-point number in 16.16 bit format. The value 0xFF.0xFF
(infinity) indicates that the link from the router identified by the id
field to the router sending this message is broken.
3.2.3 Request message 3.2.3 Request message
type: 1 octet; 0 1 2 3
plen: 1 octet; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
reserved: 1 octet; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
hop count: 1 octet; | Type = 2 | Plen | Reserved | Hop Count |
seqno: 2 octets; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
router-id hash: 2 octets; | Seqno | Id Hash |
prefix: 16 octets. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type Set to 2 to indicate a Request message.
Plen The length of the requested prefix, or 0xFF if this is
a wildcard request.
Hop Count The number of routers this request may be forwarded by.
Seqno The requested sequence number.
Id Hash A hash of the requested router id.
Prefix The requested prefix.
A request message is used for requesting an update from the receiver. A request message is used for requesting an update from the receiver.
A reply to a request is a packet consisting of update and prefix messages, A reply to a request is a packet consisting of update and prefix messages,
sent either to the well-known multicast address, or to the source address sent either to the well-known multicast address, or to the source address
of the packet carrying the request message, at the sender's discretion. of the packet carrying the request message, at the sender's discretion.
The type field is 2 to indicate a request message. There are three kinds There are three kinds of request messages.
of request messages.
3.2.3.1 Full table requests 3.2.3.1 Full table requests
If plen is 0xFF, then this is a request for a full dump of the routing If Plen is 0xFF, then this is a request for a full dump of the routing
table; in this case, hop count must be zero and is ignored on reception. table; in this case, the Hop Count field must be zero and is ignored on
When a Babel speaker receives such a request, it responds with a full dump reception. When a Babel speaker receives such a request, it responds with
of its routing table. a full dump of its routing table.
3.2.3.2 Specific requests 3.2.3.2 Specific requests
If plen is no more than 128 and hop count is 0, then this is a request for If Plen is no more than 128 and hop count is 0, then this is a request for
a route with the destination specified by prefix and plen. If the a route with the destination specified by Prefix and Plen. If the
receiving Babel speaker has selected a route with that destination, it receiving Babel speaker has selected a route with that destination, it
replies with an update for this route. Otherwise, it sends a retraction replies with an update for this route. Otherwise, it sends a retraction
for that destination. for that destination.
3.2.3.3 Multi-hop requests 3.2.3.3 Multi-hop requests
Finally, if plen is no more than 128 and hop count is larger than 0, then Finally, if Plen is no more than 128 and hop count is larger than 0, then
this is a multi-hop request for a particular sequence number. If the this is a multi-hop request for a particular sequence number. If the
receiver's router-id matches the router-id hash, and it is exporting receiver's router-id matches the Id Hash, and it is exporting a route to
a route to the requested destination, it increases its sequence number to the requested destination, it increases its sequence number to match the
match the seqno field of the request, and sends an update. seqno field of the request, and sends an update.
Otherwise, If the receiver has selected a route with the destination Otherwise, if the receiver has selected a route with the destination
specified by prefix and plen, a router id that matches the hash, and specified by Prefix and Plen, a router id that matches the ID Hash, and
a sequence number no less than seqno, it replies with an update for that a sequence number no less than Seqno, it replies with an update for that
route. If the receiver has a route for that destination with a different route. If the receiver has a route for that destination with a different
router id, it sends an update for that route. router id, it sends an update for that route.
...@@ -602,55 +706,103 @@ decreasing the hop count by one. If the hop count is 1, it remains silent. ...@@ -602,55 +706,103 @@ decreasing the hop count by one. If the hop count is 1, it remains silent.
A speaker SHOULD keep track of forwarded multi-hop requests, and forward A speaker SHOULD keep track of forwarded multi-hop requests, and forward
the replies whenever a request is satisfied. the replies whenever a request is satisfied.
Finally, if the receiver has no route to the given destination, it sends If the receiver has no route to the given destination, it remains silent.
a retraction for that destination.
3.2.4 Update 3.2.4 Update
type: 1 octet; 0 1 2 3
plen: 1 octet; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
reserved: 2 octets; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
seqno: 2 octets; | Type = 3 | Plen | Reserved |
metric: 2 octets; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
id: 16 octets. | Seqno | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Router ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type Set to 3 to indicate an Update message.
Plen The prefix length of the advertised prefix, or 0xFF.
Seqno The sequence number of this advertisement in 8.8 format, or
zero.
Metric The metric of the advertised route, or zero.
Router ID The router id of the originator of this route.
The type field is 3 to indicate an update message. If plen is 0xFF (the If Plen is 0xFF (the normal case), the field Router ID establishes the
normal case), the field id establishes the context for the following update context for the following update message; all the other fields MUST then be
message; all the other fields MUST then be sent as 0 and ignored upon sent as 0, and ignored upon reception.
reception.
If plen is between 0 and 0x80, inclusive, the message is an abbreviation If Plen is between 0 and 0x80, inclusive, the message is an abbreviation
for an update message followed by a prefix message (Section 3.2.5). More for an update message followed by a prefix message (Section 3.2.5); the
precisely, the message implicit prefix is then taken to be the prefix of length plen of the
advertised router id. More precisely, the message
(3, plen, 0, seqno, metric, id) (3, plen, 0, seqno, metric, id)
is interpreted just like the sequence of two messages is interpreted just like the sequence of two messages
(3, 0xFF, 0, 0, 0, id) (3, 0xFF, 0, 0, 0, id)
(4, plen, 0, seqno, metric, id) (4, plen, 0, seqno, metric, prefix)
where prefix is equal to id masked to plen bits.
3.2.5 Prefix information 3.2.5 Prefix information
type: 1 octet; 0 1 2 3
plen: 1 octet; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
reserved: 2 octets; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
seqno: 2 octets; | Type = 4 | Plen | Reserved |
metric: 2 octets; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
prefix: 16 octets. | Seqno | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type Set to 4 to indicate a Prefix message.
Plen The prefix length of the advertised prefix.
Seqno The sequence number of this advertisement.
Metric The metric of the advertised route, in 8.8 bit fixed-point
format.
Prefix The prefix being advertised.
The type field is 4 to indicate a prefix message. A prefix message MUST
immediately follow either an update message, or another prefix message. A Prefix message MUST immediately follow either an UPDATE message, or
another PREFIX message.
The metric field is a fixed-point number in 16.16 bit format, and The Metric field is a fixed-point number in 8.8 bit format, and represents
represents an additive metric. The value 0xFF.0xFF (infinite) indicates an additive metric. The value 0xFF.0xFF (infinity) indicates that this is
that this is a route retraction. a route retraction.
An update message specifies an update for the route to destination (prefix, An update message specifies an update for the route to destination (prefix,
plen), with a sequence number given by the field seqno, a metric given by plen), with a sequence number given by the field Seqno, a metric given by
the metric field, and a source indicated by the id field of the preceding the Metric field, and a source indicated by the Router ID field of the
update message. preceding update message.
3.2.6 IPv4 prefix information 3.2.6 IPv4 prefix information
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7