INTERNET DRAFT FUJIKAWA Kenji draft-fujikawa-plasma-00.txt Kyoto University March 1997 Point-to-point Link Assembly for Simple Multiple Access (PLASMA) Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes PLASMA, which enables a simple multicast mechanism and autoconfiguration in an IP subnet consisting of point- to-point links, such as ATM, Frame Relay, SONET/SDH, etc. PLASMA utilizes an L2 label switching mechanism and creates data flow paths in a subnet using the PLASMA protocol. The PLASMA protocol is very simply defined and works effectively within a single IP subnet. PLASMA applications to ATM and PPP are also described. FUJIKAWA Kenji Expires on September 16, 1996 [Page 1]
INTERNET DRAFT PLASMA March 1996 1. Introduction A network that is configured assembling several point-to-point links, such as ATM, Frame Relay or SONET/SDH. is generally not capable of a native multicast mechanism. Here the term ``native multicast mechanism'' refers to one that implements multicasting without requesting each sender to know the receivers, nor requesting each receiver to know the senders. However, if such a network is configured as a single IP subnet given ability of the native multicast mechanism, IP multicasting[1] and autoconfiguration of an IP subnet are simply implemented over it. This document describes the method called Point-to-point Link Assembly for Simple Multiple Access (PLASMA), and the PLASMA Protocol (PLASMAP). PLASMA requires that each datagram (cell in the case of ATM) places some kind of layer 2 labels (L2 labels) and that each node has the capability of L2 label switching. PLASMA provides a simple mechanism of multiple access in a single IP subnet by utilizing those functions. Therefore, an IP subnet based on PLASMA is multicast-capable, and in addition, autoconfigurable. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective ``required,'' means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective ``recommended,'' means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective ``optional,'' means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. FUJIKAWA Kenji Expires on September 16, 1996 [Page 2]
INTERNET DRAFT PLASMA March 1996 2. Terminology node In a PLASMA network, there are nodes which are connected to each other via point-to-point links. A node is an entity that inter- prets PLASMAP and sets up links for multiple access. This has no concern with whether an entity receives and takes in datagrams towards itself or just receives and passes it. For example, a host or a router in a PLASMA network is obviously a node, and even an ATM switch is a node, if it executes PLASMAP. It should be noted that if an ATM switch provides only, for example, PVP, not executing PLASMAP, then it is considered as just a part of a link. peer The other end of the point-to-point link. layer 2 label (L2 label) A Layer 2 label (L2 label) is a label that is placed in a layer 2 frame. In the case of ATM, a pair of VPI/VCI fields of a cell is an L2 label, In the case of another network, where the Point-to- Point Protocol (PPP)[2] could be introduced, we describe how to place an L2 label in an L2 frame in a later section. L2 label switching L2 label switching architecture detects the destination(s) of an L2 frame from its L2 label, and forwards the L2 frame to the destination(s) at a high speed, alternating the value of the L2 label. interface and link Each node owns one or more interfaces, and each interface con- sists of one or more links. An interface is an object that is assigned an address (or several addresses in multihoming). Thus, some links possibly share the same address as a result of sharing the same interface. FUJIKAWA Kenji Expires on September 16, 1996 [Page 3]
INTERNET DRAFT PLASMA March 1996 3. PLASMA Mechanisms In this section, we describe the PLASMA mechanisms. 3.1. Features of PLASMA PLASMA provides a simple and straightforward multicast mechanism in a small non-multiple-access network comprising nodes and point-to-point links, such as ATM, Frame Relay or SONET/SDH. The term ``small net- work'' refers to a network that has a small number of nodes (about less than 300), not concerning whether it is a LAN, MAN or WAN. In a network based on PLASMA, every sender does not need to know which hosts are receivers, nor every receiver needs to know which hosts are senders. One PLASMA domain constructs just one multicast-capable IP subnet. PLASMA utilizes the L2 label switching architecture in a node. For example, in ATM, an L2 frame and its L2 label correspond to a cell and the VPI/VCI value of the cell respectively. Besides, ATM switches provide hardware-level L2 label switching architecture. For other point-to-point link networks, nodes can place L2 labels in PPP frames. This method is described in a later section. Data flow paths are created as a result of L2 label switching at the en route nodes. Each node employs the PLASMA Protocol (PLASMAP) which advertises L2 label switching information just in a single IP subnet. A PLASMA node does not have to be assigned its own identif- ier for processing PLASMAP when it is not an end in terms of data transportation on the layer 2. Therefore, PLASMA enables autoconfi- guration of IP subnets, that is, all users have to do is connect PLASMA nodes and turn them on. In a PLASMA network, where PLASMAP messages are exchanged, nodes can be connected in any topological manner. Of course, a PLASMA network is allowed to contain some loops, thus improves flexibility of net- work configuration. 3.2. PLASMAP Messages PLASMAP uses the following three types of messages: JOIN A node joins uni-/multicast addresses by sending a JOIN message to its peers. If a node sends a JOIN message that has no join addresses, then it is considered to join all the addresses used in the subnet. Such a JOIN message is especially called a JOIN- ALL message. FUJIKAWA Kenji Expires on September 16, 1996 [Page 4]
INTERNET DRAFT PLASMA March 1996 NOTIFY A node notifies its peers of a data flow requested by itself or by one of its upstream nodes by sending a NOTIFY message. Nodes deliver a NOTIFY message from an upstream node to downstream nodes along the data flow path represented by it. NOTIFY mes- sages are distinguished by a pair of a source address and a flow ID. ACCEPT A node accepts an requested date flow and notifies the L2 label value by sending an ACCEPT message, when it determines that the flow is needed for itself or for one of its downstream nodes. Each Node delivers an accept message from a downstream node to an upstream node. Table 1: Key fields of JOIN, NOTIFY and ACCEPT messages +-------+---------------------------------------------------------+ |Message| Key fields | +=======+=========================================================+ |JOIN | Join addresses | +-------+---------------------------------------------------------+ |NOTIFY | Source address, Flow ID, Hop count, Destination address,| | | Flowspec | +-------+---------------------------------------------------------+ |ACCEPT | Source address, Flow ID, L2 label | +-------+---------------------------------------------------------+ Table 1 shows the key fields of the PLASMAP messages. Nodes create a data flow path, in other words, begin to receive and/or to send the data when they are sending NOTIFY messages related to the data and receive related ACCEPT messages. If nodes are pure receivers, then they are not required to receive ACCEPT messages. A node that is not one of the ends makes use of L2 label switching fabric for forwarding the data. Nodes MUST send PLASMAP messages periodically. They expire a data flow path after a defined period of time for which they are not receiving related PLASMAP messages. Therefore, data flow paths in PLASMA has the nature of the ``soft-state.'' Each node is required to process NOTIFY, ACCEPT and JOIN-ALL mes- sages, and is recommended to process JOIN messages. If a node that cannot process JOIN messages receives JOIN messages, then it simply discards them. FUJIKAWA Kenji Expires on September 16, 1996 [Page 5]
INTERNET DRAFT PLASMA March 1996 3.3. Managing Join States by JOIN Messages Each node keeps a ``join state,'' which holds join addresses, for itself and for every point-to-point link it is attached to. A join state at a link is created and managed in accordance with the JOIN messages received from the link. A node that cannot send JOIN messages is required to send at least a JOIN-ALL message to its peers. From a different point of view, this implies that a node can send a JOIN-ALL message to any peer at any time instead of sending a JOIN message. The join addresses placed in a JOIN message that is to be transmitted from one link, are determined from the join states of the node and at the other links. That is, the join addresses are the merged ones of the node and at the other links. If a join state at another link holds all addresses (this means that this interface is receiving a JOIN-ALL message), a JOIN-ALL message is sent from the link. (Join D) +--------*[N4] | D (Join D) (Join A,B) [N1]*------*[N2]ABCD---*[N5]AB------*[N7] * * BC | | | | * | (Join B,C) +--------*[N3] +---------*[N8] A | (Join A) +--------*[N6] N1, N2, N3...N8 : Node A, B, C and D : Address * : All addresses (Join A,B) : N7 joins A and B [N7] [N5]AB-- : N5 has a join state of A and B at this link Figure 1: Managing join states Figure 1 shows example join states in a PLASMA network. In this net- work, for instance, Node N5 joins Address D, and is receiving a JOIN-ALL message, a JOIN message of Address A and B and a JOIN mes- sage of Address B and C from Node N2, N7 and N8 respectively. As a FUJIKAWA Kenji Expires on September 16, 1996 [Page 6]
INTERNET DRAFT PLASMA March 1996 result, Node N5 has the join states shown in the figure, each of which corresponds to one of the receiving JOIN messages, and is send- ing a JOIN message of Address A, B, C and D to Node N2 and a JOIN-ALL message to Node N7 and N8. There is a case where some of the join states of all addresses (*) become join states of Address A, B, C and D. Assuming that the link between Node N1 and N3 breaks, and resumes after some period of time, such a case will occur. Even in this case, PLASMAP works correctly and makes the state converge to the one illustrated in the figure in time. PLASMAP simply supports this function as follows; when a node receives the same NOTIFY messages from different links, it makes join states at those links to hold all addresses (*). This function avoids loops of redundant JOIN messages. 3.4. Creating Data Flow Paths by NOTIFY and ACCEPT Messages When a node wants to send data to a certain uni-/multicast address, it sends basically a NOTIFY message to all the peers. Then, the NOTIFY message is flooded within the subnet. It should be noticed that flooded messages are not data but signaling messages, thus the load on flooding does not become so large. Besides, the flooding policy achieves simple QoS routing. A NOTIFY message is transmitted along the following procedures: 1. When a node receives a NOTIFY message, or when it is an origina- tor of the message, it goes to the next stage. 2. The node checks whether the same NOTIFY message has come from another link recently. If the same NOTIFY message that has a smaller or equal hop count has already come, then the node dis- cards the new NOTIFY message. 3. The node sends the NOTIFY message, incrementing the hop count, to a peer beyond every link that holds a join state of all addresses or the destination address. A node sends an ACCEPT message to the peer that sends a related NOTIFY message to it when it joins the destination address placed in the NOTIFY message or it receives a related ACCEPT message from a downstream node. FUJIKAWA Kenji Expires on September 16, 1996 [Page 7]
INTERNET DRAFT PLASMA March 1996 (Join D) +--------*[N4] (discarded) | -----> D -----> (Join D) (Join A,B) [N1]*------*[N2]ABCD---*[N5]AB------*[N7] * * ^ BC -----> | | | | | <----- * | | ----->(Join B,C) +--------*[N3] +---------*[N8] A | <----- (Join A) +--------*[N6] (Notify B) (a) Sending a NOTIFY message (Join D) +--------*[N4] | D <----- (Join D) (Join A,B) [N1]*------*[N2]ABCD---*[N5]AB------*[N7] * * | BC <----- | | | | | * V | <-----(Join B,C) +--------*[N3] +---------*[N8] A | -----> (Join A) +--------*[N6] (Notify B) (b) Sending ACCEPT messages Figure 2: Creating data flow path by NOTIFY and ACCEPT messages Figure 2(a) shows an example network, where Node N7 and N8 joins Address B and N6 is sending a NOTIFY message so that it can send data to Address B. The NOTIFY message is delivered finally to Node N7 and N8 according to the above mentioned procedures. Discarding the NOTIFY message from N1 to N2 avoids creating a loop of the NOTIFY message. Consequently, the ACCEPT messages are delivered as shown in Figure 2(b), and the data flow path is created along the reverse path of the ACCEPT messages. 3.5. Connecting PLASMA Networks via Routers PLASMA routers, which are PLASMA nodes as well, reside on IP subnet boundaries as the conventional routers. Each router is set up to FUJIKAWA Kenji Expires on September 16, 1996 [Page 8]
INTERNET DRAFT PLASMA March 1996 manage sets of point-to-point links as one interface belonging to a specified subnet. PLASMA routers prevent forwarding PLASMAP messages from one subnet to another. Thus, PLASMAP is terminated at routers and is valid only in a single subnet. This also implies that routers usually forward data from one subnet to another in the conventional packet forwarding, not in L2 label switching. The way to make use of L2 label switching across subnet boundaries are discussed in the next section. +--------[N2] | [N1]-------[N3] | Subnet S1 | +-----[N4] | | =====[Router]======== Subnet boundary | | | +-----[N6] | Subnet S2 [N5]-------[N7] | +--------[N8] Figure 3: Router separates PLASMA subnets In the network pictured in Figure 3, nodes from N1 to N4 and Router exchange PLASMAP within Subnet S1, while nodes from N5 to N8 and Router do within Subnet S2. However, for example, PLASMAP messages from N4 are never forwarded to N6. Furthermore, connecting N4 to N6 with a point-to-point link is not allowed because this destroys the PLASMAP schemes. FUJIKAWA Kenji Expires on September 16, 1996 [Page 9]
INTERNET DRAFT PLASMA March 1996 4. QoS Assurance in PLASMA PLASMA suits to assuring Quality of Service (QoS) of data flows since it can distinguish data flows just by their L2 labels. In this sec- tion, we describe how to utilize RSVP in PLASMA to gurantee QoS. 4.1. Introducing RSVP for QoS Specified Data Flows We incorporate RSVP[3] as a data flow setup protocol for PLASMA net- works to guarantee QoS. PLASMA supports a straightforward multicast mechanism and RSVP is considered to manage IP multicasting, so they cooperate with each other and guarantee QoS in IP multicasting together. In PLASMA with RSVP, QoS-specified transportation is implemented by utilizing an independent data flow path for each service, while non- QoS-specified transportation, i.e. best-effort transportation, is supported with a shared data flow path. Thus, PLASMA assign an independent data flow path to each RSVP flow. The nodes on the way arrange a queue for the data flow, distinguish the data by the L2 label, and queue it in a dedicated queue. 4.2. Extension of LIH Field for QoS-assured Flows across Subnets As mentioned above, routers do not usually forward data in L2 label switching. However, a PLASMA router is recommended to detect the correspondence between an ingress QoS-specified data flow path in one subnet and an egress one in another subnet for the purpose of for- warding the data from the ingress to the egress in L2 label switch- ing. PLASMAP cannot make this detection possible by itself. Thus, we make use of the LIH field in the RSVP messages. Each RSVP sender transmits an RSVP PATH message, which is transferred on a non-QoS specified data flow path, placing the flow ID of a PLASMA data flow path in the LIH field. A router detects that the ingress RSVP flow corresponds to an ingress data flow path by the LIH field placed in the PATH message. Consequently, the router detects the correspondence between the ingress and egress data flow paths since it already knows the correspondence among the ingress PATH mes- sage, the egress PATH message and the egress data flow path. 5. Message Formats The message formats of PLASMAP will be determined in the next version of this draft. FUJIKAWA Kenji Expires on September 16, 1996 [Page 10]
INTERNET DRAFT PLASMA March 1996 6. PLASMA Applications 6.1. PLASMA Application to IP/ATM Networks The PLASMA mechanisms can be easily applied to IP/ATM networks. Nodes of PLASMA, L2 labels and data flow paths correspond to ATM hosts and switches, VPI/VCI values and VCs respectively. All the ATM hosts and switches in an IP/ATM subnet exchange PLASMAP messages with each other. The advantage of utilizing ATM is that ATM cell switch- ing fabric, which corresponds to L2 label switching, transmits data at a high speed with low delay and low jitter. In IP/ATM networks based on PLASMA, IP unicasting and multicasting are simply implemented by using IPv4 (or IPv6) uni-/multicast addresses as PLASMA addresses. Any servers like an ARP server, MARS, LECS, LES and/or BUS are not required. Therefore, PLASMA enables straightforward IP multicasting in IP/ATM networks without any kinds of servers. In addition, autoconfiguration of an IP/ATM subnet is provided since ATM switches do not need to have their own identif- iers. ATM supports four sorts of bit rate services, CBR, VBR, ABR and UBR. VCs of CBR and UBR are established for RSVP data flows and non-RSVP data flows over IP/ATM networks based on PLASMA as follows: o In transportation with RSVP, each process running on a host utilizes a QoS-assured VC for each RSVP flow. o In transportation without RSVP, multiple processes on the same host is obliged to share a UBR class VC, that is, share a non- QoS-assured VC. Cell switching routers (CSRs) are proposed in [4,5], which are routers that can forwards data in cell switching as well as in packet forwarding. Since this function equals to that of our PLASMA routers in IP/ATM networks, we introduce CSRs in IP/ATM networks based on PLASMA, and add the LIH extension to CSR's features. 6.2. PLASMA Application to PPP Environment PLASMA can be applied to PPP environment, and makes PPP environment multiple-accessible one. The packet encapsulation in PLASMA inherits that in PPP except the usage of the first two octets, the protocol field. PLASMAP utilizes these two octets as the L2 label field. FUJIKAWA Kenji Expires on September 16, 1996 [Page 11]
INTERNET DRAFT PLASMA March 1996 Related Works The Tag Distribution Protocol (TDP) employed in tag switching[6,7] and the ARIS (Aggregate Route-Based IP Switching) protocol[8] intend to integrate L2 label information distribution and L3 routing. That is, they are used in inter-subnet, while PLASMAP is used in intra- subnet, not related to L3 routing at all. In the case of ATM networks, PLASMA is similar to the Ipsilon approach[9,10] regarding not using Q.2931 for signaling. The differ- ence between them is that an ATM switch of Ipsilon is a router as well as a switch, while that of PLASMA is not a router but is like a hub having cell switching fabric. PLASMA realizes autoconfiguration of an IP/ATM subnet consisting of multiple ATM switches. Acknowledgments PLASMA is designed after IP-SVC[11,12] for the purpose of generaliz- ing IP-SVC to suit not only to ATM but also to other networks based on L2 label switching. FUJIKAWA Kenji Expires on September 16, 1996 [Page 12]
INTERNET DRAFT PLASMA March 1996 References [1] Deering, S., ``Host Extensions for IP Multicasting,'' RFC1112, August 1989. [2] Simpson, W., ``The Point-to-Point Protocol (PPP),'' RFC1661, July 1994. [3] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., ``Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,'' IETF Internet Draft (work in progress), draft-ietf-rsvp-spec-14.txt, November 1996. [4] Goto, Y., Ohta, M. and Hirabaru M., ``Design of Internet Resource Reservation on ATM Network,'' Proceedings of The 10th International Conference on Information Networking (ICOIN-10), pp.510-516, January 1996. [5] Katsube, Y., Nagami, K. and Esaki, H., ``Toshiba's Router Architecture Extensions for ATM : Overview,'' RFC2098, Febru- ary 1997. [6] Rekhter, Y., Davie, B., Katz, D., Rosen, E. and Swallow, G., ``Cisco Systems' Tag Switching Architecture Overview,'' RFC2105, February 1997. [7] Doolan, P., Davie, B., Katz, D., Rekhter, Y. and Rosen, E., ``Tag Distribution Protocol,'' IETF Internet Draft (work in progress), draft-doolan-tdp-spec-00.txt, September 1996. [8] Woundy, R., Viswanathan, A., Feldman, N. and Boivie, R., ``ARIS: Aggregate Route-Based IP Switching,'' IETF Internet Draft (work in progress), draft-woundy-aris-ipswitching- 00.txt, November 1996. [9] Newman, P., Edwards, W. L., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T. and Minshall, G., ``Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0,'' RFC1953, May 1996. [10] Newman, P., Edwards, W. L., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T. and Minshall, G., ``Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0,'' RFC1954, May 1996. [11] Fujikawa, K., ``Another ATM signaling protocol for IP (IP- SVC),'' IETF Internet Draft (work in progress), draft- fujikawa-ipsvc-01.txt, November 1996. FUJIKAWA Kenji Expires on September 16, 1996 [Page 13]
INTERNET DRAFT PLASMA March 1996 [12] Fujikawa, K. and Ikeda, K., `IP-SVC: An ATM Signaling Protocol for IP Unicasting and Multicasting,'' Asian'96, Workshop on Networking, December 1996. Author's Address FUJIKAWA, Kenji Department of Information Science, Faculty of Engineering, Kyoto University Yoshidahonmachi, Sakyo Ku, Kyoto City, 606-01, Japan Phone : +81 75-753-5387 Email : magician@kuis.kyoto-u.ac.jp FUJIKAWA Kenji Expires on September 16, 1996 [Page 14]