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]