Internet DRAFT - draft-fujikawa-plasma
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 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]
