Subject: I-D for IP flow<->VC mapping

From: [email-masked] (KATSUBE Yasuhiro)
Date: Wed, 24 May 1995 00:34:52 +0900

Folks, 

As I wrote in my latest mail, I have written up an I-D which discusses
mapping issue between IP flow and datalink connection such as ATM-VC. 

I will appreciate your comments or suggestions, which had better be sent
to Colip mailing list I guess. 

Regards.

Yasuhiro Katsube
Toshiba 

------------------------- cut here ---------------------------------
                                          
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 <address/mask> pair.  

   Generally, one or more than one of the following four information 
   elements will be specified to express this attribute. 

    - <destination IP address/mask>
    - <destination port>
    - <source IP address/mask>
    - <source port> 

   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 : [email-masked]

   Ken-ichi Nagami
   R&D Center, Toshiba 
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
   Japan 
   Phone : +81-44-549-2238
   Email : [email-masked]

Katsube and Nagami        Expires Nov. 23, 1995                [page 14]