As per Relevance of the word september, we have this rfc below:
Network Working Group P.
Request for Comments: 2909 D.
Category: Experimental R.
USC/
M.
S.
USC/
D.
September 2000
The Multicast Address-Set Claim (MASC)
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document describes the Multicast Address-Set Claim (MASC
protocol which can be used for inter-domain multicast address
allocation. MASC is used by a node (typically a router) to claim
allocate one or more address prefixes to that node's domain. While
domain does not necessarily need to allocate an address set for
in that domain to be able to allocate group addresses, allocating
address set to the domain does ensure that inter-domain group
specific distribution trees will be locally-rooted, and that
will be sent outside the domain only when and where
receivers exist
Radoslavov, et al. Experimental [Page 1]
RFC 2909 The MASC Protocol September 2000
Table of
1 Introduction .................................................. 4
1.1 Terminology ................................................. 4
1.2 Definitions ................................................. 4
2 Requirements for Inter-Domain Address Allocation .............. 5
3 Overall Architecture .......................................... 5
3.1 Claim-Collide vs. Query-Response Rationale .................. 6
4 MASC Topology ................................................. 6
4.1 Managed vs Locally-Allocated Space .......................... 8
4.2 Prefix Lifetime ............................................. 8
4.3 Active vs. Deprecated Prefixes .............................. 9
4.4 Multi-Parent Sibling-to-Sibling and Internal Peering ........ 9
4.5 Administratively-Scoped Address Allocation .................. 9
5 Protocol Details .............................................. 10
5.1 Claiming Space .............................................. 10
5.1.1 Claim Comparison Function ................................. 12
5.2 Renewing an Existing Claim .................................. 12
5.3 Expanding an Existing Prefix ................................ 12
5.4 Releasing Allocated Space ................................... 13
6 Constants ..................................................... 13
7 Message Formats ............................................... 14
7.1 Message Header Format ....................................... 14
7.2 OPEN Message Format ......................................... 15
7.3 UPDATE Message Format ....................................... 17
7.4 KEEPALIVE Message Format .................................... 21
7.5 NOTIFICATION Message Format ................................. 21
8 MASC Error Handling ........................................... 24
8.1 Message Header Error Handling ............................... 24
8.2 OPEN Message Error Handling ................................. 25
8.3 UPDATE Message Error Handling ............................... 26
8.4 Hold Timer Expired Error Handling ........................... 28
8.5 Finite State Machine Error Handling ......................... 28
8.6 NOTIFICATION Message Error Handling ......................... 28
8.7 Cease ....................................................... 29
8.8 Connection Collision Detection .............................. 29
9 MASC Version Negotiation ...................................... 30
10 MASC Finite State Machine .................................... 30
10.1 Open/Close MASC Connection FSM ............................. 31
11 UPDATE Message Processing .................................... 35
11.1 Accept/Reject an UPDATE .................................... 36
11.2 PREFIX_IN_USE Message Processing ........................... 38
11.2.1 PREFIX_IN_USE by PARENT .................................. 38
11.2.2 PREFIX_IN_USE by SIBLING ................................. 38
11.2.3 PREFIX_IN_USE by CHILD ................................... 38
11.2.4 PREFIX_IN_USE by INTERNAL_PEER ........................... 38
11.3 CLAIM_DENIED Message Processing ............................ 39
11.3.1 CLAIM_DENIED by CHILD or SIBLING ......................... 39
Radoslavov, et al. Experimental [Page 2]
RFC 2909 The MASC Protocol September 2000
11.3.2 CLAIM_DENIED by INTERNAL_PEER ............................ 39
11.3.3 CLAIM_DENIED by PARENT ................................... 39
11.4 CLAIM_TO_EXPAND Message Processing ......................... 39
11.4.1 CLAIM_TO_EXPAND by PARENT ................................ 39
11.4.2 CLAIM_TO_EXPAND by SIBLING ............................... 40
11.4.3 CLAIM_TO_EXPAND by CHILD ................................. 40
11.4.4 CLAIM_TO_EXPAND by INTERNAL_PEER ......................... 40
11.5 NEW_CLAIM Message Processing ............................... 41
11.6 PREFIX_MANAGED Message Processing. ........................ 41
11.6.1 PREFIX_MANAGED by PARENT ................................. 41
11.6.2 PREFIX_MANAGED by CHILD or SIBLING ....................... 41
11.6.3 PREFIX_MANAGED by INTERNAL_PEER .......................... 41
11.7 WITHDRAW Message Processing ................................ 42
11.7.1 WITHDRAW by CHILD ........................................ 42
11.7.2 WITHDRAW by SIBLING ...................................... 42
11.7.3 WITHDRAW by INTERNAL ..................................... 42
11.7.4 WITHDRAW by PARENT ....................................... 43
11.8 UPDATE Message Ordering .................................... 43
11.8.1 Parent to Child .......................................... 43
11.8.2 Child to Parent .......................................... 44
11.8.3 Sibling to Sibling ....................................... 44
11.8.4 Internal to Internal ..................................... 44
12 Operational Considerations ................................... 45
12.1 Bootup Operations .......................................... 45
12.2 Leaf and Non-leaf MASC Domain Operation .................... 45
12.3 Clock Skew Workaround ...................................... 45
12.4 Clash Resolving Mechanism .................................. 46
12.5 Changing Network Providers ................................. 47
12.6 Debugging .................................................. 47
12.6.1 Prefix-to-Domain Lookup .................................. 47
12.6.2 Domain-to-Prefix Lookup .................................. 47
13 MASC Storage ................................................. 47
14 Security Considerations ...................................... 48
15 IANA Considerations .......................................... 48
16 Acknowledgments .............................................. 48
17 APPENDIX A: Sample Algorithms ................................ 49
17.1 Claim Size and Prefix Selection Algorithm .................. 49
17.1.1 Prefix Expansion ......................................... 49
17.1.2 Reducing Allocation Latency .............................. 50
17.1.3 Address Space Utilization ................................ 50
17.1.4 Prefix Selection After Increase of Demand ................ 50
17.1.5 Prefix Selection After Decrease of Demand ................ 51
17.1.6 Lifetime Extension Algorithm ............................. 51
18 APPENDIX B: Strawman Deployment .............................. 51
19 Authors' Addresses ........................................... 52
20 References ................................................... 54
21 Full Copyright Statement ..................................... 56
Radoslavov, et al. Experimental [Page 3]
RFC 2909 The MASC Protocol September 2000
1.
This document describes MASC, a protocol for inter-domain
address set allocation. The MASC protocol (a Layer-3 protocol in
multicast address allocation architecture [MALLOC]) is used by a
(typically a router) to claim and allocate one or more
prefixes to that node's domain. Each prefix has an
lifetime, and is chosen out of a larger prefix with a lifetime
least as long, in a manner such that prefixes are aggregatable.
any time, each MASC node (a Prefix Coordinator in [MALLOC])
typically advertise several prefixes with different lifetimes
scopes, allowing Multicast Address Allocation Servers (MAAS's)
that domain or child MASC domains to choose appropriate addresses
their clients
The set of prefixes ("address set") associated with a domain
injected into an inter-domain routing protocol (e.g., BGP4+ [MBGP]),
where it can be used by an inter-domain multicast tree
protocol (e.g., BGMP [BGMP]) to construct inter-domain group-
trees
Note that a domain does not need to allocate an address set for
hosts in that domain to be able to allocate group addresses, nor
allocating necessarily guarantee that hosts in other domains will
use an address in the set (since, for example, hosts are not
to contact a MAAS before using a group address). Allocating
address set to a domain does, however, ensure that inter-
group-specific multicast distribution trees for any group in
address set will be locally-rooted, and that traffic will be
outside the given domain only when and where external
exist
1.1.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [RFC2119].
Constants used by this protocol are shown as [NAME_OF_CONSTANT],
summarized in Section 6.
1.2.
This specification uses a number of terms that may not be familiar
the reader. This section defines some of these and refers to
documents for definitions of others
Radoslavov, et al. Experimental [Page 4]
RFC 2909 The MASC Protocol September 2000
MAAS (Multicast Address Allocation Server
A host providing multicast address allocation services to
users (e.g. via MADCAP [MADCAP]).
MASC
A node running MASC
Other MASC speakers a node directly communicates with
IP Multicast, as defined for IPv4 in [RFC1112] and for IPv6
[RFC2460].
Multicast
An IP multicast address or group address, as defined in [RFC1112]
and [RFC2373]. An identifier for a group of nodes
2. Requirements for Inter-Domain Address
The key design requirements for the inter-domain address
mechanism are
o Efficient address space utilization when space is scare,
naturally implies that address allocations be based on the
address usage patterns, and therefore that it be dynamic
o Address aggregation, that implies that the address
mechanism be hierarchical
o Minimize flux in the allocated address sets (e.g. the address
should be reused when possible).
o Robustness, by using decentralized mechanisms
The timeliness in obtaining an address set is not a major
constraint as this is taken care of at a lower level [MALLOC].
3. Overall
The Multicast Address Set Claim (MASC) protocol is used by
domains to claim and allocate address sets for use by
Address Allocation Servers (MAASs) within each domain. Typically
or more border routers of each domain that requires multicast
space of its own would run MASC. Throughout this document, the
"MASC domain" refers to a domain that has at least one node
MASC; typically these domains will be Autonomous Systems (AS's).
MASC node (on behalf of its domain) chooses an address set to claim
Radoslavov, et al. Experimental [Page 5]
RFC 2909 The MASC Protocol September 2000
sends a claim to other MASC domains in the network, and waits
listening for any colliding claims. If there is a collision,
losing claimer gives up the colliding claim and claims a
address set
After a sufficiently long collision-free waiting period, the
set chosen by a MASC node is considered allocated to that node'
domain. Three things may then happen
a) The allocated prefix can then be injected as a "multicast route
into the inter-domain routing protocol (e.g., BGP4+ [MBGP])
"G-RIB" Network Layer Reachability Information (NLRI), where
may be used by an inter-domain multicast routing protocol (e.g.,
BGMP [BGMP]) to construct group-shared trees. To reduce the
and slow the growth of the G-RIB, MASC nodes may perform CIDR-
aggregation [CIDR] of the multicast NLRI information.
motivates the need for an algorithm to select prefixes for
in such a way as to ensure good aggregation in addition
achieving good address space utilization
b) The node's domain may assign to itself a sub-prefix which can
used by MAASs within the domain
c) Sub-prefixes may be allocated to child domains, if any
3.1. Claim-Collide vs. Query-Response
We choose a claim-collide mechanism instead of a query-
mechanism for the following reasons. In a query-response mechanism
replicas of the MASC node would be needed in parent MASC domains
order to make their responses be robust to failures. This
about the associated problem of synchronization of the replicas
possibly additional fragmentation of the address space. In addition
even in this mechanism, address collisions would still need to
handled. We believe the proposed claim-collide mechanism is
and more robust than a query-response mechanism
4. MASC
The domain hierarchy used by MASC is congruent to the
hierarchical structure of the inter-domain topology, e.g.,
connected to regionals, regionals connected to
providers, etc. As in BGP, MASC connections are locally configured
A MASC domain that is a customer of other MASC domains will have
or more of those provider domains as its parent. For example, a
domain that is a regional provider will choose one (or more) of
backbone provider domains as its parent(s). Children are
with their parent MASC domain, and parents are configured with
Radoslavov, et al. Experimental [Page 6]
RFC 2909 The MASC Protocol September 2000
children domains. At the top, a number of Top-Level Domains
connected in a (sparse) mesh and share the global multicast
space. To improve the robustness, a pair of children of the
parent domain MAY be configured as siblings with regard to
parent
Figure 1 illustrates a sample topology. Double-line links
intra-domain TCP peering sessions, and single-line links
inter-domain TCP connections. T1 and T2 are Top-Level Domains (e.g.,
backbone providers), containing MASC speakers T1a and T2a
respectively. P3 and P4 are regional domains, containing (P3a, P3b),
and (P4a, P4b) respectively. P3 has a single customer (or "child"),
C5, containing (C5a, C5b, C5c). P4 has three children, C5, C6, C7,
containing (C5a, C5b, C5c), (C6a, C6b), and (C7a) respectively
T1a-----------T2
| |
| |
| |
P3a====P3b P4a====P4
| | / | / | \
| | _______/ | / | \
| | / | / | \______
| | / | / | \
C5a====C5b C6a====C6b----------C7
\\ //
\\//
C5
Figure 1: Example MASC
All MASC communications use TCP. Each MASC node is connected to
communicates directly with other MASC nodes. The local node acts
exactly one of the following four roles with respect to each
note
INTERNAL_
The local and remote nodes are both in the same MASC domain.
example, P4b is an INTERNAL_PEER of P4a
A customer relationship exists whereby the local node may
address space from the remote node. For example, C6a is a
in its session with P4a
Radoslavov, et al. Experimental [Page 7]
RFC 2909 The MASC Protocol September 2000
A provider relationship exists whereby the remote node may
address space from the local node. For example, T2a is a
in its session with P4a. Whether space is actually requested
up to the implementation and local policy configuration
No customer-provider relationship exists. For example, T2a is
SIBLING in its session with T1a (Top-Level Domain
peering). Also, C6b is a SIBLING in its session with C7a
regard to their common parent P4.
A node's message will be propagated to its parent, all siblings
the same parent, and its children. Since a domain need not have
direct peering session with every sibling, a MASC domain
propagate messages from a child domain to other children,
propagate messages from a parent domain to other siblings, and, if
Top-Level Domain, it must propagate messages from a sibling to
siblings, otherwise may propagate messages from a sibling domain
its parent and other siblings
4.1. Managed vs Locally-Allocated
Each domain has a "Managed" Address Set, and a "Locally-Allocated
Address Set. The "managed" space includes all address space which
domain has successfully claimed via MASC. The "locally-allocated
space, on the other hand, includes all address space which
inside the domain may use. Thus, the locally-allocated space is
subset of the managed space, and refers to the portion which a
allocates for its own use
For leaf domains (ones with no children), these two sets
identical, since all claimed space is allocated for local use.
parent domain, on the other hand, "manages" all address space
it has claimed via MASC, while sub-prefixes can be allocated
itself and to its children
4.2. Prefix
Each prefix has an associated lifetime. If a domain wants to use
prefix longer than its lifetime, that domain must "renew" the
BEFORE its lifetime expires (see Section 5.2). If the
cannot be extended, then the domain should either retry later
extend, or should choose and claim another prefix
Radoslavov, et al. Experimental [Page 8]
RFC 2909 The MASC Protocol September 2000
After a prefix's lifetime expires, MASC nodes in the domain that
that prefix must stop using that prefix. The corresponding
from the G-RIB database must be removed, and all
associated with the expired prefix may be deleted from the
node's local memory
4.3. Active vs. Deprecated
Each prefix advertised by a parent to its children can be
"active" or "deprecated". A "deprecated" prefix is a prefix that
parent wishes to discontinue to use after its lifetime expires.
"active" prefixes only are candidates for size expansion or
extension. Usually, this information will be used by a child as
hint to know which of the parent's prefixes might have their
extended
4.4. Multi-Parent Sibling-to-Sibling and Internal
Two sibling nodes that have more than one common parent will
and use between them a number of transport-level connections, one
each common parent. The information associated with a parent will
sent over the connection that corresponds to the same parent
Internal peers do not need to open multiple connections between them
a single connection is used for all information
4.5. Administratively-Scoped Address
MASC can also be used for sub-allocating prefixes of addresses
an administrative scope zone [SCOPE], but only if the scope
"divisible" (as described in [MALLOC] and [MZAP]). A MASC node
learn what scopes it resides within by listening to MZAP [MZAP
messages
A "Zone TLD" is a domain which has no parent domain within the
zone. Zone TLDs act as TLDs for the prefix associated with
scope. Figure 2 gives an example, where a scope boundary
domains P3 and C5 has been added to Figure 1. Domain P3 is a
TLD, since its only parent (T1) is outside the boundary. Hence, P
can claim space directly out of the prefix associated with the
itself. Domain C5, on the other hand, has a parent within the
(namely, P3), and hence is not a Zone TLD
Radoslavov, et al. Experimental [Page 9]
RFC 2909 The MASC Protocol September 2000
T1a-----------T2
| |
............|....... |
. | . |
. P3a====P3b . P4
. | | . /
. | | _______/
. | | / .
. | | / .
. C5a====C5b .
. \\ // .
. \\// .
. C5c .
. .
. Admin Scope Zone .
....................
Figure 2: Scope Zone
It is assumed that the role of a node (as discussed in Section 4)
with respect to a given peering session is the same for every
in which both ends are contained. A peering session that crosses
scope boundary (such as the session between C5b and P4a in Figure 2)
is ignored when propagating messages that pertain to the given scope
That is, such messages are not sent across such sessions
5. Protocol
5.1. Claiming
When a MASC node, on behalf of a MASC domain, needs more
space, it decides locally the size and the value of the
prefix(es) it will claim from one of its parents. For example,
decision might be based on the knowledge this node has about
parent's address set, its siblings' claims and allocations, its
address set, the claim messages from its siblings, and/or the
pattern of its children and the local domain. A sample algorithm
given in Appendix A
A MASC node which is not in a top-level domain can initiate a
toward a parent MASC domain if and only if it currently has
established connection with at least one node in that parent domain
After the prefix address and size are decided, the claim proceeds
follows
Radoslavov, et al. Experimental [Page 10]
RFC 2909 The MASC Protocol September 2000
a) The claim is scheduled to be sent after a random delay in
interval (0, [INITIATE_CLAIM_DELAY]). If a claim originated by
node from the same MASC domain is received, and that
eliminates the need for the local claim, the local claim
canceled and no further action is taken
b) The claim is sent to one of the parents (if the domain is not
top-level domain), all known siblings with the same parent,
all internal peers. A Claim-Timer is then started
[WAITING_PERIOD], and the MASC node starts listening for
claims
c) If a colliding claim is received while the Claim-Timer is running
that claim is compared with the locally initiated claim using
function described in Section 5.1.1. If the local claim is
loser, a new prefix must be chosen to claim, and the loser claim'
Claim-Timer must be canceled. The loser claim can be
explicitly withdrawn, or can be left to expire without
further actions. If the winning claim was originated by a
from the same MASC domain, no new claim will be initiated. If
local claim is the winner, no actions need to be taken
d) If the Claim-Timer expires, the claimed prefix becomes
with the claimer's domain, i.e. it is considered allocated to
domain and the following actions can be performed
o Advertise the prefix to its parent, and to all siblings
the same parent, by sending a PREFIX_IN_USE claim to them
o Inject the prefix into the G-RIB of the inter-domain
protocol
o Send a PREFIX_MANAGED message to all children and
peers, informing them that they may issue claims within
managed space. A sub-prefix may then be claimed for
usage (see Section 12.2).
Each MASC node receives all claims from its siblings and children.
received claim must be evaluated against all claims saved in
local cache using the function described in Section 5.1.1.
output of the function will define the further processing of
claim (see Section 11).
Radoslavov, et al. Experimental [Page 11]
RFC 2909 The MASC Protocol September 2000
5.1.1. Claim Comparison
Each claim message includes
o a "type", being one of: PREFIX_IN_USE, CLAIM_DENIED
CLAIM_TO_EXPAND, or NEW_CLAIM (PREFIX_MANAGED and WITHDRAW
not considered as claims that have to be compared
o timestamp when the claim was
o the claimed prefix and
o MASC Identifier of the node that originated the
When two claims are compared, first the type is compared based on
following precedence
PREFIX_IN_USE > CLAIM_DENIED > CLAIM_TO_EXPAND > NEW_
If the type is the same, then the timestamps are used to compare
claims. In practice, two claims will have the same type if the
is either NEW_CLAIM (ordinary collision) or PREFIX_IN_USE (signal
a clash). When the timestamps are compared, the claim with
smallest, i.e. earliest timestamp wins. If the timestamps are
same, then the claim with the smallest Origin Node Identifier wins
5.2. Renewing an Existing
The procedure for extending the lifetime of prefixes already in
is the same as claiming new space (see Section 5.1), except that
claim type must be CLAIM_TO_EXPAND, while the Address and the Mask
the claim (see Section 7.3) must be the same as the already
prefix. If the Claim-Timer expires and there is no collision,
desired lifetime is assumed
5.3. Expanding an Existing
The procedure for extending the lifetime of prefixes already in
is the same as claiming new space (see Section 5.1), except that
claim type must be CLAIM_TO_EXPAND, while the Address and the Mask
the claim (see Section 7.3) must be set to the desired values.
the Claim-Timer expires and there is no collision, the desired
prefix is associated with the local domain
Radoslavov, et al. Experimental [Page 12]
RFC 2909 The MASC Protocol September 2000
5.4. Releasing Allocated
If the lifetime of a prefix allocated to the local domain expires
the domain does not need to reuse it, all resources associated
this prefix are deleted and no further actions are taken. If
lifetime of the prefix has not expired, and if no subranges of
prefix have being allocated for local usage or by some of
children domains, the space may be released by sending a
message to the parent domain, all known siblings with the
parent, and all internal peers
6.
MASC uses the following constants
[PORT_NUMBER
2587. The TCP port number used to listen for incoming
connections, as assigned by IANA
[WAITING_PERIOD
The amount of time (in seconds) that must pass between a NEW_
(or CLAIM_TO_EXPAND), and a PREFIX_IN_USE for the same prefix
This must be long enough to reasonably span any single inter
domain network partition. Default: 172800 seconds (i.e. 48
hours).
[INITIATE_CLAIM_DELAY
The amount of time (in seconds) a MASC node must wait
initiating a new claim or a claim for space expansion. This
be a random value in the interval (0, [INITIATE_CLAIM_DELAY]).
Default value for [INITIATE_CLAIM_DELAY]: 600 seconds (i.e. 10
minutes).
[TLD_ID
The Parent Domain Identifier used by a Top-Level Domain (which
no parent). Must be 0.
[HOLDTIME
The amount of time (in seconds) that must pass without
messages received from a remote node before considering
connection is down. Default: 240 seconds (i.e. 4 minutes).
Radoslavov, et al. Experimental [Page 13]
RFC 2909 The MASC Protocol September 2000
7. Message
This section describes message formats used by MASC
Messages are sent over a reliable transport protocol connection.
message is processed only after it is entirely received. The
message size is 4096 octets. All implementations are required
support this maximum message size
7.1. Message Header
Each message has a fixed-size (4-octets) header. There may or
not be a data portion following the header, depending on the
type. The layout of these fields is shown below
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
This 2-octet unsigned integer indicates the total length of
message, including the header, in octets. Thus, e.g., it
one to locate in the transport-level stream the start of the
message. The value of the Length field must always be at least 4
and no greater than 4096, and may be further constrained
depending on the message type. No "padding" of extra data
the message is allowed, so the Length field must have the
value required given the rest of the message
Type
This 1-octet unsigned integer indicates the type code of
message. The following type codes are defined
1 -
2 -
3 -
4 -
Reserved
This 1-octet field is reserved. MUST be set to zero by the sender
and MUST be ignored by the receiver
Radoslavov, et al. Experimental [Page 14]
RFC 2909 The MASC Protocol September 2000
7.2. OPEN Message
After a transport protocol connection is established, the
message sent by each side is an OPEN message. If the OPEN message
acceptable, a KEEPALIVE message confirming the OPEN is sent back
Once the OPEN is confirmed, UPDATE, KEEPALIVE, and
messages may be exchanged
The minimum length of the OPEN message is 20 octets (
message header). In addition to the fixed-size MASC header, the
message contains the following fields
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |R| AddrFam |Rol| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MASC Node Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parent's Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
This 1-octet unsigned integer indicates the protocol
number of the message. The current MASC version number is 1.
R bit
This 1-bit field is reserved. MUST be set to zero by the sender
and MUST be ignored by the receiver
AddrFam
This 5-bit field is the IANA-assigned address family number of
encoded prefix [IANA]. These include (among others):
Number
------ -----------
1 IP (IP version 4)
2 IPv6 (IP version 6)
Radoslavov, et al. Experimental [Page 15]
RFC 2909 The MASC Protocol September 2000
My Role (Rol):
This 2-bit field indicates the proposed relationship of
sending system to the receiving system
00 = INTERNAL_PEER (sent from one internal peer to another
01 = CHILD (sent from a child to its parent
10 = SIBLING (sent from one sibling to another
11 = PARENT (sent from a parent to its child
Hold Time
This 2-octet unsigned integer indicates the number of seconds
the sender proposes for the value of the Hold Timer. Upon
of an OPEN message, a MASC speaker MUST calculate the value of
Hold Timer by using the smaller of its configured Hold Time
that peer and the Hold Time received in the OPEN message.
Hold Time MUST be either zero or at least three seconds.
implementation may reject connections on the basis of the
Time. The calculated value indicates the maximum number
seconds that may elapse between the receipt of
KEEPALIVE and/or UPDATE messages by the sender. RECOMMENDED
is [HOLDTIME] seconds
Sender Domain Identifier
A globally unique identifier. Its length is determined based
the Address Family, and should be treated as an unsigned
(e.g. a 4-octet integer for IPv4, or a 16-octet integer for IPv6),
but must be at least 4 octets long. It should be set to
Autonomous System number of the sender, but the network
prefix address is also acceptable
Sender MASC Node Identifier
This field's length and format are same as the Sender
Identifier field, and indicates the MASC Node Identifier of
sender. A given MASC speaker sets the value of its MASC
Identifier to a globally-unique value assigned to that
speaker (e.g., an IPv4 or IPv6 address). The value of the
Node Identifier is determined on startup and is the same for
MASC session opened
Parent's Domain Identifier
This field's length and format are same as the Sender
Identifier field, and is set to the Domain Identifier of
sender's parent (e.g. the parent's Autonomous System number,
network prefix address), or is set to [TLD_ID] if the sender is
TLD. Used only when Rol is INTERNAL_PEER or SIBLING, otherwise
ignored. This field is used to determine the common
between siblings, to associate each sibling-to-sibling
with a particular parent, and to discover TLD-
Radoslavov, et al. Experimental [Page 16]
RFC 2909 The MASC Protocol September 2000
configuration problems among internal peers. If a non-TLD
does not know yet the Domain ID of any of its parents, it can
its own Domain ID in the OPEN messages to its internal peers
Optional Parameters
This field may contain a list of optional parameters, where
parameter is encoded as a <Parameter Length, Parameter Type
Parameter Value> triplet. The combined length of all
parameters can be derived from the Length field in the
header
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Length | Parm. Type | Parameter Value (variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Parameter Length is a one octet field that contains the length
the Parameter Value field in octets. Parameter Type is a
octet field that unambiguously identifies individual parameters
Parameter Value is a variable length field that is
according to the value of the Parameter Type field.
optional parameters MUST be silently ignored
This document does not define any optional parameters
7.3. UPDATE Message
UPDATE messages are used to transfer Claim/Collision/
information between MASC speakers. The UPDATE message
includes the fixed-size MASC header, and one or more attributes
described below. The minimum length of the UPDATE message is 40
octets (including the message header).
Each attribute is of the form
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All attributes are 4-octets aligned
Radoslavov, et al. Experimental [Page 17]
RFC 2909 The MASC Protocol September 2000
Length
The Length is the length of the entire attribute, including
length, type, and data fields. If other attributes are
within the data field, the length includes the size of all
nested attributes
Type
This 1-octet unsigned integer indicates the type code of
attribute. The following type codes are defined
0 = PREFIX_IN_USE (prefix is being used by the origin
1 = CLAIM_DENIED (the claim is refused (probably by
origin's parent domain))
2 = CLAIM_TO_EXPAND (origin is trying to expand the size
an existing prefix
3 = NEW_CLAIM (origin is trying to claim a new prefix
4 = PREFIX_MANAGED (parent is informing child of
available
5 = WITHDRAW (origin is withdrawing a previous claim
Types 128-255 are reserved for "optional" attributes. If
required attribute is unrecognized, a NOTIFICATION with
Error Code and Unrecognized Required Attribute subcode will
sent. Unrecognized optional attributes are simply ignored
Reserved
This 1-octet field is reserved. MUST be set to zero by
sender, and MUST be ignored by the receiver
Types 0-3 are collectively called "CLAIMs". The message format
describes the encoding of a CLAIM, PREFIX_MANAGED and WITHDRAW
Radoslavov, et al. Experimental [Page 18]
RFC 2909 The MASC Protocol September 2000
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 |D| AddrFam |Rol| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Claim Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Domain Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Node Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved1:
This 1-octet field is reserved. MUST be set to zero by
sender, and MUST be ignored by the receiver
D-bit
DEPRECATED_PREFIX bit. If set, indicates that the
address prefix is Deprecated, otherwise the prefix is Active (
Section 4.3).
AddrFam
This 5-bit field is the IANA-assigned address family number of
encoded prefix [IANA].
Rol
This 2-bit field indicates the relationship/role of the Origin
the message to the node sending that message
00 = INTERNAL (originated by the sender's domain
01 = CHILD (originated by a child of the sender's domain
10 = SIBLING (originated by a sibling of the sender's domain
11 = PARENT (originated by a parent of the sender's domain
Reserved2:
This 2-octet field is reserved. MUST be set to zero by
sender, and MUST be ignored by the receiver
Radoslavov, et al. Experimental [Page 19]
RFC 2909 The MASC Protocol September 2000
Claim Timestamp
The timestamp of the claim when it was originated. The
is expressed in number of seconds since midnight (0 hour),
1, 1970, Greenwich
Claim Lifetime
The time in seconds between the Claim Timestamp, and the time
which the prefix will become free
Claim Holdtime
The time in seconds between the Claim Timestamp, and the time
which the claim should be deleted from the local cache.
PREFIX_IN_USE and PREFIX_MANAGED claims it should be equal
Claim Lifetime; for CLAIM_TO_EXPAND, NEW_CLAIM, and CLAIM_
it should be equal to [WAITING_PERIOD].
Origin Domain Identifier
The domain identifier of the claim originator. Its length
format definition are same as the Sender Domain Identifier (
Section 7.2).
Origin Node Identifier
The MASC Node ID of the claim originator. Its length and
definition are same as the Sender MASC Node Identifier (
Section 7.2).
Address
The address associated with the given prefix to be encoded.
length is determined based on the Address Family (e.g. 4
for IPv4, 16 for IPv6)
Mask
The mask associated with the given prefix. The length is the
as the Address field and is determined based on the
Family. The field contains the full bitmask
Optional Parameters
This field may contain a list of optional parameters, where
parameter is encoded using same format as the optional
of an OPEN message (see Section 7.2). Unrecognized
parameters MUST be silently ignored. This document does
define any optional parameters
Radoslavov, et al. Experimental [Page 20]
RFC 2909 The MASC Protocol September 2000
7.4. KEEPALIVE Message
MASC does not use any transport protocol-based keep-alive
to determine if peers are reachable. Instead, KEEPALIVE messages
exchanged between peers often enough as not to cause the Hold
to expire. A reasonable maximum time between the last KEEPALIVE
UPDATE message sent, and the time at which a KEEPALIVE message
sent, would be one third of the Hold Time interval.
messages MUST NOT be sent more frequently than one per second.
implementation MAY adjust the rate at which it sends
messages as a function of the Hold Time interval
If the negotiated Hold Time interval is zero, then periodic
messages MUST NOT be sent
A KEEPALIVE message consists of only a message header, and has
length of 4 octets
7.5. NOTIFICATION Message
A NOTIFICATION message is sent when an error condition is detected
Depending on the error condition, the MASC connection might or
be closed immediately after sending the message. If the sender
the NOTIFICATION decides that the connection is to be closed, it
indicate this by zeroing the O-bit in the NOTIFICATION message (
below).
In addition to the fixed-size MASC header, the NOTIFICATION
contains the following fields
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O-bit
Open-bit. If zero, it indicates that the sender will close
connection. If '1', it indicates that the sender has chosen
keep the connection open
Error Code
This 7-bit unsigned integer indicates the type of NOTIFICATION
The following Error Codes have been defined
Radoslavov, et al. Experimental [Page 21]
RFC 2909 The MASC Protocol September 2000
Error Code Symbolic Name
1 Message Header Error Section 8.1
2 OPEN Message Error Section 8.2
3 UPDATE Message Error Section 8.3
4 Hold Timer Expired Section 8.4
5 Finite State Machine Error Section 8.5
6 NOTIFICATION Message Error Section 8.6
7 Cease Section 8.7
Error subcode
This 1-octet unsigned integer provides more specific
about the nature of the reported error. Each Error Code may
one or more Error Subcodes associated with it. If no
Error Subcode is defined, then a zero (Unspecific) value is
for the Error Subcode field, and the O-bit must be zero (i.e.
connection will be closed). The notation used in the
description below is: MC = Must Close connection = O-bit is zero
CC = Can Close connection = O-bit might be zero
Message Header Error subcodes
0 - Unspecific (MC
1 - Bad Message Length (MC
2 - Bad Message Type (CC
OPEN Message Error subcodes
0 - Unspecific (MC
1 - Unsupported Version Number (MC
2 - Bad Peer Domain ID (MC
3 - Bad Peer MASC Node ID (MC
6 - Unacceptable Hold Time (MC
7 - Invalid Parent Configuration (MC
8 - Inconsistent Role (MC
9 - Bad Parent Domain ID (MC
10 - No Common Parent (MC
13 - Unrecognized Address Family (MC
Radoslavov, et al. Experimental [Page 22]
RFC 2909 The MASC Protocol September 2000
UPDATE Message Error subcodes
0 - Unspecific (MC
1 - Malformed Attribute List (MC
2 - Unrecognized Required Attribute (CC
5 - Attribute Length Error (MC
10 - Invalid Address field (CC
11 - Invalid Mask field (CC
12 - Non-Contiguous Mask (CC
13 - Unrecognized Address Family (MC
14 - Claim Type Error (CC
15 - Origin Domain ID Error (CC
16 - Origin Node ID Error (CC
17 - Claim Lifetime Too Short (CC
18 - Claim Lifetime Too Long (CC
19 - Claim Timestamp Too Old (CC
20 - Claim Timestamp Too New (CC
21 - Claim Prefix Size Too Small (CC
22 - Claim Prefix Size Too Large (CC
23 - Illegal Origin Role Error (CC
24 - No Appropriate Parent Prefix (CC
25 - No Appropriate Child Prefix (CC
26 - No Appropriate Internal Prefix (CC
27 - No Appropriate Sibling Prefix (CC
28 - Claim Holdtime Too Short (CC
29 - Claim Holdtime Too Long (CC
Hold Timer Expired subcodes (the O-bit is always zero):
0 - Unspecific (MC
Finite State Machine Error subcodes
0 - Unspecific (MC
1 - Open/Close MASC Connection FSM Error (MC
2 - Unexpected Message Type FSM Error (MC
Cease subcodes (the O-bit is always zero):
0 - Unspecific (MC
NOTIFICATION subcodes (the O-bit is always zero):
0 - Unspecific (MC
Data
This variable-length field is used to diagnose the reason for
NOTIFICATION. The contents of the Data field depend upon
Error Code and Error Subcode. See Section 8 for more details
Radoslavov, et al. Experimental [Page 23]
RFC 2909 The MASC Protocol September 2000
Note that the length of the Data field can be determined from
message Length field by the formula
Message Length = 6 + Data
The minimum length of the NOTIFICATION message is 6
(including message header).
8. MASC Error
This section describes actions to be taken when errors are
while processing MASC messages. MASC Error Handling is similar
that of BGP [BGP].
When any of the conditions described here are detected,
NOTIFICATION message with the indicated Error Code, Error Subcode
and Data fields is sent. In addition, the MASC connection might
closed. If no Error Subcode is specified, then a zero (Unspecific
must be used
The phrase "the MASC connection is closed" means that the
protocol connection has been closed and that all resources for
MASC connection have been deallocated
Unless specified explicitly, the Data field of the
message is empty
8.1. Message Header Error
All errors detected while processing the Message Header are
by sending the NOTIFICATION message with Error Code Message
Error. The Error Subcode elaborates on the specific nature of
error. The Data field contains the erroneous Message (including
message header).
If the Length field of the message header is less than 4 or
than 4096, or if the length of an OPEN message is less than
minimum length of the OPEN message, or if the length of an
message is less than the minimum length of the UPDATE message, or
the length of a KEEPALIVE message is not equal to 4, then the
Subcode is set to Bad Message Length
If the Type field of the message header is not recognized, then
Error Subcode is set to Bad Message Type
Radoslavov, et al. Experimental [Page 24]
RFC 2909 The MASC Protocol September 2000
8.2. OPEN Message Error
All errors detected while processing the OPEN message are
by sending the NOTIFICATION message with Error Code OPEN
Error. The Error Subcode elaborates on the specific nature of
error. The Data field contains the erroneous OPEN Message (
the Message Header), unless stated otherwise
If the version number contained in the Version field of the
OPEN message is not supported, then the Error Subcode is set
Unsupported Version Number. The Data field is a 1-octet
integer, which indicates the largest locally supported version
less than the version the remote MASC node bid (as indicated in
received OPEN message).
If the Sender Domain Identifier field of the OPEN message
unacceptable, then the Error Subcode is set to Bad Peer Domain ID
The determination of acceptable Domain IDs is outside the scope
this protocol
If the Sender MASC Node Identifier field of the OPEN message
unacceptable, then the Error Subcode is set to Bad Peer MASC Node ID
The determination of acceptable Node IDs is outside the scope of
protocol
If the Hold Time field of the OPEN message is unacceptable, then
Error Subcode MUST be set to Unacceptable Hold Time.
implementation MUST reject Hold Time values of one or two seconds
An implementation MAY reject any proposed Hold Time.
implementation which accepts a Hold Time MUST use the
value for the Hold Time
If the remote system's proposed Role is INTERNAL_PEER, and
(but not both) the local system or the remote system's Parent
ID is [TLD_ID], then the Error Subcode is set to Invalid
Configuration. The Data field must be filled with all the
system's Parent Domain IDs
If the remote system's proposed Role conflicts with its expected
(based on the local system's configured Role), then the Error
is set to Inconsistent Role. The Data field is 1-octet long,
contains the local system's configured Role
If the remote system's Parent Domain ID is unacceptable, then
Error Subcode is set to Bad Parent Domain ID, and the Data field
filled with the erroneous Parent Domain ID. The determination
acceptable Parent Domain ID is outside the scope of this protocol
Radoslavov, et al. Experimental [Page 25]
RFC 2909 The MASC Protocol September 2000
If the remote system is supposed to be a sibling, but it does
have a common parent with the local system (based on the
Domain ID information in the OPEN message), the Error Subcode is
to No Common Parent, and the Data field is filled with all
Domain IDs of the local MASC domain
If the Address Family is unrecognized, then the Error Subcode is
to Unrecognized Address Family
8.3. UPDATE Message Error
All errors detected while processing the UPDATE message are
by sending the NOTIFICATION message with Error Code UPDATE
Error. The error subcode elaborates on the specific nature of
error. The Data field contains the erroneous UPDATE
(including the attribute header, but excluding the Message Header),
unless stated otherwise
If any recognized attribute has an Attribute Length that
with the expected length (based on the attribute type code), then
Error Subcode is set to Attribute Length Error
If any of the mandatory well-known attributes are not recognized
then the Error Subcode is set to Unrecognized Required Attribute
If the Address field includes an invalid address (except 0), then
Error Subcode is set to Invalid Address
If the Mask field includes an invalid mask (for example,
with 0), then the Error Subcode is set to Invalid Mask
If the Mask field includes a non-contiguous bitmask, and that
server does not support, or is not configured to use non-
masks, then the Error Subcode is set to Non-Contiguous Mask
If the Address Family is unrecognized, then the Error Subcode is
to Unrecognized Address Family
If the Origin Role/Claim Type combination is not one of
following, then the Error Subcode is set to Claim Type Error
Radoslavov, et al. Experimental [Page 26]
RFC 2909 The MASC Protocol September 2000
Origin
Role
ICS PREFIX_IN_USE (0)
I P CLAIM_DENIED (1)
ICS CLAIM_TO_EXPAND (2)
ICS NEW_CLAIM (3)
I P PREFIX_MANAGED (4)
ICSP WITHDRAW (5)
If there is a reason to believe that the Origin Domain ID is invalid
then the Error Subcode is set to Origin Domain ID Error. The
applies for Origin Node ID (the corresponding error is Origin Node
Error).
If a node (usually a parent receiving a claim from a child)
that the Claim Lifetime is too short (for example, less than 172800,
i.e. 48 hours), it MAY send an UPDATE Message Error with
Claim Lifetime Too Short
If a node (usually a parent receiving a claim from a child)
that the Claim Lifetime is too long (for example, more
15,768,000, i.e. half year), then it MAY send an UPDATE Message
with subcode Claim Lifetime Too Long. Note that usually a
MASC node should send first CLAIM_DENIED collision messages
Claim Lifetime field filled with the longest acceptable lifetime.
the child refuses to claim with shorter lifetime, then Claim
Too Long should be sent
If a node (usually a parent receiving a claim from a child)
that the Claim Timestamp is too small, i.e. too old (for example,
a node is self-confident that its clock is quite accurate), then
MUST send an UPDATE Message Error with subcode Claim Timestamp
Old. Claim Timestamp Too New is defined similarly
If a node (usually a parent receiving a claim from a child)
that the prefix size implied by the Mask field is too small (
example, smaller than 16 addresses), then it MAY send an
Message Error with subcode Claim Prefix Size Too Small
If a node (usually a parent receiving a claim from a child)
that the prefix size implied by the Mask field is too large, then
MAY send an UPDATE Message Error with subcode Claim Prefix Size
Large. Note that usually a parent MASC node should send
CLAIM_DENIED collision messages for some subrange of the child'
large claimed address range. If the child refuses to shrink
claim size, then Claim Prefix Size Too Large should be sent
Radoslavov, et al. Experimental [Page 27]
RFC 2909 The MASC Protocol September 2000
If the received UPDATE message's computed Updated Origin Role
illegal (see Table 1 in Section 11.1), then the Error Subcode is
to Illegal Origin Role Error
If the received UPDATE message needs to be associated with a parent'
prefix, but the association is not successful, then the Error
is set to No Appropriate Parent Prefix. The No Appropriate
Prefix, No Appropriate Internal Prefix, and No Appropriate
Prefix Error Subcodes are defined similarly
If a node decides that the Claim Holdtime is too short (for example
just few seconds), it MAY send an UPDATE Message Error with
Claim Holdtime Too Short
If a node decides that the Claim Holdtime is too long (for example
more than 15,768,000, i.e. half year), then it SHOULD send an
Message Error with subcode Claim Holdtime Too Long
If any other error is encountered when processing attributes,
the Error Subcode is set to Malformed Attribute List, and the
attribute is included in the data field
8.4. Hold Timer Expired Error
If a system does not receive successive KEEPALIVE and/or
and/or NOTIFICATION messages within the period specified in the
Time field of the OPEN message, then the NOTIFICATION message
Hold Timer Expired Error Code must be sent and the MASC
closed
8.5. Finite State Machine Error
Any error detected by the MASC Finite State Machine (e.g., receipt
an unexpected event) is indicated by sending the NOTIFICATION
with Error Code Finite State Machine Error. The Error
elaborates on the specific nature of the error
8.6. NOTIFICATION Message Error
If a node sends a NOTIFICATION message, and there is an error in
message, and the O-bit of that message is not zero, a
with O-bit zeroed, Error Code of NOTIFICATION Error, and
Unspecific must be sent. In addition, the Data field must
the erratic NOTIFICATION message. However, if the
NOTIFICATION message had the O-bit zeroed, then any error, such as
unrecognized Error Code or Error Subcode, should be noticed,
Radoslavov, et al. Experimental [Page 28]
RFC 2909 The MASC Protocol September 2000
locally, and brought to the attention of the administrator of
remote node. The means to do this, however, lies outside the
of this document
8.7.
In absence of any fatal errors (that are indicated in this section),
a MASC node may choose at any given time to close its MASC
by sending the NOTIFICATION message with Error Code Cease. However
the Cease NOTIFICATION message must not be used when a fatal
indicated by this section does exist
8.8. Connection Collision
If a pair of MASC speakers try simultaneously to establish a
connection to each other, then two parallel connections between
pair of speakers might well be formed. We refer to this situation
connection collision. Clearly, one of these connections must
closed. Note that if the nodes were siblings, and each of
connections was associated with a different parent, then we do
consider this situation as collision (see Section 4.4).
Based on the value of the MASC Node Identifier a convention
established for detecting which MASC connection is to be
when a connection collision does occur. The convention is to
the MASC Node Identifiers of the remote nodes involved in
collision and to retain only the connection initiated by the
speaker with the higher-valued MASC Node Identifier
Upon receipt of an OPEN message, the local system must examine all
its connections that are in the OpenConfirm state. A MASC
may also examine connections in an OpenSent state if it knows
MASC Node Identifier of the remote node by means outside of
protocol. If among these connections there is a connection to
remote MASC speaker whose MASC Node Identifier equals the one in
OPEN message, and, in case of a sibling-to-sibling connection,
Parent Domain ID of that connection equals the one in the
message, then the local system performs the following
collision resolution procedure
1. The MASC Node Identifier of the local system is compared to
MASC Node Identifier of the remote system (as specified in
OPEN message). Comparing MASC Node Identifiers is done
treating them as unsigned integers (e.g. 4-octets long for IPv
and 16-octets long for IPv6).
Radoslavov, et al. Experimental [Page 29]
RFC 2909 The MASC Protocol September 2000
2. If the value of the local MASC Node Identifier is less than
remote one, the local system closes MASC connection that
exists (the one that is already in the OpenConfirm state),
accepts the MASC connection initiated by the remote system
3. Otherwise, the local system closes the newly created
connection (the one associated with the newly received
message), and continues to use the existing one (the one that
already in the OpenConfirm state).
A connection collision with an existing MASC connection that is
the Established state causes unconditional closing of the
created connection. Note that a connection collision cannot
detected with connections that are in Idle, or Connect, or
states (see Section 10).
Closing the MASC connection (that results from the
resolution procedure) is accomplished by sending the
message with the Error Code Cease
9. MASC Version
MASC speakers may negotiate the version of the protocol by
multiple attempts to open a MASC connection, starting with
highest version number each supports. If an open attempt fails
an Error Code OPEN Message Error, and an Error Subcode
Version Number, then the MASC speaker has available the
number it tried, the version number the remote node tried,
version number passed by the remote node in the NOTIFICATION message
and the version numbers that it supports. If the two MASC
do support one or more common versions, then this will allow them
rapidly determine the highest common version. In order to
MASC version negotiation, future versions of MASC must retain
format of the OPEN and NOTIFICATION messages
10. MASC Finite State
This section specifies MASC operation in terms of a Finite
Machine (FSM). The FSM and the operations are peer peering session
Following is a brief summary and overview of MASC operations by
as determined by this FSM
Initially the peering session is in the Idle state
Radoslavov, et al. Experimental [Page 30]
RFC 2909 The MASC Protocol September 2000
10.1. Open/Close MASC Connection
Idle state
In this state MASC refuses all incoming MASC connections from
peer. No resources are allocated to the remote node. In
to the Start event (initiated by either system or operator)
local system initializes all MASC resources, starts
ConnectRetry timer, initiates a transport connection to the
node, while listening for a connection that may be initiated
the remote MASC node, and changes its state to Connect. The
value of the ConnectRetry timer is a local matter, but should
sufficiently large to allow TCP initialization
If a MASC speaker detects an error, it shuts down the
and changes its state to Idle. Getting out of the Idle
requires generation of the Start event. If such an event
generated automatically, then persistent MASC errors may result
persistent flapping of the speaker. To avoid such a condition
is recommended that Start events should not be
immediately for a node that was previously transitioned to
due to an error. For a node that was previously transitioned
Idle due to an error, the time between consecutive generation
Start events, if such events are generated automatically,
exponentially increase. The value of the initial timer shall be 60
seconds. The time shall be doubled for each consecutive retry,
shall not be longer than 24 hours
Any other event received in the Idle state is ignored
Connect state
In this state MASC is waiting for the transport
connection to be completed
If the transport protocol connection succeeds, the local
clears the ConnectRetry timer, completes initialization, sends
OPEN message to the remote node, and changes its state
OpenSent. If the transport protocol connect fails (e.g.,
retransmission timeout), the local system restarts
ConnectRetry timer, continues to listen for a connection that
be initiated by the remote MASC node, and changes its state
Active state
Radoslavov, et al. Experimental [Page 31]
RFC 2909 The MASC Protocol September 2000
In response to the ConnectRetry timer expired event, the
system restarts the ConnectRetry timer, initiates a
connection to the other MASC node, continues to listen for
connection that may be initiated by the remote MASC node,
stays in the Connect state
The Start event is ignored in the Connect state
In response to any other event (initiated by either system
operator), the local system releases all MASC resources
with this connection and changes its state to Idle
Active state
In this state MASC is trying to acquire a remote node by
for a transport protocol connection initiated by the remote node
If the transport protocol 