Internet DRAFT - draft-fujikawa-ipsvc

draft-fujikawa-ipsvc



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:00:14 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 06 May 1996 22:00:00 GMT
ETag: "2e69f8-5376-318e7660"
Accept-Ranges: bytes
Content-Length: 21366
Connection: close
Content-Type: text/plain



INTERNET-DRAFT                                           FUJIKAWA, Kenji
<draft-fujikawa-ipsvc-00.txt>                           Kyoto University
                                                           May 6th, 1996


            Another ATM Signaling Protocol for IP (IP-SVC)


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-abstracts.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 the IP-SVC that is another ATM signaling protocol
   for implementing IP protocols.  The IP-SVC restricts the range of
   signaling to an IP subnet and uses IP for signaling.  This
   restriction makes the IP-SVC structure simple.  The IP-SVC provides
   ease implementation of the mechanism of ARP and IP multicasting
   without any servers.

   The IP-SVC can not establish VCs across IP subnet boundaries by
   itself.  But adapting the conventional IP over ATM model with the
   RSVP enables end-to-end VC establishment across IP subnet boundaries.
   This method also shows one solution of RSVP over ATM.


1  Introduction

   Applications requiring broad bandwidth for transferring continuous
   media in the Internet have been being developed.  These applications
   require that the network be capable of IP multicasting, since these
   are used for something like conferences.  ATM networks can provide these
   applications with broad bandwidth and QoS.

   There are several IP over ATM models[FRAM][CLIP][NHRP], requiring some
   servers.  This means that these models are not so fault tolerant.  IP
   multicasting with MARS[MARS] also needs MARS servers.

   The problem of requiring servers is caused  from using UNI x.x as ATM

FUJIKAWA, K.           Expires November 6th, 1996               [Page 1]

INTERNET-DRAFT         draft-fujikawa-ipsvc-00.txt         May 6th, 1996

   signaling.  We propose a new ATM signaling protocol, IP-SVC, which is
   supposed to implement IP, and describe how to  implement this with IP
   and PVC interfaces.

   The IP-SVC restricts the range of signaling to an IP subnet and uses
   IP for signaling.  This restriction makes the IP-SVC structure
   simple.  The IP-SVC provides ease implementation of the mechanism of
   ARP and IP multicasting without any servers. We adapt the
   conventional model as an IP over ATM model, and describe signaling
   when RSVP is used as a resource reservation protocol.


2  Problem of Classical Model, NHRP and MARS

   In IP over ATM models that use UNI x.x for signaling, UNI x.x is
   considered as a network layer protocol. Thus they are trying to
   modify IP to fit to UNI x.x.  That is why servers are necessary.  But
   considering ATM network is only datalink layer technology, developing
   a new signaling scheme that suits to IP solves the problem.


3  Overview of IP-SVC   

   Considering ATM is only datalink layer protocol, the IP-SVC is
   designed to implement IP over it.  The IP-SVC has the following
   features:

    o a simple signaling protocol valid only in an IP subnet.

    o establishing VCs with soft state.

    o not modifying an ATM cell switching fabric.

    o providing ease implementation of IP unicasting and multicasting.

    o no servers such as ARP servers or MARS servers are necessary when
      constructing IP on the IP-SVC.

   
3.1  Environment

   The network where the IP-SVC is effective has the following features:

    o An IP subnet is small (the maximum number of hosts is about 200,
      ATM switches about 20)

    o ATM switches and hosts does not do signaling over IP subnet
      boundaries.  In this case, routers are needed .

   The IP-SVC is simple since the range of signaling is restricted to an
   IP subnet.

   You can establish end-to-end VCs between IP subnets that differs from
   each other, although routers has to forward the data.  This  function

FUJIKAWA, K.           Expires November 6th, 1996               [Page 2]

INTERNET-DRAFT         draft-fujikawa-ipsvc-00.txt         May 6th, 1996

   is described in the section 4.

	
3.2  IP-SVC system

   In the IP-SVC system, UDP/IP packets are used for ATM signaling to
   make the implementation of IP-SVC easy.

   Two daemons are designed for processing UDP packets for signaling.

   o atmsd
      An atmsd is the daemon that manages an ATM switch.  It decides a
      VPI/VCI value of a VC and set up an ATM switch with PVC
      interfaces, communicating with other atmsds and atmesds.

   o atmesd
      An atmesd is the daemon that manages ATM end systems such as ATM
      hosts (workstations), MPEG CODECs and etc.  It sets up VCs of ATM
      end systems with PVC interfaces, communicating with the atmsd it
      is connected to.

   These daemons communicate with one another with the predefined
   VPI/VCI and IP address (class D).

                        /-------\       /-------\
                        | atmsd |       | atmsd |
                        \-------/       \-------/
                          +----+          +----+ 
                          | \/ |          | \/ | 
                          | /\ |----------| /\ | 
            /--------\   /+----+          +----+\   /--------\
            | atmesd |  / ATM SW          ATM SW \  | atmesd |
            \--------/ /                          \ \--------/
                 +----+                            +----+
                 |    |                            |    |
                 +----+                            +----+
                /______\                          /______\
             ATM end system                    ATM end system

                           Figure 1: IP-SVC system


