Network Working Group S. Shimizu
INTERNET-DRAFT S. Sato
K. Murakami
July 1999
MAPOS Automatic Switch-address Assignment Protocol (ASAP) Option
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Please send comments to the
authors <shimizu@ntt-20.ecl.net> <sato@ingrid.org> <murakami@ntt-
20.ecl.net>.
Abstract
This document describes Automatic Switch-address Assignment
Protocol (ASAP) option for SSP (switch-switch protocol) of MAPOS
(Multiple Access Protocol Over SONET/SDH). It enables each switch in
a MAPOS network to decide its unique MAPOS address in coordination
with other switches and provides an environment free of manual
configuration. Upon an address collision, an arbitration takes place
to resolve the conflict.
1. Outline
Shimizu, Sato & Murakami [Page 1]
INTERNET-DRAFT July 1999
MAPOS [1] is a layer 2 protocol that provides multiple access
capability over SONET/SDH networks, DWDM links or dark fibers. SSP
[2] is used for layer 2 routing in a MAPOS network with multiple
switches. Each switch must have a unique MAPOS HDLC address,
hereinafter referred to as "MAPOS address", within the network. In a
conventional MAPOS switch, it must be manually configured, and is
prone to misconfiguration, especially in a large network. To cope
with this issue, Automatic Switch-address Assignment Protocol (ASAP)
is designed. It enables automatic configuration of MAPOS address and
provides plug-and-play operation for a switch.
ASAP is an option for SSP and is designed for MAPOS16 [3]. A
switch randomly selects an initial MAPOS address at boot time and
starts SSP route exchange with its peers. Unlike conventional SSP,
each switch is assumed to have a global IEEE 48 bit MAC address,
hereinafter referred to as "MAC address". Since MAC address is
globally unique, each switch can be identified even if the initial
MAPOS address collides with others. Note that the MAC address is
independent of the routing process. It is utilized only for a switch
to coordinate a unique MAPOS address with other switches.
Each SSP route entry has its origin's MAC address in addition to
its MAPOS address. Route entries are exchanged and flooded by
switches as defined in SSP. Each switch inspects the destination
MAPOS addresses in SSP route update messages. When a switch finds
that its MAPOS address collides with the others, it compares the
precedence of itself with those of the colliding switches as
described in section 3. If it has lower precedence, a new MAPOS
address is selected so that it does not conflict with the others, and
begins re-advertising its routes. Unused addresses may be identified
by inspecting the existing SSP route entries. In this distributed
manner, each switch eventually gets a unique MAPOS address. This
automatic address coordination is used not only for switch boot-up
process, but also when connecting independent MAPOS networks.
In the next section, ASAP packet format is specified. The address
coordination process is described in Section 3. In section 4,
updates required at node side are discussed. Section 5 and 6 shows
some exceptional situations and an example, respectively. Section 7
shows a rough estimation of convergence time based on simulation
results.
2. New SSP Packet Format
This section explains the new SSP packet and route entry format for
supporting ASAP.
Shimizu, Sato & Murakami [Page 2]
INTERNET-DRAFT July 1999
2.1 Modified SSP Fields
Figure 1. shows the ASAP enabled SSP message format. It consists
of SSP header and SSP route entries. A message should include at
least one route entry and should not contain more than 20 entries
because the maximum packet size is limited to 512 bytes. An SSP
session may be composed of several SSP messages.
Differences from the conventional SSP are
(1) Age field is added.
(2) Originating switch's 48bit IEEE MAC address field is added.
(3) Address Family Identifier (AFI) is re-defined as a bit-field,
instead of unsigned integer value.
(4) Metric field is shrunk to 16bit from original 32bit width.
Other fields and message length are unchanged.
(MSB) (LSB)
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------
| Command | Version | unused |header
+---------------+---------------+-------------------------------+------
| Address Family Identifier(AFI)| Age |
+-------------------------------+-------------------------------+ an
| HDLC Address | SSP
+---------------------------------------------------------------+ route
| Subnet Mask | entry
+---------------------------------------------------------------+
|(MSB 48bit IEEE MAC address of the origin |
+---------------------------------------------------------------+
| MAC LSB)| Metric |
+---------------+---------------+-------------------------------+------
| Address Family Identifier | Age |
Figure 1. New SSP Packet Format for ASAP
2.2 Header Description
ASAP enabled SSP uses the same header as the conventional SSP. It
consists of a command field and a version field. The command field
is one octet long and holds one of the following values;
1 - request A request to send all or a part of SSP routing
table.
2 - response A message containing all, or a part of the
Shimizu, Sato & Murakami [Page 3]
INTERNET-DRAFT July 1999
sender's SSP routing table. This message may be
sent in response to a request, or it may be an
update message generated by the sender.
The Version field indicates the version of SSP being used. The
current version number is 1.
2.3 SSP Route Entries
(1) Address Family Identifier (AFI)
Each entry has an address family identifier. It is 2 octet (16bit)
bit-field that indicates attributes of the entry (Figure 2).
(MSB) (LSB)
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-----------+-+-+---------------+
| Reserved |H|D| Mode |
+-----------+-+-+---------------+
Mode (in decimal) :
0 : Unspecified, used when a switch requests adjacent
switches to send the entire SSP routing table.
2 : Valid entry
Flags:
D : Dynamic/Static address (0: Static 1: Dynamic)
H : Host/Switch route (0: Switch 1: Host )
Figure 2. AFI Bit-field
Mode field indicates whether the entry is a valid entry, or a dummy
entry used when requesting adjacent switches to send all of its
routing table entries. It is compatible with the conventional SSP.
Flag D is used to indicate whether the entry contains a
conventional fixed address or a dynamically configured address. The
values 0 and 1 specify a static address and a dynamic address,
respectively. A static address indicates manually configured address
and may never be changed. Switches that are manually configured
should advertise its route with the value 0 for D flag.
Flag H is used to identify that the entry is either a host route or
a switch route. The values 0 and 1 specify a switch route and a host
route, respectively.
A host route is ignored in ASAP since it is a part of its parent
switch's subnet. When the address of the parent switch changes, the
host routes in its subnet also change according to the new switch
Shimizu, Sato & Murakami [Page 4]
INTERNET-DRAFT July 1999
address.
Followings are the possible AFI values and the meanings;
0x0000: Unspecified, entire table request
0x0002: A switch route that has a static address
0x0102: A switch route that has a dynamic address
0x0202: A host route connected to a switch that has a static
address
0x0302: A host route connected to a switch that has a dynamic
address
An entry with unknown value should be ignored by the recipient.
(2) Age
Age field is 2 octet unsigned short integer and shows the uptime of
the originating switch. The unit is one hour. When a switch has run
for almost 8 years and Age value becomes 65535, it MUST stop
incrementing this field.
When address collision is detected, this field is used to decide
the precedence of the switch address as described in section 3.
(3) HDLC Address
The HDLC address indicates a switch address or a host address. The
field is 4 octet long and the address is placed in the least
significant position. It consists of switch address part and node
address part.
(4) Subnet Mask
Its length and use are the same as the conventional SSP. It is
applied to the HDLC address to extract the switch address portion of
HDLC address.
(5) IEEE MAC Address
A globally unique 48bit IEEE MAC address of the originating switch.
(6) Metric
Metric indicates the distance to the destination switch. Unlike
the conventional SSP, it is 2 octet long. It must contain a value
between 1 and 31. The metric of 16 indicates that the destination is
not reachable and is ignored by recipients. The values between 17
and 31 are utilized for poisoned reverse with split horizon and also
Shimizu, Sato & Murakami [Page 5]
INTERNET-DRAFT July 1999
means unreachable. The metric 0 indicates the local switch itself.
3. ASAP Address Coordination Process
This section describes the address coordination process of ASAP in
detail. It consists of three parts, initialization, message
reception, and new address selection.
3.1 Initialization
Initially, a switch selects its address randomly. Its subnet mask
is decided based on the maximum number of ports of the switch. For
example, a switch that has 8 ports uses a 0xFFF0 (3 bit host-part + 1
bit EAbit) subnet mask. Note that address 0x0001 is reserved for
control processor inside a switch. That is, a switch MUST NOT select
0 for its address.
After the initial address selection, it starts advertising SSP
route entries. They include the route entry for the switch itself
and host route of leaf nodes if necessary. Note that the switch
route MUST be advertised in addition to host routes.
3.2 Receiving a SSP Message
Every time a switch receives an SSP message, it first compares the
HDLC addresses of all the switch route entries against that of the
switch. Then it look over the all entries to calculate routes and
update its forwarding table.
An entry is considered to be 'in collision' when it satisfies the
following conditions;
(1) Logical AND of the HDLC address of the switch and the entry
yields the same result. If the switch netmask and the entry
netmask are different, the shorter one should be used.
For example, two routes, 0x4000 with subnet mask 0xF000 and
0x4200 with subnet mask 0xFF00 are masked with 0xF000. Both
of them yields the same 0x4 switch address and indicates a
collided address.
(2) Origin MAC address is different. That is, collided entry
should come from different switch.
When a colliding entry is found, the local switch compares its
precedence with that of the colliding entry as follows;
(1) One with the static flag set in its AFI has the highest
precedence.
(2) One with the larger age has higher precedence.
Shimizu, Sato & Murakami [Page 6]
INTERNET-DRAFT July 1999
(3) One with the shorter subnet-mask, that is, a switch with
larger number of nodes has higher precedence.
(4) One with the smaller MAC address has higher precedence.
The comparisons are made in the listed order from (1) to (4). If
both the switch and the colliding entry have static-flagged AFI,
these switches should stop forwarding immediately and notify the
operator about the error. If they both have dynamic-flagged AFI, age
fields are compared next. If the values are the same, subnet-mask
length is compared. If the length is equal, their MAC addresses are
compared as the final criteria to break the tie.
Colliding entries that have lower precedence MUST NOT be copied to
the forwarding table inside the switch, so that no frame is forwarded
based on the obsolete entry. However, those entries SHOULD remain in
the routing table manipulated by SSP so that the colliding entries
flood with others. Figure 3 shows the relationship between the
routing table and the forwarding table in a switch.
SSP route SSP route
exchange +---------------------+ exchange
<--------> | Routing Table | <-------->
| - Calculate Routes |
| - Entry validation |
+---------------------+
||
VV download
Packet +---------------------+
Header | Forwarding Table |
--------> | - Destination-Port |
<-------- | Index |
Output Port +---------------------+
Figure 3. Relationship between Routing Table and Forwarding Table
3.3 Selecting a New HDLC Address
When a switch detects that its address collides with another switch
with a higher precedence, it MUST select a new HDLC address through
the following procedure.
(1) Stop forwarding all frames.
(2) Pick an unused MAPOS address by inspecting all received routing
entries.
(3) Advertise new routing entry based on the new HDLC address by
triggered update.
(4) Notify the address change to all nodes under the switch using
NSP
Shimizu, Sato & Murakami [Page 7]
INTERNET-DRAFT July 1999
(5) Wait for unicast routing to stabilize.
(6) Start forwarding unicast.
(7) Wait for broadcast/multicast spanning tree to become stable.
(8) Start forwarding multicast and broadcast.
(9) Nodes resets and requests its new address to the parent switch.
3.4 Timings
In addition to the original SSP timers (EXPIRATION_TIMER, GC_TIMER,
FORWARD_DELAY_TIMER, PORT_EXPIRATION_TIMER), ASAP introduces another
timer HOLD_TIMER to suspend packet forwarding while address
coordination is in progress. It is 30 seconds (3 * FULL_UPDATE_TIME)
by default. Since the address coordination utilizes triggered update
and is independent of FULL_UPDATE_TIME, 3 * FULL_UPDATE_TIME is
enough to stabilize unicast forwarding. Refer to Section 7 for the
estimation of convergence time.
Figure 4 shows the time-chart. When a switch detects an address
collision and find that it must change its MAPOS address, it stops
packet forwarding and starts HOLD_TIMER. Then, it starts address
coordination with the others and chooses a new MAPOS address. Note
that the switch continues routing information exchange although it
suppresses packet forwarding.
Address Coordination VRPB T : FULL_UPDATE_TIME
starts (keep routing) ready (10 seconds by default)
| |
V T T T T T T V T T T T T
[SWITCH]-+---+---+---+---+---+---+---+---+---+---+---+--> Time
^ HOLD_TIMER FORWARD_DELAY
|<--------->|<--------->|
| ^ ^
| | |
| | Broadcast/multicast forwarding starts
| Unicast forwarding starts
|
Notifies its address change to end nodes by NSP
|
V
[END -+---+---+---+---+---+---+---+---+---+---+---+--> Time
NODES] ^ RESTART_DELAY_TIMER ^
|<--------------------->|
Detects |
Address Change |
Restart
Get node address by NSP and send UNARP three times
Figure 4. Time-chart of Routing and Forwarding on Address
Shimizu, Sato & Murakami [Page 8]
INTERNET-DRAFT July 1999
Coordination
On the expiration of HOLD_TIMER, it resumes unicast forwarding.
However, as with broadcast and multicast forwarding, FORWARD_DELAY is
employed to suppress forwarding loop as specified in the original
SSP. That is, when a poison reversed packet is newly received from a
port after HOLD_TIMER expiration, the local switch knows that a
downstream switch has appeared. Then, it marks the bit corresponding
to the port and starts FORWARD_DELAY_TIMER (30 second by default,
that is, 3 * FULL_UPDATE_TIME) for the port. The forwarding of
broadcast/multicast frames to the port is prohibited until the timer
expires. Every time the local switch receives a poison reversed
packet through a port, it initializes PORT_EXPIRATION_TIMER (30
seconds by default, that is, FULL_UPDATE_TIME * 3) corresponding to
the port. A continuous loss of poison reversed packets or a failure
of downstream port results in expiration of PORT_EXPIRATION_TIMER,
and the corresponding bit is cleared. Section 4 describes it in
detail the timing for the end nodes.
Figure 5 shows the time-chart for boot-up. The behavior of the
switch is almost the same as that of address coordination. However,
NSP starts after FORWARD_DELAY timer expiration.
Routing starts VRPB T : FULL_UPDATE_TIME
ready (10 seconds by default)
| |
V T T T T T T V T T T T T
[SWITCH] +---+---+---+---+---+---+---+---+---+---+---+--> Time
^ HOLD_TIMER FORWARD_DELAY
|<--------->|<--------->|
^ ^
| |
| Broadcast/multicast forwarding starts
Unicast forwarding starts
NSP starts
|
V
[END --+---+---+---+---+---+---+---+---+---+---+---+--> Time
NODES] ^
|
Get node address by NSP and send UNARP three times
Figure 5. Time-chart of Routing and Forwarding on Boot-up
4. Modification to NSP
Shimizu, Sato & Murakami [Page 9]
INTERNET-DRAFT July 1999
When a switch address is changed, the switch assigns a new HDLC
address to each leaf node. This work is done through NSP keep-alive
process, using NSP reply packet. That is, an end node MUST always
verify the assigned HDLC address and accept any change.
When an end node detects address change, it must restart the MAPOS
interface after RESTART_DELAY_TIMER (60 seconds by default)
expiration. This timer is newly introduced for ASAP. On restart, as
the original NSP specifies, the end node first requests its address
by sending NSP requests. When it receives the response and get its
address, it must broadcast MAPOS UNARP [5] three times to purge old
ARP entry on other end nodes associated with the IP address.
On switch boot-up, an end node requests its address as specified in
NSP. Since switch delays starting NSP process for the first
HOLD_TIMER and FORWARD_DELAY expiration, the leaf nodes will get HDLC
addresses after that period.
5. Exceptional Cases
In this section, some exceptional cases are considered to verify
the soundness of ASAP.
(1) Parallel Address Coordination
When a switch detects the third switch announcing the same address
during the coordination process, it immediately restarts the process
based on the entry information. That is, the coordination process
continues until no duplication address is detected. Every time it
restarts the process, HOLD_TIMER is cleared and restarted. Estimated
convergence time of the coordination process depends on the address
space to the number-of-switches ratio. One of the worst cases is
examined in Section 7.
(2) Running Out of MAPOS 16 Address Space
When the MAPOS 16 address runs out of space, the switch immediately
stops the coordination process and notifies operator with an error
message indicating "out of space". When there are many switches with
very short netmask, this problem can happen. To protect against
this, use of a large number of switches should be avoided. Since
MAPOS is designed for very high speed networks, the number of
switches should be suppressed to keep the network sound. Otherwise,
throughput may be severely impaired.
6. Examples
Shimizu, Sato & Murakami [Page 10]
INTERNET-DRAFT July 1999
Figure 6 shows an example of address collision. It assumes that two
working MAPOS networks, Na and Nb, are being connected.
Network Na Network Nb
Port4 Port3
S1[0x1210/FFF0]-- --S2[0x1200/FF00]
| Port 2 | Port2
Port3 | Port3 |
S0[0x3000/FFF0] S3[0x4000/FF00]
State (I) Independent Networks
S1[0x1210/FFF0]-----------S2[0x1200/FF00]
| |
S0[0x3000/FFF0] S3[0x4000/FF00]
State (II) Networks are just connected.
S1[0x1010/FFF0]-----------S2[0x1200/FF00]
| |
S0[0x3000/FFF0] S3[0x4000/FF00]
State (III) S1 changes its address.
Figure 6. Address Reassignment Process
State (I) in Figure 6 is the initial state. Two MAPOS networks are
running independently. Switch S1 has a MAPOS address 0x1210 with
netmask 0xFFF0, and Switch S2 has 0x1200 with 0xFF00. S0 and S3 also
have unique switch addresses as shown in Figure 6. Table 1 shows the
routing table in each switch in State (I) in the Figure 6.
Destination Subnet mask Next Hop Metric MAC Address Age
-----------------------------------------------------------------
0x3000 0xFFF0 Direct - 0x0090ED 000001 5
0x1210 0xFFF0 Port 3 1 0x0090ED 000002 3
(a) Routing Table of S0
Destination Subnet mask Next Hop Metric MAC Address Age
-----------------------------------------------------------------
0x1210 0xFFF0 Direct - 0x0090ED 000002 3
0x3000 0xFFF0 Port 2 1 0x0090ED 000001 5
(b) Routing Table of S1
Shimizu, Sato & Murakami [Page 11]
INTERNET-DRAFT July 1999
Destination Subnet mask Next Hop Metric Mac Address Age
-----------------------------------------------------------------
0x1200 0xFF00 Direct - 0x0090ED 000003 3
0x4000 0xFF00 Port 2 1 0x0090ED 000004 2
(c) Routing Table of S2
Destination Subnet mask Next Hop Metric Mac Address Age
-----------------------------------------------------------------
0x4000 0xFF00 Direct - 0x0090ED 000004 2
0x1200 0xFF00 Port 3 1 0x0090ED 000003 3
(d) Routing Table of S3
Table 1. Routing Table Entries at State I.
When these two networks are connected, S1 and S2 exchange SSP
routes (State II). Table 2 shows the routing tables at this time.
Destination Subnet mask Next Hop Metric Mac Address Age
-----------------------------------------------------------------
0x3000 0xFFF0 Direct - 0x0090ED 000001 5
*0x1210 0xFFF0 Port 3 1 0x0090ED 000002 3
0x1200 0xFF00 Port 3 2 0x0090ED 000003 3
0x4000 0xFF00 Port 3 3 0x0090ED 000004 2
(a) Routing Table of S0
Destination Subnet mask Next Hop Metric Mac Address Age
-----------------------------------------------------------------
*0x1210 0xFFF0 Direct - 0x0090ED 000002 3
0x1200 0xFF00 Port 4 1 0x0090ED 000003 3
0x3000 0xFFF0 Port 2 1 0x0090ED 000001 5
0x4000 0xFF00 Port 4 2 0x0090ED 000004 2
(b) Routing Table of S1
Destination Subnet mask Next Hop Metric Mac Address Age
-----------------------------------------------------------------
0x1200 0xFF00 Direct - 0x0090ED 000003 3
*0x1210 0xFFF0 Port 3 1 0x0090ED 000002 3
0x3000 0xFFF0 Port 3 2 0x0090ED 000001 5
0x4000 0xFF00 Port 2 1 0x0090ED 000004 2
(c) Routing Table of S2
Shimizu, Sato & Murakami [Page 12]
INTERNET-DRAFT July 1999
Destination Subnet mask Next Hop Metric Mac Address Age
-----------------------------------------------------------------
0x4000 0xFF00 Direct - 0x0090ED 000004 2
0x1200 0xFF00 Port 3 1 0x0090ED 000003 3
*0x1210 0xFFF0 Port 3 2 0x0090ED 000002 3
0x3000 0xFFF0 Port 3 3 0x0090ED 000001 5
(d) Routing Table of S3
Table 2. Table Entries at State (II)
(* sign shows invalid/collided entry)
Note that a switch verifies all the routes in its routing table and
copies only valid routes to its forwarding table. Entries with *
sign in the Table 2 are invalid and are not copied to the forwarding
table.
In this example, all switches find that the address of S1 and S2
collids. Since the both route entries for S1 and S2 has the same age
values, the comparison is made on their subnet-mask length. The
precedence of S1 is lower than that of S2, because S1 has a longer
subnet-mask.
Therefore, in state (III), S1 changes its address and chooses a new
address and subnet-mask (0x1010/FFF0) that does not conflict with
other switches. In contrast, S2 does nothing because it has the
higher precedence. S1 advertises the new route by triggered update,
and it is flooded through other switches. Since the old route of S1
is not updated any more, associated route entries in S2 and S3 are
eventually removed.
Immediately after S1 changes its address, it reassigns new end node
addresses to its locally attached nodes by NSP. Table 3 shows the
routing table at state (III).
Destination Subnet mask Next Hop Metric Mac Address Age
-----------------------------------------------------------------
0x3000 0xFFF0 Direct - 0x0090ED 000001 5
0x1010 0xFFF0 Port 3 1 0x0090ED 000002 3
0x1200 0xFF00 Port 3 2 0x0090ED 000003 3
0x4000 0xFF00 Port 3 3 0x0090ED 000004 2
(a) Routing Table of S0
Destination Subnet mask Next Hop Metric Mac Address Age
-----------------------------------------------------------------
0x1200 0xFF00 Port 4 1 0x0090ED 000003 3
0x1010 0xFFF0 Direct - 0x0090ED 000002 3
Shimizu, Sato & Murakami [Page 13]
INTERNET-DRAFT July 1999
0x3000 0xFFF0 Port 2 1 0x0090ED 000001 5
0x4000 0xFF00 Port 4 2 0x0090ED 000004 2
(b) Routing Table of S1
Destination Subnet mask Next Hop Metric Mac Address Age
-----------------------------------------------------------------
0x1200 0xFF00 Direct - 0x0090ED 000003 3
0x1010 0xFFF0 Port 3 1 0x0090ED 000002 3
0x3000 0xFFF0 Port 3 2 0x0090ED 000001 5
0x4000 0xFF00 Port 2 1 0x0090ED 000004 2
(c) Routing Table of S2
Destination Subnet mask Next Hop Metric Mac Address Age
-----------------------------------------------------------------
0x4000 0xFF00 Direct - 0x0090ED 000004 2
0x1200 0xFF00 Port 3 1 0x0090ED 000001 3
0x1010 0xFFF0 Port 3 2 0x0090ED 000002 3
0x3000 0xFFF0 Port 3 3 0x0090ED 000001 5
(d) Routing Table of S3
Table 3. Routing Table Entries at State (III)
In state (III), S1 stops packet unicast forwarding for HOLD_TIMER
and broadcast/multicast forwarding for HOLD_TIMER plus FORWARD_DELAY.
Even if S1 suspended forwarding, it continues routing information
exchange. Switches can continue routing exchange because SSP uses
the fixed HDLC address 0x0001 for adjacent switch-to-switch
communication. Unicast routing is stabilized by HOLD_TIMER
expiration. As for the new spanning tree for VRPB, it is expected to
stabilize by FORWARD_DELAY timer expiration.
7. Estimated Convergence Time
This section shows the nature of ASAP convergence time based on a
simulation. The simulation concentrates on the number of address
renumbering required for all the switches to get unique addresses at
boot time. For the simplicity, the followings are assumed;
(1) The address space is 8K, since ASAP is designed for MAPOS 16.
(2) Propagation delay of triggered update packet is negligible and
there is no packet loss. All the switches can get triggered
routing updates instantly. This means that there is no
specific topology to be assumed.
Shimizu, Sato & Murakami [Page 14]
INTERNET-DRAFT July 1999
(3) No statistical distribution is considered on queuing,
processing, and transferring of routing packets. Each switch
reassigns address every time T. T is considered to be less
than one second.
(4) All the switches are booted at the same time.
(5) The number of switches is seven.
In this simulation, the following two cases are investigated;
Case 1: Each switch has 64 ports (6bits for nodes). The subnet mask
is 0xFF80 and whole the MAPOS-16 address space corresponds to 127
(7bits - 1) switches.
That is, switches choose seven unique addresses out of 127. This
shows a recommended use of the MAPOS16 address assignment.
Case 2: Each switch has 1024 ports (10bits for nodes). The subnet
mask is 0xF000 and whole the MAPOS-16 address space correspnds to 7
(3bits - 1) switches.
That is, switches choose seven unique addresses out of seven. This
shows one of the worst situation.
Figure 7 shows the result. The X axis indicates the number of
renumbering time. The Y axis indicates the percentage of the switches
which have fixed unique addresses. The cases 1 and 2 are indicated by
+ and *, respectively.
In the case 1, address coordination almost completes within three
renumbering times. Even in the relatively worse case 2, it almost
completes within four renumbering times. Address coordination while
ordinaly operation will take less time, since only few switches will
be booting. Therefore, the address coordination process completes
within several renumbering time and the time is considered to be
negligible in the MAPOS network clocked by FULL_UPDATE_TIME, which is
10 seconds by default.
Shimizu, Sato & Murakami [Page 15]
INTERNET-DRAFT July 1999
100|% + + +* +* +* +* +*
90| *
80| + + series * series
70| 0 0.8451 0 0.0061
60| 1 0.9999 1 0.4355
50| 2-7 1.0 2 0.9656
40| * 3 0.9999
30| 4-7 1.0
20|
10|
-+--*--+--+--+--+--+--+--+-->
0 1 2 3 4 5 6 7 Time(T)
Figure 7. ASAP Renumbering Process Convergence Time
8. Consideration for the use of ASAP
ASAP causes network instability during the address coordination.
Switches stop forwarding frames until unicast/broadcast routing
becomes stable, which is at least 60 seconds. That is, HOLD_TIMER
(30 seconds by default) to stabilize unicast routing and
FORWARD_DELAY (30 seconds by default) to rebuild the spanning tree
for broadcast. Operators who do not want the suspension should use
static addressing.
When ASAP is employed, the network designer should consider the
number of switches and ports. As shown in Section 7, the total
address usage should be kept small to shorten the the address
coordination time.
9. Security Considerations
Security considerations ane not discussed in this memo.
10. Expiration
This Internet Draft expires within 6 months from the date of
submission.
11. References
[1] Murakami, K., and Maruyama, M., "MAPOS - Multiple Access
Protocol over SONET/SDH Version 1", RFC2171, June 1997.
Shimizu, Sato & Murakami [Page 16]
INTERNET-DRAFT July 1999
[2] Murakami, K. and Maruyama, M., "A MAPOS version 1 Extension -
Switch-Switch Protocol", RFC2174, June 1997.
[3] Murakami, K. and Maruyama, M., "MAPOS 16 - Multiple Access
Protocol over SONET/SDH with 16 Bit Addressing", RFC2175, June
1997.
[4] Murakami, K. and Maruyama, M., "A MAPOS version 1 Extension -
Node Switch Protocol", RFC2173, June 1997.
[5] Murakami, K. and Maruyama, M., "IPv4 over MAPOS Version 1",
RFC2176, June 1997.
12. Acknowledgements
The authors would like to acknowledge the contributions and
thoughtful suggestions of Takahiro Sajima.
13. Author's
Address:
Susumu Shimizu
Shin-ya Sato
Ken Murakami
NTT Network Innovation laboratories,
3-9-11 Midori-cho Musashino-shi Tokyo 180-8585 Japan
Phone: +81 422 59 3323
Fax: +81 422 59 3765
Email: shimizu@ntt-20.ecl.net
Email: sato@ingrid.core.ntt.co.jp
Email: murakami@ntt-20.ecl.net
14. Full Copyright Statement
"Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
Shimizu, Sato & Murakami [Page 17]
INTERNET-DRAFT July 1999
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Shimizu, Sato & Murakami [Page 18]