|
|
Title: Message
Okay, that's what
I thought. Just wanted to be sure.
Thanks
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 18 14:19:29 2003
12534 messages in chronological order
|