3.3 IP-SVC signaling protocol

   The daemons send UDP packets periodically so that VCs become soft
   state.  A VC is released if UDP packets for it are not received in
   some period of time.

   The signals of the IP-SVC are shown below:

   o JOIN
      An ATM host notifies to the adjacent ATM switch by JOINs that it
      wants to receive data sent to a certain IP address.  This address
      may be a multicast address.

FUJIKAWA, K.           Expires November 6th, 1996               [Page 3]

INTERNET-DRAFT         draft-fujikawa-ipsvc-00.txt         May 6th, 1996


   o LEAVE
      An ATM host notifies to the adjacent ATM switch by LEAVEs that it
      will not receive data sent to the IP address specified by them any
      more.

   o VC REQUEST
      An ATM host notifies to the adjacent ATM switch by VC REQUESTs
      that it wants to send data to a unicast address in the IP subnet
      or a multicast address.  This signal includes a VCID and a VC
      identifier which an ATM host decides.  VC REQUESTs cause VC
      NOTIFYs.

   o VC RELEASE
      An ATM host notifies to the adjacent ATM switch by VC RELEASEs
      that it will not use the VC specified by them any more.

   o VC NOTIFY
      An ATM switch sends VC NOTIFYs to other ATM switches and to ATM
      hosts to notify which VC corresponds to the IP address.  ATM
      switches and ATM hosts assign a VC to the IP address according to
      VC NOTIFYs.

   o ROUTE
      An ATM switch notifies the connection status of switches in the IP
      subnet by ROUTEs.  Units of a ATM switch and IP addresses which ATM
      hosts connected to it joins.

   In the IP-SVC, a VC REQUEST corresponds to an ARP request, and a VC
   NOTIFY corresponds to an ARP reply.  A JOIN and a ROUTE distribute
   joining information without discriminating between unicasting and
   multicasting.

   If a sending host sends VC REQUESTs with a VCID that differs from
   each other, it can use multiple VCs for one IP address, not
   concerning whether unicasting or multicasting. This mechanism enables
   an application to have its own VCs.
 

4 LAN by IP-SVC

4.1 VC Establishment for IP Unicasting

   The example of establishing a VC for IP unicasting is shown in Figure
   2, in which host B wants to send data to host A.  Note that signals
   are sent periodically.

   1) Host A sends JOINs including its own IP address to switch A.  The
      VC is not established at this moment.

   2) All the switches in the IP subnet become to know by ROUTEs that
      switch A has an adjacent host which wants to receive data sent to
      host A's IP address.


FUJIKAWA, K.           Expires November 6th, 1996               [Page 4]

INTERNET-DRAFT         draft-fujikawa-ipsvc-00.txt         May 6th, 1996

   3) Host B sends VC REQUESTs including host A's IP address.

   4) Switch B establishes the VC from host B to switch A, and sends VC
      NOTIFYs to host B and switch A.  VC NOTIFYs are also sent from
      switch A to host A.

   5) Each node establishes the VC according to the received VC NOTIFYs.

   6) Thus the VC from host B to host A is established.


               host A ---- switch A --- switch B ---- host B
                  |            |            |            |
                  | ---------> |            |            |
                  |   JOIN     | ---------> |            |
                  |            |   ROUTE    | <--------- |
                  |            | <--------- | VC REQUEST |
                  | <--------- |  VC NOTIFY | ---------> |
                  |  VC NOTIFY |            | VC NOTIFY  |
                  |            |            |            |
   
                Figure 2: VC establishment for IP unicasting


4.2 VC Establishment for IP Multicasting

   Next, the example of establishing a VC for IP multicasting is shown
   in Figure 3.  If there exist multiple hosts that send to the same IP
   multicast address, point-to-multipoint VCs are established per
   sender.  Figure 3 shows the case that there is one sender.

   1) Host B and C send JOINs to the adjacent switch of each in order to
      join multicast address M.

   2) Switch A can know by ROUTEs that a host connected to switch B and
      one connected to switch C joins multicast address M.  Note that
      the information that which hosts join multicast address M is not
      notified.

   3) Host A sends VC REQUESTs including multicast address M to switch A
      in order to establish a point-to-multipoint VC by which it can
      sends data to multicast address M.

   4) Switch A set up a point-to-multipoint VC from host A to switch B
      and C, and sends VC NOTIFYs to switch B and C.  Switch B and C set
      up a VC and send VC NOTIFYs to host B or C respectively.  

   5) Host A set up a send-only VC, and host B and C set up a
      receive-only VC, according to the received VC NOTIFYs

   6) If host D connected to switch C joins multicast address M by
      sending VC REQUESTs after the above setting, it receives VC
      NOTIFYs immediately.  Switch C should change the established VC into
      a point-to-multipoint one.

