Internet DRAFT - draft-goto-sinp
draft-goto-sinp
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:09:28 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 02 Mar 1996 13:57:48 GMT
ETag: "2e69fd-483d-313853dc"
Accept-Ranges: bytes
Content-Length: 18493
Connection: close
Content-Type: text/plain
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 <to be assigned
by IANA>.
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]
