|
|
Title: Message
Hi,
please see below.
The drawing in http://www.haifa.il.ibm.com/satran/ips/EddyQuicksall-iSCSI-in-diagrams/portal_groups.pdf has used the label
"network entity" in a manner inconsistent with the usage/intent in
the iSCSI protocol specification. A "network entity" is meant to
represent a computer system with ethernet egress points. As a computer
system, it can contain one iSCSI Node if it's an initiator, and one or more
iSCSI Nodes if it's a target. It's not correct to talk about
an iSCSI Node "accessing" a network entity, it's a containment
relationship.
[KAG] Yes, this is what confused me. Due to the
accessibility indicated to the storage nodes, according to the iSCSI
draft, I believe all of the Portals shown must belong to the same
"network entity". If the IP-Address values were added to the
Portals, along with the TCP port number, and all Portals, Portal Groups, and
Nodes were associated with one entity - then this figure would make sense
to me..
Portal tags must only be unique within the scope of
a single iSCSI target node, and are 16 bit integers. I don't see where
you get the UTF-8 out of the examples in (1)? I just see numbers, with
no mention of what format they must be exchanged in. Of course,
SendTargets commands are character strings, so the exchange of
TargetPortalGroupTags are integers represented in character format.
[KAG] The
string(i.e.UTF-8) values I mention were used in http://www.haifa.il.ibm.com/satran/ips/iSCSIConfigurationExamples.pdf on the iSCSI Architectural Model (2) and
iSCSI Architectural Model (3) pages. If these were 16 bit integers, then
it would make sense to me. I want to make sure that only
integer values are valid Portal Group Tag definitions. Yes, the
SendTargets command examples in the document did use integer values for
the Portal Group Tags, but the figures did
not.
If there was an entity-relationship model that
defined the iSCSI Architectural model, it would really
help.
Many
Thanks, Kevin
Marjorie Krueger
Networked Storage
Architecture
Networked Storage Solutions
Hewlett-Packard
I have been reviewing the iSCSI Model examples on http://www.haifa.il.ibm.com/satran/ips , and am trying to get them straight in my head. I was
hoping someone can help.
Network Entity: Can different entities provide access to the
same iSCSI Node? In 1) "iSCSI
Configuration Examples", http://www.haifa.il.ibm.com/satran/ips/iSCSIConfigurationExamples.pdf, the iSCSI Network Entity contains iSCSI Nodes and Network
Portals. Each Network Portal has
a TCP/IP network address. This limits
access to an iSCSI Node to one Entity,
and seems to agree with the architecture model in the iSCSI
draft. But 2) "Portal Groups", http://www.haifa.il.ibm.com/satran/ips/EddyQuicksall-iSCSI-in-diagrams/portal_groups.pdf, shows Network Entities that
provide access to, but do not contain, Network Portals and iSCSI
Nodes. These feed into Portal
Groups and then iSCSI Nodes.
This would mean multiple Entities can provide access
to the same iSCSI Node, and the
example (2) shows this. This seems to disagree with (1). I
tried but could not map this into the iSCSI draft architecture
model.
Portal Tags: Are they
uniquely defined using 16 bit
integers? In 1) "iSCSI
Configuration Examples" figures, the
Portal Tags are specified using UTF-8 characters. But the included Send Targets examples use integer
values. In 2) "Portal
Groups", integer values are used for defining Portal Tags.
This seems to agree with the
iSCSI draft.
Is there a UML/entity-relationship model for the iSCSI
architecture? This would help me a
lot. I am aware of one for the iSCSI MIB model, but not the
iSCSI Architecture.
Many
Regards, Kevin
Eddy,
Your point is exactly
correct!
The key point that
was being missed was the words at the bottom of the figure on page 40
which says "(within Network Entity,
not shown)".
When one has more
than one target (node) within a Network Entity, the portal (IP
Address:Port) can be part of any of the enclosed Targets. That is
because the path to the Target is defined by the portal (IP Address:Port)
and the Target Name. This is reasonable since nothing is ambiguous
about the description of the path that is intended.
Having said that, there is also NO
requirement that all portals need be connectable to all targets within the
Network Entity. This is an implementation decision. (Just
thought I would through that in.)
Your point is also supported by the figure in section 3.4 and
also the following example that describes what is returned by SendTargets
for a Network Entity that has two iSCSI targets:
- iSCSI Draft20 Appendix D : SendTargets
Operation
"The next example has two internal iSCSI targets, each
accessible via
two different ports with different IP addresses.
The following is
the text response:
TargetName=iqn.1993-11.com.example:diskarray.sn.8675309
TargetAddress=10.1.0.45:3000,1
TargetAddress=10.1.1.45:3000,2
TargetName=iqn.1993-11.com.example:diskarray.sn.1234567
TargetAddress=10.1.0.45:3000,1
TargetAddress=10.1.1.45:3000,2 "
.
.
John L. Hufferd
Senior Technical Staff
Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408)
256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office: (408)
997-6136, Cell: (408) 499-9702
Internet Address:
hufferd@us.ibm.com
|
| Eddy Quicksall
<eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu
04/01/2003 05:13 PM
|
To: Kevin Gibbons
<kgibbons@NishanSystems.com>, ips@ece.cmu.edu
cc:
Subject: RE: iSCSI: Portal
Group clarification
|
Yes.
Note however that a Network Portal
can belong to more than one Target Portal
Group but only one Target
Portal Group within a single node (which is a
target in this
context).
Eddy
-----Original Message-----
From: Kevin
Gibbons [mailto:kgibbons@NishanSystems.com]
Sent: Tuesday, April 01,
2003 6:39 PM
To: ips@ece.cmu.edu
Subject: iSCSI: Portal Group
clarification
Hi, I would like to make sure I understand the iSCSI
model correctly. Can
anyone confirm that a Portal, providing
access to a target, is part of
exactly one Portal Group at a time?
My reading of the spec indicates this
is true. That each
Portal has a 16 bit Portal Group tag. But I would like
to make
sure.
I believe that in iSCSI draft 20, it states that a Portal can
be part of
exactly one Portal Group. Please see page
15:
- Portal Groups: iSCSI supports multiple connections
within the same
session; some implementations will have the
ability to combine
connections in a session across multiple
Network Portals. A Portal
Group defines a set of Network Portals
within an iSCSI Network
Entity that collectively supports the
capability of coordinating a
session with connections spanning
these portals. Not all Network
Portals within a Portal Group
need participate in every session
connected through that Portal
Group. One or more Portal Groups may
provide access to an iSCSI
Node. Each Network Portal, as utilized by
a given iSCSI Node,
belongs to exactly one portal group within that
node.
Also,
please see page 39 for similar wording. There is also a
figure on
page 40:
----------------------------IP
Network---------------------
|
|
|
+----|---------------|-----+
+----|---------+
| +---------+ +---------+ |
| +---------+ |
| | Network | | Network | | | | Network
| |
| | Portal | | Portal
| | | | Portal | |
| +--|------+ +---------+ |
| +---------+ |
| |
| |
| |
|
| | Portal
| | | |
Portal |
| | Group
1 | | |
| Group 2 |
+--------------------------+
+--------------+
| |
|
+--------|---------------|--------------------|--------------------+
| |
|
|
|
| +----------------------------+
+-----------------------------+ |
| | iSCSI Session
(Target side)| | iSCSI Session (Target side) | |
| |
| |
|
|
| | (TSIH = 56)
| | (TSIH = 48)
| |
|
+----------------------------+ +-----------------------------+
|
|
|
|
iSCSI Target Node
|
|
(within Network Entity, not shown)
|
+------------------------------------------------------------------+
Please
let me know if I am in error.
Thanks very much!
Kevin
-------------------------------------------------
Kevin
Gibbons
Nishan Systems, Inc.
kgibbons@NishanSystems.com
(408)
519-3756
-------------------------------------------------
Home
Last updated: Thu Apr 03 19:19:15 2003
12449 messages in chronological order
|
