Network Working Group S. Shimizu INTERNET-DRAFT S. Sato K. Murakami July 1999 MAPOS Automatic Switch-address Assignment Protocol (ASAP) Option (draft-shimizu-mapos-asap-00.txt) 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 . 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]