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]