Error Subcode is set to Bad Parent Domain ID, and the Data field is
filled with the erroneous Parent Domain ID. The determination of
acceptable Parent Domain ID is outside the scope of this protocol.
If the remote system is supposed to be a sibling, but it does not
have a common parent with the local system (based on the Parent
Domain ID information in the OPEN message), the Error Subcode is set
to No Common Parent, and the Data field is filled with all Parent
Domain IDs of the local MASC domain.
If the Address Family is unrecognized, then the Error Subcode is set
to Unrecognized Address Family.
8.3. UPDATE Message Error Handling
All errors detected while processing the UPDATE message are indicated
by sending the NOTIFICATION message with Error Code UPDATE Message
Error. The error subcode elaborates on the specific nature of the
error. The Data field contains the erroneous UPDATE Message
(including the attribute header, but excluding the Message Header),
unless stated otherwise.
If any recognized attribute has an Attribute Length that conflicts
with the expected length (based on the attribute type code), then the
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 the
Error Subcode is set to Invalid Address.
If the Mask field includes an invalid mask (for example, starting
with 0), then the Error Subcode is set to Invalid Mask.
If the Mask field includes a non-contiguous bitmask, and that MASC
server does not support, or is not configured to use non-contiguous
masks, then the Error Subcode is set to Non-Contiguous Mask.
If the Address Family is unrecognized, then the Error Subcode is set
to Unrecognized Address Family.
If the Origin Role/Claim Type combination is not one of the
following, then the Error Subcode is set to Claim Type Error.
Origin Claim
Role Type
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 same
applies for Origin Node ID (the corresponding error is Origin Node ID
Error).
If a node (usually a parent receiving a claim from a child) decides
that the Claim Lifetime is too short (for example, less than 172800,
i.e. 48 hours), it MAY send an UPDATE Message Error with subcode
Claim Lifetime Too Short.
If a node (usually a parent receiving a claim from a child) decides
that the Claim Lifetime is too long (for example, more than
15,768,000, i.e. half year), then it MAY send an UPDATE Message Error
with subcode Claim Lifetime Too Long. Note that usually a parent
MASC node should send first CLAIM_DENIED collision messages with
Claim Lifetime field filled with the longest acceptable lifetime. If
the child refuses to claim with shorter lifetime, then Claim Lifetime
Too Long should be sent.
If a node (usually a parent receiving a claim from a child) decides
that the Claim Timestamp is too small, i.e. too old (for example, if
a node is self-confident that its clock is quite accurate), then it
MUST send an UPDATE Message Error with subcode Claim Timestamp Too
Old. Claim Timestamp Too New is defined similarly.
If a node (usually a parent receiving a claim from a child) decides
that the prefix size implied by the Mask field is too small (for
example, smaller than 16 addresses), then it MAY send an UPDATE
Message Error with subcode Claim Prefix Size Too Small.
If a node (usually a parent receiving a claim from a child) decides
that the prefix size implied by the Mask field is too large, then it
MAY send an UPDATE Message Error with subcode Claim Prefix Size Too
Large. Note that usually a parent MASC node should send first
CLAIM_DENIED collision messages for some subrange of the child's
large claimed address range. If the child refuses to shrink the
claim size, then Claim Prefix Size Too Large should be sent.
If the received UPDATE message's computed Updated Origin Role is
illegal (see Table 1 in Section 11.1), then the Error Subcode is set
to Illegal Origin Role Error.
If the received UPDATE message needs to be associated with a parent's
prefix, but the association is not successful, then the Error Subcode
is set to No Appropriate Parent Prefix. The No Appropriate Child
Prefix, No Appropriate Internal Prefix, and No Appropriate Sibling
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 subcode
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 UPDATE
Message Error with subcode Claim Holdtime Too Long.
If any other error is encountered when processing attributes, then
the Error Subcode is set to Malformed Attribute List, and the erratic
attribute is included in the data field.
8.4. Hold Timer Expired Error Handling
If a system does not receive successive KEEPALIVE and/or UPDATE
and/or NOTIFICATION messages within the period specified in the Hold
Time field of the OPEN message, then the NOTIFICATION message with
Hold Timer Expired Error Code must be sent and the MASC connection
closed.
8.5. Finite State Machine Error Handling
Any error detected by the MASC Finite State Machine (e.g., receipt of
an unexpected event) is indicated by sending the NOTIFICATION message
with Error Code Finite State Machine Error. The Error Subcode
elaborates on the specific nature of the error.
8.6. NOTIFICATION Message Error Handling
If a node sends a NOTIFICATION message, and there is an error in that
message, and the O-bit of that message is not zero, a NOTIFICATION
with O-bit zeroed, Error Code of NOTIFICATION Error, and subcode
Unspecific must be sent. In addition, the Data field must include
the erratic NOTIFICATION message. However, if the erratic
NOTIFICATION message had the O-bit zeroed, then any error, such as an
unrecognized Error Code or Error Subcode, should be noticed, logged
locally, and brought to the attention of the administrator of the
remote node. The means to do this, however, lies outside the scope
of this document.
8.7. Cease
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 connection
by sending the NOTIFICATION message with Error Code Cease. However,
the Cease NOTIFICATION message must not be used when a fatal error
indicated by this section does exist.
8.8. Connection Collision Detection
If a pair of MASC speakers try simultaneously to establish a TCP
connection to each other, then two parallel connections between this
pair of speakers might well be formed. We refer to this situation as
connection collision. Clearly, one of these connections must be
closed. Note that if the nodes were siblings, and each of those
connections was associated with a different parent, then we do not
consider this situation as collision (see Section 4.4).
Based on the value of the MASC Node Identifier a convention is
established for detecting which MASC connection is to be preserved
when a connection collision does occur. The convention is to compare
the MASC Node Identifiers of the remote nodes involved in the
collision and to retain only the connection initiated by the MASC
speaker with the higher-valued MASC Node Identifier.
Upon receipt of an OPEN message, the local system must examine all of
its connections that are in the OpenConfirm state. A MASC speaker
may also examine connections in an OpenSent state if it knows the
MASC Node Identifier of the remote node by means outside of the
protocol. If among these connections there is a connection to a
remote MASC speaker whose MASC Node Identifier equals the one in the
OPEN message, and, in case of a sibling-to-sibling connection, the
Parent Domain ID of that connection equals the one in the OPEN
message, then the local system performs the following connection
collision resolution procedure:
1. The MASC Node Identifier of the local system is compared to the
MASC Node Identifier of the remote system (as specified in the
OPEN message). Comparing MASC Node Identifiers is done by
treating them as unsigned integers (e.g. 4-octets long for IPv4
and 16-octets long for IPv6).
2. If the value of the local MASC Node Identifier is less than the
remote one, the local system closes MASC connection that already
exists (the one that is already in the OpenConfirm state), and
accepts the MASC connection initiated by the remote system.
3. Otherwise, the local system closes the newly created MASC
connection (the one associated with the newly received OPEN
message), and continues to use the existing one (the one that is
already in the OpenConfirm state).
A connection collision with an existing MASC connection that is in
the Established state causes unconditional closing of the newly
created connection. Note that a connection collision cannot be
detected with connections that are in Idle, or Connect, or Active
states (see Section 10).
Closing the MASC connection (that results from the collision
resolution procedure) is accomplished by sending the NOTIFICATION
message with the Error Code Cease.
9. MASC Version Negotiation
MASC speakers may negotiate the version of the protocol by making
multiple attempts to open a MASC connection, starting with the
highest version number each supports. If an open attempt fails with
an Error Code OPEN Message Error, and an Error Subcode Unsupported
Version Number, then the MASC speaker has available the version
number it tried, the version number the remote node tried, the
version number passed by the remote node in the NOTIFICATION message,
and the version numbers that it supports. If the two MASC speakers
do support one or more common versions, then this will allow them to
rapidly determine the highest common version. In order to support
MASC version negotiation, future versions of MASC must retain the
format of the OPEN and NOTIFICATION messages.
10. MASC Finite State Machine
This section specifies MASC operation in terms of a Finite State
Machine (FSM). The FSM and the operations are peer peering session.
Following is a brief summary and overview of MASC operations by state
as determined by this FSM.
Initially the peering session is in the Idle state.
10.1. Open/Close MASC Connection FSM
Idle state:
In this state MASC refuses all incoming MASC connections from the
peer. No resources are allocated to the remote node. In response
to the Start event (initiated by either system or operator) the
local system initializes all MASC resources, starts the
ConnectRetry timer, initiates a transport connection to the remote
node, while listening for a connection that may be initiated by
the remote MASC node, and changes its state to Connect. The exact
value of the ConnectRetry timer is a local matter, but should be
sufficiently large to allow TCP initialization.
If a MASC speaker detects an error, it shuts down the connection
and changes its state to Idle. Getting out of the Idle state
requires generation of the Start event. If such an event is
generated automatically, then persistent MASC errors may result in
persistent flapping of the speaker. To avoid such a condition it
is recommended that Start events should not be generated
immediately for a node that was previously transitioned to Idle
due to an error. For a node that was previously transitioned to
Idle due to an error, the time between consecutive generation of
Start events, if such events are generated automatically, shall
exponentially increase. The value of the initial timer shall be 60
seconds. The time shall be doubled for each consecutive retry, but
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 protocol
connection to be completed.
If the transport protocol connection succeeds, the local system
clears the ConnectRetry timer, completes initialization, sends an
OPEN message to the remote node, and changes its state to
OpenSent. If the transport protocol connect fails (e.g.,
retransmission timeout), the local system restarts the
ConnectRetry timer, continues to listen for a connection that may
be initiated by the remote MASC node, and changes its state to
Active state.
In response to the ConnectRetry timer expired event, the local
system restarts the ConnectRetry timer, initiates a transport
connection to the other MASC node, continues to listen for a
connection that may be initiated by the remote MASC node, and
stays in the Connect state.
The Start event is ignored in the Connect state.
In response to any other event (initiated by either system or
operator), the local system releases all MASC resources associated
with this connection and changes its state to Idle.
Active state:
In this state MASC is trying to acquire a remote node by listening
for a transport protocol connection initiated by the remote node.
If the transport protocol connection succeeds, the local system
clears the ConnectRetry timer, completes initialization, sends an
OPEN message to the remote node, sets its Hold Timer to a large
value, and changes its state to OpenSent. A Hold Timer value of
[HOLDTIME] seconds is suggested.
In response to the ConnectRetry timer expired event, the local
system restarts the ConnectRetry timer, initiates a transport
connection to other MASC node, continues to listen for a
connection that may be initiated by the remote MASC node, and
changes its state to Connect.
If the local system detects that a remote node is trying to
establish a MASC connection to it, and the IP address of the
remote node is not an expected one, the local system restarts the
ConnectRetry timer, rejects the attempted connection, continues to
listen for a connection that may be initiated by the remote MASC
node, and stays in the Active state.
The Start event is ignored in the Active state.
In response to any other event (initiated by either system or
operator), the local system releases all MASC resources associated
with this connection and changes its state to Idle.
OpenSent state:
In this state MASC waits for an OPEN message from the remote node.
When an OPEN message is received, all fields are checked for
correctness. If the MASC message header checking or OPEN message
checking detects an error (see Section 8.2), or a connection
collision (see Section 8.8) the local system sends a NOTIFICATION
message and, if the connection is to be closed, it changes its
state to Idle.
If the locally configured role is SIBLING and there is no parent
domain with Domain ID equal to the Parent Domain ID in the OPEN
message, the local system sends a NOTIFICATION Open Message Error
with Error Subcode set to No Common Parent, the connection must be
closed, and the state of the local system must be changed to Idle.
If there are no errors in the OPEN message, MASC sends a KEEPALIVE
message and sets a KeepAlive timer. The Hold Timer, which was
originally set to a large value (see above), is replaced with the
negotiated Hold Time value (see Section 7.2). If the negotiated
Hold Time value is zero, then the Hold Time timer and KeepAlive
timers are not started. If the value of the MASC Domain ID field
is the same as the local MASC Domain ID, and if the Role field of
the OPEN message is set to INTERNAL_PEER, then the connection is
an "internal" connection; otherwise, it is "external". Finally,
the state is changed to OpenConfirm.
If a disconnect notification is received from the underlying
transport protocol, the local system closes the MASC connection,
restarts the ConnectRetry timer, while continue listening for
connection that may be initiated by the remote MASC node, and goes
into the Active state.
If the Hold Timer expires, the local system sends a NOTIFICATION
message with error code Hold Timer Expired and changes its state
to Idle.
In response to the Stop event (initiated by either system or
operator) the local system sends a NOTIFICATION message with Error
Code Cease and changes its state to Idle.
The Start event is ignored in the OpenSent state.
In response to any other event the local system sends a
NOTIFICATION message with Error Code Finite State Machine Error
and Error Subcode Open/Close MASC Connection FSM Error, and
changes its state to Idle.
Whenever MASC changes its state from OpenSent to Idle, it closes
the MASC (and transport-level) connection and releases all
resources associated with that connection.
OpenConfirm state:
In this state MASC waits for a KEEPALIVE or NOTIFICATION message.
If the local system receives a KEEPALIVE message, it changes its
state to Established.
If the Hold Timer expires before a KEEPALIVE message is received,
the local system sends a NOTIFICATION message with error code Hold
Timer Expired and changes its state to Idle.
If the local system receives a NOTIFICATION message with the O-bit
zeroed, it changes its state to Idle.
If the KeepAlive timer expires, the local system sends a KEEPALIVE
message and restarts its KeepAlive timer.
If a disconnect notification is received from the underlying
transport protocol, the local system changes its state to Idle.
In response to the Stop event (initiated by either system or
operator) the local system sends a NOTIFICATION message with Error
Code Cease and changes its state to Idle.
The Start event is ignored in the OpenConfirm state.
In response to any other event the local system sends a
NOTIFICATION message with Error Code Finite State Machine Error
and Error Subcode Unspecific, and changes its state to Idle.
Whenever MASC changes its state from OpenConfirm to Idle, it
closes the MASC (and transport-level) connection and releases all
resources associated with that connection.
Established state:
In the Established state MASC can exchange UPDATE, NOTIFICATION,
and KEEPALIVE messages with the remote node.
If the local system receives an UPDATE, or KEEPALIVE message, or
NOTIFICATION message with O-bit set, it restarts its Hold Timer,
if the negotiated Hold Time value is non-zero.
If the local system receives a NOTIFICATION message, with the O-
bit zeroed, it changes its state to Idle.
If the local system receives an UPDATE message and the UPDATE
message error handling procedure (see Section 8.3) detects an
error, the local system sends a NOTIFICATION message and, if the
O-bit was zeroed, changes its state to Idle.
If a disconnect notification is received from the underlying
transport protocol, the local system changes its state to Idle.
If the Hold Timer expires, the local system sends a NOTIFICATION
message with Error Code Hold Timer Expired and changes its state
to Idle.
If the KeepAlive timer expires, the local system sends a KEEPALIVE
message and restarts its KeepAlive timer.
Each time the local system sends a KEEPALIVE or UPDATE message, it
restarts its KeepAlive timer, unless the negotiated Hold Time
value is zero.
In response to the Stop event (initiated by either system or
operator), the local system sends a NOTIFICATION message with
Error Code Cease and changes its state to Idle.
The Start event is ignored in the Established state.
After entering the Established state, if the local system has
UPDATE messages that are to be sent to the remote node, they must
be sent immediately (see Section 11.8).
In response to any other event, the local system sends a
NOTIFICATION message with Error Code Finite State Machine Error
with the O-bit zeroed and Error Subcode Unspecific, and changes
its state to Idle.
Whenever MASC changes its state from Established to Idle, it
closes the MASC (and transport-level) connection, releases all
resources associated with that connection, and deletes all state
derived from that connection.
11. UPDATE Message Processing
The UPDATE message are accepted only when the system is in the
Established state.
In the text below, a MASC domain is considered a child of itself with
regard to the claims that are related to the address space with local
usage purpose (i.e. to be used by the MAASs within that domain). For
example, a NEW_CLAIM initiated by a MASC node to obtain more space
for local usage from a prefix managed by that domain will have field
Role = CHILD.
If an UPDATE is to be propagated further, it should not be sent back
to the node that UPDATE was received from, unless there is an
indication that the connection to that node was down and then
restored.
If the local system receives an UPDATE message, and there is no
indication for error, it checks whether to accept or reject the
message, and if it is not rejected, the UPDATE is processed based on
its type.
If an UPDATE message must be associated with a parent domain, then
there must be a PREFIX_MANAGED by some parent domain for a prefix
that covers the prefix of the particular UPDATE.
11.1. Accept/Reject an UPDATE
The Origin Role field is first compared against the local system's
configured Role, according to Table 1, to determine the relationship
of the origin to the local system, where Locally-Configured Role is
the local configuration with regard to the peer-forwarder of the
message. A result of "---" means that receiving such an UPDATE is
illegal and should generate a NOTIFICATION. Any other result is the
value to use as the "Updated" Origin Role when propagating the UPDATE
to others. This is analogous to updating a metric upon receiving a
route, based on the metric of the link.
Locally-Configured Role
Origin
Role || INTERNAL_PEER | CHILD | SIBLING | PARENT
=========++===============+=========+=========+=========
INTERNAL || INTERNAL_PEER | PARENT | SIBLING | CHILD
CHILD || CHILD | SIBLING | --- | ---
SIBLING || SIBLING | --- | SIBLING | CHILD
PARENT || PARENT | --- | PARENT | ---
Table 1: Updated Origin Role Computation
After the Origin Role is updated, the following additional processing
needs to be applied:
o If the output from the Updated Origin Role Computation is SIBLING,
but the Origin Domain ID is the same as the local MASC domain, the
Updated Origin Role is changed to INTERNAL. This is necessary in
case a MASC node receives from a parent or sibling its own UPDATEs
after reboot, or if because of internal partitioning, the
INTERNAL_PEERs are exchanging UPDATEs via other MASC domains
(either parent or sibling(s)).
o If both Locally-Configured Role, and Origin Role are equal to
PARENT, and the Origin Domain ID is the same as the local MASC
domain, the Updated Origin Role is changed to INTERNAL. This is
necessary to allow a parent to receive its own UPDATEs through its
own children, although the parent might drop those UPDATEs if it
has a reason not to believe its children.
o If both Locally-Configured Role, and Origin Role are equal to
PARENT, and the Origin Domain ID is the same as the remote MASC
domain, and the UPDATE type is CLAIM_DENIED, the Updated Origin
Role is changed to INTERNAL. This is necessary to allow a parent
to receive the CLAIM_DENIED it has originated through the child
whose claim was denied. If the Origin Domain ID is not same as
the remote MASC domain, but is same as some of the other MASC
children domains, the Updated Origin Role still should be changed
to INTERNAL, although the parent might drop this UPDATE if it has
a reason not to believe a third party child.
If the Updated Origin Role is INTERNAL, but the Origin Domain ID
differs from the local Domain ID, a NOTIFICATION of <UPDATE Message
Error, Illegal Origin Role> must be sent back, and the claim is
rejected.
If Claim Timestamp and Claim Holdtime indicate that the claim has
expired (e.g. Timestamp + Claim Holdtime <= CurrentTime), the UPDATE
is silently dropped and no further actions are taken.
Each new arrival UPDATE is compared with all claims in the local
cache. The following fields are compared, and if all of them are the
same, the message is silently rejected and no further actions are
taken:
o Role, D-bit, Type
o AddrFam
o Claim Timestamp
o Claim Lifetime
o Claim Holdtime
o Origin Domain Identifier
o Origin Node Identifier
o Address
o Mask
Further processing of an UPDATE is based on its type and the Updated
Origin Role.
11.2. PREFIX_IN_USE Message Processing
11.2.1. PREFIX_IN_USE by PARENT
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error,
Illegal Origin Role> should be sent back.
11.2.2. PREFIX_IN_USE by SIBLING
If the claim cannot be associated with any parent's PREFIX_MANAGED,
the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
Appropriate Parent Prefix> must be sent back and no further actions
should be taken.
If the claim collides with some of the local domain's pending claims,
the local claims must not be considered further, and the Claim-Timer
of each of them must be canceled. If the received PREFIX_IN_USE claim
clashes with and wins over some of the local domain's allocated
prefixes, resolve the clash according to Section 12.4. Finally, the
claim must be propagated further to all INTERNAL_PEERs, all MASC
nodes from the corresponding parent MASC domain and all known
siblings with the same parent domain.
11.2.3. PREFIX_IN_USE by CHILD
If the claim's prefix is not a subrange of any of the local domain's
PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE
Message Error, No Appropriate Parent Prefix> must be sent back and no
further actions should be taken. Otherwise, the claim must be
propagated further to all INTERNAL_PEERs and all MASC children
domains.
11.2.4. PREFIX_IN_USE by INTERNAL_PEER
If the MASC node decides that the local domain does not need that
prefix any more, it may be withdrawn, otherwise, the claim is
processed as PREFIX_MANAGED.
11.3. CLAIM_DENIED Message Processing
11.3.1. CLAIM_DENIED by CHILD or SIBLING
The message is rejected, and a NOTIFICATION of <UPDATE Message Error,
Illegal Origin Role> should be sent back.
11.3.2. CLAIM_DENIED by INTERNAL_PEER
Propagate to all INTERNAL_PEERs and all MASC children nodes.
11.3.3. CLAIM_DENIED by PARENT
If the Origin Domain ID is not same as the local domain ID, and the
UPDATE cannot be associated with any parent domain, the message is
dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate
Parent Prefix> must be sent back and no further actions should be
taken.
If the Origin Domain ID is not same as the local domain ID, and the
UPDATE can be associated with a parent domain, the message is
propagated to all nodes from that parent domain, all INTERNAL_PEERs,
and all known SIBLINGs with regard to that parent.
If the Origin Domain ID is same as the local domain ID, and there is
no corresponding pending claim originated by the local MASC domain
(i.e. a NEW_CLAIM or CLAIM_TO_EXPAND with same AddrFam, Origin Domain
ID, Claim Timestamp, Address and Mask), a NOTIFICATION of <UPDATE
Message Error, No Appropriate Internal Prefix> must be sent back and
no further actions should be taken. Otherwise, the matching NEW_CLAIM
or CLAIM_TO_EXPAND's Claim-Timer must be canceled and the claim must
not be considered further. Finally, the received CLAIM_DENIED must be
propagated to all INTERNAL_PEERs, all MASC nodes from the
corresponding parent MASC domain, and all known SIBLINGs with regard
to that parent.
11.4. CLAIM_TO_EXPAND Message Processing
11.4.1. CLAIM_TO_EXPAND by PARENT
The claim is rejected, and a NOTIFICATION of <UPDATE Message Error,
Illegal Origin Role> should be sent back.
11.4.2. CLAIM_TO_EXPAND by SIBLING
If the claim cannot be associated with any parent's PREFIX_MANAGED,
the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
Appropriate Parent Prefix> must be sent back and no further actions
should be taken.
If there is no overlapping PREFIX_IN_USE by the same MASC domain, the
claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
Appropriate Sibling Prefix> must be sent back and no further actions
should be taken.
If the claim collides with and wins over some of the local domain's
pending claims, the loser claims must not be considered further, and
the Claim-Timer of the each of them must be canceled. Also, the
received claim must be propagated further to all INTERNAL_PEERs, all
MASC nodes from the corresponding parent MASC domain and all known
siblings with the same parent domain.
11.4.3. CLAIM_TO_EXPAND by CHILD
If the claim cannot be associated with any of the local domain's
PREFIX_MANAGED, the claim is dropped, a NOTIFICATION of <UPDATE
Message Error, No Appropriate Parent Prefix> must be sent back and no
further actions should be taken.
If there is no overlapping PREFIX_IN_USE by the same MASC domain, the
claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
Appropriate Child Prefix> must be sent back and no further actions
should be taken.
Otherwise, the claim has to be propagated to all INTERNAL_PEERs. If
the lifetime of the claim is longer than the lifetime of the
corresponding prefix managed by the local domain, or if there is an
administratively configured reason to prevent the child from
succeeding allocating the claimed prefix, a CLAIM_DENIED must be sent
to all MASC children nodes that have same Domain ID as Origin Domain
ID in the received message. The CLAIM_DENIED must be the same as the
received claim, except Rol=INTERNAL, and Claim Lifetime should be set
to the maximum allowed lifetime. Otherwise, propagate the claim to
all children as well.
11.4.4. CLAIM_TO_EXPAND by INTERNAL_PEER
If the claim cannot be associated with any parent's PREFIX_MANAGED,
the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
Appropriate Parent Prefix> must be sent back and no further action
should be taken.
If there is no overlapping PREFIX_IN_USE by the local MASC domain,
the claim is dropped, a NOTIFICATION of <UPDATE Message Error, No
Appropriate Internal Prefix> must be sent back and no further actions
should be taken.
If the MASC node decides that the local domain does not need that
pending claim any more, it MAY be withdrawn. Otherwise, the claim
must be propagated to all INTERNAL_PEERs and all MASC nodes from the
corresponding parent MASC domain.
11.5. NEW_CLAIM Message Processing
If the claim's Address field is 0 (i.e. a hint by a child to a parent
to obtain more space), the claim should be propagated only among the
nodes that belong to the child Origin Domain and the parent domain.
Otherwise, process like CLAIM_TO_EXPAND, except that no check for
overlapping PREFIX_IN_USE needs to be performed.
11.6. PREFIX_MANAGED Message Processing.
11.6.1. PREFIX_MANAGED by PARENT
If the Origin Domain ID matches one of the parents' domain ID's, the
prefix is recorded, and can be used by the address allocation
algorithm for allocating subranges. Also, the message is propagated
to all MASC nodes of the corresponding parent domain, all
INTERNAL_PEERs, and SIBLINGs with same parent.
11.6.2. PREFIX_MANAGED by CHILD or SIBLING
The message is rejected, and a NOTIFICATION of <UPDATE Message Error,
Illegal Origin Role> should be sent back.
11.6.3. PREFIX_MANAGED by INTERNAL_PEER
The prefix is recorded as allocated to the local domain, propagated
to all INTERNAL_PEERs, and can be used for (all items apply):
a) address ranges/prefixes advertisements to all MASC children and
local domain's MAASs;
b) injection into G-RIB;
c) further expansion by the address allocation algorithm (see
Appendix A);
11.7. WITHDRAW Message Processing
11.7.1. WITHDRAW by CHILD
If the WITHDRAW cannot be associated with any of the child domain's
PREFIX_IN_USE (i.e. no child's PREFIX_IN_USE covers WITHDRAW's
range), or if the WITHDRAW does not match any of the child domain's
NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no child's claim with
same Address, Mask and Timestamp), the message is dropped, a
NOTIFICATION of <UPDATE Message Error, No Appropriate Child Prefix>
must be sent back and no further actions should be taken. Otherwise,
propagate to all INTERNAL_PEERs and children.
11.7.2. WITHDRAW by SIBLING
If the WITHDRAW cannot be associated with any of the siblings'
PREFIX_IN_USE (i.e. no sibling's PREFIX_IN_USE covers WITHDRAW's
range), or if the WITHDRAW does not match any of the sibling domain's
NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no sibling's claim with
same Address, Mask and Timestamp), the message is dropped, a
NOTIFICATION of <UPDATE Message Error, No Appropriate Sibling Prefix>
must be sent back and no further actions should be taken. Otherwise,
propagate to all INTERNAL_PEERs, all MASC nodes from the same parent
MASC domain and all known siblings with the same parent domain.
11.7.3. WITHDRAW by INTERNAL
If the WITHDRAW cannot be associated with any of the local domain's
PREFIX_IN_USE or PREFIX_MANAGED (i.e. no local domain's prefix covers
WITHDRAW's range), or if the WITHDRAW does not match any of the local
domain's NEW_CLAIM or CLAIM_TO_EXPAND (i.e. there is no local
domain's claim with same Address, Mask and Timestamp) the message is
dropped, a NOTIFICATION of <UPDATE Message Error, No Appropriate
Internal Prefix> must be sent back and no further actions should be
taken.
Otherwise, propagate to all INTERNAL_PEERs, all MASC nodes of the
corresponding parent domain of that prefix, all known siblings with
that parent domain, and all children. If the WITHDRAW can be
associated with some of local domain's PREFIX_IN_USE or
PREFIX_MANAGED, stop advertising the WITHDRAW range to the MAASs and
withdraw that range from the G-RIB database. In the special case
when there is an indication that the WITHDRAW has been originated by
the local domain because of a clash, and the range specified in
WITHDRAW is a subrange of the local PREFIX_MANAGED, and the Claim
Holdtime of WITHDRAW is shorter than the Claim Holdtime of
PREFIX_MANAGED, the WITHDRAW's range should not be withdrawn from the
G-RIB. If the WITHDRAW matches a local domain's NEW_CLAIM or
CLAIM_TO_EXPAND, cancel the matching claim's Claim-Timer.
11.7.4. WITHDRAW by PARENT
If the WITHDRAW cannot be associated with any parent domain, a
NOTIFICATION of <UPDATE Message Error, No Appropriate Parent Prefix>
must be sent back and no further actions should be taken.
Otherwise, propagate to all INTERNAL_PEERs and all known siblings
with the same parent domain. Also, originate a WITHDRAW message for
each intersection of a locally owned PREFIX_MANAGED/PREFIX_IN_USE and
the received WITHDRAW. The locally originated WITHDRAW message's
Claim Holdtime should be at least equal to the Claim Holdtime in the
WITHDRAW message received from the parent; the Origin Node ID should
be the same as the particular PREFIX_MANAGED/PREFIX_IN_USE.
11.8. UPDATE Message Ordering
To simplify consistency and sanity check implementations, if there is
more than one UPDATE message that needs to be send to a peer (for
example, after a connection (re)establishment), some of the UPDATEs
must be sent before others.
The rules that always apply are:
o PREFIX_IN_USE must always be sent BEFORE CLAIM_TO_EXPAND,
NEW_CLAIM, and WITHDRAW by the same MASC domain
o WITHDRAW must always be sent AFTER PREFIX_IN_USE, CLAIM_TO_EXPAND,
NEW_CLAIM, and PREFIX_MANAGED by the same MASC domain
Any further ordering is defined below by the roles of the sender and
the receiver.
11.8.1. Parent to Child
Messages are sent in the following order:
1) Parent's PREFIX_MANAGED and WITHDRAWs.
2) All children's PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs.
CLAIMs from third party children that are hints for more space
(i.e. address = 0) should not be propagated; if propagated, the
child should drop them.
3) Parent initiated CLAIM_DENIED and children initiated WITHDRAWs.
CLAIM_DENIED regarding third party children's claims/hints with
address = 0 should not be propagated; if propagated, the child
should drop them.
11.8.2. Child to Parent
Messages are sent in the following order:
1) Parent's PREFIX_MANAGED and WITHDRAWs.
2) All PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMSs from that
parent's space, initiated by that child and all its siblings.
3) Parent's initiated CLAIM_DENIED, and all WITHDRAWSs that can be
associated with that parent's space and are initiated by the local
domain or all known siblings with that parent.
11.8.3. Sibling to Sibling
Messages are sent in the following order:
1) All common parent's PREFIX_MANAGED and WITHDRAWs.
2) PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs, initiated by
siblings.
3) CLAIM_DENIEDs initiated by common parent, and WITHDRAWs initiated
by local domain and all known siblings with that parent.
11.8.4. Internal to Internal
Messages are sent in the following order:
1) All parents' PREFIX_MANAGED and WITHDRAWs.
2) Local domain's and all siblings' PREFIX_IN_USE, CLAIM_TO_EXPAND,
and NEW_CLAIMs. CLAIMs from siblings that are hints for more
space (i.e. address = 0) should not be propagated; if propagated,
the recipient should drop them.
3) CLAIM_DENIEDs initiated by all parents, and WITHDRAWs initiated by
local domain and all known siblings.
4) All children's PREFIX_IN_USE, CLAIM_TO_EXPAND, and NEW_CLAIMs.
5) All local domain initiated CLAIM_DENIED regarding children claims
and all children initiated WITHDRAWs.
12. Operational Considerations
12.1. Bootup Operations
To learn about its parent domains' IDs and prefixes, a MASC node
SHOULD try to establish connections to its PARENT nodes before
initiating a connection to a SIBLING node. To avoid learning about
its own PREFIX_MANAGED from its children or siblings, a MASC node
SHOULD try to establish connections to its PARENT nodes and
INTERNAL_PEER nodes before initiating a connection to a CHILD or
SIBLING node.
12.2. Leaf and Non-leaf MASC Domain Operation
A non-leaf MASC domain (i.e. a domain that has children domains)
should advertise its PREFIX_MANAGED addresses to its children, and
should claim from that space the sub-ranges that would be advertised
to the internal MAASs (the claim wait time SHOULD be equal to
[WAITING_PERIOD]). A MASC node that belongs to a non-leaf MASC
domain should perform dual functions by being a child of itself with
regard to the claiming and management of the sub-ranges for local
usage. A leaf MASC domain should advertise all PREFIX_MANAGED
addresses to its MAASs without explicitly claiming them for internal
usage. A MASC node can assume that it belongs to a leaf domain if it
simply does not have any UPDATEs by children domains. If an UPDATE
by a child is received, the domain MUST switch from "leaf" to "non-
leaf" mode, and if it needs more addresses for internal usage, it
MUST claim them from that domain's PREFIX_MANAGED. After the last
UPDATE originated by a child expires, the domain can switch back to
"leaf" mode.
12.3. Clock Skew Workaround
Each UPDATE has "Claim Timestamp" field that is set to the absolute
time of the MASC node that originated that UPDATE. The timestamp is
used for two purposes: to resolve collisions, and to define how long
an UPDATE should be kept in the local cache of other MASC nodes. A
skew in the clock could result in unfair collision decision such that
the claims originated by nodes that have their clock behind the real
time will always win; however, because collisions are presumably
rare, this will not be an issue. Skew in the clock however might
result in expiring an UPDATE earlier than it really should be
expired, and a node might assume too early that the expired
UPDATE/prefix is free for allocation. To compensate for the clock
skew, an UPDATE message should be kept longer than the amount of time
specified in the Claim Holdtime. For example, keeping UPDATEs for an
additional 24 hours will compensate for clock skew for up to 24
hours.
12.4. Clash Resolving Mechanism
If a MASC node receives a PREFIX_IN_USE claim originated by a sibling
and the claim overlaps with some of the local prefixes, the clash
must be resolved. Two MASC domains should not manage overlapping
address ranges, unless the domains have an ancestor-descendant (e.g.
parent-child) relationship in the MASC hierarchy. Also, two MASC
domains should not have locally-allocated overlapping address ranges.
The clashed address ranges should not be advertised to the MAASs and
allocated to multicast applications/sessions. If a clashed address
has being allocated to an application, the application should be
informed to stop using that address and switch to a new one.
The G-RIB database must be consistent, such that it does not have
ambiguous entries. "Ambiguous G-RIB entries" are those entries that
might cause the multicast routing protocol to loop or lose
connectivity. In MASC the WITHDRAW message is used to solve this
problem. When a clashing PREFIX_IN_USE is received, it is compared
(using the function describe in Section 5.1.1) against all prefixes
allocated to the local domain. If the local PREFIX_IN_USE is the
winner, no further actions are taken. If the local PREFIX_IN_USE is
the loser, the clashing address range must be withdrawn by initiating
a WITHDRAW message. The message must have Role = INTERNAL, Origin
Node ID and Origin Domain ID must be the same as the corresponding
local PREFIX_IN_USE message, while Claim Timestamp, Claim Lifetime,
Claim Holdtime, Address and Mask must be the same as the received
winning PREFIX_IN_USE. The initiated WITHDRAW message must be
processed as described in Section 11.7.
If a cached WITHDRAW times out and the local MASC domain owns an
overlapping PREFIX_MANAGED or PREFIX_IN_USE, the overlapping prefix
ranges can be injected back into the G-RIB database. Similarly, the
address ranges that were not advertised to the local domain's MAASs
due to the WITHDRAW, can now be advertised again.
In addition to the automatic resolving of clashes, a MASC
implementation should support manual resolving of clashes. For
example, after a clash is detected, the network administrator should
be informed that a clash has occurred. The specific manual
mechanisms are outside the scope of this protocol.
A MASC node must be configured to operate using either manual or
automatic clash resolution mechanisms.
12.5. Changing Network Providers
If a MASC domain changes a network provider, such that the old
provider cannot be used to provide connectivity, any traffic for
sessions that are in progress and use that MASC domain as the root of
multicast distribution trees will not be able to reach that domain.
If the new network provider is willing to carry the traffic for the
old sessions rooted at the customer domain, then it must propagate
the customer's old prefixes through the G-RIB. However, at least one
MASC node in the customer domain must maintain a TCP connection to
one of the old network provider's MASC nodes. Thus, it can continue
to "defend" the customer's prefixes, and should continue until the
old prefixes' lifetimes expire.
If the new network provider is not willing to propagate the old
prefixes, then the customer should remove its prefixes from the G-
RIB. If BGMP is in use, the old network provider's domain will
automatically become the Root Domain for the customer's old groups
due to the lack of a more specific group route. MASC nodes in the
customer domain MAY still connect with the old provider's MASC nodes
to defend their allocation.
12.6. Debugging
12.6.1. Prefix-to-Domain Lookup
Use mtrace [MTRACE] to find the BGMP/MASC root domain for a group
address chosen from that prefix.
12.6.2. Domain-to-Prefix Lookup
We can find the address space allocated to a particular MASC domain
by directly querying one of the MASC servers within that domain, by
observing the state in parents, siblings, or children MASC domains,
or by observing the G-RIB information originated by that domain.
From those three methods, the first method can provide the most
detailed information. Finding the address of one of the MASC nodes
within a particular domain is outside the scope of MASC.
13. MASC Storage
In general, MASC will be run by a border routers, which, in general
do not have stable storage. In this case, MASC must use the Layer 2
protocol/mechanism (e.g., ([AAP]) as described in [MALLOC] to store
the important information (the prefixes allocated by the local
domain) in the domain's MAASs who should have stable storage. If the
MASC speaker has local storage, it should use it instead of the Layer
2 protocol/mechanism. Claims that are in progress do not have to be
saved by using the Layer 2 protocol/mechanism.
14. Security Considerations
IPsec [IPSEC] can be used to address security concerns between two
MASC peering nodes. However, because of the store-and-forward nature
of the UPDATE messages, it is possible that if a non-trustworthy MASC
node can connect to some point of the MASC topology, then this node
can undetectably inject malicious UPDATEs that may disturb the normal
operation of other MASC nodes. To address this problem, each MASC
node should allow peering only with trustworthy nodes.
After a reboot, a MASC node/domain can restore its state from its
neighbors (internal peers, parents, siblings, children). Typically,
the state received from a parent or internal peer will be
trustworthy, but a node may choose to drop its own UPDATEs that were
received through a sibling or a child.
A misbehaving node may attempt a Denial of Service attack by sending
a large number of colliding messages that would prevent any of its
siblings from allocating more addresses. A single mis-behaving node
can easily be identified by all of its siblings, and all of its
UPDATEs can be ignored. A Denial of Service attack that uses
multiple origin addresses can be prevented if a third-party UPDATE
(e.g. by a non-directly connected sibling) is accepted only if it is
sent via the common parent domain, and the MASC nodes in the parent
domain accept children UPDATEs only if they come via an internal
peer, or come directly from a child node that is same as the Origin
Node ID.
15. IANA Considerations
This document defines several number spaces (MASC message types, MASC
OPEN message optional parameters types, MASC UPDATE message attribute
types, MASC UPDATE message optional parameters types, and MASC
NOTIFICATION message error codes and subcodes). For all of these
number spaces, certain values are defined in this specification. New
values may only be defined by IETF Consensus, as described in [IANA-
CONSIDERATIONS]. Basically, this means that they are defined by RFCs
approved by the IESG.
16. Acknowledgments
The authors would like to thank the participants of the IETF for
their assistance with this protocol.
17. APPENDIX A: Sample Algorithms
DISCLAIMER: This section describes some preliminary suggestions by
various people for algorithms which could be used with MASC.
17.1. Claim Size and Prefix Selection Algorithm
This section covers the algorithms used by a MASC node (on behalf of
a MASC domain) to satisfy the demand for multicast addresses. The