Internet DRAFT - draft-fujisawa-ip1394-rsvp-00

draft-fujisawa-ip1394-rsvp-00



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:00:44 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 29 Jul 1997 08:12:37 GMT
ETag: "2e6d9f-1df2-33dda5f5"
Accept-Ranges: bytes
Content-Length: 7666
Connection: close
Content-Type: text/plain


INTERNET DRAFT                                               K. Fujisawa
Expires August 1, 1997
draft-fujisawa-ip1394-rsvp-00-970725.txt                       
                                                               July 1997

                A proposal for RSVP over IEEE 1394

Status of this Memo

/* NOT YET
   This document is an Internet-Draft.   .....
*/

Abstract

   This document describes a proposal for transmission of RSVP
   message over IEEE 1394 serial bus.


1. Introduction

IEEE 1394 is ...

To use isochronous communication over IEEE 1394, the sender 
(or somebody) must allocate the bandwidth and the channel number 
from isochronous resouce manager on each bus before transmitting
isochronous packet.

When two 1394 buses are connected by a bridge, the sender (or somebody)
must allocate bandwidth and channel number on each bus,
and configure the bridge to pass isochronous stream.

Some mechanism is required to indicate the channel number
from sender to receiver and bridge.

The difficulty is the channel number may change on each 1394-bus.

                                     ch'             R1
              S  ch              -+------------------+-- bus-2
      bus-1 --+----------+----- Bridge
                         R3      -+------------------+-- bus-3
                                     ch"             R2

		ch, ch', ch" 	channel for each bus
		S 		sender
		Rx 		receiver

	Figure 1. sample topology


The author propose to use RSVP [4] to indicate the channel number
and to configure the bridge.

The bridge acts similary to a RSVP router.
It examins RSVP message, process it, and forward it.
It allocate a isochronous channel and bandwidth for a RSVP flow 
when necessary. Detailed behavior is described bellow.


2. Proposal

2.1 isochronous channel

LIH (Logical Interface Handle) in RSVP_HOP object is used 
to indicate the channel number.

The format of LIH for 1394-interface is,

31                                                 6 5         0
+---------------+---------------+---------------+-+-+-----------+
|                    local use                    |v|  channel  |
+---------------+---------------+---------------+-+-+-----------+

bit 0 - 5	channel number for a flow on a bus
bit 6		1: channel field is valid
		0: no channel is allocated yet
bit 7 - 31	local use for PATH message sender (opaque to receiver)

RSVP router may use 'local use' field for its own purpose, such 
as for tunneling.
Bridge may use this field to identify its port number.
This field shall not interpreted by the receiver of PATH message.


The sender or the ingress RSVP router should allocate a isochronous
channel after it receives a RESV message.


2.2 trasmission of RSVP message

To reduce the overhead of the bridge, RSVP messages over IEEE 1394 
shall be sent as a IP multicast packet (even if the session is for 
unicast). The address is TBD.
Every node which supports RSVP and the bridge shall listen
this address.

For unicast session, the sender or the ingress router
shall add LAN_NHOP object described in SBM [5] to PATH message.
LAN_NHOP object contains a IP unicast address of the receiver or 
egress router.
The purpose of LAN_NHOP is that the bridge can forward RSVP 
message and configure isochronous channel properly when the 
destination host exists in outside of a 1394 subnet.
The egress router shall remove LAN_NHOP object when it forwards
PATH message to outside of 1394 subnet.


2.3 operation of 1394 bridge

Even the bridge, it shall have a IP address.
The bridge shall act as a RSVP router, process the RSVP messages,
forward them, and allocate & release resouces.
It shall configure the registers such as CHANNEL_SWITCH[], 
OUTPUT_PLUG[], INPUT_PLUG[] by itself.
(the sender is not required to configure the bridge)

                                     PATH(ch') -->   R1
              S  PATH(ch) -->    -+------------------+-- bus-2
      bus-1 --+----------+----- Bridge
                         R3      -+------------------+-- bus-3
                                     PATH(ch") -->   R2

	Figure 2. sample flow of RSVP PATH messages (for multicast)


The bridge shall discard RSVP PATH message when the LAN_NHOP is 
reaced via a port where the message is received.

The bridge should allocate the isochronous channel on necessary.
(channel is allocated on a inbound port, and at least one receiver
exists for a flow on a outbound port).

The bridge shall release the channel when it detect the channel 
is not required any more (PATH_TEAR, last RESV_TEAR on a outbound 
port, or timed out).


         S             Bridge          R1              R2
        =======================================================
        PATH (no) --->
                       PATH (no) ---->
                       PATH (no) ------------------->
                                  R1 joined here
                                  <--- RESV (no)
                  <--- RESV (no)
        alloc ch on bus-1
        PATH (ch) --->
                       alloc ch' on bus-2
                       PATH (ch') --->
                                  <--- RESV (ch')
                  <--- RESV (ch)


                       PATH (no) ------------------->
                                                   R2 joined here
                                 <------------------- RESV (no)
                       alloc ch" on bus-3
                       PATH (ch") ------------------>
                                 <------------------- RESV (ch")

	    (some transactions are omitted in this figure)

	Figure 3. sample flow of RSVP messages


3. Security Considerations

   Security issues are not discussed in this document.


4. Acknowledgments

   The author acknowledge Masataka Ohta, he suggested to use 
   LIH to indicate channel number.


5. References

   [1] IEEE, "Standard for a High Performance Serial Bus", IEEE 
       1394-1995, 1995.

   [2] IEEE P1394a WG, "Draft Standard for a High Performance Serial 
       Bus (Supplement)", P1394a Draft 0.09, June 1997.
       ftp://ftp.symbios.com/pub/standards/io/1394/P1394a/Drafts/
       P1394a09.pdf

   [3] IEEE P1394.1 WG, "Draft Standard for a High Performance Serial
       Bus Bridges", P1394.1 Draft 0.02, March 1997.
       ftp://ftp.symbios.com/pub/standards/io/1394/P1394.1/Drafts/
       D00_02.pdf

   [4] R. Braden, et al, "Resource ReSerVation Protocol (RSVP)", 
       draft-ietf-rsvp-spec-16.txt, June 1997

   [5] R. Yavatkar, et al, "SBM (Subnet Bandwidth Manager)",
       draft-yavatkar-sbm-ethernet-03.txt, February 1997


6. Authors' Addresses


Appendix A.  The difference with SBM [5]


--------------------------------+------------------------------------
	SBM			|	1394
================================+====================================
DSBM per MS(Managed Segment)	| Bridge at bus boundary
--------------------------------+------------------------------------
manage bandwidth in a MS	| allocate channel number & bandwidth
				| channel number modification
				| (resouces are managed by isochronous
				|  resouces manager)
--------------------------------+------------------------------------
AllSBMAddress and		| some multicast address TBD
DSBMLogicalAddress for RSVP	| (maybe same with AllSBMAddress)
--------------------------------+------------------------------------
LAN_PHOP is used to detect loop | LAN_PHOP is not used
--------------------------------+------------------------------------
LAN_NHOP is always used		| LAN_NHOP is used only for unicast
				| session
--------------------------------+------------------------------------



K.Fujisawa               Expires August 1, 1997              [Page xx]