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]
