Internet Draft Yasuhiro Katsube Ken-ichi Nagami (Toshiba R&D Center) May 23 , 1995 Mapping of IP Flow to Datalink Layer Connection 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]