INTERNET-DRAFT T. Ogura Expires: December 2003 M. Maruyama NTT Laboratories T. Yoshida Werk Mikro Systems June 2003 A Multicast Extension to MAPOS NSP (Node Switch Protocol) - NSP+ Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html 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 and . Abstract This document describes NSP+, an extension of the MAPOS NSP (Node Switch Protocol). MAPOS is a multiple access protocol for transmitting of network-protocol datagrams, encapsulated in High- Level Data Link Control (HDLC) frames, over SONET/SDH. NSP is a protocol for automatically assigning MAPOS node addresses. The NSP+ extension enables the nodes to provide their directly connected switch with information about the multicast groups to which they belong, so the switch forwards only required multicast frames to the nodes. Ogura, et al. Expires December 2003 [Page 1] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 1. Introduction MAPOS [1][2] (Multiple Access Protocol over SONET/SDH [3][4]), is a link-layer protocol for transmitting of HDLC frames over SONET/SDH. In MAPOS, HDLC frames are switched according to their destination addresses (MAPOS addresses) and eventually delivered to the destination network interfaces of nodes. (In the remainder of this document, the term "MAPOS" is used unless the distinction between MAPOS version 1 [1] and MAPOS 16 [2] is required.) In addition to unicasting, MAPOS also supports multicasting. Namely, the destination address field of an HDLC frame can include a multicast address which indicates that the frame must be delivered to one or more network interfaces of nodes. Conventionally, even when an optimized multicast transmission tree had been built in the network layer (layer 3), MAPOS switches forwarded multicast frames to all ports regardless of their destination addresses because there were no specifications to restrict unnecessary multicast-frame transmission in MAPOS. However, it is preferable for the switches to forward multicast frames only to ports to which the frames really need to be forwarded, instead of flooding all ports with them. This document describes NSP+, which eliminates unnecessary multicast- frame transmission between a MAPOS switch and its directly connected nodes. Similar to NSP [5], NSP+ is a protocol which enables MAPOS addresses to be automatically assigned to each network interface of nodes. In addition to that, NSP+ enables nodes to provide their directly connected switch with information about the multicast groups to which they belong, so the switch forwards only required multicast frames to the nodes. NSP+ does not control the transmission of unicast frames and broadcast frames, or multicast-frame transmission between switches. 2. NSP+ 2.1 Overview Similar to NSP, NSP+ provides an automatic node address assignment function in MAPOS. It saves the administrative burden of address configuration for each network interface of nodes and prevents trouble such as address inconsistency and collision. Here, the term "node" means components other than switches in MAPOS networks; nodes are usually hosts or IP routers. When a node is connected to a switch and receives a SONET signal correctly, the node sends an address request frame to the control processor in the switch; the destination address of this frame is Ogura, et al. Expires December 2003 [Page 2] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 0x01 (MAPOS version 1) [1] or 0x0001 (MAPOS 16) [2]. NSP+ differs from NSP in that it enables nodes to provide their directly connected switch with information about the multicast groups to which they belong. For that purpose, a multicast option can be added to the address request frame. The multicast option includes a complete set of multicast MAPOS addresses derived from all the network-layer multicast group addresses to which the network interface of the node belongs. When the switch receives the address request frame, it replies with an address assignment frame. The address assignment frame is exactly the same as that of NSP, i.e., it includes the assigned MAPOS address, and its destination is the assigned address [5]. The address assigned to the network interface of the node is decided in the same way as in NSP, i.e., the address consists of the switch number and the port number of the switch to which the network interface of the node is connected [5]. Other than address assignment, the switch configures its frame forwarding table so that in the case of multicasting, it forwards to the network interface only multicast frames whose destination addresses are the same as one of the multicast MAPOS addresses included in the multicast option. NSP+ does not influence the configuration of the frame forwarding table relevant to the transmission of unicast frames and broadcast frames, or multicast- frame transmission between switches. 2.2 Behavior of nodes A node must generate a multicast option and send address request frames as described below. (a) Generating multicast MAPOS addresses Each multicast MAPOS address included in a multicast option is generated from a network-layer multicast group address in the way that each " over MAPOS" specification describes. For example, in the case of IPv4 over MAPOS version 1 [6], the MSB and LSB of the MAPOS address are set to 1, then the remaining six bits of the MAPOS address must contain the lowest-order six bits of the IP multicast group address [7]. (Here, the term "multicast" does not include broadcast. A multicast option must not include the broadcast MAPOS address.) In the case of IP, there are two types of IP multicast group addresses. The first is group addresses to which all the network interfaces of nodes belong since the system initialization such as 224.0.0.1 (all hosts) or 224.0.0.2 (all routers) [8]. The other is Ogura, et al. Expires December 2003 [Page 3] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 group addresses which a network interface joins or leaves at the request of application software. Regardless of that, corresponding multicast MAPOS addresses must be included in the multicast option if necessary. (b) Configuring a multicast option (b.1) The set of destination addresses of multicast frames that a node can receive through a network interface is exactly the same as the set of multicast MAPOS addresses included in the multicast option of the latest address request frame sent from the network interface. (If the latest address request frame does not have a multicast option, the node can receive all multicast frames regardless of their destination addresses. See (b.3).) Therefore, whenever a node sends an address request frame with a multicast option, the multicast option must contain a complete set of multicast MAPOS addresses derived from all the network-layer multicast group addresses to which the network interface of the node belongs. A node can join or leave network-layer multicast groups by sending a new address request with the new complete set of multicast MAPOS addresses. (b.2) There is no limit on the number of addresses in a multicast option. In other words, even all the multicast MAPOS addresses in the MAPOS address space can be included together in a multicast option. This number is 64 (the sixth power of two) in the case of MAPOS version 1, and 8192 (the thirteenth power of two) in the case of MAPOS 16. As described in section 3, each of multicast MAPOS address is stored in a 32-bit wide field in a multicast option. Therefore, in the case of MAPOS 16, 32,768 octets are required to store all the multicast MAPOS addresses (8192 addresses) in a multicast option. Even an address request frame with the multicast option can be stored in a MAPOS frame because the maximum length of the information field of a MAPOS frame, in which an address request is stored, is 65,280 octets. However, if an implementation allows a smaller MTU than that, cases where the length of an address request frame exceeds the MTU are not improbable. Such an address request cannot be transmitted because there is no function for dividing an address request frame into multiple MAPOS frames in NSP+ just as in NSP. System administrators are responsible for fixing an appropriate MTU that can prevent it in their use. Ogura, et al. Expires December 2003 [Page 4] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 (b.3) When a node needs to receive all multicast frames regardless of their destination addresses through a network interface, it must send an address request without the multicast option through the network interface, i.e. an address request which consists of only the command field and the address field. (See Figure 1 in section 3.) For example, this rule defines the outcome of cases where a node which supports only conventional NSP is connected to a switch. According to this rule, the node receives all multicast frames regardless of their destination addresses. (b.4) When a node does not need to receive any multicast frames through a network interface, it must send an address request with a multicast option with no address fields through the network interface, i.e. a multicast option consisting of code, form, and length field. (See Figure 3 in section 3.) In this case, the value of the length field is 4. In the case of IP, this is an exceptional case because a node's network interface which supports IP multicasting usually belongs to multicast groups 224.0.0.1 (all hosts) or 224.0.0.2 (all routers). (c) When to issue an address request The NSP+ frames are basically issued on the same events as those for NSP. These are described in [5] as follows. (c.1) When a node is connected to a switch and receives a SONET signal, it sends an address request frame to a switch directly connected to itself. When the switch receives the frame, it replies with an address assignment frame. (c.2) If the node has not yet been assigned a MAPOS address and it does not receive the address assignment frame within 5 seconds, it continues to transmit address request frames until the node receives the address assignment frame. (c.3) Whenever a node detects a transmission error such as carrier loss or out-of-synchronization, it should send an address request frame to the switch and verify its current address. (c.4) In addition to (c.3), a node must verify its address by sending address request frames every 30 seconds. The switch regards these as keep-alive frames and utilizes them to detect the node's status. If the switch does not receive an address request frame for more than 90 seconds, it assumes that the Ogura, et al. Expires December 2003 [Page 5] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 node went down. In addition to the above, an NSP+ address request frame should be issued under the following conditions. (c.5) When application software running on a node joins or leaves network-layer multicast groups, an address request frame should be issued. Here, its multicast option must contain the new complete set of multicast MAPOS addresses, each of which may be the destination address of the multicast frame the node needs to receive. 2.3 Behavior of switches A switch compliant with NSP+ must obey the followings when it receives an address request frame from a directly connected node: 1) A switch must configure its frame forwarding table so that multicast MAPOS frames are transmitted to the node as described in (b.1), (b.3), and (b.4) in section 2.2. (The configuration of the frame forwarding table relevant to the transmission of unicast frames and broadcast frames, or multicast-frame transmission between switches must not be influenced by NSP+.) 2) A switch assigns a MAPOS address to the network interface that issued the address request in the same way as in NSP, then replies with an address assignment frame. This address assignment frame is exactly the same as that of NSP. When the switch cannot assign the address for some reason, it replies with a reject frame. The order of the above is not specified. Furthermore, the behavior of a switch only supports NSP when receiving an NSP+ address request frame is not defined. 2.4 Consideration for special cases There are two special cases to consider as described in [5]. The first is point-to-point connection without a switch. The other is loop-back, that is, direct connection between the input and output of the same port. In the above cases, a network interface is assigned an address 0x03 (MAPOS version 1) or 0x0003 (MAPOS 16) in the same way as in NSP. The multicast option of an address request frame is ignored. Ogura, et al. Expires December 2003 [Page 6] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 3. Frame Format The HDLC frame for NSP+ is almost the same as that of NSP. Namely, the HDLC protocol field of an NSP+ frame contains 0xFE03 (hexadecimal) similar to NSP [9], and the HDLC information field contains a 32-bit command field and a 32-bit address field shown in Figure 1, which are the same as those of NSP [5]. +-------------+-------------+ | Command | Address | +-------------+-------------+ |<- 32 bits ->|<- 32 bits ->| Figure 1. Content of the HDLC information field of an NSP+ frame. The details of the fields are as follows: Command 1 - address request 2 - address assignment 3 - reject (error) Address In address request frames, the address field should be filled with zeroes, although the switch ignores this. In address assignment frames, in the case of MAPOS version 1, the assigned 8-bit address is placed in the least significant octet of the field and the rest of the field is padded with zeroes. In the case of MAPOS 16, the assigned 16-bit address is placed in the least significant octets of the field and the rest of the field is padded with zeros. When the switch cannot assign the address for some reason, the switch replies with a reject frame (the value of the command field is 3). The value of its address field is undefined. In NSP+, differently from NSP, when the value of the command field is 1 (address request) and the address field is filled with zeros, a multicast option can be added as shown in Figure 2. The length of the multicast option is variable. Ogura, et al. Expires December 2003 [Page 7] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 +-------------+-------------+------------------------+ | Command | Address | Multicast option | +-------------+-------------+------------------------+ |<- 32 bits ->|<- 32 bits ->| Figure 2. Content of the HDLC information field of an NSP+ frame with a multicast option. Figure 3 shows the details of the multicast option. The address fields store multicast MAPOS addresses derived from network-layer multicast group addresses to which a network interface of a node belongs. +----------+----------+-----------+-----------+-----------+--- | Code | Form | Length | Address | Address |... +----------+----------+-----------+-----------+-----------+--- |<-8 bits->|<-8 bits->|<-16 bits->|<-32 bits->|<-32 bits->| Figure 3. Multicast option format. The details of the fields are as follows: Code 1 - reserved for future use 2 - multicast (Indicates that the multicast option includes multicast MAPOS addresses.) Other values are not used. Form 1 - MAPOS version 1 2 - MAPOS 16 Length The length of the multicast option in units of 1 octet. Address Includes a multicast MAPOS address. In MAPOS version 1, an 8-bit multicast MAPOS address is placed in the least significant octet of the 32-bit address field and the rest of the field is padded with zeros. In MAPOS 16, a 16-bit multicast MAPOS address is placed in the least significant octets of the 32-bit address field and the rest of the field is padded with zeros. 4. Example Ogura, et al. Expires December 2003 [Page 8] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 Figure 4 shows an example. In Figure 4, MAPOS version 1 is assumed and the switch numbers are assumed to be two bits long. Node N1 is connected to port 0x3 of switch S1 and node N2 is connected to port 0x5 of the same switch. The switch is numbered 0x1 (01 in binary). The network interface of node N1 is a member of IP multicast groups G1 and G2, and that of N2 is a member of IP multicast groups G1 and G3. Here, G1 stands for an IP multicast group address and G1' stands for a multicast MAPOS address derived from G1; the same applies to the others. In addition, the notation "m_option (G1', G2')" stands for a multicast option which includes multicast MAPOS addresses G1' and G2'. After joining their multicast groups, N1 and N2 send address request frames (AddrReq) with multicast option to the control processor in S1 through their network interfaces. Specifically, N1 and N2 send address request frames with multicast options m_option(G1', G2') and m_option(G1', G3') respectively, and the destination of the address request frames is 0x01 (the control processor in the local switch S1). On receiving the address request frames, S1 sends back address assignment frames (AddrAssign) to assign MAPOS addresses to the network interfaces in the same way NSP does, i.e., their form is "0 1" [5]. In this case, the address assigned to N1 is 0 + 01 + 00011, that is, 00100011 (0x23), and the address assigned to N2 is 00100101 (0x25). The address assignment frames include these addresses, and their destinations are 0x23 and 0x25, respectively. In addition, S1 configures its frame forwarding table so that it forwards incoming frames with destination address G1' to N1 and N2, frames with destination address G2' only to N1, and frames with destination address G3' only to N2. It also ensures that any multicast frames with destination addresses other than G1', G2', and G3' are not forwarded to N1 or N2. Care should be taken that NSP+ does not influence multicast-frame transmission between switches. Usually in MAPOS, all multicast frames are transmitted between S1 and S2. Ogura, et al. Expires December 2003 [Page 9] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 ---------+ | AddrReq with | m_option (G1',G2') | ---------------> |0x9 +------+ +---+----+ +--------+ | node +--------------------+ switch +----------+ switch | | N1 | <------------ 0x3 | S1 |0x7 | S2 | +------+ AddrAssign | 0x1 | | | 00100011 (0x23) +---+----+ +--------+ | 0x5 | AddrReq with | m_option (G1',G3') | ---------------> | +------+ | | node +------------------------+ | N2 | <--------------- +------+ AddrAssign 00100101 (0x25) Figure 4. An example of NSP+. 5. Security Considerations Security issues are not discussed in this memo. 6. References [1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol over SONET/SDH, Version 1," RFC-2171, June 1997. [2] Murakami, K. and M. Maruyama, "MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing," RFC2175, June 1997. [3] American National Standards Institute, "Synchronous Optical Network (SONET) - Basic Description Including Multiplex Structure, Rates and Formats," ANSI T1.105-1995. [4] ITU-T Recommendation G.707, "Network Node Interface for the Synchronous Digital Hierarchy (SDH)," 10/2000. [5] Maruyama, M. and K. Murakami, "A MAPOS Version 1 Extension - Node Switch Protocol," RFC-2173, June 1997. [6] Murakami, K. and M. Maruyama, "IPv4 over MAPOS Version 1," Ogura, et al. Expires December 2003 [Page 10] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 RFC-2176, June 1997. [7] Deering, S., "Host Extensions for IP Multicasting," RFC-1112, August 1989. [8] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS," RFC-1700, October 1994. [9] Murakami, K. and M. Maruyama, "MAPOS Version 1 Assigned Numbers," RFC-2172, June 1997. 7. Authors' Address Tsuyoshi Ogura NTT Network Innovation Laboratories 3-9-11, Midori-cho Musashino-shi Tokyo 180-8585, Japan E-mail: ogura@core.ecl.net Mitsuru Maruyama NTT Software Laboratories 3-9-11, Midori-cho Musashino-shi Tokyo 180-9595, Japan E-mail: mitsuru@core.ecl.net Toshiaki Yoshida Werk Mikro Systems 250-1, Mikajiri Kumagaya Saitama 360-0843, Japan E-mail: yoshida@tera.core.ecl.net 8. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 procedures for Ogura, et al. Expires December 2003 [Page 11] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-01.txt June 2003 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. Ogura, et al. Expires December 2003 [Page 12]