FUJIKAWA, K.           Expires November 6th, 1996               [Page 5]

INTERNET-DRAFT         draft-fujikawa-ipsvc-00.txt         May 6th, 1996


   7) The total VC illustrated in Figure 3 is established.


                           +----------------- switch C ---------------+
                           |                     +----------+         |
                           |                                |         |
   host B -- switch B - switch A -- host A                host C  host D

     |          |          |          |          |          |          |
     |--------->|          |          |          |<---------|          |
     |   JOIN   |--------->|<--------------------|   JOIN   |          |
     |          |  ROUTE   |        ROUTE        |          |          |
     |          |          |<---------|          |          |          |
     |          |          |VC REQUEST|          |          |          |
     |          |<---------|-------------------->|          |          |
     |          |VC NOTIFY |      VC NOTIFY      |          |          |
     |<---------|          |--------->|          |--------->|          |
     |VC NOTIFY |          |VC NOTIFY |          |VC NOTIFY |          |
     |          |          |          |          |          |          |
     |          |          |          |          |<--------------------|
     |          |          |          |          |        JOIN         |
     |          |          |          |          |-------------------->|
     |          |          |          |          |       VC NOTIFY     |
     |          |          |          |          |          |          |
   
                           +--------- A
                           |
     B<--------------------+---------------------+--------->C
              established p-to-mp VC             |
                                                 +-------------------->D

                Figure 2: VC establishment for IP multicasting


   In case that UNI 3.0/3.1 is utilized for IP multicasting, point to
   multipoint VCs are established in a sender initiated manner. Thus a
   sender has to know all the receivers.  Though a receiver initiated
   manner is available in case of UNI 4.0, a receiver has to know all
   senders.

   In the IP-SVC, A sender do not have to know which are receivers, and
   receivers do not have to know which are senders.  That means the
   IP-SVC is very suitable to the current IP multicasting scheme.


4.3  Adaptation of Conventional Model

   The IP-SVC can not establish VCs across IP subnet boundaries by
   itself, since it restricts the range of signaling to an IP subnet.
   Routers, therefore, assemble cells to a packet and re-fragment it to
   cells, so it is hard to make use of the advantage of ATM that end to
   end QoS assurance is available.


FUJIKAWA, K.           Expires November 6th, 1996               [Page 6]

INTERNET-DRAFT         draft-fujikawa-ipsvc-00.txt         May 6th, 1996

   Adapting the conventional model as an IP over ATM model solves the
   problem.  The conventional model provides the special routers, CSRs
   (Cell Switching Router), which enable end-to-end VC establishment
   across IP subnet boundaries if resource reservation protocols such as
   RSVP precede the data transfer.  VC establishment using RSVP and CSRs
   is described in 4.4.


4.4  Utilizing RSVP

   The IP-SVC provides the method of specifying a service (UBR or CBR)
   and maximum bit rate.  In case of communication without resource
   reservations, however, only UBR services are applied to applications.
   Each application communicating with ones of the same IP address uses
   a single VC of UBR in this case.  An application can use a separate
   VC of CBR when it reserve the communication by RSVPs or something.

   Figure 4 shows a network where IP subnets that consist of a ATM
   network are connected by CSRs.  RSVP PATHs and RSVP RESERVs are sent
   with pre-established UBR VCs.  Assume that the reserved VC of CBR
   from host S to CSA A has been already established in Figure 4.


      host R -- switch -- CSR B --- switch -- CSR A --- switch -- host S   
        |         |         |         |         |         |         |
        |         |         |         |         |<------------------|
        |         |         |         |         |     RSVP PATH     |
        |         |         |<------------------|         |         |
        |         |         |     RSVP PATH     |         |         |
        |<------------------|         |         |         |         |
        |     RSVP PATH     |         |         |         |         |
        |------------------>|         |         |         |         |
        |    RSVP RESERV    |         |         |         |         |
        |-------->|         |------------------>|         |         |
        |  JOIN   |         |    RSVP RESERV    |         |         |
        |         |<--------|-------->|         |         |         |
        |         | VC REQ. |  JOIN   |         |         |         |
        |<--------|-------->|         |<--------|         |         |
        |VC NOTIFY|VC NOTIFY|         | VC REQ. |         |         |
        |         |         |<--------|-------->|         |         |
        |         |         |VC NOTIFY|VC NOTIFY|         |         |
        |         |         |         |         |         |         |

        Figure 4: VC establishment over IP subnet boundaries by RSVP


   The routine of establishing the VC from host S to R is as the
   following:

   1) RSVP PATHs are sent through intermediate CSRs from host S to R.

   2) Host R sends RSVP RESERVs to CSR B, and also sends JOINs if RSVP
      RESERVs includes a multicast address which host R must join.


