Internet Draft INTERNET DRAFT Yukinori Goto draft-goto-sinp-01.txt Nara Institute of Science and Technology January 1996 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 of the transport layer and VC of ATM. A communication in the internet using ATM is guaranteed of QoS on the datalink layer with establishing a VC satisfied QoS's request between hosts. But, if a sender host, receiver host and intermediate router(s) do not understand to established a VC for which flow, then this flow's QoS is not guaranteed on upper layer. Thus SINP is used to notify information of the QoSed flow corresponding to the VC. 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 a host which is established a VC by ATM setup signal need to understand for guarantee of QoS that the VC is established for which flow. SINP specification itself is simple because most of the VC setup and error handling job is assumed to be performed in the datalink layer. Y. Goto Expires on July 5, 1996 [Page 1] INTERNET DRAFT SINP Specification January 1996 SINP is specified as a separate protocol than a field in transport layer reservation protocols [RSVP, ST2], because: 1) The correspondence between a VC and a flow should be given in- dependent 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. ATM ATM is datalink technology which guarantees the QoS of each VC. In ATM, signaling mechanism is provided to dynamically establish VCs. CSR (Cell Switch Router) CSR is a router which can relay cell by cell between ATM datalink layer segments [CONV-IP]. On the catenet model using CSR, a VC which is established for a flow through subnet is terminated in each intermediate CSR. Calling host This host (include router) sends ATM setup signaling for establishing VC. Called host This host (include router) receives ATM setup signaling for establishing VC. On the catenet model using CSR, since a VC is terminated in each intermediate CSR, therefore intermediate CSR is called host at the time of receiving ATM setup signal, and CSR is calling host at the time of sending ATM setup signal to establish a VC in that receiver direction. VCID (Virtual Channel IDentifier) VCID is a 32 bit integer of a VC's datalink layer identifier shared between adjacent pair of a calling host and a called host. A unique VCID is assigned by a calling host. It can simply be a sequence number. Y. Goto Expires on July 5, 1996 [Page 2] INTERNET DRAFT SINP Specification January 1996 BHLI (Broadband High Layer Information) BHLI is a field of ATM setup signal, 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.1] which is, as shown in section 4.3, shorter than typical Session ID. With SINP, BHLI carries VCID. 3. SINP Protocol Specification A calling host usually sends ATM setup signal for establishing VC from a calling host to a called host, then the called host can know that the VC is established for which flow with sending a Session ID put in BHLI field. But, since BHLI field has only 8bytes, therefore it is difficult to put a Session ID in BHLI field. At that time we use SINP to support BHLI field function. SINP send a message which include a Session ID corresponding to VCID put in BHLI field. 3.2 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. o. 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. o. VCID o. Session ID 3.2 Datalink Layer Signaling and SINP Functional Specification When a calling host initiates signaling to establish a VC to a called host, SINP messages are exchanged as follows to map the transport layer Session ID and a datalink layer VCID. (1) At first, calling host initiates signaling to establish a VC and sends a NOTIFY message to called host. The calling host should keep the information of the NOTIFY message for 30 Y. Goto Expires on July 5, 1996 [Page 3] INTERNET DRAFT SINP Specification January 1996 seconds after signaling. (2) If the calling host receives an INQUIRY message for a certain VCID from the called host, the calling host sends a NOTIFY message for the VCID to the called host. (3.1) If the called host receives a NOTIFY message before signaling, called host should keep the information in the NOTIFY message for 30 seconds. (3.2) If a VC is established between a calling host and a called host but the called host has not yet received a NOTIFY message on the VC, then the called host should send an INQUIRY message. The INQUIRY messages are sent 5 times with intervals of 5 seconds till the NOTIFY message is received. If a NOTIFY message can be received within 30 seconds after establishing the VC, then a called host should be torn down the VC. (4) If the VC is disconnected before receiving a NOTIFY message, called host terminates sending a INQUIRY message. When a called host receives a NOTIFY message, the calling host and the called host can 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 as soon as the original VC is torn down. 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 July 5, 1996 [Page 4] INTERNET DRAFT SINP Specification January 1996 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 sequences on ATM datalink segments. 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 | +---------------+---------------+---------------+---------------+ Y. Goto Expires on July 5, 1996 [Page 5] INTERNET DRAFT SINP Specification January 1996 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 NOTIFY 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. 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: Y. Goto Expires on July 5, 1996 [Page 6] INTERNET DRAFT SINP Specification January 1996 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. 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. Y. Goto Expires on July 5, 1996 [Page 7] INTERNET DRAFT SINP Specification January 1996 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. 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.1] The ATM Forum, "ATM USER-NETWORK INTERFACE SPECIFICATION Version 3.1", PTR Prentice Hall, ISBN 0-13-393828-X, 1995. [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. Y. Goto Expires on July 5, 1996 [Page 8] INTERNET DRAFT SINP Specification January 1996 [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 Araki's 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 July 5, 1996 [Page 9]