Internet DRAFT - draft-fujikawa-plasma


HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:00:18 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sun, 16 Mar 1997 14:31:57 GMT
ETag: "2e69fa-6e96-332c045d"
Accept-Ranges: bytes
Content-Length: 28310
Connection: close
Content-Type: text/plain

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 (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).


   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.

       This word, or the adjective ``required,'' means that the
       definition is an absolute requirement of the specification.

       This phrase means that the definition is an absolute prohibition
       of the specification.

       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.

       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

       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

       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

   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

   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:

       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

       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

       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)
                            D        (Join D)    (Join A,B)
                *           *           BC
                |           |           |
                |           *           |        (Join B,C)
                +--------*[N3]          +---------*[N8]
                            |        (Join A)

                    N1, N2, N3...N8 : Node
                    A, B, C and D   : Address
                    *               : All addresses

                    (Join A,B)      : N7 joins A and B

                    [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)
                (discarded) |
                   ----->   D -----> (Join D)    (Join A,B)
                *           * ^         BC ----->
                |           | |         |
                | <-----    * |         |  ----->(Join B,C)
                +--------*[N3]          +---------*[N8]
                            | <----- (Join A)
                                    (Notify B)

                       (a) Sending a NOTIFY message

                                     (Join D)
                            D <----- (Join D)    (Join A,B)
                *           * |         BC <-----
                |           | |         |
                |           * V         |  <-----(Join B,C)
                +--------*[N3]          +---------*[N8]
                            | -----> (Join A)
                                    (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

                         |                Subnet S1
                         |  +-----[N4]
                         |  |
                  =====[Router]========   Subnet boundary
                         |  |
                         |  +-----[N6]
                         |                Subnet S2

                 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

   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-

   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.


   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


   [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

   [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 :

FUJIKAWA Kenji       Expires on September 16, 1996             [Page 14]