FUJIKAWA, K.           Expires November 6th, 1996               [Page 7]

INTERNET-DRAFT         draft-fujikawa-ipsvc-00.txt         May 6th, 1996

   3) CSR B, which receives RSVP RESERVs, specifying QoSs, the host R
      address or the multicast address and a new VCID, sends VC REQUESTs.

   4) VC NOTIFYs are sent to host R, to CSR B and to the intermediate
      switches.  Then the VC from host R to CSR B is established.

   5) The VC between CSR B and A is established in the same way.  The VC
      between host S and CSR A, however, is not created because it
      already exists.

   6) Each CSR recognizes the VCs which is on the way from host S to
      R, and treats them as a single VC by its cell-relaying fabric.
      The delay caused by assembling cells into packets does not occur.
      Finally the end-to-end VC is established.

   In the RSVP, routers merge different incoming RSVP RESERV messages
   into one outgoing RSVP RESERV message, that is, data paths are merged
   by routers.  IP over ATM models that use UNI x.x instead of using IP
   routers, data paths are decided with no relation to IP.  It is,
   therefore, difficult to implement the mechanism of merging data
   paths. In the conventional model with the IP-SVC, that problem does
   not arise.

   The SINP[SINP] is also used for notifying correspondences between a
   VC and a session.  But this mechanism is not described in this
   document.


5  Related Works

   The Ipsilon approach[FLMN][FLLB] is similar to the IP-SVC at the
   point that it discards Q.2931 signaling but make use of IP for
   signaling.  The main difference between the Ipsilon approach and the
   IP-SVC is that the Ipsilon approach makes all ATM switches IP routers
   like CSR, while the IP-SVC does not.  Multiple IP-SVC's ATM switch
   can be connected to one another in a single IP subnet.


References

   [FRAM] Cole, R., et al., "IP over ATM: A Framework Document", RFC1932,
          April 1996.

   [CLIP] Laubach, M., et al., "Classical IP and ARP over ATM", RFC1577, 
          January 1994.

   [CVIP] Ohta, M., et al., "Conventional IP over ATM", IETF Internet
          Draft (work in progress), draft-ohta-ip-over-atm-02.txt, 
          March 1995.

   [NHRP] Heinanen, J., et al., "NBMA Next Hop Resolution Protocol (NHRP)",
          IETF Internet Draft (work in progress), 
          draft-ietf-rolc-nhrp-07.txt, December 1995.


FUJIKAWA, K.           Expires November 6th, 1996               [Page 8]

INTERNET-DRAFT         draft-fujikawa-ipsvc-00.txt         May 6th, 1996

   [RSVP] Zhang, L., et al.,  "Resource ReSerVation Protocol  (RSVP),
          Version 1 Functional Specification", IETF Internet Draft 
          (work in progress), draft-ietf-rsvp-spec-07.ps, April 1995.

   [MARS] Amitage, G., "Support for Multicast over UNI 3.0/3.1 based 
          ATM Networks", IETF Internet Draft (work in progress),
          draft-ietf-ipatm-ipmc-12.txt, February 1996.

   [MCST] Deering, S., "Host Extensions for IP Multicasting", RFC1112,
          August 1989.

   [SINP] Goto, Y., "Session Identity Notification Protocol (SINP)",
          IETF Internet Draft (work in progress), 
          draft-goto-sinp-01.txt, January 1996.

   [FLMN] Newman, P., et al., "Ipsilon Flow Management Protocol 
          Specification for IPv4  Version 1.0", IETF Internet Draft 
          (work in progress), draft-rfced-info-flowman-00.txt,
          February 1996.

   [FLLB] Newman, P., et al., "The Transmission of Flow Labelled IPv4 on 
          ATM Data Links  Version 1.0", IETF Internet Draft 
          (work in progress), draft-rfced-info-flowlabel-00.txt,
          February 1996.


Author's Address

   FUJIKAWA, Kenji
   Department of Information Science,
   Faculty of Engineering, Kyoto University
   Yoshidahonmachi, Sakyo Ku, Kyoto city, 606-01, Japan
   Phone : +81 75-753-5387
   Email : magician@kuis.kyoto-u.ac.jp





















FUJIKAWA, K.           Expires November 6th, 1996               [Page 9]