INTERNET-DRAFT T. Ogura Expires: March 2003 M. Maruyama NTT Laboratories T. Yoshida Werk Mikro Systems September 2002 A MAPOS NSP (Node Switch Protocol) Multicast Expansion - 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 expansion of the MAPOS NSP (Node Switch Protocol). MAPOS is a multiple access protocol for transmission 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. Other than the same function as NSP, NSP+ has an additional function to reduce unnecessary multicast frame transmission on MAPOS switches. In NSP+, a node can send a list of multicast HDLC addresses to a directly connected switch to notify that, in the case of multicasting, the Ogura, et al. Expires March 2003 [Page 1] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 node needs to receive only those frames whose destination addresses are included in the list. This enables the switch to forward only required multicast frames to directly connected nodes and reduce unnecessary bandwidth consumption. 1. Introduction MAPOS [1][2], Multiple Access Protocol over SONET (Synchronous Optical Network) [3] / SDH (Synchronous Digital Hierarchy) [4], is a link layer protocol for transmission of HDLC frames over SONET/SDH. In MAPOS, HDLC frames are switched according to their destination addresses and eventually delivered to the destination network interfaces of nodes. 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. Here, the term "nodes" means components other than switches in MAPOS networks; which are usually hosts or IP routers. In addition, the term "multicast address" does not include the broadcast address, i.e. HDLC addresses whose MSBs are 1 [1][2] except for the broadcast address. These multicast addresses are derived from IP multicast group addresses using the method described in [1][2]. Even though they are based on IP multicast group addresses, the multicast destination addresses should be used in link layer switching to save network resources. Namely, it is preferable for switches to forward multicast frames only to ports to which they really need to be forwarded, instead of flooding all ports with them. However, conventional specifications regarding MAPOS do not specify the method of determining such ports from a multicast destination address. Thus, there is no other way than for switches to flood all ports with multicast frames and this leads to serious bandwidth consumption. This document describes NSP+, an expansion of NSP [5], which have been designed with a function to reduce bandwidth consumption related to multicasting. NSP+ is almost the same protocol as NSP except that it enables nodes to send a list of multicast HDLC addresses to a directly connected switch to notify it that, in the case of multicasting, they only need to receive those frames whose destination addresses are included on the list. According to the list, the switch can forward only required multicast frames to directly connected nodes. Here, NSP+ does not have any function to restrain multicast traffic between switches. Other than NSP+, some methods such as IGMP Snooping [6] and CGMP Ogura, et al. Expires March 2003 [Page 2] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 (Cisco Group Management Protocol) [6] have been proposed to achieve the same link-layer multicast traffic restrictions between a switch and nodes. In IGMP Snooping, a link layer switch must have equipment which enables itself to refer to the layer 3 information of IP multicast packets in order to distinguish IGMP packets from others without degrading the transmission. In CGMP, IP routers must transform IGMP messages from nodes (such as IGMP membership report and IGMP leave) into CGMP messages and then send them to a link layer switch. NSP+, however, is simple in that layer 3 information is not required, and in the case of multicast traffic restrictions, it only uses messages from nodes to a switch. 2. NSP+ 2.1 Protocol overview Basically, NSP+ is a protocol which enables HDLC addresses to be automatically assigned to each network interface of a node connected to a switch similar to NSP. Namely, as described in [5], when the network interface of a node is connected to a switch, it sends an address request frame to the switch. In reply to that, the switch sends an address assignment frame to the network interface of the node. NSP+ differs from NSP in that a multicast option field is added to the address request frame. The multicast option field is a list of multicast HDLC addresses. Each of the addresses is derived from IP multicast group addresses, to which the network interface of the node sending the address request belongs. The network interface sends the address request to a directly connected switch to enable the switch to forward multicast frames with these multicast HDLC addresses to itself. (A node can send such a list of multicast HDLC addresses because its operating system (OS) usually maintains various kinds of data structures on each network interface to hold the set of multicast link layer addresses, each of which may be the destination address of a multicast frame that the network interface needs to receive.) On receiving an address request with a multicast option field, the switch configures its route tables, which consist of information about which ports incoming frames should be forwarded to, in order to forward only required multicast frames to directly connected nodes. 2.2 Example Figure 1 shows an example where the network interface of node N1 connected to switch S1 is a member of IP multicast group G1 and G2, and the network interface of N2 connected to S1 is a member of IP Ogura, et al. Expires March 2003 [Page 3] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 multicast group G1 and G3. Here, G1' stands for a multicast HDLC address derived from an IP multicast group address which corresponds to G1, and the notation "m_option(G1', G2')" stands for a multicast option field which includes multicast HDLC addresses G1' and G2'. After joining their multicast groups, N1 and N2 send address request frames with multicast option fields through their appropriate network interfaces. In this example, N1 and N2 send address requests with multicast options m_option(G1', G2'), m_option(G1', G3') respectively through their interface connected to S1. On receiving the address requests, switch S1 sends back address assignment frames to assign HDLC addresses to the network interfaces in the same way NSP does. In NSP+, S1 configures its route tables so that it forwards incoming frames with destination address G1' to N1 and N2 (Figure 2 (a)), frames with destination address G2' only to N1 (Figure 2 (b)), and frames with destination address G3' only to N2 (Figure 2 (c)). In addition, it also configures its route tables not to forward multicast frames with a destination address other than G1', G2', and G3' to N1 or N2 (Figure 2 (d)). Here, care should be taken because of the fact that NSP+ does not have any function to restrain multicast traffic between switches. Therefore, the examples in Figure 2 are based on the assumption that multicast frames are always transferred between S1 and S2. ---------+ | Address request | with m_option(G1',G2') | ---------------> | +------+ +---+----+ +--------+ | node +--------------------+ switch +----------+ switch | | N1 | <--------------- | S1 | | S2 | +------+ address assignment | | | | +---+----+ +--------+ | Address request | with m_option(G1',G3') | ---------------> | +------+ | | node +------------------------+ | N2 | <--------------- +------+ address assignment Figure 1 NSP+ address requests. Ogura, et al. Expires March 2003 [Page 4] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 HDLC frames with a destination address G1' -------> ---------+ | | | +------+ +---+----+ +--------+ | node +--------------------+ switch +----------+ switch | | N1 | <--------------- | S1 | -------> | S2 | +------+ Forwarded | | Forwarded| | +---+----+ +--------+ | | +------+ | | node +------------------------+ | N2 | <-------------- +------+ Forwarded Figure 2 (a) Multicast frame transmission under NSP+. HDLC frames with a destination address G2' -------> ---------+ | | | +------+ +---+----+ +--------+ | node +--------------------+ switch +----------+ switch | | N1 | <--------------- | S1 | -------> | S2 | +------+ Forwarded | | Forwarded| | +---+----+ +--------+ | | +------+ | | node +------------------------+ | N2 | +------+ Figure 2 (b) Multicast frame transmission under NSP+. Ogura, et al. Expires March 2003 [Page 5] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 HDLC frames with a destination address G3' -------> ---------+ | | | +------+ +---+----+ +--------+ | node +--------------------+ switch +----------+ switch | | N1 | | S1 | -------> | S2 | +------+ | | Forwarded| | +---+----+ +--------+ | | | +------+ | | node +------------------------+ | N2 | <--------------- +------+ Forwarded Figure 2 (c) Multicast frame transmission under NSP+. HDLC frames with a destination address other than G1', G2', and G3'. -------> ---------+ | | | +------+ +---+----+ +--------+ | node +--------------------+ switch +----------+ switch | | N1 | | S1 |--------> | S2 | +------+ | |Forwarded | | +---+----+ +--------+ | | +------+ | | node +------------------------+ | N2 | +------+ Figure 2 (d) Multicast frame transmission under NSP+. 2.3 Frame Format Ogura, et al. Expires March 2003 [Page 6] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 The frame format of NSP+ is almost the same as NSP. Namely, the HDLC protocol field of an NSP+ frame contains 0xFE03 (hexadecimal) [7] similar to NSP, and the HDLC information field contains a 32-bit command field and a 32-bit address field which are the same as for NSP [5]. The only difference between NSP and NSP+ is the multicast option field which is added to the NSP+ address request command. The details of the multicast option field are described later. Figure 3 shows the NSP+ frame format. +------------+------------+ | command | address | +------------+------------+ |<- 32 bit ->|<- 32 bit ->| Figure 3 NSP+ frame format. The command field is 32 bits long and has the following values (in decimal); 1 address request 2 address assignment 3 reject (error) The length of the address field is 32 bits. In address request frames, the NSP 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 byte of the field and the rest of the field is padded with zeroes. For MAPOS16, the assigned 16-bit address is placed in the least significant bytes of the 32-bit address 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 command (the value is 3). The value of the address field is undefined. In NSP+, when the value of the command filed is 1 (address request) and the address field is filled with zeros, the multicast option field follows the address field as Figure 4 shows. That is the only difference from NSP. The length of the multicast option field is variable. Ogura, et al. Expires March 2003 [Page 7] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 +------------+------------+--------------------------+ | command | address | multicast option field | +------------+------------+--------------------------+ |<- 32 bit ->|<- 32 bit ->| Figure 4 NSP+ frame format (address request). Figure 5 has the format for the multicast option field. It can include multicast HDLC addresses. In this field, a node stores all the multicast HDLC addresses, each of which may be the destination address of a multicast frame it needs to receive through a network interface, then sends an address request with the multicast option field through the network interface. +----------+----------+-----------+-----------+-----------+--- | Code | Form | Length | Address | Address |... +----------+----------+-----------+-----------+-----------+--- |<-8 bits->|<-8 bits->|<-16 bits->|<-32 bits->|<-32 bits->| Figure 5 Multicast option field format. The code field is 8 bits long and has the following values (decimal). 1 (For future use) 2 Multicast Value 1 is reserved for future use. Value 2 indicates that the multicast option field includes multicast addresses, each of which corresponds to an IP multicast group address. The form field is 8 bits long and has the following values (decimal). 1 MAPOS Version 1 2 MAPOS 16 The length field is 16 bits long and shows the length of the option field in units of 1 octet. The address fields include multicast HDLC addresses. Each of the address field is 32 bits long. In MAPOS Version 1, the 8-bit multicast group 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, the 16-bit multicast group address is placed in the least significant octets of the 32-bit address field and the rest of the field is padded with zeros. Ogura, et al. Expires March 2003 [Page 8] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 2.4 Behavior of nodes and switches 2.4.1 Behavior of nodes A node must use the multicast option field under the following rules. 1) There are two types of IP multicast group addresses, The first type is group addresses to which all the network interfaces of a node start to belong at system initialization. 224.0.0.1 (all hosts) and 224.0.0.2 (all routers) are examples of this type. The other type is group addresses to which a network interface starts to belong at the request of application software. Regardless of this, a node must store all the multicast HDLC addresses, each of which may be the destination address of a multicast frame the node needs to receive in the multicast option field, then it must send the address request to a directly connected switch. 2) 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 field through the network interface , i.e. an address request which consists of only the command field and the address field. For example, IP routers may use this because they need to receive all IP multicast packets regardless of their destination addresses. In addition, this rule defines the outcome of cases where a node which supports only NSP is connected to a switch. According to this rule, the node receives all multicast frames regardless of their destination addresses. 3) 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 field without an address field through the network interface, i.e. a multicast option field with the value of its length field being 4. 4) 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 HDLC addresses included in the multicast option field of the latest address request sent from the network interface. It does not depend on the history of address requests from the network interface. Thus, whenever a node sends an address request, it must store all the multicast HDLC addresses, each of which may be the destination address of a multicast frame the node needs to receive in a multicast option field. Ogura, et al. Expires March 2003 [Page 9] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 2.4.2 Behavior of switches When a switch receives an address request, it must configure its route tables according to the following. 1) When a switch receives an address request with a multicast option field which includes multicast HDLC addresses from the network interface of a node, it must configure its route tables so that for multicast frame transfer, it forwards to the network interface only multicast frames whose destination addresses are the same as one of the multicast HDLC addresses included in the multicast option field. 2) When a switch receives an address request without a multicast option field from the network interface of a node, it must configure its route tables so that it forwards all multicast frames to the network interface regardless of their destination addresses. 3) When a switch receives an address request with a multicast option field which does not have an address field from the network interface of a node, it must configure its route tables so that it does not forward any multicast frames to the network interface. This document does not provide any specifications for transferring multicast frames between switches. 2.5 When to issue NSP+ frames The NSP+ frames are basically issued on the same events as those for NSP. These are described in [5] as follows. 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. 2) If the node has not yet been assigned an HDLC 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. 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. 4) In addition to 3), a node must verify its address by sending address request frames every 30 seconds. The switch regards these Ogura, et al. Expires March 2003 [Page 10] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 as keep-alive frames and utilizes them to detect the node's status. If it does not receive a request frame for more than 90 seconds, it assumes that the node went down. In addition to the above, an NSP+ address request frame should be issued under the following conditions. 5) When application software running on a node joins new IP multicast groups or leaves some IP multicast groups, an address request frame should be issued. Here, its multicast option field must contain the new set of multicast HDLC addresses, each of which may be the destination address of the multicast frame the node needs to receive. 2.6 Point-to-point/loop-back connection 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 for NSP+, a node is assigned an address 0x03 (MAPOS Version 1) or 0x0003 (MAPOS 16) in the same way as NSP. The multicast option field of an address request frame is ignored. 3. Security Considerations Security issues are not discussed in this memo. 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. Ogura, et al. Expires March 2003 [Page 11] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 [6] "Multicast in a Campus Network: CGMP and IGMP Snooping," http://www.cisco.com/warp/public/473/22.pdf [7] Murakami, K. and M. Maruyama, "MAPOS Version 1 Assigned Numbers," RFC-2172, June 1997. 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 4. Full Copyright Statement "Copyright (C) The Internet Society (2002). 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 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 Ogura, et al. Expires March 2003 [Page 12] INTERNET-DRAFT draft-ogura-mapos-nsp-multiexp-00.txt September 2002 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 March 2003 [Page 13]