As per Relevance of the word datagram, we have this rfc below:
Network Working Group Y.
Request for Comments: 2098 K.
Category: Informational H.
Toshiba R&D
February 1997
Toshiba's Router Architecture Extensions for ATM :
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This memo describes a new internetworking architecture which
better use of the property of ATM. IP datagrams are
along hop-by-hop path via routers, but datagram assembly/
and IP header processing are not necessarily carried out
individual routers in the proposed architecture. A concept of "
Switch Router (CSR)" is introduced as a new
equipment, which has ATM cell switching capabilities in addition
conventional IP datagram forwarding. Proposed architecture
provide applications with high-throughput and low-latency ATM
while retaining current router-based internetworking concept.
also provides applications with specific QoS/bandwidth by
with internetworking level resource reservation protocols such
RSVP
1.
The Internet is growing both in its size and its traffic volume.
addition, recent applications often require guaranteed bandwidth
QoS rather than best effort. Such changes make the current hop-by
hop datagram forwarding paradigm inadequate, then
investigations on new internetworking architectures
Roughly two distinct approaches can be seen as possible solutions
the use of ATM to convey IP datagrams, and the revision of IP
support flow concept and resource reservation. Integration
interworking of these approaches will be necessary to provide
hosts with high throughput and QoS guaranteed
services over any datalink platforms as well as ATM
New internetworking architecture proposed in this draft is based
"Cell Switch Router (CSR)" which has the following properties
Katsube, et. al. Informational [Page 1]
RFC 2098 Toshiba's Router Extension for ATM February 1997
- It makes the best use of ATM's property while retaining
router-based internetworking and routing architecture
- It takes into account interoperability with future IP
supports flow concept and resource reservations
Section 2 of this draft explains background and motivations of
proposal. Section 3 describes an overview of the
internetworking architecture and its several remarkable features
Section 4 discusses control architectures for CSR, which will need
be further investigated
2. Background and
It is considered that the current hop-by-hop best effort
forwarding paradigm will not be adequate to support future
scale Internet which accommodates huge amount of traffic with
QoS requirements. Two major schools of investigations can be seen
IETF whose main purpose is to improve ability of the Internet
regard to its throughput and QoS. One is to utilize ATM
as much as possible, and the other is to introduce the concept
resource reservation and flow into IP
1) Utilization of
Although basic properties of ATM; necessity of connection setup
necessity of traffic contract, etc.; is not necessarily suited
conventional IP datagram transmission, its excellent throughput
delay characteristics let us to investigate the realization of
datagram transmission over ATM
A typical internetworking architecture is the "Classical IP Model
[RFC1577]. This model allows direct ATM connectivities only
nodes that share the same IP address prefix. IP datagrams
traverse routers whenever they go beyond IP subnet boundaries
though their source and destination are accommodated in the same
cloud. Although an ATMARP is introduced which is not based on
datalink broadcast but on centralized ATMARP servers, this model
not require drastic changes to the legacy
architectures with regard to the IP datagram forwarding process
This model still has problems of limited throughput and
latency, compared with the ability of ATM, due to IP
processing at every router. It will become more critical
multimedia applications that require much larger bandwidth and
latency become dominant in the near future
Katsube, et. al. Informational [Page 2]
RFC 2098 Toshiba's Router Extension for ATM February 1997
Another internetworking architecture is "NHRP (Next Hop
Protocol) Model" [NHRP09]. This model aims at resolving
and latency problems in the Classical IP Model and making the
use of ATM. ATM connections can be directly established from
ingress point to an egress point of an ATM cloud even when they
not share the same IP address prefix. In order to enable it,
Next Hop Server [KAT95] is introduced which can find an egress
of the ATM cloud nearest to the given destination and resolves
ATM address. A sort of query/response protocols between
server(s) and clients and possibly server and server are specified
After the ATM address of a desired egress point is resolved,
client establishes a direct ATM connection to that point through
signaling procedures [ATM3.1]. Once a direct ATM connection has
set up through this procedure, IP datagrams do not have to
hop-by-hop IP processing but can be transmitted over the direct
connection. Therefore, high throughput and low
communications become possible even if they go beyond IP
boundaries. It should be noted that the provision of such direct
connections does not mean disappearance of legacy routers
interconnect distinct ATM-based IP subnets. For example, hop-by-
IP datagram forwarding function would still be required in
following cases
- When you want to transmit IP datagrams before direct ATM
from an ingress point to an egress point of the ATM cloud
- When you neither require a certain QoS nor transmit large amount
IP datagrams for some
- When the direct ATM connection is not allowed by security or
2) IP level resource reservation and flow
Apart from investigation on specific datalink technology such as ATM
resource reservation technologies for desired IP level flows
been studied and are still under discussion. Their typical
are RSVP [RSVP13] and STII [RFC1819].
RSVP itself is not a connection oriented technology since
can be transmitted regardless of the result of the
reservation process. After a resource reservation process from
receiver (or receivers) to a sender (or senders) is
completed, RSVP-capable routers along the path of the flow
their resources for datagram forwarding according to the
flow spec
Katsube, et. al. Informational [Page 3]
RFC 2098 Toshiba's Router Extension for ATM February 1997
STII is regarded as a connection oriented IP which
connection setup process from a sender to a receiver (or receivers
before transmitting datagrams. STII-capable routers along the
of the requested connection reserve their resources for
forwarding according to the flow spec
Neither RSVP nor STII restrict underlying datalink networks
their primary purpose is to let routers provide each IP flow
desired forwarding quality (by controlling their datagram
rules). Since various datalink networks will coexist as well as
in the future, these IP level resource reservation technologies
be necessary in order to provide end-to-end IP flow with
bandwidth and QoS
aking this background into consideration, we should be aware
several issues which motivate our proposal
- As of the time of writing, the ATM specific
architecture proposed does not take into account
with IP level resource reservation or connection setup protocols
In particular, operating RSVP in the NHRP-based ATM cloud seems
require much effort since RSVP is a soft-state receiver-
protocol with multicast capability as a default, while ATM
NHRP is a hard-state sender-oriented protocol which does
support multicast yet
- Although RSVP or STII-based routers will provide each IP flow
a desired bandwidth and QoS, they have some native
limitations due to the processor-based IP forwarding
compared with the hardware switching mechanism of ATM
The main objective of our proposal is to resolve the above issues
The proposed internetworking architecture makes the best use of
property of ATM by extending legacy routers to handle future
features such as flow support and resource reservation with the
of ATM's cell switching capabilities
3. Internetworking Architecture Based On the Cell Switch Router (CSR
3.1
The Cell Switch Router (CSR) is a key network element of the
internetworking architecture. The CSR provides cell
functionality in addition to conventional IP datagram forwarding
Communications with high throughput and low latency, that are
properties of ATM, become possible by using this cell
functionality even when the communications pass through IP
Katsube, et. al. Informational [Page 4]
RFC 2098 Toshiba's Router Extension for ATM February 1997
boundaries. In an ATM internet composed of CSRs, VPI/VCI-based
switching which bypasses datagram assembly/disassembly and IP
processing is possible at every CSR for communications which
themselves to such (e.g., communications which require certain
of bandwidth and QoS), while conventional hop-by-hop
forwarding based on the IP header is also possible at every CSR
other conventional communications
By using such cell-level switching capabilities, the CSR is able
concatenate incoming and outgoing ATM VCs, although the
in this case is controlled outside the ATM cloud (ATM's control
management-plane) unlike conventional ATM switch nodes. That is,
CSR is attached to ATM networks via an ATM-UNI instead of NNI.
carrying out such VPI/VCI concatenations at multiple
consecutively, ATM level connectivity composed of multiple ATM VCs
each of which connects adjacent CSRs (or CSR and hosts/routers),
be provided. We call such an ATM pipe "ATM Bypass-pipe"
differentiate it from "ATM VCC (VC connection)" provided by a
ATM datalink cloud through ATM signaling
Example network configurations based on CSRs are shown in figure 1.
An ATM datalink network may be a large cloud which
multiple IP subnets X, Y and Z. Or several distinct ATM
may accommodate single IP subnet X, Y and Z respectively. The
configuration would be straightforward in discussing the CSR, but
CSR is also applicable to the former configuration as well.
addition, the CSR would be applicable as a router which
multiple NHRP-based ATM clouds
Two different kinds of ATM VCs are defined between adjacent CSRs
between CSR and ATM-attached hosts/routers
1) Default-
It is a general purpose VC used by any communications which
conventional hop-by-hop IP routed paths. All incoming cells
from this VC are assembled to IP datagrams and handled based on
IP headers. VCs set up in the Classical IP Model are classified
this category
2) Dedicated-
It is used by specific communications (IP flows) which are
by, for example, any combination of the destination IP address/port
the source IP address/port or IPv6 flow label. It can
concatenated with other Dedicated-VCs which accommodate the same
flow as it, and can constitute an ATM Bypass-pipe for those IP flows
Katsube, et. al. Informational [Page 5]
RFC 2098 Toshiba's Router Extension for ATM February 1997
Ingress/egress nodes of the Bypass-pipe can be either CSRs or ATM
attached routers/hosts both of which speak a Bypass-pipe
protocol. (we call that "Bypass-capable nodes") On the other hand
intermediate nodes of the Bypass-pipe should be CSRs since they
to have cell switching capabilities as well as to speak the Bypass
pipe control protocol
The route for a Bypass-pipe follows IP routing information in
CSR. In figure 1, IP datagrams from a source host or router X.1 to
destination host or router Z.1 are transferred over the route X.1 ->
CSR1 -> CSR2 -> Z.1 regardless of whether the communication is on
hop-by-hop basis or Bypass-pipe basis. Routes for
Dedicated-VCs which constitutes the Bypass-pipe X.1 --> Z.1 (X.1 ->
CSR1, CSR1 -> CSR2, CSR2 -> Z.1) would be determined based on
routing protocols such as PNNI [PNNI1.0], and would be independent
IP level routing
An example of IP datagram transmission mechanism is as follows
o The host/router X.1 checks an identifier of each IP datagram
which may be the "destination IP address (prefix)",
"source/destination IP address (prefix) pair", "destination
address and port", "source IP address and Flow label (in IPv6)",
and so on. Based on either of those identifiers, it
over which VC the datagram should be transmitted
o The CSR1/2 checks the VPI/VCI value of each incoming cell.
the mapping from the incoming interface/VPI/VCI to
interface/VPI/VCI is found in an ATM routing table, it is
forwarded to the specified interface through an ATM switch module
When the mapping in not found in the ATM routing table (or
table shows an IP module as an output interface), the cell
assembled to an IP datagram and then forwarded to an
outgoing interface/VPI/VCI based on an identifier of the datagram
Katsube, et. al. Informational [Page 6]
RFC 2098 Toshiba's Router Extension for ATM February 1997
IP subnet X IP subnet Y IP subnet
<---------------------> <-----------------> <--------------------->
+-------+ Default +-------+ Default +-------+ Default +-------+
| | -VC | CSR 1 | -VC | CSR 2 | -VC | |
| Host +=============+ +===============+ +=============+ Host |
| X.1 +-------------+++++---------------+++++-------------+ Z.1 |
| +-------------+++++---------------+++++-------------+ |
| +-------------+++++---------------+++++-------------+ |
| |Dedicated | | Dedicated | |Dedicated | |
+-------+ -VCs +-------+ -VCs +-------+ -VCs +-------+
<--------------------------------------------------->
Bypass-
Figure 1 Internetworking Architecture based on
3.2
The main feature of the CSR-based internetworking architecture is
same as that of the NHRP-based architecture in the sense that
both provide direct ATM level connectivity beyond IP
boundaries. There are, however, several notable differences in
CSR-based architecture compared with the NHRP-based one as follows
1) Relationship between IP routing and ATM
In the NHRP model, an egress point of the ATM network is
determined in the next hop resolution phase based on IP level
information. Then the actual route for an ATM-VC to the
egress point is determined in the ATM connection setup phase based
ATM level routing information. Both kinds of routing
would be calculated according to factors such as network topology
available bandwidth for the large ATM cloud. The ATM routing will
based on PNNI phase1 [PNNI1.0] while the IP routing will be based
OSPF, BGP, IS-IS, etc. We need to manage two different
protocols over the large ATM cloud until Integtrated-PNNI [IPNNI96]
which takes both ATM level metric and IP level metric into
will be phased in in the future
In the CSR model, IP level routing determines an egress point of
ATM cloud as well as determines inter-subnet level path to the
that shows which CSRs it should pass through. ATM level
determines an intra-subnet level path for ATM-VCs (both Dedicated-
and Default-VC) only between adjacent nodes (CSRs or ATM-
hosts/routers). Since the roles of routing are
subdivided into inter-subnet level (router level) and intra-
level (ATM SW level), ATM routing does not have to operate all
Katsube, et. al. Informational [Page 7]
RFC 2098 Toshiba's Router Extension for ATM February 1997
the ATM cloud but only in individual IP subnets independent from
other. This will decrease the amount of information for ATM
protocol handling. But an end-to-end ATM path may not be
compared with the NHRP model since the path should go through
at subnet boundaries in the CSR model
2) Dynamic routing and redundancy
A CSR-based network can dynamically change routes for Bypass-
when related IP level routing information changes. Bypass-
related to the routing changes do not have to be torn down
established from scratch since intermediate CSRs related to
routing changes can follow them and change routes for
Bypass-pipes by themselves
The same things apply when some error or outage happens in any
nodes/links/routers on the route of a Bypass-pipe. CSRs that
noticed such errors or outages would change routes for
Bypass-pipes by themselves
3) Interoperability with IP level resource reservation protocols
multicast
As current NHRP specification assumes application of NHRP to
environments only, multicast IP flows should still be carried
on a hop-by-hop manner with multicast routers. In addition
realization of IP level resource reservation protocols such as
over NHRP environments requires further investigation
The CSR-based internetworking architecture which keeps subnet-by
subnet internetworking with regard to any control protocol
can provide multicast Bypass-pipes without requiring
modifications in IP multicast over ATM [IPMC96] or multicast
techniques. In addition, since the CSR can handle RSVP
which are transmitted in a hop-by-hop manner, it can provide Bypass
pipes which satisfy QoS requirements by the cooperation of the
and the Bypass-pipe control protocol
4. Control Architecture for
Several issues with regard to a control architecture for the CSR
discussed in this section
4.1 Network Reference
In order to help understanding discussions in this section,
following network reference model is assumed. Source hosts S1, S2,
and destination hosts D1, D2 are attached to Ethernets, while S3
Katsube, et. al. Informational [Page 8]
RFC 2098 Toshiba's Router Extension for ATM February 1997
D3 are attached to the ATM. Routers R1 and R5 are attached
Ethernets only, while R2, R3 and R4 are attached to the ATM. The
datalink for subnet #3 and subnet #4 can either be
separated datalinks or be the same datalink. In other words, R3
be either one-port or multi-port router
Ether Ether ATM ATM Ether
| | +-----+ +-----+ | |
| | | | | | | |
S1--| S2---| S3---| | | |---D3 |---D2 |--D
| | | | | | | |
|---R1---|---R2---| |--R3--| |---R4---|---R5---|
| | | | | | | |
| | +-----+ +-----+ | |
subnet subnet subnet subnet subnet
#1 #2 #3 #4 #5 #6
Figure 2 Network Reference
Bypass-pipes can be configured [S3 or R2]-->R3-->[D3 or R4].
means that S3, D3, R2, R3 and R4 need to speak Bypass-pipe
protocol, and means that R3 needs to be the CSR. We use
"Bypass-capable nodes" for hosts/routers which can speak Bypass-
control protocol but are not necessarily CSRs
As shown in this reference model, Bypass-pipe can be configured
host to host (S3-->R3-->D3), router to host (R2-->R3-->D3), host
router (S3-->R3-->R4), and router to router (R2-->R3-->R4).
4.2 Possible Use of Bypass-
Possible use (or purposes) of Bypass-pipe provided by CSRs, in
words, possible triggers that initiate Bypass-pipe setup procedure
is discussed in this subsection
Following two purposes for Bypass-pipe setup are assumed at present
a) Provision of low latency
This indicates cases in which end hosts or routers initiate
Bypass-pipe setup procedure when they will transmit large amount
datagrams toward a specific destination. For instance
- End hosts or routers initiate Bypass-pipe setup procedures
on the measurement of IP datagrams transmitted toward a
destination
Katsube, et. al. Informational [Page 9]
RFC 2098 Toshiba's Router Extension for ATM February 1997
- End hosts or routers initiate Bypass-pipe setup procedures
it detects datagrams with certain higher layer protocols such
ftp, nntp, http, etc
Other triggers may be possible depending on the policy in
network. In any case, the purpose of Bypass-pipe setup in each
these cases is to reduce IP processing burden at intermediate
as well as to provide a communication path with low latency for
data transfer, rather than to provide end host applications
specific bandwidth/QoS
There would be no rule for determining bandwidth for such kinds
Bypass-pipes since no explicit information about bandwidth/
requirement by end hosts is available without IP-level
reservation protocols such as RSVP. Using UBR VCs as components
the Bypass-pipe would be the easiest choice although there is
guarantees for cell loss quality, while using other services such
CBR/VBR/ABR with an adequate parameter tuning would be possible
b) Provision of specific bandwidth/QoS requested by
This indicates cases in which routers or end hosts initiate
Bypass-pipe setup procedure by triggers related to IP-
bandwidth/QoS request from end hosts. The "resource
entity" in the host or router, which has received bandwidth/
requests from applications or adjacent nodes may choose
accommodate the requested IP flow to an existing VC or choose
allocate a new Dedicated-VC for the requested IP flow. Selecting
latter choice at each router can correspond to the trigger
constituting a Bypass-pipe. When both an incoming VC and an
VC (or VCs) are dedicated to the same IP flow(s), those VCs can
concatenated at the CSR (ATM cut-through) to constitute a Bypass
pipe. Bandwidth for the Bypass-pipe (namely, individual
constituting the Bypass-pipe) in this case would be determined
on the bandwidth/QoS requirements by the end host which is
by, e.g., RSVP messages. The ATM service classes; e.g., CBR/VBR/ABR
that would be selected depends on the IP-level service
requested by the end hosts
Bypass-pipe provision for the purpose of b) will surely be
in the near future when related IP-level resource
protocol will become available as well as when definitions
individual service classes and flow specs offered to
become clear. On the other hand, Bypass-pipe setup for the
of a) may be beneficial right now since it does not
availability of IP-level resource reservation protocols. In
sense, a) can be regarded as a kind of short-term use while b) is
long-term use
Katsube, et. al. Informational [Page 10]
RFC 2098 Toshiba's Router Extension for ATM February 1997
4.3 Variations of Bypass-pipe Control
A number of variations regarding Bypass-pipe control architecture
introduced. Items which are related to architectural variations are
o Ways of providing Dedicated-
o Channels for Bypass-pipe control message
o Bypass-pipe control
Each of these items are discussed below
4.3.1 Ways of Providing Dedicated-
There are roughly three alternatives regarding the way of
Dedicated-VCs in individual IP subnets as components of a Bypass
pipe
a) On-demand SVC
Dedicated-VCs are set up in individual IP subnets each time you
to set up a Bypass-pipe through the ATM signaling procedure
b) Picking up one from a bunch of (semi-)
Several VCs are set up beforehand between CSR and CSR, or CSR
other ATM-attached nodes (hosts/router) in each IP subnet. Unused
is picked up as a Dedicated-VC from these PVCs in each IP subnet
a Bypass-pipe is set up
c) Picking up one VCI in PVP/
PVPs or SVPs are set up between CSR and CSR, or CSR and other ATM
attached nodes (hosts/routers) in each IP subnet. PVPs would be
up as a router/host initialization procedure, while SVPs, on
other hand, would be set up through ATM signaling when the first
(either Default- or Dedicated-) setup request is initiated by
of some peer nodes. Then, Unused VCI value is picked up as
Dedicated-VC in the PVP/SVP in each IP subnet when a Bypass-pipe
set up. The SVP can be released through ATM signaling when no
value is in active state
The best choice will be a) with regard to efficient network
usage. However, you may go through three steps, ATMARP (for
[RFC1577] or multicast [IPMC96] in each IP subnet), SVC setup (
each IP subnet) and exchange of Bypass-pipe control message in
case. Whether a) is practical choice or not will depend on
Katsube, et. al. Informational [Page 11]
RFC 2098 Toshiba's Router Extension for ATM February 1997
you can allow larger Bypass-pipe setup time due to three-
procedure mentioned above, or whether you can send datagrams
Default-VCs in a hop-by-hop manner while waiting for the Bypass-
set up
In the case of b) or c), the issue of Bypass-pipe setup time will
improved since SVC setup step can be skipped. In b), each node (
or ATM-attached host/router) should specify some traffic
even for unused VCs, and the ATM datalink should reserve its
resource (such as VCI value and bandwidth) for them. In addition
the ATM datalink may have to carry out UPC functions for those
VCs. Such burden would be reduced when you use UBR-PVCs and set
cell rate for each of them equal to link rate, but bandwidth/QoS
the Bypass-pipe is not provided in this case. In c), on the
hand, traffic descriptors which should be specified by each node
the ATM datalink is not each VC's but VP's only.
reservations for individual VCs will be carried out not as
functionality of the ATM datalink but of each CSR or ATM-
host/router if necessary. A functionality which need to be
by the ATM datalink is control of VPs' bandwidth only such as UPC
dynamic bandwidth negotiation if it would be widely available
4.3.2 Channels for Bypass-pipe Control Message
There are several alternatives regarding the channels for
(setting up, releasing, and possibly changing the route of)
Bypass-pipe. This subsection explains these alternatives
discusses their properties
Three alternatives are discussed, Inband control message,
control message, and use of ATM signaling
i) Inband Control
When setting up a Bypass-pipe, control messages are transmitted
a Dedicated-VC which will eventually be used as a component of
Bypass-pipe. These messages are handled at each CSR, and
messages are transmitted to the next-hop node over a Dedicated-
along the selected route (based on IP routing table). Unlike
message protocol described in ii), each message does not have
indicate a Dedicated-VC which will be used since the message
is carried over "that" VC
The inband control message can be either "datagram dedicated
Bypass-pipe control" or "actual IP datagram" sent by
application. Actual IP datagrams can be transmitted over Bypass-
after it has been set up in the former case. In the latter case,
the other hand, the first (or several) IP datagram(s) received
Katsube, et. al. Informational [Page 12]
RFC 2098 Toshiba's Router Extension for ATM February 1997
an unused Dedicated-VC are analyzed at IP level and
toward adequate next hop over an unused Dedicated-VC. Then
Dedicated-VC and outgoing Dedicated-VC are concatenated to
a Bypass-pipe
In inband control, Bypass-pipe control messages transmitted after
Bypass-pipe has been set up cannot be identified at intermediate
since those messages are forwarded at cell level there. As
possible solution for this issue, intermediate CSRs can
Bypass-pipe control messages by marking cell headers, e.g., PTI
which indicates F5 OAM cell. With regard to Bypass-pipe release
explicit release message may not be necessary if individual
administer the amount of traffic over each Dedicated-VC and
concatenation information for an inactive Bypass-pipe with their
decision
ii) Outband Control
When a Bypass-pipe is set up or released, control messages
transmitted over VCs which are different from Dedicated-VCs used
components of the Bypass-pipe. Unlike inband message
described in i), each message has to indicate which Dedicated-VCs
message would like to control. Therefore, an identifier
uniquely discriminates a VC, which is not a VPI/VCI that is
identical at both endpoints of the VC, need to be defined and
given at VC initiation phase. However, an issue of control
transmission after a Bypass-pipe has been set up in inband case
not exist
Four alternatives are possible regarding how to convey Bypass-
control messages hop-by-hop over ATM datalink networks
1) Defines VC for Bypass-pipe control messages only
2) Uses Default-VC and discriminates Bypass-pipe control
from user datagrams by an LLC/SANP value in RFC1483 encapsulation
3) Uses Default-VC and discriminates Bypass-pipe control
from user datagrams by a protocol field value in IP header
4) Uses Default-VC and discriminates Bypass-pipe control
from user datagrams by a port ID in the UDP frame
When we take into account interoperability with Bypass-
routers, 1) will not be a good choice. Whether we select 2) or 3) 4)
depends on whether we should consider multiprotocol rather than
only
Katsube, et. al. Informational [Page 13]
RFC 2098 Toshiba's Router Extension for ATM February 1997
In the case of IP multicast, point-to-multipoint VCs in
subnets are concatenated at CSRs consecutively in order to
end-to-end multicast tree. Above four alternatives may require
same number of point-to-multipoint Defalut-VCs as the number
requested point-to-multipoint Dedicated-VCs in multicast case.
fifth alternative which can reduce the necessary number of VCs
convey control messages in a multicast environment is
5) Defines point-to-multipoint VC whose leaves are members
multicast group 224.0.0.1. All nodes which are members of
least one of active multicast group would become leaves of
point-to-multipoint VC
Each upstream node may become a root of the point-to-multipoint VC
or a sort of multicast server to which each upstream node
cells over a point-to-point VC may become a root of that. In
case, Bypass-pipe control messages for every multicast group
transmitted to all nodes which are members of either of the group
When a downstream node has received control messages which are
related to a multicast group it belongs, it should discard them
referring to a destination group address on their IP header
Donwstream node would still need to use point-to-point VC to
control messages toward upstream
iii) Use of ATM Signaling
Supposing that ATM signaling messages can convey IP addresses (
possibly port IDs) of source and destination, it may be possible
ATM signaling messages be used as Bypass-pipe control messages also
In that case, an ATM connection setup message indicates a setup of
Dedicated-VC to an ATM address of a desirable next-hop IP node,
also indicates a setup of a Bypass-pipe to an IP address (
possibly port ID) of a target destination node. Information
for the Dedicated-VC setup (ATM address of a next-hop node
bandwidth, QoS, etc.) are handled at ATM nodes, while
elements for the Bypass-pipe setup (source and destination
addresses, possibly their port IDs, or flow label for IPv6, etc.)
transparently transferred to the next-hop IP node. The next-hop
node accepts Dedicated-VC setup and handles such IP level
elements
ATM signaling messages can be transferred from receiver to sender
well as sender to receiver when you set zero Forward Cell Rate
non-zero Backward Cell Rate as an ATM traffic descriptor
element in unicast case, or when Leaf Initiated Join
will become available in multicast case
Katsube, et. al. Informational [Page 14]
RFC 2098 Toshiba's Router Extension for ATM February 1997
Issues in this method are
- Information elements which specify IP level (and port level
information need to be defined, e.g., B-HLI or B-UUI, as an
signaling specification
- It would be difficult to support soft-state Bypass-pipe
which transmits control messages periodically since ATM
is a hard-state protocol
4.3.3 Bypass-pipe Control
This subsection discusses several items with regard to
procedures for Bypass-pipe control
a) Distributed trigger vs. Centralized (restricted)
The first item to be discussed is whether the functionality
detecting a trigger of Dedicated-VC/Bypass-pipe control
distributed to all the nodes (including CSRs and hosts/edge devices
or restricted to specific nodes
In the case of the distributed trigger, every node is regarded
having a capability of detecting a trigger of Bypass-pipe setup
termination. For example, every node detects datagrams for ftp,
sets up (or fetches) a Dedicated-VC individually to construct
Bypass-pipe. After setting up or fetching the Dedicated-VCs
messages which informs (or requests) the transmission of the IP
over the Dedicated-VC are exchanged between adjacent nodes.
enables peer nodes to share the same knowledge about the
relationship between the IP flow and the Dedicated-VC. There is
end-to-end message transmission in the Bypass-pipe control
itself, but transmission between adjacent nodes only
In the case of the centralized (or restricted) trigger, capability
detecting a trigger of Bypass-pipe setup or termination is
to nodes which are located at "the boundary of the CSR-cloud".
boundary of the CSR-cloud signifies, for individual IP flows,
node which is the first-hop or the last-hop CSR-capable node.
example, a node which detects datagrams for ftp can initiate Bypass
pipe setup procedure only when its previous hop is non-ATM or CSR
incapable. In this case, Bypass-pipe control messages are
at the boundary of the CSR-cloud, and forwarded hop-by-hop
another side of the boundary, which is similar to ATM
messages. The semantics of the messages may be the request of end
to-end Bypass-pipe setup as well as notification or request
mapping relationship between the IP flow and the Dedicated-VC
Katsube, et. al. Informational [Page 15]
RFC 2098 Toshiba's Router Extension for ATM February 1997
b) Upstream-initiated control vs. Downstream-initiated
The second item to be discussed is whether the setup of a Dedicated
VC and the control procedure for constructing a Bypass-pipe
initiated by upstream side or downstream side
In the case of the upstream-initiated control, the upstream
takes the initiative when setting up a Dedicated-VC for a specific
flow and creating the mapping relationship between the IP flow
the Dedicated-VC. For example, a CSR which detects datagrams for
sets up (or fetches) a Dedicated-VC toward its downstream
and notifies its downstream neighbor that it will transmit a
IP flow over the Dedicated-VC. This means that the downstream
is requested to receive datagrams from the Dedicated-VC
In the case of the downstream-initiated control, the downstream
takes the initiative when setting up a Dedicated-VC for a specific
flow and creating the mapping relationship between the IP flow
the Dedicated-VC. For example, a CSR which detects datagrams for
sets up (or fetches) a Dedicated-VC toward its upstream neighbor
requests its upstream neighbor to transmit a specific IP flow
the Dedicated-VC. This means that the upstream node is requested
transmit the IP flow over the Dedicated-VC
c) Hard-state management vs. Soft-state
The third item to be discussed is whether the control (setup
maintain, and release) of the Bypass-pipe is based on hard-state
soft-state
In hard-state management, individual nodes transmit Bypass-
control messages only when they want to notify or request any
in their neighbors' state. They should wait for an
of the message before they change their internal state. For example
after setting up a Bypass-pipe, it is maintained until either of
peer nodes transmits a message to release the Bypass-pipe
In soft-state management, individual nodes periodically
Bypass-pipe control messages in order to maintain their neighbors
state. They do not have to wait for an acknowledgement of
message before they changes its internal state. For example,
after setting up a Bypass-pipe, either of a peer nodes is required
periodically transmit refresh messages to its neighbor in order
maintain the Bypass-pipe
5. Security
Security issues are not discussed in this memo
Katsube, et. al. Informational [Page 16]
RFC 2098 Toshiba's Router Extension for ATM February 1997
6.
Basic concept of Cell Switch Router (CSR) are clarified and
architecture for CSR is discussed. A number of methods to
Bypass-pipe will be possible each of which has its own advantages
disadvantages. Further investigation and discussion will
necessary to design control protocol which may depend on
requirements by users
7.
[IPMC96] Armitage, G., "Support for Multicast over UNI 3.0/3.1
ATM Networks", RFC 2022, November 1996.
[ATM3.1] The ATM-Forum, "ATM User-Network Interface Specification
v.3.1", Sept. 1994.
[RSVP13] Braden, R., et al., "Resource ReSerVation Protocol (RSVP),
Version 1 Functional Specification", Work in Progress
[IPNNI96] R. Callon, et al., "Issues and Approaches for
PNNI", The ATM Forum Contribution No. 96-0355, April 1996.
[NHRP09] Luciani, J., et al., "NBMA Next Hop Resolution
(NHRP)", Work in Progress
[PNNI1.0] The ATM-Forum, "P-NNI Specification Version 1.0",
1996.
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over
Adaptation Layer 5", RFC 1483, July 1993.
[RFC1577] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
October 1993.
[RFC1819] Delgrossi, L, and L. Berger, "Internet STream
Version 2 (STII) Protocol Specification Version ST2+", RFC 1819,
August 1995.
Katsube, et. al. Informational [Page 17]
RFC 2098 Toshiba's Router Extension for ATM February 1997
8. Authors'
Yasuhiro
R&D Center,
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Phone : +81-44-549-2238
EMail : katsube@isl.rdc.toshiba.co.
Ken-ichi
R&D Center,
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Phone : +81-44-549-2238
EMail : nagami@isl.rdc.toshiba.co.
Hiroshi
R&D Center,
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Phone : +81-44-549-2238
EMail : hiroshi@isl.rdc.toshiba.co.
Katsube, et. al. Informational [Page 18]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
