INTERNET DRAFT Yukinori Goto draft-goto-sinp-00.txt Nara Institute of Science and Technology July 1995 Session Identity Notification Protocol (SINP) 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 document describes SINP (Session Identity Notification Protocol) specification. SINP provides information of Sessions of reserved flow in the transport layer and their corresponding VCs (Virtual Circuits) in datalink layer. 1.Introduction SINP is a protocol to correspond between QoSed flow the transport layer and VC of the datalink layer. On CSRs (Cell Switch Routers) [CONV-IP], SINP is used to connect appropriate VCs between adjacent datalink layer segments. SINP is also necessary with NHRP [NHRP], because the correspondence information is still necessary. SINP specification itself is simple because most of the VC setup and error handling job is assumed to be performed in the datalink layer. SINP is specified as a separate protocol than a field in transport layer reservation protocols [RSVP, ST2], because: Y. Goto Expires on January 5, 1996 [Page 1] INTERNET DRAFT SINP Specification July 1995 1) The correspondence should be given independent of the reservation protocols. 2) The natural signaling direction of the datalink layer may be different from that of the natural propagation direction of the transport layer reservation request. SINP message is carried in UDP with the port number of . 2. Terminology Session A Session is a transport layer flow which reserves resources. A Session is established between end points but resource are reserved in datalink layer segments or on routers on the way. A Session is identified by a Session ID in the transport layer and by VCID within each datalink layer segment. Session ID A Session ID is an identifier of a Session. Session ID depends on resource reservation protocol. VCID (Virtual Channel IDentifier) VCID is a 32 bit integer of a VC's datalink layer identifier shared between an adjacent pair (or more, if VCID is for datalink layer multicast) of routers. A unique VCID is assigned by a host or a router which initiates a signaling request and propagates it to adjacent router(s) through the signaling mechanism along with the MAC address of the originating the host or the router. It can simply be a sequence number. ATM ATM is datalink technology which guarantees the QoS of each VC. In ATM, signaling mechanism is provided to dynamically establish VCs. BHLI (Broadband High Layer Information) BHLI is a field of ATM signaling, which designates purpose of the VC in the upper layer. If the BHLI field can be made lengthy enough, Session identity can be directly described in the BHLI field and SINP is not necessary. But, BHLI length is limited to 8 bytes [ATM-SPEC3.0] which is, as shown in section 4.3, shorter than typical Session ID. With SINP, BHLI carries VCID. CSR (Cell Switch Router) CSR is a router which can relay cell by cell between ATM datalink layer segments [CONV-IP]. Y. Goto Expires on January 5, 1996 [Page 2] INTERNET DRAFT SINP Specification July 1995 3. SINP Protocol Specification 3.1 SINP Messages Structure SINP has two message types: NOTIFY and INQUIRY. [INQUIRY] An INQUIRY message is issued to query Session ID when a host or a router receives signaling with unknown VCID. An INQUIRY message has the following field. VCID [NOTIFY] A NOTIFY message is used to notify correspondence between Session ID and VCID. A NOTIFY message is first sent with a signaling initiation. If the NOTIFY message is lost in network, a host or a router which received the signaling responds with an INQUIRY message to request the NOTIFY message again. A NOTIFY message has the following fields. VCID Session ID 3.2 Datalink Layer Signaling and SINP Functional Specification When Host1 initiates signaling to set up a VC to Host2, SINP messages are exchanged as follows to map the transport layer Session ID and a datalink layer VCID. (1) At first, Host1 initiates signaling to set up a VC and sends a NOTIFY message to Host2. Host1 should keep the information of the NOTIFY message for 30 seconds after signaling. (2) If Host1 receives an INQUIRY message for a certain VCID from Host2, Host1 sends a NOTIFY message for the VCID to Host2. (3.1) If Host2 receives a NOTIFY message before signaling, Host2 should keep the information in the NOTIFY message for 30 seconds. Y. Goto Expires on January 5, 1996 [Page 3] INTERNET DRAFT SINP Specification July 1995 (3.2) If signaling to Host2 completes but the Host2 has not yet received a NOTIFY message on the VC, then Host2 should send an INQUIRY message. INQUIRY messages are sent 5 times with intervals of 5 seconds till a NOTIFY message is received. If no NOTIFY message is received within 30 seconds after the signaling completion, then Host2 should release the VC. (4) If the VC is disconnected before receiving a NOTIFY message, Host2 terminates sending INQUIRY messages. When Host2 receives a NOTIFY message, Host1 and Host2 are able to establish correspondence between the Session in the transport layer and the VC in the datalink layer. A VCID value for a VC should not be reused again for another VC within 5 minutes of the original VC termination. 3.3 SINP and Multicast For multicasting, SINP messages may be exchanged separately between a sender and individual receivers. With CATENET model, this will not cause scalability problem, because subnets are small. Y. Goto Expires on January 5, 1996 [Page 4] INTERNET DRAFT SINP Specification July 1995 3.4 Example An example of SINP sequence with RSVP[RSVP05] on ATM datalink is shown in Figure 1. Host CSR1 CSR2 CSR3 Host S1 / \ / \ / \ R1 \ / \ / \ / \ / +\------/-+ +\------/-+ +\------/-+ +\------/-+ | ATM | | ATM | | ATM | | ATM | +---------+ +---------+ +---------+ +---------+ RSVP Path RSVP Path RSVP Path RSVP Path ---------> ----------> ----------> ----------> RSVP Resv RSVP Resv <--------- <---------- RSVP Resv NOTIFY <---------- NOTIFY ----------> RSVP Resv ----->X <---------- VC signaling VC signaling ----------> VC signaling ----------> VC signaling ----------> ----------> INQUIRY \ <---------- INQUIRY \INQUIRY <---------- <-\-------- NOTIFY \ ----------> NOTIFY \ NOTIFY ----->X +----> INQUIRY NOTIFY <---------- ----------> NOTIFY -----------> Figure 1: An example of SINP messages exchange SINP sequences on ATM datalink segments. Y. Goto Expires on January 5, 1996 [Page 5] INTERNET DRAFT Specification July 1995 4 SINP Message Format 4.1 INQUIRY The format of an INQUIRY message is as follows: 0 7 8 15 16 23 24 31 +---------------+---------------+---------------+---------------+ | Version | M-type | //////////////////////////// | +---------------+---------------+---------------+---------------+ | VCID | +---------------+---------------+---------------+---------------+ Version Identifies SINP version number. Currently 1. M-Type Identifies SINP message type. 1 for INQUIRY. VCID A bigendean 32-bit field containing VCID. 4.2 NOTIFY The format of INQUIRY message is as follows: 0 7 8 15 16 23 24 31 +---------------+---------------+---------------+---------------+ | Version | M-type | Session ID Length (bytes) | +---------------+---------------+---------------+---------------+ | VCID | +---------------+---------------+---------------+---------------+ | | // Session ID // | | +---------------+---------------+---------------+---------------+ Version Identifies SINP version number. Currently 1. M-Type Identifies SINP message type. 2 for NOTIFY. Y. Goto Expires on January 5, 1996 [Page 6] INTERNET DRAFT SINP Specification July 1995 Session ID Length A 16-bit field containing the Session ID length in bytes. VCID A bigendean 32-bit field containing VCID. Session ID This field is contains variable length Session ID. 4.3 Session ID format 4.3.1 Session ID format for RSVP with IPv4 Session ID format for RSVP [RSVP05] with IPv4 is as follows: 0 7 8 15 16 23 24 31 +---------------+---------------+---------------+---------------+ | RP-type | C-Type | Style-ID | Protocol ID | +---------------+---------------+---------------+---------------+ | DestPort | SrcPort | +---------------+---------------+---------------+---------------+ // IP DestAddress // +---------------+---------------+---------------+---------------+ // IP SrcAddress // +---------------+---------------+---------------+---------------+ RP-type Identifies resource reservation protocol type. 1 for RSVP C-type Identifies object type. Values are defined in RSVP specification. [RSVP05] 1 = IPv4, 2 = IPv6, 3 = IPv6(using Flow Label) Style-ID Identifies the filter style. Values are defined in RSVP specification. 1 = WF (Wildcard-Filter Style) 2 = FF (Fixed-Filter Style) 3 = SE (Shared Explicit Style) Protocol ID The IP protocol Identifier, or zero to indicate a 'wildcard'. DestAddress The IP unicast or multicast destination address of the session. Y. Goto Expires on January 5, 1996 [Page 7] INTERNET DRAFT SINP Specification July 1995 SrcAddress The IP source address for sender host, or zero to indicate a 'wildcard'. DestPort The UDP/TCP destination port for the Session. Zero may be used to indicate a 'wildcard', i.e., any port. SrcPort The UDP/TCP source port for sender, or zero to indicate a 'wildcard', i.e., any port. When Sessions are reserved in transport layer using Fixed Filter Style or Shared Explicit Style, SrcAddress and SrcPort are not necessary. But NOTIFY message has these informations, because when using Fixed Filter Style or Shared Explicit Style, VCs are established each source hosts in datalink layer. 4.3.2 Session ID format for IPv5 Session ID format for IPv5 [ST2] is as follows: 0 7 8 15 16 23 24 31 +---------------+---------------+---------------+---------------+ | RP-type | ///////////// | Stream ID | +---------------+---------------+---------------+---------------+ | IP DestAddress | +---------------+---------------+---------------+---------------+ | IP SrcAddress | +---------------+---------------+---------------+---------------+ RP-type Identifies resource reservation protocol type. 2 for ST2. Stream ID Identifies stream ID. DestAddress The IP unicast or multicast destination address of the Session. SrcAddress The IP source address for a sender host of the Session. Y. Goto Expires on January 5, 1996 [Page 8] INTERNET DRAFT SINP Specification July 1995 5. Security Considerations To authenticate SINP messages in a unreliable datalink layer segment, IP security protocol [IPSEC] can be used. 6. References [CONV-IP] M. Ohta, et al., "Conventional IP over ATM", IETF Internet Draft (work in progress), draft-ohta-ip-over-atm-02.txt, March 1995. [NHRP] D. Katz, et al., "NBMA Next Hop Resolution Protocol (NHRP)", IETF Internet Draft (work in progress), draft-ietf-rolc-nhrp-04.txt, May 1995. [ST2] L. Delgrossi, et al., "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", IETF Internet Draft (work in progress), draft-ietf-st2-spec-04.txt, March 1995. [ATM-SPEC3.0] The ATM Forum, "ATM USER-NETWORK INTERFACE SPECIFICATION Version 3.0", PTR Prentice Hall, ISBN 0-13-225863-3, September 1993. [RSVP05] 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. [IPSEC] Randall Atkinson, "IP Authentication Header", IETF Internet Draft (work in progress), draft-ietf-ipsec-auth-02.txt, Mat 1995. 7. Acknowledgments The author is grateful to Dr. Masataka Ohta of Tokyo Institute of Technology, Dr. Masaki Hirabaru of NAIST, Mr. Keiiti Shima, Mr. Hisayoshi Shoyama, Mr. MASHMANI Manzoor Ahmed of NAIST, staffs and students of my laboratory and researchers of JAIN Consortium for their helpful comments and discussion. 8. Author's Address Yukinori Goto Graduate School of Information Science, Nara Institute of Science and Technology, Japan 8916-5 Takayama-cho, Ikoma city, Nara 630-01, Japan. Phone : +81-7437-9-9211 ext.5236 Email : yukino-g@is.aist-nara.ac.jp Y. Goto Expires on January 5, 1996 [Page 9]