CO and CL IP Transport over ATM BOF (COLIP)
Reported by Hiroshi Esaki/Toshiba Corporation
The COLIP BOF met on Tuesday, 4 April, at the 32nd IETF. The meeting was
chaired by Hiroshi Esaki and Masataka Ohta.
Mailing list information:
Mailing list:
[email protected]
To Subscribe:
[email protected]
I. Abstract
The issues and framework of IP packet transport with the provision of
QoS using ATM in large scale and heterogeneous Internet were discussed.
The methodology and framework of mapping between the QoS'ed IP packet
flow defined by the resource reservation protocol (e.g., ST-II and RSVP)
and the ATM data-link connection (i.e., QoS'ed cell-relaying channel) is
the important issue to explore and this issue has not been discussed in
other working groups. The roughly identified work items are:
o Architecture model documentation.
o Protocol development associated with the interaction between ATM
and ST-II/RSVP.
o Large scale multicast over the Internet including ATM.
o Methodology and framework to optimize (i.e., cut-thru packet
switching) IP packet forwarding.
The work items should be clarified on the mailing list.
II. Agenda
1. Purpose of the BOF -- H. Esaki
2. Conventional model of IP over ATM -- M. Ohta
3. IP packet transport using Cell Switch Router (CSR) model -- Y.
Katsube
4. Flow management and control issues on ATM -- H. Esaki
5. Conclusion
Item 4 was not discussed.
III. Purpose of the BOF
The purpose of this BOF is to discuss the protocol and architecture that
extract the capability of ATM, that can provide QoS data-link pipe for
each communication flow, for IP communication with new network and
transport protocol suite (e.g., resource reservation oriented protocol
such as RSVP).
In the wide area Internet, it was said that it was almost impossible to
provide cell-relay based end-to-end pipe. When the QoS requirement and
the required bandwidth for the IP flow can be explicitly indicated to
the router, it will be easy to relay the IP packet cell-by-cell in the
router, while provide QoS assurance. In other words, the interaction
between the QoS oriented network/transport protocol (e.g., RSVP/ST-II)
and the ATM protocol must be explored to provide end-to-end QoS
provision over the Internet.
The conventional connectionless service can be provided just using a
connection oriented data-link pipe among the routers.
The discussed architecture and protocol should accommodate all
architecture models discussed in the IETF (e.g., NHRP with NBMA) and the
ATM Forum (LAN Emulation). The point that should be discussed is how to
transport the IP packets, when the data-link is connection oriented
platform (especially ATM) providing QoS pipes. By the use of routers,
we can provide hard-state, soft-state and stateless paths over the
heterogeneous Internet.
IV. Conventional Model of IP over ATM
Presentation Summary
Masataka Ohta presented the conventional model of IP over ATM. The
issues of the currently discussed IP over ATM models from the viewpoint
of global Internet are clarified, and the cell-relay capable router was
introduced.
o Signaling by IP, not by Q.2931
One of the difficulties of ``IP over ATM'' is that ATM signaling
carried by Q.2931 packet cannot be sent over IP routers.
As IP routers do not recognize Q.2931, the global Internet must use
IP style packet format for signaling. Just as legacy ATM switches
recognize Q.2931 signaling requests and setup switching hardware
appropriately, cell switching routers or IP-routing switches,
having hardware cell switching capability, should recognize IP
signaling requests, consult IP routing table, and setup switching
hardware appropriately.
IP signaling preserves CATENET model including scalability and
dynamic re-routability.
o Transport layer resource reservation protocol
As the network layer of the Internet does not have any notion of
QoS, higher layers must be consulted to know the QoS requirement to
link-layer ATM connection. Existing transport layer resource
reservation protocol (e.g., RSVP/ST-II) of the Internet can map
directly to the ATM link level resource reservation requirement.
That is, RSVP/ST-II can be regarded as ``IP signaling,'' when we
use similar terminology to ATM.
Multiple datalink segments, which may or may not be ATM based, will
be signaled by RSVP/ST-II. Within ATM based datalink segments,
Q.2931 signaling will be performed.
o Communication without QoS
IP packets without QoS specification will be relayed by default VC
between cell relaying IP routers packet by packet. ABR, having
poor feedback over long segments, will be useful, if control is
terminated on cell relaying IP routers. In other words, ABR should
be terminated at the IP router and ABR connection should be used
for the short-haul connection between IP routers.
o Large cloud issues
Cell switching routers can offer cell-by-cell connection between
ATM large clouds.
But, instead of implementing ATM public data networks as large
cloud NSAP based networks, they should be constructed with cell
relaying routers connecting small datalink layers.
o IPv6 autoconfiguration
IPv6 autoconfiguration means complete autoconfiguration. That is,
it is not allowed to manually configure each host of NSAP addresses
of ARP and/or multicast servers. In order to support this type of
autoconfiguration, the ATM protocol must be extended to have real,
server-less, broadcast functionality.
o Multi-protocol issues
On the Internet, multiprotocol means single IP over multiple
datalink layer protocols. Applications should not be required as
special case handling only because end hosts are connected purely
by ATM. That is, for multiprotocolness, QoS requirement must be
signaled by IP packet format.
On the other hand, in a pure ATM world, it is often desired to
support end-to-end ATM connection regardless of the format of the
data. As IP signaling sets up cell-by-cell relaying end-to-end
path even through routers, users, who know they are using pure ATM
datalink segments, may use any non-IP data in the path.
o IP packet forwarding by cell switching
A Router that interconnects the ATM clouds could have both packet
switch and cell switch simultaneously. The IP packet flows, whose
required bandwidth and QoS requirement is realized, can be
forwarded only through cell switch with bypassing packet switch.
Discussion
The following are questions/comments received and the
realizations/solutions for them.
o How to map between IP packet flows and ATM cell-relaying channel?
How to aggregate the IP flows into the ATM cell-relaying channel
should be the router's local decision. One to one mapping between
IP flows and ATM cell-relaying channel is possible, but multiple IP
flows can aggregated into a single ATM cell-relaying channel by the
router's local decision.
o Is the use of RSVP required for the communication within the ATM
cloud?
As long as we need QoS'ed communication on the global Internet, we
need some reservation protocol (i.e., RSVP/ST-II). Data without QoS
can be transmitted packet by packet even over ATM without
reservation protocols. ABR over ATM cannot assure delay bound that
is the QoS parameter discussed in the INTSERV Working Group.
o Must we interconnect small ATM (data-link) clouds by routers, even
in LPDN?
It is impossible to force the use of the architecture that small
ATM clouds are interconnected by routers. However, at least, LPDNs
should not be forced to use a large cloud model.
o IPv6 autoconfigurable data-link platform
IPv6 does not always require a complete autoconfigurable platform,
that does not need any configuration server. Some data-link
platforms require the complete autoconfigurable capability. ATM
platform may not be able to satisfy IPv6 autoconfiguration
requirement.
V. IP Packet Transport Using CSR Architecture
Presentation Summary
The architecture of Cell Switch Router (CSR) was introduced by Y.
Katsube, from the viewpoint of RSVP over ATM. The introduced router
architecture is the router to interconnect any size ATM cloud. The
features of the introduced architecture follow.
o Segregation of control packet flow from application data flow
The control message (e.g., path message and reservation message in
RSVP) packet flow and application data packet flow use the
different ATM cell-relaying channel. The information exchange
related to the control of cut-through pipe is performed using the
control message packet also.
Such information exchange is performed hop-by-hop, not end-to-end.
o Packet forwarding by cell switch
When the IP packet flow(s), whose requiring bandwidth is specified
and whose destinations are common (e.g., the same subnet), are
conveyed over dedicated-VCs, it can be forwarded by cell-switch
without any examination of IP packet header at the intermediate
routers. Other IP packet flows are forwarded using an IP packet
forwarder.
o Any size/model of ATM clouds interconnection
CSR router does not care about the size and model of ATM cloud that
the CSR router is attached. Any size and any model of ATM clouds
can be interconnected, while the packet forwarding performance will
be the same as the case where the ATM clouds are interconnected
without routers using P-NNI protocol.
Discussion
The following issues were discussed.
o RSVP Path/Reserve message over large cloud model
In the large cloud ATM model, a RSVP multicast would have a scaling
problem.
For the large scale multicast including large ATM cloud, there
would not be any router between the ingress router to the ATM cloud
and the down-stream routers (egress routers from ATM cloud). When
ATM cloud is large and RSVP multicast is large scale, i.e., large
fan-out within the multicast tree, the upstream router (ingress
router to the ATM cloud) will receive a large number of reserve
messages from the down-stream routers.
o Dynamic reservation status changing over ATM
RSVP and Integrated Service model allow to change the reservation
status (e.g., QoS class) during a session. Q.2931 does not have
QoS re-negotiation capability at this time. How to support dynamic
reservation status changing over ATM network must be solved.
o ATM-VCC channel and cut-through pipe establishment and tear-down
The decision criteria of ATM-VCC channel and cut-through pipe
establishment and tear-down is not clear enough. Basically, the
decision of ATM-VCC (i.e., dedicated VC) establishment and
tearing-down should be CSR router's local decision.
o Benefit of CSR model
The introduced CSR model may provide a new service benefit.
However, it is not explored enough during this BOF session. When
the introduced model can provide something, a new benefit, that ATM
cloud model cannot provide, it should be clarified.
o What is the standardization issue
Obviously, CSR architecture itself is not for standardization item.
But, for the implementation, we need some protocol to map flow
labels and VCI/VPI values. The point of standardization item must
be clarified, with the clarification of the benefits when we have
new protocol messages associated with the introduced CSR model.
o Document handling
The Internet-Drafts associated with CSR router (e.g.,
draft-katsube-router-atm-overview-00.txt) should be published as an
Informational RFC, from the viewpoint of the interworking between
ATM and RSVP.
VI. Conclusion and Summary
The issues and framework of IP packet transport with the provision of
QoS using ATM in large scale and heterogeneous Internet were discussed.
It was realized that the methodology and framework of mapping between
the QoS'ed IP packet flow defined by the resource reservation protocol
(e.g., ST-II and RSVP) and the ATM data-link connection (i.e., QoS'ed
cell-relaying channel) is the important issue to explore and this issue
has not been discussed in other working groups. The roughly identified
work items are:
o Architecture model documentation.
It was understood that CATENET does not need to be abandoned to
support ATM on the Internet; and, for example, the use of CATENET
model in ATM may provide the functions that LIS and large ATM cloud
model cannot.
It was agreed that architecture documents should be published as
Informational RFCs (i.e., there was no explicit objection to
requesting to publish the architectural documents as Informational
RFCs).
o Protocol development associated with the interaction between ATM
and ST-II/RSVP.
It was not understood by everybody that new protocols are needed
for the interaction between ATM and ST-II/RSVP. And even if they
are needed, whether it should be developed in a new working group
or in existing working groups.
o Large scale multicast over the Internet including ATM.
The work items should be clarified on the mailing list. The work items
raised in the BOF session relate to many other working groups, and may
overlap with other groups. The group could not decide whether to
propose to create a new working group. Joel Halpern said that a working
group cannot be created to only design a router. Further discussion and
clarification will take place on the mailing list.
VII. Existing Drafts
Internet-Draft: M. Ohta, H. Esaki, K. Nagami, ``Conventional IP over ATM,''
draft-ohta-ip-over-atm-02.txt, March, 1995.
Internet-Draft: H. Esaki, M. Ohta, K. Nagami, ``Connection Oriented and
Connectionless IP Forwarding over ATM Networks,''
draft-esaki-co-cl-ip-forw-atm-01.txt, Oct., 1994.
Internet-Draft: Y. Katsube, K. Nagami, H. Esaki, ``Router Architecture
Extensions for ATM: Overview,''
draft-katsube-router-atm-overview-00.txt.
