Internet Draft
Internet Draft Yasuhiro Katsube
Ken-ichi Nagami
(Toshiba R&D Center)
May 23 , 1995
Mapping of IP Flow to Datalink Layer Connection
<draft-katsube-flow-mapping-dl-conn-00.txt>
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-abstract.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 memo describes an information exchange protocol which enables
IP nodes (hosts or routers) to associate various kinds of "flow"
with "datalink connections". By performing such an information
exchange between adjacent nodes, some of functions performed in the
routers (e.g., classification of datagrams with regard to output
interface and/or requesting service class) would be able to be
carried out without (or before) analyzing each datagram but by
referring to a datalink connection ID which conveys the datagram.
This facilitates the routers to provide high-throughput and
QoS-supported services much more efficiently.
Katsube and Nagami Expires Nov. 23, 1995 [page 1]
Internet Draft May 23, 1995
1. Introduction
Connection-oriented (CO) datalink services such as ATM, Frame-Relay
(FR) or ISDN are being introduced in the Internet as well as
connectionless (CL) ones such as Ethernet/EtherSwitch or FDDI.
The most remarkable difference of CO datalinks from CL ones is
capability of providing multiple virtual connections between
adjacent nodes (hosts/routers). Each of the virtual connections can
be used to segregate traffic (datagrams) while all the traffic can
be aggregated to a single virtual connection. Decision of such
traffic segregation/aggregation in the router will be done based on
various attributes of datargams such as requesting service class,
destination and/or source IP address (or address prefix).
For example, when a router connected to ATM has received a resource
reservation request for guaranteed QoS service[GUARANTEED-00], it
will need to set up a new CBR ATM-VC toward its next-hop router even
when it already has an ABR ATM-VC toward that router. On the
contrary, another resource reservation request for controlled-delay
service[CONT-DELAY-00] may be accommodated to the ABR ATM-VC provided
that the VC has enough bandwidth left. This is an example of traffic
segregation based on the service class.
Another example is the case in which a router has received a resource
reservation request for some end-end session and has set up an ATM-VC
dedicated to the requested session toward the next-hop router.
In this case, the router would not accept any other resource
reservation requests nor accommodate any best-effort datagrams into
the ATM-VC. This is an example of traffic segregation based on the
source/destination addresses (and possibly port addresses).
Here we define a word "flow" as a group of datagrams which are
characterized by various attributes such as their service class,
source/destination addresses, source/destination ports, and so on.
The flow in this memo does not necessarily mean IPv6 flow but allows
various levels of aggregations or segregations. As shown in the
above examples, routers may accommodate a single flow to a virtual
connection, or accommodate multiple flows to it which have several
common attributes. Routers connected to CO datalinks can identify
these attributes not by analyzing datagrams but by referring to the
virtual connection ID which conveys the datagrams, provided that the
routers have mapping information between the attributes of the
datagrams and the virtual connection ID. That will enable routers
to perform more efficient and optimized datagram processing.
Katsube and Nagami Expires Nov. 23, 1995 [page 2]
Internet Draft May 23, 1995
This memo describes advantages of letting routers have mapping
information between each of datalink layer virtual connections
they terminate and various attributes of flows in it. Then it
describes possible message formats and protocol examples to enable
such information exchanges.
2. Mapping between Flows and Datalink Layer Virtual Connection
A flow in this memo can be specified by the following attributes.
1) Protocol (e.g., IP/IPX/Appletalk/... , IPv4/IPv5/IPv6)
2) Service class (e.g., Guaranteed/Predictive 1,2,3/
Controlled Delay1,2,3/Best Effort)
3) Address (e.g., address/mask/port for source and/or destination)
For example, a flow may be specified by {Protocol=IPv4, service
class=Any, Address=[destination:133.196.1.0, mask:255.255.
255.0, port:any]}, while another flow may be specified by
{protocol=IPv6, service class=Guaranteed, Address=[source:133.196.
1.1, mask:255.255.255.255, port:16]}.
When a datalink is CO, datagrams of each flow toward a next-hop
node are transmitted over one of the virtual connections which is
deemed adequate. Multiple flows can be multiplexed to the same
virtual connection when it is allowed. In the case that none of
the existing virtual connections is available for newly originated
flow for some reason (lack of bandwidth, service class of the flow
is unacceptable to the virtual connection, etc.), a new virtual
connection for the flow may be established.
When a router knows the mapping relationship between a virtual
connection it terminates and attributes of flows accommodated to
the virtual connection, the following advantages are expected.
- Since a router can identify the protocol 1) of the incoming
datagram just by referring to the virtual connection ID, it can
assign an appropriate processor resource for the protocol in a
multiple processors environment without (or before) referring
to the datagram itself.
- Since a router can identify the service class 2) of the incoming
datagram just by referring to the virtual connection ID, it can
classify the datagram with regard to the QoS without (or before)
Katsube and Nagami Expires Nov. 23, 1995 [page 3]
Internet Draft May 23, 1995
referring to the datagram itself. That is, scheduling at an
input driver would become possible, which would be effective
when the processing capability of an IP forwarder (classifier)
is not powerful enough compared to the incoming line rate.
- Since a router can identify the address information 3) of the
incoming datagram just by referring to the virtual connection ID,
it can determine a next-hop node, an output interface, and
possibly a virtual connection (when output datalink is also CO) to
transmit the datagram without referring to the datagram itself.
Generally speaking, some of the tasks currently performed at an IP
forwarder could be replaced by the tasks of datalink layer processing
functions by letting routers have the mapping information between IP
flow(s) and a virtual connection ID at the datalink.
3. Flow Attribute Notification Protocol (FANP)
In order to enable routers to acquire mapping information between
each virtual connection ID and attributes of flow(s) in it, routers
require some protocol which exchanges such information with adjacent
routers or hosts. We call this protocol "Flow Attribute Notification
Protocol (FANP)". This protocol should be independent of a specific
datalink technology (ATM, FR, or ISDN etc.), and be independent of
whether the datalink connection is set up by management procedure
(permanent-connection) or by signaling procedure (switched-
connection).
3.1 Overview
In order that a peer nodes share a common knowledge about a virtual
connection and attributes of flow(s) which is(are) accommodated to
the virtual connection, a message exchanged by the peer nodes should
be able to specify both information; "flow(s)" and "virtual
connection".
Virtual connection should be identified as a common value by a
peer nodes. Since connection identifier in the header of a datalink
layer packet (e.g., VCI in ATM or DLCI in Frame Relay) does not
generally have common value at each end, another identifier which is
common at both ends should be defined.
Flow is defined as an aggregate of datagrams which are specified by
one or more than one of the following attributes.
Katsube and Nagami Expires Nov. 23, 1995 [page 4]
Internet Draft May 23, 1995
a) Protocol
As identifications of protocols at several levels, Protocol Type
such as IP, IPX or Appletalk, Protocol Version such as IPv4, IPv5
or IPv6, Protocol ID such as UDP or TCP, would be possible.
- Protocol Type (e.g., IP, IPX, Appletalk)
- Protocol Version (e.g., IPv4, IPv5, IPv6)
- Protocol ID (e.g., TCP, UDP)
b) Address/Port
Source node address or destination node address specifies origination
point or termination point for detagrams respectively. Source port
address or destination port address for TCP/UDP specifies origination
or termination service interface for datagrams respectively.
In order to enable to specify a group of nodes (e.g., network or
subnetwork) as well as a single node, source or destination node
address is expressed as pair.
Generally, one or more than one of the following four information
elements will be specified to express this attribute.
-
-
-
-
For example, a flow that is specified by the destination address/mask
value <133.196.1.0/255.255.255.0> signifies datagrams whose
destination addresses spans from 133.196.1.0 to 133.196.1.255. When
the above flow is further specified by the source address/mask value
<133.222.1.1/255.255.255.255>, the flow can include datagrams whose
source address is 133.222.1.1 and the destination addresses spans
from 133.196.1.0 to 133.196.1.255. When the above flow is further
specified by the destination port value <16>, the flow can include
datagrams whose source address is 133.222.1.1, the destination
addresses spans from 133.196.1.0 to 133.196.1.255, and the
destination ports in all those addresses are 16.
c) Connection Identifier
Besides or instead of the above-mentioned addresses/ports in the
datagrms, flow may be identified by a sort of connection or flow ID
in the datagrams. Examples of them are Stream ID of STII or Flow ID
of IPv6.
Katsube and Nagami Expires Nov. 23, 1995 [page 5]
Internet Draft May 23, 1995
d) Service Class/QoS
An aggregate of datagrams which have the same service class or QoS
requirements may be regarded as a single flow.
As of now, service class or QoS can be specified by TOS in IPv4 or
Priority in IPv6 both of which are included in the IP header, or be
specified by one of the services currently being defined in Intserv
WG (Guaranteed, Predictive[PREDICTIVE-00], Controlled-delay).
e) IP Options
An aggregate of datagrams specified by the same IP option such as
"source route" may be defined as being a "flow".
As already described, one or more than one of the above items can
be specified to define various levels of flow. Some flow may be
specified by only "protocol : IPv4" and "service class :
Guaranteed", while some other flow may be specified by "protocol :
IPv6", "destination address/mask/port : 133.196.1.1/255.255.255.255
/16", and "service class : predictive".
Although below mainly discusses IP, this discussion applies to any
other network protocols.
3.2 Protocol Sequence Examples
Messages which constitute FANP (Flow Attribute Notification Protocol)
between adjacent nodes may be transferred over the very virtual
connection in which the actual datagrams of a flow are also
transmitted (Inband message). Or they may be transferred over the
virtual connection which is different from the virtual connection in
which the actual datagrams of a flow are transmitted (Outband
message).
An example of FANP protocol sequence over ATM datalink is shown in
Figure 1. Here a direction of datagrams is assumed to be from router
R1 to router R2. After an ATM connection VC1 is set up between R1
and R2 with some trigger (e.g., detection of datagrams, reception of
IP resource reservation message), R1 sends an ADD_FLOW message to R2.
This message indicates that R1 will transmit (or is transmitting)
datagrams belonging to flow1, which is characterized by several
attributes described in the previous subsection, over VC1. R2 may
return an ADD_ACK message to R1.
Then R1 sends an ADD_FLOW message to notify that it will transmit (or
is transmitting) datagrams belonging to another flow flow2, which
Katsube and Nagami Expires Nov. 23, 1995 [page 6]
Internet Draft May 23, 1995
is characterized by attributes distinct from flow1, over the VC1. A
trigger of this message may be the reception of IP resource
reservation message for the flow2, or may be the detection of
datagrams belonging to the flow2. R2 this time returns an ADD_ERROR
message to R1 in order to indicate that it refuses to receive flow2
from VC1 with some reason, or to indicate that it finds some error in
the received ADD_FLOW message. Then R1 sets up another ATM
connection VC2 toward R2, and sends an ADD_FLOW message to R2 to
indicate an accommodation of flow2 into VC2, which is accepted by
ADD_ACK message.
When the resource reservation at IP level has expired or some other
conditions (e.g., detection of no datagrams for some amount of
period) are met, a DEL_FLOW message is sent for each flow.
Mapping or deletion of multiple flows to or from a VC by a single
message would also be possible.
+---------------+
| |
from LAN -- R1 --| ATM-LAN |--R2 -- to LAN
| |
+---------------+
Setup VC1 (ATM signaling)
<- - - - - - - - - ->
ADD_FLOW{flow1,VC1} ------------------>
<------------------ ADD_ACK{flow1,VC1}
ADD_FLOW{flow2,VC1} ------------------>
<------------------ ADD_ERROR{flow2,VC1}
Setup VC2 (ATM signaling)
<- - - - - - - - - ->
ADD_FLOW{flow2,VC2} ------------------>
<------------------ ADD_ACK{flow2,VC2}
DEL_FLOW{flow1,VC1} ------------------>
<------------------ DEL_ACK{flow1,VC1}
DEL_FLOW(flow2,VC2} ------------------>
<------------------ DEL_ACK{flow2,VC2}
Figure 1 FANP Protocol Example
Katsube and Nagami Expires Nov. 23, 1995 [page 7]
Internet Draft May 23, 1995
Through these sequence, R2 can always know the attributes of flows
accommodated to individual VCs it receives, which leads to several
advantages in the datagram processing algorithm in R2 as described
in section 2. Regarding whether the ACK or ERROR messages are
necessary requires further study. That is, whether the mapping of
flows onto VCs should be able to be negotiated between routers that
terminate the VC, or all the decision about mapping of flows onto VCs
should be made only by the upstream routers, requires further
consideration. Initial decision regarding in what VC each flow
should be carried, including the determination of the ATM service
class acceptable for the flow, will be made by the upstream node.
Another example of FANP protocol sequence in conjunction with an RSVP
protocol sequence[RSVP-05] is shown in Figure 2. Three ATM datalinks
and one EtherSW-based datalink are assumed to be used for datagram
transmission from Host S1 to D1.
Host Router Router Router Host
S1 R1 R2 R3 D1
\ / \ / \ / \ /
+\--------/+ +\-------/+ +\-------/+ +\--------/+
| ATM | | ATM | | ATM | | Ether |
| | | | | | | SW |
+----------+ +---------+ +---------+ +----------+
RSVP Path RSVP Path RSVP Path RSVP Path
-----------> ----------> ----------> ----------->
RSVP Resv RSVP Resv
<---------- <-----------
ATM VC setup
RSVP Resv <--------->
<---------- ADD_FLOW
ADD_FLOW ==========>
RSVP Resv ==========>
<-----------
ATM VC setup
<---------->
ADD_FLOW
===========>
Figure 2 An Example of FANP Sequence with RSVP
Katsube and Nagami Expires Nov. 23, 1995 [page 8]
Internet Draft May 23, 1995
When a router R2 receives an RSVP Resv message from a router R3 for a
session between S1 and D1, it decides to set up a new ATM VC between
R2 and R3 for the requested session. After setting up the new ATM
VC, R2 sends a FANP ADD_FLOW message to R3, which would include
attributes of requested RSVP session such as dest.IP#, dest.port#,
sourceIP#, and service class. Then R2 sends RSVP Resv message to its
upstream router R1. When R1 receives RSVP Resv message for the
session, it decides to accommodate the requested session to an
existing ATM VC between R1 and R2. Then it does not set up a new ATM
VC but sends a FANP ADD_FLOW message to R2, which would indicate
attributes of requested RSVP session also. With regard to the
procedure between S1 and R1, almost the same thing as the procedure
between R2 and R3 would apply. (ADD_ACK or ADD_ERR messages are
omitted in Figure 2)
3.3 Message Format
FANP messages consist of a common header followed by a VCID (Virtual
Connection Identifier) and attributes of flows. Addition or deletion
of more than one flows may be notified in a single message, and more
than one attributes will be specified for a single flow.
Format of the common header is shown in Figure 3.
0 15 16 31
+------+------+-------------+-------------+-------------+
| Ver | Flag | Checksum |
+------+------+-------------+-------------+-------------+
| Type |
+-------------+
Ver : Protocol version number. This is version 1.
Flag : TBD
Type : Prescribes message types.
1 = ADD_FLOW 2 = DEL_FLOW
3 = ADD_ACK 4 = DEL_ACK
5 = ADD_ERROR 6 = DEL_ERROR
Checksum : checksum for whole of the message
Figure 3 Common Header for FANP Messages
Katsube and Nagami Expires Nov. 23, 1995 [page 9]
Internet Draft May 23, 1995
3.3.1 ADD_FLOW / DEL_FLOW Message
Format of ADD_FLOW and DEL_FLOW are shown in Figure 4.
0 15 16 31
+------+------+-------------+-------------+-------------+
| Ver | Flag | Checksum |
+------+------+-------------+-------------+-------------+
| Type (1or2) | Message ID | # of Flows | Type of VC |
+-------------+-------------+-------------+-------------+
| VCID |
+-------------+-------------+-------------+-------------+
/ Flows /
/ .... /
/ .... /
+-------------+-------------+-------------+-------------+
Message ID : Sequential number given by an originator of this
message. ADD_FLOW/DELETE_FLOW and ADD_ACK/DELETE
_ACK are associated at routers by identifying
this value.
# of Flows : Number of flows an originator of this message
wants to add/delete to/from the virtual connection.
Type of VC : Indicates network which provides VC.
1 = ATM
VCID : Virtual connection ID value which is unique between
a peer nodes.
Flows : Includes one or more than one flows, the number of
which is shown as "# of Flows", each of which is
identified by its own way. Examples of flow
description are shown below.
Figure 4 ADD_FLOW / DEL_FLOW Message
Katsube and Nagami Expires Nov. 23, 1995 [page 10]
Internet Draft May 23, 1995
Attributes of a flow begin with a Type of Flow field followed by
actual attribute values.
0 15 16 31
+-------------+-------------+-------------+-------------+
| Type of Flow | - - - - - - - - - |
+-------------+-------------+-------------+-------------+
/ Attributes of Flow /
/ .... /
/ .... /
+-------------+-------------+-------------+-------------+
Type of Flow : Indicates what attributes are specified to
define a flow. Each of sixteen bits shows
whether each attribute is specified or not
to define a flow. A possible example is
15 bit : Source Address/Mask
14 bit : Destination Address/Mask
13 bit : Source Port
12 bit : Destination Port
11 bit : TBD
[...] [...]
0 bit : TBD
Figure 5 Flow Description Format
According to above, examples of flow description are as follows.
0 15 16 31
+-------------+-------------+-------------+-------------+
| Type of Flow = 2 | - - - - - - - - - |
+-------------+-------------+-------------+-------------+
| Destination Address |
+-------------+-------------+-------------+-------------+
| Destination Address Mask |
+-------------+-------------+-------------+-------------+
Figure 6 Examples of Flow Description
Katsube and Nagami Expires Nov. 23, 1995 [page 11]
Internet Draft May 23, 1995
0 15 16 31
+-------------+-------------+-------------+-------------+
| Type of Flow = 3 | - - - - - - - - - |
+-------------+-------------+-------------+-------------+
| Source Address |
+-------------+-------------+-------------+-------------+
| Source Address Mask |
+-------------+-------------+-------------+-------------+
| Destination Address |
+-------------+-------------+-------------+-------------+
| Destination Address Mask |
+-------------+-------------+-------------+-------------+
0 15 16 31
+-------------+-------------+-------------+-------------+
| Type of Flow = 15 | - - - - - - - - - |
+-------------+-------------+-------------+-------------+
| Source Address |
+-------------+-------------+-------------+-------------+
| Source Address Mask |
+-------------+-------------+-------------+-------------+
| Destination Address |
+-------------+-------------+-------------+-------------+
| Destination Address Mask |
+-------------+-------------+-------------+-------------+
| Source Port | Destination Port |
+---------------------------+---------------------------+
Figure 6 Examples of Flow Description (Cont'd)
3.3.2 ADD_ACK / DEL_ACK Message
0 15 16 31
+------+------+-------------+-------------+-------------+
| Ver | Flag | Checksum |
+------+------+-------------+-------------+-------------+
| Type (3or4) | Message ID | - - - - - | Type of VC |
+-------------+-------------+-------------+-------------+
| VCID |
+-------------+-------------+-------------+-------------+
Figure 7 ADD_ACK / DEL_ACK Message
ADD_ACK and DELETE_ACK are associated with ADD_FLOW and DEL_FLOW
by referring to the Message ID value.
Katsube and Nagami Expires Nov. 23, 1995 [page 12]
Internet Draft May 23, 1995
3.3.3 ADD_ERROR / DEL_ERROR Message
0 15 16 31
+------+------+-------------+-------------+-------------+
| Ver | Flag | Checksum |
+------+------+-------------+-------------+-------------+
| Type (5or6) | Message ID | Cause | Type of VC |
+-------------+-------------+-------------+-------------+
| VCID |
+-------------+-------------+-------------+-------------+
Figure 8 ADD_ERROR / DEL_ERROR Message
ADD_ERROR and DEL_ERROR are associated with ADD_FLOW and DEL_FLOW
by referring to the Message ID value. This message will be issued
when the received ADD_FLOW or DEL_FLOW message has some error in
its format, or when the received ADD_FLOW or DEL_FLOW message is not
acceptable. Further study is required regarding any other reasons.
The reason is indicated by "Cause" field.
4. Open Issues
TBD
5. Acknowledgements
We are grateful to Hiroshi Esaki and Takeshi Saito of Toshiba for
their helpful comments.
6. References
[GUARANTEED-00] S. Shenker and C. Partridge, "Specification of
Guaranteed Quality of Service", IETF Internet Draft (work in
progress), draft-ietf-intserv-guaranteed-svc-00.txt, March 1995.
[PREDICTIVE-00] S. Shenker and C. Partridge, "Specification of
Predictive Quality of Service", IETF Internet Draft (work in
progress), draft-ietf-intserv-predictive-svc-00.txt, March 1995.
[CONT-DELAY-00] S. Shenker and C. Partridge, "Specification of
Controlled Delay Quality of Service", IETF Internet Draft (work in
progress), draft-ietf-intserv-controlled-delay-svc-00.txt, March
1995.
Katsube and Nagami Expires Nov. 23, 1995 [page 13]
Internet Draft May 23, 1995
[RSVP-05] L. Zhang, et al., "Resource ReSerVation Protocol (RSVP),
Version 1 Functional Specification", IETF Internet Draft (work in
progress), draft-ietf-rsvp-spec-05.ps, April 1995.
7. Authors' Address
Yasuhiro Katsube
R&D Center, Toshiba
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
Email : katsube@isl.rdc.toshiba.co.jp
Ken-ichi Nagami
R&D Center, Toshiba
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
Email : nagami@isl.rdc.toshiba.co.jp
Katsube and Nagami Expires Nov. 23, 1995 [page 14]