|
|
Title: Message
Just
to clarify - more than one initiator node name existing in a single OS image is
strongly discouraged, and a poor implementation choice. We were prohibited
from making this a MUST NOT by the politics of IETFness...
:-)
Strongly discouraged. Poor
implementation choice.
We
jumped thru hoops designing the naming specification so that a single
iSCSI node name would be associated with a single OS image, for the purpose of
providing assurance that authorization and authentication policies (which are
highly resource consuming to construct and maintain) could be tied to the OS
image (via a single iSCSI initiator node name). That's the intent
of section 3.2.6 iSCSI Names and 9.1.2 iSCSI Name, ISID, TPGT Use. We'd
have made it a MUST except initiator vendors complained that they were
constrained by OS implementations - there was much discussion on this subject
on the reflector, it was pointed out that initiator vendors could ensure one
name per OS image thru configuration utilities, and the ISID was partitioned
to help assist in this process. FC caused all kinds of headaches
by not getting this association correctly implemented. Hopefully iSCSI
vendor solutions will heed the recommendations in the iSCSI protocol
specification. (end of soapbox :-)
Marjorie Krueger
Networked Storage
Architecture
Networked Storage Solutions
Hewlett-Packard
Marj,
You wrote
"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." Are you saying that it's *prohibited* for a computer
system to contain two or more iSCSI nodes if those nodes are acting as
initiators? Or is it simply discouraged?
---
David
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.
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.
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: Fri Apr 04 14:19:15 2003
12458 messages in chronological order
|
